Re: usability and getting things done

[Seth Nickell <snickell stanford edu>]

> I certainly agree that the we should respect the decisions of the 
> UI team, and that people who want to participate, need to get involved
> in the UI team. There is a reason I applied the patch before
> sending out my mail, not after.

*wink, wink* - lets just say the rant wasn't directed in your direction.
Ironically, it was realizing that a patch had been integrated first and
fought later that made me realize how frustrating the other direction
was.

> That being said, I would like to point out that there are other
> considerations that need to factor into what we do other
> than making the perfect UI.
> 
>  A) Implementability in GNOME/GTK+
>  B) Degree that UI changes imply API changes
>
> I'm sure that the UI team takes these into consideration, but for A) and 
> B) in particular, it may quite difficult to tell how things
> play out until people look into actually implementing the changes.
> So, there will inevitably be some pushback.

Some of this can be alleviated by including interface considerations in
the initial stages of development. That is to say that at various points
in development remembering how a feature or api may affect user
interfaces (or better yet, involving a usability person in the initial
design, if only for a minute to consider these issues ;-) can avoid
conflicts between API & UI in the future.

Given that we are working on top of an existing platform there are
certainely times that things are just not possible, or are non-trivial,
such as having volume names for formatting partitions ;-) We recognize
this and roll with the punches.

> Also, as this thread demonstrates, talking about UI design is vastly
> more interesting than making UI decisions, so you have to expect
> chatter outside the structure of the UI team and move on.

I'm thrilled with discussion as long as the general consensus is "accept
patch first, discuss later" <hides>. Seriously, discussion is a great
way to get people to think more closely about UI issues in general.

>  C) Effort by application writers to switch to the new standard

We've tried very hard to keep this in mind. A number of us are hackers
and have a sense of what's hard and what's relatively easy. Given how
much could potentially be fixed in the GNOME interface, and that's its
not all feasible for 2.0 or 2.2, we've tried to focus on things that
both improve usability and are relative easy to change. Some things that
have fallen into this category are menu standardization, toolbars,
wording and appropriate use of controls.

> (*) I'm a little disturbed by the viewpoint that seemed to come up
> repeatedly in the conversation from certain parties that the target
> user:
> 
>  - Has never used a computer before
>  - Will not be mixing use GNOME applications with use of other
>    applications on the free desktop or with use of proprietary
>    operating systems.
>  - Will never use anything but GNOME in the future.

You're right, this is not reasonable. Its a very alluring idea and easy
to fall prey to. Its good to keep these users in mind, but they aren't
GNOMEs target audience - certainely not in the near to mid future.

> Our users:
 ^Some of

>  - *Will* be using Mozilla

Or Galeon, we actually have a viable pretty-much-as-full-featured
"alternative" here (alternative in quotes because its Mozilla-inside).

>  - *Will* be using OpenOffice

I still hope and think it would be a very important undertaking to try
and get a GNOME-native version of OpenOffice going. Its going to be a
major force in the Linux desktop world whether its a GNOME app or not,
so if we have the ability to make it a GNOME app..... I've looked at
this a little though its not clear to me yet whether this is feasible;
it looks possible but I can imagine many project killing snags (and it
would be a lot of work).

>  - *Will* be using KDE Apps

Yup.

>  - *Will* be using Windows
>
> Any decision that causes a significant UI deviation from what these
> environments do must be considered with great care.
> We can't do anything about how Windows works except look at it and
> recognize that UI interoperability with Windows is a valid concern,

Yup. And also will generally be coming from a Windows environment. I do
make one assumption that may be contentious in who I design for, and
that is I design for a user for whom GNOME will be their primary
environment. There are still lots of limits to how incompatible you can
become UI wise, but minor differences (I consider dialogue button
ordering to be a relatively minor difference) are not, I believe, a
major concern. People adapt to minor differences pretty easily as long
as its easy for them to quickly figure out which "mode" they're in (and
given that GNOME and Windows look very different, I don't think that
will be a problem). 

More problematic are interaction differences, for example copy and paste
(which Maciej points to as one of his most annoying problems when
switching between OS/X and GNOME and vice versa). Also it can be a big
problem if first time users have difficulty find things or figuring
things out because we have made a radically different choice (and
thereby decreasing the learnability of the interface).

I guess I'm saying that we have significant design freedom without
causing major problems for users that switch back and forth. That is to
say, that making sure users can happily learn and use both does *NOT*
mean we are constrained to looking like windows or even using the same
conventions. It means that when we do something differently we need to
make sure that it will be obvious and easy to figure out, and won't
cause confusion when users switch back and forth.

I think the difference between Macintosh and Windows is around the
acceptable interface gap we can sustain. Users in an academic
environment (well, at least here) migrate between the two all the time
and I've never really seen any problems that can be directly attributed
to this migration. Most users have a preferred environment in which they
are more comfortable, but they usually do pretty well using the other. A
small but significant percentage of people seem to avoid using the other
(suggesting that they don't know how to use it at all), but this isn't a
problems we really have to deal with. One of the benefits of our user
base is that they will be relatively technically savvy and probably
won't be afraid to try new computer things.

> but we need to be talking to people from the other open source
> projects and working on _common_ standards. Otherwise, no matter how
> beautiful and theoretically useable our UI is, we are doomed to UI
> failure.

I'm subscribed to the KDE usability list, though it doesn't look like
their usability project is very, um, agressive at the moment. I've been
toying with trying to see if we can work with them to establish common
interface conventions (if not exactly alike, given that we are working
with different widget systems etc, at least based on the same model).
Maybe we could broach the idea at ALS (assuming I find the time and a
way to get to oakland ;-)

-Seth