[HIG] Re: [Usability] UI guidelines and the libraries
- From: Seth Nickell <snickell stanford edu>
- To: Havoc Pennington <hp redhat com>
- Cc: usability gnome org, gnome-hackers gnome org, hig gnome org
- Subject: [HIG] Re: [Usability] UI guidelines and the libraries
- Date: 27 Nov 2001 16:15:56 -0800
> 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.
We definitely plan to make this implementable with GtkDialog, and
probably GtkMessageDialog (though we'll recommend that people not use
the stock button feature).
> 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
The reason I like including such points in the HIG is:
1) it gives app developers a flavour of where we are going, and maybe
will answer questions as to why we started doing something a particular
way
2) it means we apply more rigorous thinking to the problem than if we
consider them as theoretical features
We can file things as bug reports too, but I'm esp. interested in #2.
Its way too easy to do a half-ass job on something, which I don't feel
we've been doing for the HIG, so I'd like to carry the momentuum on to
designing things that require library changes.
> 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.
We really aren't doing the idealized UI, I mean the HIG hasn't gone off
the deep end in terms of implementability or we'd be saying "computer
should converse fluently with the user in their native language" or
something ;-) It would be great if you could point out things that
aren't easy to implement with stock libraries.
> 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 think the HIG should be a guide to "rewrites that would be good for
usability", at least to some extent, but we need to make it clear which
items are for app developers to implement today, and which are things
that will need changes in library gnome-foo.
-Seth
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]