RFC: UI design

[Benjamin Otte <otte gnome org>]

Hey,

Here's another discussion point I want people to think about before
the hackfest. This time it's not so much about API in a direct way but
more about a guiding principles for the kinds of APIs we want to
provide. The short question is this:

  Who gets to decide how an application looks?

This question is aimed at theming and the question of graphic
design[1] and not at intersection design[2]. The way I see it, there
is two extremes to this:
A) The application decides on the theme
Examples: The Web, Windows, Games
On the web, no page looks like any other page. If you for example
compare http://maps.google.com and http://www.openstreetmap.org/ one
of them looks greenish with a lot of rounded corners, the other
blueish with sharp corners; font sizes are different and so on. Every
application decides on its own how it wants to look and implements
that look.
B) The platform decides on the theme
Examples: GNOME 2, OS X, office suites
Here the platform decides how things look and it's discouraged to
deviate from the norm with custom designs. ITunes could win a Finder
look-alike contest, even though both are very different applications.
Even portable applications try to blend in. You will notice that
Firefox looks a lot more like a platform app on OS X and GNOME than it
does on Windows.
Of course, there are a lot of shades of gray inbetween. Phone
platforms have UI guidelines but applications often break it and games
don't look like Apple apps even on OS X. OTOH Microsoft applications
blend in quite well with the Windows design and all the Google web
pages look very similar, too.

There is no obvious answer for which way is better. But a lot of
things need to be done very differently depending on what way you
decide to implement. Some examples:
- switching themes
Using a completely different theme is a thing people like. With
platform themes, the N900 people were able to look quite different
from the GNOME on your desktop and various distributions could make
themselves stand out by using their own theme. All without changing
the applications. This would not have been possible with application
themes.
On the other hand, with application themes you can add features you
want quickly. If you want to merge a foreground and a background
button in a browser, you just add the styling to do that.[3] Or if you
want to make info messages blue, you just make them blue. However, if
the platform changes the theming from under you in a way you didn't
expect, that tuning might make your app look like crap. Say if the
theme decides backgrounds are blue now, your info messages are now
unreadable.
- complexity of theme design
Writing a CSS for an application is easy. If your application has no
toolbar, you don't need to style toolbars. And if you add toolbars
later, you just style them in the CSS then. On the other hand, you
have to write a CSS for every application. Writing a theme for a
platform is hard. The current Adwaita CSS for example is roughly 5000
lines, so it's slowly getting as large as the code for GtkTreeview.
But then, there's only one CSS file for all applications...
- application UI design
When developers design a UI for their application, the two ways
require very different approaches. If the application decides on the
theme, you can start with an image that's supposed to be a screenshot
of the app when it's done. And then you can go and tweak the
application's CSS until it matches. OTOH, if you're bound by the
platform theme, the output should look closer to a Glade file, because
you can't enforce pixel-exact alignment as you would expect in
screenshots. This however usually requires the platform to provide (a)
the editor to do these designs in and (b) a HIG so that application
designers know why thinks work the way they do.
- accessibility
We have high-contrast, low-contrast, large-print and various other
themes for people with visual disabilities. If applications theme
things, GTK needs to make sure that these features are available even
with custom themes. If there is platform themes, those people can just
switch to a platform-provided theme for that feature.
- form factors
If you want to have different themes for desktops and mobile devices,
this is easy on a platform theme. Just use a different one. But if
it's done on the application side, the application needs to cater to
those form factors explicitly. Whether this is a problem at all of
course depends on how GTK aims to provide portability between
different devices

Now why is this interesting for GTK? Because the public API we want to
expose and the cases we want to optimize the theming engine for differ
quite a bit between the two approaches. Some examples:
- gtk_settings_set (settings, "gtk-theme", "Adwaita")
This does not make sense in an application-themed world. It should not
be possible to change the theme.
- gtk_widget_set_style (button, "color: red; border: 0");
This does not make sense in a platform-themed world. It should not be
trivial to override the platform theme that easily.

It's also interesting because the GNOME 3 design efforts are currently
very focused on implementing pixel-exact screenshots in their
applications while the GTK API is still mostly unchanged from the
GNOME 2 design. And as a GTK developer I'm always torn between those
two sides. Currently I'm telling both sides "you can't have that"
whenever they want something, so they're equally unhappy. But I'd like
that to change in the future.

Benjamin


1: http://en.wikipedia.org/wiki/Graphic_design
2: http://en.wikipedia.org/wiki/Interaction_design
3: Hi Xan!