Re: [Usability] GIMP - CSDI and Toolbox

[Marek Peteraj <marpet naex sk>]

> 
> There's a Microsoft page that's sort of similar, defining "archetypes"
> for applications:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaero/html/apparchetypes.asp

Defining archetypes is a good idea. But let's look at the current
situation first.

The Gnome HiG as it is now has already influenced several non-gnome
applications. It's starting to get more and more obvious. The Gnome HiG
isn't a Gnome HiG anymore. It's also logical because there are parts of
the HiG which are not only desktop agnostic, i believe that they're also
toolkit agnostic. Even the Gimp-team is working hard on HiG-ifying.

The HiG has got a large and broad influence on lots of new gtk+/gnome
apps which (partly or entirely) belong to other domains than desktop
domain. 

So it might be benefitial if the gnome HiG became a freedesktop HiG.

That said, we should not only define archetypes, we should study the oss
applications with respect to their chosen window/document model. Most
oss desktop or desktop related applications will probably be typical
SDI/MDI applications.

Then there are applications which are hard to determine which group they
belong to - Do they fit SDI, MDI or CSDI model? I think Evolution fits
neither. Does it share the same model with other types of applications,
a model that hasn't been defined yet? Should the HiG encourage or
discourage already defined models for these kinds of apps?

One major flaw of the HiG is that it tends to prefer certain models and
encourage them. But each model has its logic that perfectly fits the
purpose of a given application. You might say - shouldn't bother us. But
it's got a deeper inpact on oss development. In fact, the Inkscape and
Passepartout UI is follwing HiG by picking SDI. (which i believe is
completely wrong as these types of applications usually target
professional users and tend to have considerably more complicated UIs
than desktop applications, thus CSDI would be the right UI)

It seems that the HiG is measuring each interface according to usability
studies with perfect newbies(those who haven't used a computer before or
rarely etc). Which is perfectly fine, but the HiG should not limit
itself only to those kinds of users.

Simplifying and unifying doesn't concern perfect newbies only. Such UIs
are not only easy to learn by newbies in general but also very efficient
to use for advanced users.

"MDI has several inherent usability problems, so its use is not
encouraged in new GNOME applications."

The tabbed MDI UI was the best thing i've seen so far. While it might be
not easy for perfect newbies, it makes it very convenient to manage
certain documents which share certain kind of properties(easy to adapt
to window size, like text documents). Tabs are a perfect way to take the
burden of managing multiple windows off the WM. It's easy to close,
regroup them, easy to see which document each tab refers to. Moreover,
documents are kept in one window, so by minimizing it you minimize the
whole application. How would you solve this problem with SDI where each
document represents each instance of one application? Suppose i have 3
documents open in abiword but i'd like to minimize abiword. Is it
possible?

I can't browse without tabs anymore. ;)

> So what we really need is to write a document that has diagrams of a
> "correct" app in each major archetype or pattern, and defines the EWMH
> window types and expected behaviors for the window manager for these.
> 
> Then we have a framework to fix the problem, because we can say "the
> GIMP is trying for app archetype Foo and has to change in XYZ ways to
> implement it properly" and then we can say "the WM is handling archetype
> Foo incorrectly in XYZ ways" and we can fix the WM.

But i think the problem is quite the opposite when it comes to Gimp. 

1. They have worked out a reference CSDI style UI
2. They are HiG-ifying areas which are compatible (desktop/toolkit
agnostic areas)
3. They have done usability studies picking gimp 1.2 users
http://www.relevantive.de/gimp/report/results_usabilitytest_05.04.html

That said, 

1. i think the HiG should reflect their work, not
vice-versa(re-thinking, perhaps reinventing the wheel ui-wise or
"forcing", telling gimp devs or devs of other apps that might take use
of the gimp CSDI UI model, to do this or that without any or not enough
knowledge of the target userbase).

2. As the gimp represents a reference CSDI design(which i think is no
surprise since it's been 7 years of CSDI Gimp), it's already possible to
start working on WM behaviour for CSDI.
 
> 
> The obvious archetype to start with is the basic "office" archetype most
> word processors use. This one probably won't work well for GIMP though,
> so one question is what _would_ work well for GIMP. Once we know that we
> can figure out how to translate it to EWMH and implement it in the WM.
> 
> Personally I don't think it's possible to get this right by bottom-up
> arguing about how to tweak the GIMP. We need to start with the global
> view of _all_ the major ways to organize an application and its windows.


I think we have an even more general problem with WM behaviour. The
solving of this issue would immenselly increase the comfort.

It's not only about archetypes and window/document models. In general,
the WM should treat each application as a whole. That doesn't only
concern gimp but also things like open dialogs in other applications.

Example, right now i've got evolution running, i open up the Settings
dialog. It shows up in the window list. If i click on a different app
and then on the setting dialog, only the settings dialog will
appear/move on top. That settings dialog is a part of evolution but now
refers to the other app which is underneath that dialog. 
If i click on evolution the settings dialog moves on top with evolution
which is fine. 

Now i open up ephy and click on the bookmark item in the menu. A
bookmark dialog shows up(in the window list aswell), this dialog is
completely loose - if i click ephy it gets on top but without that
dialog, if i click on that dialog then ephy doesn't get on top.

Then i click on preferences - this time, the dialog doesn't show up in
the menu bar at all thus a correct behaviour, each time i click on ephy
it gets on top with that dialog. 

Even if the dialog shows up as a separate window in the window list, the
WM doesn't seem to handle this in a reasonable way, it doesn't seem to
handle the application as _one_, althogh with several windows open.

The curent WM behaviour in general seems more like window = application,
while it's almost always window != application, even for MDI.

So to sum up - 3 different behaviours of child dialogs. I think WM
behaviour should be a part of the usability study.

Marek