[esp-r] Some thoughts on usability

[Axel Jacobs]

Dear all,

Although I don't actually use esp-r, I've had to play around with it
recently. I'm very excited about the recent development that have been
made with the interface, in particular the move to the Gtk toolkit.

My experiences are mostly based on the RADIANCE export/viewing module, so
this is what I shall confine myself too, although I've no doubt that other
modules exhibit a very similar behaviour.

Before I go any further, allow me to mention that I did try to find an esp-r
roadmap, or even Interface design guideline, but did not succeed. If such
documents exists, please forgive my ignorance, and kindly point me to
them.

The reason why I'm sitting down to write this in the first place is that
I'm just as aware as anybody else on this list how the usability and
interface of esp-r needs to be improved.
With more than ten years of almost exclusively using GNU/LINUX, I've come
to see an awful many changes and improvements in user interfaces. Although
I'm not a programmer, I appreciate how much time will be spent to port the
old X11 interface to GTK, and there is no point in doing something two or
three times, when you could get it right from the beginning. So here are
my two Pence...

Open a model

http://luminance.londonmet.ac.uk/pickup/model_open.png

If I click 'Help', then close the help windows, all buttons will then open
the same help window, rather than do what they're meant to do. Since this
is cleary a bug, allow me to just raise it and carry on.

The arrangement of the three radio buttons looks somewhat strange. Why
can't they be aligned in one column?

What does the 'default' tick box do?

'Cancel' should cancel the operation. The operation is to open a model, so
cancel should bring me back to the main menu, not anywhere else. Most
dialogs will actually ignore the 'cancel' option, and do something anyway,
with parameters that we don't know. Remember, we cancelled the operation.

Every dialog box should have a clearly highlighted default action, i.e.
the one that happens if I just hit Enter. In Gtk, this is usually done by
drawing a thicker border around the button.

We're in the exemplars menu now, and like to pick a daylight model

http://luminance.londonmet.ac.uk/pickup/model_with_photocells.png

Again. What does 'continue' do? 'Cancel' doesn't cancel. 'Open another
model' is redundant, since this is what should happen if I hit 'Cancel'.
Remember that 'Cancel' should cancel the operation. The operation in this
case is to open a model, NOT to pick WHICH model. This information (and
hence this dialog window) is only necessary to carry out the job.
Therefore, 'cancel' should bring me back to the menu that has 'open a
model' as one of the entries.

Fine. The model is loaded. Let's go look at it in RADIANCE. To even get
into the visual simulation menu, I have to answer FOUR pop-ups.

http://luminance.londonmet.ac.uk/pickup/visualisation_options_all.png

This brings me 'Scene purpose', which is 'External'. At last, we're ready
to rock-n-roll. But not before answering another SEVEN pop-up dialogs:

http://luminance.londonmet.ac.uk/pickup/external_images_all.png

To understand what is going wrong here, we need to get some advice from
people who know how a good, intuitive, user-friendly interface should be
designed. Wikipedia lists quite hand-full of different User Interface
Guidelines (HIGs):
http://en.wikipedia.org/wiki/Human_Interface_Guidelines

Since I am a GNOME user, and since the new esp-r uses the GTK toolkit,
which is what GNOME is based on, I'll choose this one for now. I also
happen to know that those guidelines are not just the result of some
abstract theoretical exercise, but were written after many, many hours of
real people spending real time in front of real software doing real tasks.

Before we get too heavy and actually read the document
(http://developer.gnome.org/projects/gup/hig/2.0/),
let's look here
http://gnomejournal.org/article/44/three-simple-tips-for-interface-design-you-should-know
for Three Simple Tips for Interface Design You Should Know.

We learn that the three most important points in interface design are:
(1) Get your Window Types Straight
(2) Order Buttons and Label them Appropriately
(3) Layout with Spacing and Alignment

Looking into point (1), we find that there are five types of secondary
windows:
    * Utility Windows
    * Dialogs
    * Alerts
    * Progress Windows
    * Assistants

"A dialog provides an exchange of information, or dialog, between the user
and the application. Use a dialog to obtain additional information from the
user that is needed to carry out a particular command or task."
(http://developer.gnome.org/projects/gup/hig/2.0/windows-dialog.html)

To me, this seems the right one to choose for the visualisation jobbie.
That's the four-pop-up one. We need to know:
- type of visualisation (wireframe/rendered)
  This is a radio button or (better) a drop-down list:
  http://developer.gnome.org/projects/gup/hig/2.0/controls-option-menus.html
- monitor type (bw/greyscale/colour)
  As above, but: Is this still necessary?
- config file
  Text entry box (or file picker)
- Use RADIANCE default settings or not
  (radio buttons), or just assume defaults, then let user fiddle with the
  options later on.

All those options could/should be displayed in ONE dialog window.

I understand that the esp-r GUI is very much in a state of flux at the
moment, and have  deliberately only looked at the dialog windows, simply
because they are already new. The main interface is being re-written, so
no comment on it yet.

Anyhow, what I would like suggest is to not leave the GUI to its own
evolution, but rather draft up some HIGs, so that the esp-r interface (the
single most important aspect from an end-user's point of view that needs
improving) will end up a lot better than the old one, if not perfect.

Here are some other points that I would just like to throw in:

- Internationalzation (i18n). The GTK toolkit provides for translating the
interface into any number of languages. This would not mean extra support
for ESRU. All that needs to be provided for is the possibility to do this
in the first place, all translations that are submitted would then just be
hosted by ESRU, but supported by people in Italy, France, etc. I
understand that you have no desire to trouble-shoot screenshots in Greek,
but if it is possible to change the language on-the-fly, there would be no
problem.

- Use an external, configurable editor for output that is longer than a
few lines. The little window below the wireframe preview is not really
appropriate for long output. Most users will be used to their Favourite
Editor, and most modern editors will allow you to open a file read-only.

- If possible, separate the simulation engine from the GUI. Re-writing for
GTK3 will be a lot easier ;-)

Well, this is all for now. I sincerely hope you don't see this as a rant,
but rather as some feedback from an end-user (who isn't actually an
end-user).

Cheers

Axel