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

[Bill Bell]

Dave <dheller at gmail.com> wrote, in part:

> I really like the angel that you are trying to take here.

Thank you, Dave. I appreciate that.

> 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. 

Absolutely. I don't mean to be merely glib when I say that flow (among other aspects of a UI) 
is part of the _how_ that designers can suggest and thereby fit a communications paradigm 
that works in many open source project teams.

I, like many other developers, have spent many tiring hours trying to intuit what might be 
suitable for users because no-one is available who is especially interested in the UI.

(Incidentally this happened recently. I was working with the wxPython GUI framework and it 
has two kinds of calendar widgets, neither of which is data aware. Probably because neither 
is data aware neither deals with the question of how best to represent a null date value for 
the user. A small part of my overall task was to make one of these controls data-aware and it 
was inevitable that I would have to adapt it to be able to represent null values, and to be able 
to morph between two states, either null or representing a valid date.)

Where would an OS programmer go for advice about something like this? Having someone 
on the project who is able to suggest widgets certainly without necessarily having written all 
of the underlying code would be invaluable.
 
> 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. 

The first part of this appears to imply the use of the traditional "waterfall" model in which all 
design work, for instance, precedes implementation. This kind of project design might not 
work well for projects entailing significant risks of various kinds, and in fact when many 
software projects begin the participants share only a limited understanding of what the 
product should do or why. (This is of course one of the many reasons for the high failure rate 
in software development.) Many OS projects are more like exploration or experimentation. 
Which is to say that one or two people have been inspired to try something, and they want to 
see how far they can push it. 

My question at this point would be, why couldn't groups of UI designers and programmers 
form OS projects in which they attempt to push the envelope?

> I do think though that OSS projects themselves need to change from the
> ground up.

I agree, assuming that I understand you. To the extent that OS projects are amenable to 
control at all they need to be designed in such a way that the many sources of risk involved--
including those associated with the UI--are effectively minimised.

I'm not going to hold my breath.

Bill