Re: Three Point Zero - Idea Mockups

[Havoc Pennington <hp redhat com>]

Hi,

You kind of replied here as if you were arguing, but I think what you
said is consistent with what I said ;-) so just checking.

On Thu, 2005-05-26 at 10:58 -0400, Nat Friedman wrote:
> On Thu, 2005-05-26 at 10:28 -0400, Havoc Pennington wrote:
> 
> > I think for us to jump "product generations" the branch/fork approach is
> > probably required and you really need a structural change in "what the
> > product _is_" to justify it.
> 
> Another way to look at this which I haven't even seen considered is,
> "What do we need to do to create a really exciting, useful, and usable
> desktop environment that people love to use?"

Again, I'm not saying we should take this "structural change in what the
thing is for users" path for GNOME - though I think Maemo and Workplace
show that there are alternate paths of this nature, and I see no reason
to shoot down people who want to explore them. I do think it would be a
mistake to explore these by changing GNOME "in place" because it
inherently hoses the existing userbase. (Trying to explain this is how I
ended up on Slashdot a while back...)

What I'm saying is that it's the only kind of change that would justify
the way people seem to be thinking about GNOME 3 (as a "big break").
There's no way we should break the hell out of stuff just to rewrite
everything and end up with more or less the same product we already have
from an end user perspective.

Owen's argument as I take it is that the sort of changes you just listed
in your mail could simply be labeled GNOME 3. In other words we should
be dropping this "big break" concept from GNOME 3 planning.

> My point is just that there's plenty of cool and productive work for us
> to do that doesn't involve rethinking everything, breaking ABI, or doing
> something totally and fundamentally original in computing.  We are
> already doing something totally and fundamentally original in computer
> software -- we're building a completely free desktop environment upon
> which anyone can try out their craziest ideas, and we're trying to make
> it useful and exciting to regular people.  

I'm with you on this, it's what I meant by:

 - we should have a great ongoing vision for GNOME itself and 
   continuing cool progress through GNOME 3, 4, 5

Although, I would disagree a bit with your emphasis. Usability testing
is important, but the really important focus is on interaction design:
what can users do. That's what Apple focuses on. They don't focus on HIG
type of stuff - in part because they probably get it 95% right in the
first place and just mop up some loose ends with usability testing.

Taking a couple of your usability testing examples, I'd argue a designer
would not have specified the "Send/Receive" operation in Evolution in
the first place, they would have made it an automatic background
operation that was aware of network connection status. And as for not
knowing that Evolution was Email... the GNOME design team has long
advocated calling the menu item Email, and on my system it is in fact
called that ;-)

Designers screw up of course and I look at usability testing as a QA
process to catch those mistakes. Valuable, but not a substitute for
selecting the right operations that the software supports in the first
place. You wouldn't fix a software architecture in the QA phase and you
can't fix a design in the QA phase either. In both cases if the big
picture is all wrong the QA phase is too late.

The first-order problem then is how do we get quality design up front,
before the code is written. Quality design is about _what the software
does_, not HIG-level cosmetics. i.e. "is there a send-receive operation"
not "what is the send-receive button labeled." That's why design has to
come up front.

I do agree that originality is overhyped, but still "enabling people to
do new things" is important. When "new things" is with respect to the
state of the art, we're talking originality; when "new things" is with
respect to current GNOME, we don't necessarily have to be original.

Coming back to the adjectives you used - exciting, useful, usable - I
would encourage a focus on what people can do with the software, not how
easy it is to do it. How easy it is matters, but not as much as having
something useful to do in the first place ;-)

What this focus means concretely is probably "applications,
applications, applications" - it's way more interesting to add a chat
app than it is to make the panel 10% more usable.

Havoc