Re: UI Guidelines -- What I'm doing

[Dan Mueth <dan eazel com>]

On Tue, 1 May 2001, Joakim Ziegler wrote:

> Personally, I don't think we'll be able to have the UI guidelines ready for
> GNOME 2.0. Isn't the freeze date some time in July? That's a very, very
> short time for writing (essentially from scratch) something that's a
> book-sized document.

Exactly.  That is why we need to plan our work more carefully and try to
figure out what we can get done in the GNOME 2.0 time frame.  We can
definitely write certain key parts of the Guidelines in this time frame,
and have a very significant effect on GNOME 2.0.

My point was that we need to carefully consider exactly what we work we do
and how we should proceed so that we can get the most usable GNOME 2.0
possible.

> Probably other parts of the GUP could interact more with the 2.0 release,
> but I'm unconvinced that it's useful to try to sync the guidelines up with
> it very much. In the best case, we'll ahve a small document that might help
> a bit, in the worst case, we'll have something that's incomplete and
> underdeveloped, and might be plain wrong in many respects. 

The way we do this is to focus on key parts first.  We can stabalize some
sections in time for GNOME 2.0, but we probably can't write up the full
Guidelines in time.

I suggest we identify the biggest usability and UI problem spots and then
come up with a plan which focusses on solving these problem spots for the
GNOME 2.0 release.  

Part of this, as I envision it, will be to write certain sorts of UI
Guidelines for GNOME 2.0.  This would probably be a GNOME UI Guideline
document with only certain sections one may want in the final 1.0
document, or it may be a set of mini Guideline documents on various
topics.

> I'd like to see the UI guidelines be pretty definitive and not change
> a huge amount after a 1.0 release.

At the risk of repeating myself... 

I like the GNOME development platform model instead.  The whole GNOME 1.x
development platform was not released at once, it was released as pieces
at different times.  However, once a piece is released it should not be
modified in any backwards-incompatible way until the next major release
cycle.  I think this is the most functional way to do things.  It gets the
product to its consumer as soon as early as possible, but without the risk
of breaking compatibility.

Dan