[Scribus] User-interface design [was" Thus is has been with Scribus."]

[Hedley Finger]

The example proffered below by Peter Nermander is a straw man.

>On Mon, 4 Feb 2008 14:28:29 +0100 (CET)
>"Peter Nermander" <peter.nermander at abc.se> wrote:
>
> > Imagine working in a text editor where you would always have to first
> > choose "select" in a menu to be able to select text. Then choose "copy" in
> > a menu, move the cursor and select "paste" in a menu. And finally go back
> > to the selection, select it (using that same menu again, and trying to
> > remember how much you selected before) and the choose "delete" in a menu.
> > Is that user friendly?

Keyboard shortcuts and menus are not mutually exclusive.  Yes, you 
can have both (fancy that).  And a well-designed GUI will teach you 
what the keyboard shortcuts are so that you can progress from novice 
to intermediate to expert:  File > Save (Ctrl-s), Edit > Copy 
(Ctrl-c).  It's sort of handy if the keyboard shortcuts are mnemonic 
wherever possible.  In FrameMaker you have Esc e c (meaning e=edit, 
c=copy), etc.

Another rule of thumb is that all context menus should also be 
available from the main menubar and menus.  A program whose name I 
forget also used to pop up little messages like: "I see you are using 
Edit > Copy frequently.  Do you know that pressing Ctrl-c also copies 
the selection?"  How friendly!

The people who argue that the Scribus GUI is fine as it is, generally 
argue that once people learn a GUI then it doesn't matter how it is 
designed.  One would therefore expect that especial care had been 
taken to ensure that it was easy to learn, right?  Would anybody like 
to argue that this is the case?  But the conundrum for GUI designers 
is that you need to somehow cater for both novice and expert, not 
putting obstacles in the way of the former but not hampering the 
latter with clutter.  That's why so many GUIs now allow you to 
customise them.  And that's why it is important for a GUI to teach 
shortcuts.  That way, all functions should be available by the 
(possibly inefficient) menus so the user can gradually progress to 
quicker ways of achieving their goals.

The extreme example is the original Emacs, entirely keyboard and 
command driven, which placed enormous demands on your memory but was 
very efficient "once you had learned its UI".  But it took years to 
learn from very bad documentation that could not be searched and had 
no index.  Anyone brave enough to propose an entirely keyboard driven Scribus?

Pip, pip!
Hedley


--
Hedley Stewart Finger
28 Regent Street   Camberwell VIC 3124   Australia
Tel. +61 3 9809 1229   Mobile +61 412 461 558,
E-mail <mailto:hfinger at handholding.com.au>