I have a problem

[Benjamin Otte <otte gnome org>]

Hey,

I have a problem. I've not talked about this a lot, but it has crept
up in my work of trying to improve GTK. It's the problem with how I
see developers in GNOME currently approach developing the user
interfaces for their applications. I have a feeling it goes something
like this:
- Someone comes up with mockup imagery.
- Someone tries to make an implementation matches these mockups as
exactly as possible.

What these mockups usually do is present a visual design that cannot
be achieved with the current GTK widgets. So what happens is the
developers do is start writing a lot of widgets and trying to get them
included in GTK (examples for that are GEditOverlay[1] or
GtkSwitch[2]). And I'm somewhat lost what to do then. Should I say yes
because it's a good widget to use in general? Should I say no, because
it shouldn't be used? What are the features and behaviors I have to
look out for in those widgets so they end up in a consistent toolkit?

Is there any advice on the wikis or mailing lists or elsewhere[2]
about what the overarching design rules are for GNOME3 that I should
look for? Because whenever someone comes with "it looks like this on
the mockups" I ask "why does it look like this and not like that?" and
the only answer I get is "dunno".
I usually try to understand why the current widgets don't achieve the
goal the design is trying to achieve and if we should modify the
widgets to include the needed features. Or do the existing widgets not
work for what we want to achieve and we should deprecate them?

I'll now going to use a GNOME Contacts mockup[4] to list a few
examples for cases where I'm struggling with what to say. They are by
no means meant personal, neither towards the developer implementing
them, nor towards the designer who did the mockups. It is just the
last example of where I found this problem, so it's freshest in my
mind.
So let's go from top left to bottom right:

* The text says "Highlight and symbolic icon on hover indicates that
the item is actionable"
So far we've not had icons anywhere in GTK that only show up on hover.
Is displaying symbolic icons on hover a new UI paradigm that we want
to promote? Should space for those icons generally be reserved in
advance or should we reflow when they become visible? Or should they
be drawn on top of existing content? Do we expect to use this paradigm
in other places (menuitems or buttons come to mind) or is this just
for contacts?

* The text says "only the content gets scrolled"
This looks to me like there's this new idea of putting more static
content into scrollable areas to allow the scrollbars to be wider. Now
we obviously do not have a scrollable widget to embed static content,
the only widgets that do that have special code for it (treeview
headers for example). Do we expect this to happen more often and
should we have a widget? Do we expect this to transition to other
scrolling interfaces like panning on touchscreens or Ubuntu's new
scrollbars? How should this static content interact with vertical
scrollbars? Was the designer doing this aware of the fact that we
cannot currently do fade-in/out of adjacent widgets, so the nice fade
effect in the mockup is almost impossible to write in a generic way?
Even if this was possible, how would this interact with the scrolling
content? Should the content be scrollable until it's no longer below
the fade effect or should it not be possible to make the topmost N
pixels of the scrolling content come out from under the fade? And how
should this interface interact with widgets with non-scrollable
content like treeview headers?

* There's button(s) that say  ( Notes | Edit )
How are these buttons different from notebooks? Is it just visually
different or is it a completely different interaction? Because from
the interaction described it looks like a notebook to me, just with a
different UI. But I can't really pinpoint what's missing from
GtkNotebook for this. Also, should we try to get rid of notebooks and
replace it with buttons like these in other places?

* The [ More v ] button
So there's this button that pops up a menu, so it's somewhere between
a menubar, a combobox and a button. Now, how should this behave? How
should it look?

Wow, that's already long. I'll leave it at that. I think it gives
examples for everything I want to say already. Just one more example
because I've been encountering it in a lot of places:

* Overlays/Popups
It seems a lot of designs overlay things on top of existing widgets.
It seems a bit like the modern version of dialogs. GEditOverlay is an
example for this, the contacts example[4] has it for its [ More v ]
menu and when showing the "Embedded" image. The menus design page[5]
is an obvious example. What is the interaction for those overlays and
popups? Is it ok if there are multiple of those? Are they modal?
Should a user be able to get rid of them to get access to the content
they overlap? How? What's the intended interaction with them? Are they
focusable? Clickable? Draggable? Do they allow richer interactions,
such as dragging to/from/on them or using the mouse wheel? Can these
popups have popups themselves? When they pop up, where do they pop up,
and in what direction? Are they constrained to the window they pop up
from, or do they possible overlap the window?

I'm pretty sure there's more than one interaction in this case
(GEditOverlay is very different from menus), but I'd like to get ideas
about this, so that I can give the people working on this a useful
code review, especially when deciding on the API we have to support
for the next years. Most importantly I want to come up with APIs that
make developers not involved in GNOME and not having read the HIGs
that we have, design beautiful interfaces by default and have them
work hard should they insist on something ugly. But that requires me
knowing what I need to look for.

Thanks,
Benjamin


1: https://bugzilla.gnome.org/show_bug.cgi?id=646841
2: https://bugzilla.gnome.org/show_bug.cgi?id=634987
3: http://gitorious.org/gnome-design (why is that not in GNOME git btw?)
4: http://imgpaste.com/i/ogbjx.png
5: https://live.gnome.org/Design/Whiteboards/Menus#Mega_Menu.21.21.21