[Sigia-l] Open Source Usability -- curable?

[Dave]

On Thu, 22 Jul 2004 12:08:19 -0400, Bill Bell
<bill-bell at bill-bell.hamilton.on.ca> wrote:
> I would suggest that most of the discourse I in which I participate on open source lists has to
> do with _how_ something can be done or achieved. We want to know what established
> patterns might be applicable and which to avoid. I suspect that UI people willing to offer ideas
> about _how_ users are known to prefer to approach various tasks would be very welcome on
> many open source projects. Senior software people _know_ that UI design is difficult--if only
> because we have become accustomed to coping with so many really bad designs ourselves.
> We also know that all unifying high-level concepts are extremely valuable if not essential for
> making projects progress faster and better.

HI Bill, I really like the angel that you are trying to take here.
I think the flaw for me is the assumption on what UCD is. I think
there is a practice of UI Design that does what you described (if I'm
understanding it) where buy a UI designer creates a vocabularly of
widgets that developers get to pick and choose and put on screens to
fulfill requirements. I think this is a great approach when developing
a platform. I tried to use this approach when I was designing the
web-based platform at DCTM. But when it came time to put that platform
into use to develop solutions based on it The design needed to do a
lot more than put a puzzle together. The flow between screens was as
important as the layout of the widgets on the screens and often the
widgets that I originally designed for the platform did not work in
this new context.

I bring this up because there are a few levels of UCD that we need to
consider. So far we have concentrated on Usability. Usability being
the success rate of completing tasks. But what hasn't been discussed
are the other issues of User Experience--usefulness and desireability
(or what I call engagement). To do these, requires a level of research
that goes way before the  actual design of widgets, let alone the
design of whole solutions.

How can this be incorporated into a process that does not include the
why or the what? as I described in my earlier suggestion.

Some have suggested it is just about making relationships with lead
developers. I think this is a great idea. But I do think that it is
limited.

I do think though that OSS projects themselves need to change from the
ground up. So I wouldn't expect Gnome to change very soon, but if we
wanted to create an OSS project for a type of software product, we
could attempt to set it up in a way that meets both developer and
designer's needs.

-- dave