Re: I have a problem

[Emmanuele Bassi <ebassi gmail com>]

hi Benjamin;

On 28 May 2011 22:01, Benjamin Otte <otte gnome org> wrote:
> 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?

ignoring those two cases (I'll go back to them in a jiffy) I think the rule of
thumb has been to include a widget in the toolkit if the design team has
been using a UI visual element in different mockups for different
components - i.e. if a widget is part of the visual grammar used to create
the user interface.

for GtkSwitch, the switch widget satisfied that requirement: every single
hardware-related control panel item was designed with that particular UI
visual element, and the design team also wanted to have that element in
other applications outside of the control center domain. it was a tad hurried
along, and since the interface guidelines haven't been updated along for the
3.0 UI because of its work in progress/point-zero release status, people
started abusing it a bit.

the GeditOverlay is another instance: it's used in different
applications (Gedit,
Epiphany, Nautilus) to implement the overlay message box/status area; it
is a common element of the visual grammar for 3.0 applications.

> 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".

the designers hold the keys for the visual (and interaction) aspect. the
wiki and the git repository is a place to hold the reference, but you'll
have to talk to the designers if you want explanations.

> 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 think the visual styling is still a work in progress, and we should look at
potentially fixing existing widgets - but if the end result is either
a frankenstein
monster of widget that can do four different styles (and I'm looking at you,
GtkComboBox) and makes maintainership a misery, then we should probably
looking at deprecating old widgets and introducing new widgets for the new
visual designs.

[snip]

these questions are important, and I think the design team should work
alongside the toolkit team to provide an answer; sadly, it's not as easy as
it would be in an office - just get up, cross the room, and ask one of the
design authors to comment on the behaviour, in my case. I also don't know
whether the design team is all subscribed to the usability@ list, as they
don't use emails to discuss. the #gnome-design channel is probably a
better option, since Google killed Wave.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/