Re: [Usability] UI guidelines and the libraries

[Maciej Stachowiak <mjs noisehavoc org>]

On 27Nov2001 03:11PM (-0500), Havoc Pennington wrote:
> 
> Hi,
> 
> A point about the HIG - it needs to follow the Mac guidelines in one
> important respect, which is that the guidelines should be easy to
> implement using the stock libraries. In fact I think it would be a
> good idea to go ahead and have notes in the HIG on how to implement
> each of the suggestions in code, when it might not be obvious.
> 
> It's fine to also have a paragraph about the ideal situation and/or
> planned library changes, but we need to be telling people what they
> can reasonably do in apps today.
> 
> To try to make the point concrete, it's OK if implementing the HIG
> requires a funky hack or two, like gtk_label_set_markup
> (dialog->label), but it's not OK if implementing the HIG requires
> rolling dialogs from scratch and not using GtkDialog. If every app is
> rolling from scratch that just screws our long-term maintainability,
> and will tend to break a lot of other details (such as setting the
> semantic type of dialogs, or whatever) in the process of matching what
> the HIG says.
> 
> If GtkDialog isn't the perfect thing, then tough; we didn't get the
> perfect thing in time for 2.0, we'll get it in 2.2. But the HIG should
> document what people can do today. It can have a footnote about the
> 2.2 plan, with a reference to the GTK bug number that will enable it,
> of course.

Can you be more specific about what you mean? As far as I know, all of
the HIG's recommendations can be implemented with GtkDialog. If there
are any that can't be, we would probably want to revise the HIG.

The recommendations for alerts can't be implemented with
GtkMessageDialog. But that's just thin syntactic sugar over GtkDialog,
right?

I agree with your point generally (see below). But I think the cost of
people rolling their own alerts out of GtkDialog is outweighed by the
usability benefit of meaningful button labels. Developers could even
use a cut & pasted utility class, or one in a non-platform utility
library.
 
> I understand Maciej's point about bottom-up design; but I think my
> point here stands regardless. If the HIG team files a bug for 2.2,
> then we will have a top-down design for 2.2. And in fact many parts of
> GTK 2 were designed with the UI in mind already. But reality requires
> that the HIG document what can be done today without creating
> unmaintainable code - the HIG should not document an idealized UI, but
> the UI GNOME can reasonably have using our current platform.
> 
> If the HIG isn't done with this in mind, it's an academic exercise,
> not a useful product. HIG is a guide to using the GNOME platform to
> make usable apps, not a guide to rewriting the GNOME platform.

I agree on that point. In fact, I've discussed this with other HIG
authors before, where they wanted to recommend things that would
effectively require changes to Gtk to implement. My suggestion at the
time was to talk to the Gtk+ developers first.  I would like the HIG
to ship as part of the GNOME 2.0 developer documentation, and to do
that, it must stay within the realm of reality.

I think it would be really helpful if you pointed out any spots in the
HIG that are not practically implementable, since you probably know
way more about the toolkit than most HIG contributors. In fact, one
reason this early draft is going out for wider review is for people to
point out problems like this.

Regards,

Maciej