[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-look
Subject: Comments on GUI Standards
From: Alistair <abayley () bigfoot ! com>
Date: 1999-09-24 23:10:56
[Download RAW message or body]
Reply to: abayley@bigfoot.com
<introduction>
I've reviewed the GUI Stds and I have some comments. I've also browsed the
mailing list archives so I hope I'm not going over old ground. So here's my 2
cents worth...
Having re-read this it's a bit large... oh well. Perhaps there's a more
appropriate medium in which to publish this.
Here's a summary:
- Resources
- GUI Standards Web Page
- Save settings
- Colours
- Comparison of vendor GUIs
- MDI vs SDI; Quit + Close
- Application classification
- Dialogs
<body>
- Resources
------------------------------------
www.iarchitect.com
- Check out the halls of fame and shame.
www.useit.com
- Jacob Nielsen's website.
www.asktog.com
- Excellent articles on web page and app design.
- check out "Quiz designed to give you Fitts";
- this explains why Mac-style menus are better
- (among other things).
Also, Alan Cooper's book "About Face" goes into great detail about MSWindows
design guidelines. I think this may help the standards writers provide
explanations/rationale for the guidelines (where they match MS Windows ones).
Unfortunately I don't have this book.
- GUI Standards Web Page
------------------------------------
I vaguely recall some request to redesign these pages. What changes did you
have in mind ? I think the current design is good (simple and effective), but
I'd like to see more content.
- Save settings
------------------------------------
There's nothing in the standards about saving application settings. Even simple
things such as window position and size should be saved.
Under the Options menu section there's the quote
"Please don't save options automatically! Let the user decide if he is satisfied
with current configuration of the options."
Call me old-fashioned, but if the user has just clicked OK, Apply, or Cancel
on the options dialog, then they have ALREADY DECIDED whether or not to keep
the current application configuration. And I'll bet you that NO application
will prompt you as it's closing "You have made changes to the application
settings. Do you want to save them ?".
The issue of forcing users to explicitly save changes is quite a minefield. I
recall an article where the author argued that users should never have to save
explicitly. He described novice users with a word processor. When they closed
their document, they where prompted with the confirmation dialog: "Do you want
to save changes ?". Some of them thought that the software had made changes
to the document and was asking for permission to apply them (but of couse they
had no idea what these changes were). The novice users hadn't realised that
there were effectively two version of the document: the one on disk, and the
one they were editing (essentially in memory).
The author essentially argued that changes should be savd as they are made.
Combined with sophisticated Undo and Revision mechanisms, I think this is
an excellent approach.
- Colours
------------------------------------
There should be a section defining how colours are used. Fro example, apps
should use the text, background and 3D object colours defined by the user.
Also, fonts chosen by the user should be used.
Some guidelines or heuristics on the (over) use of colour in apps should also
be present.
- Comparison of vendor GUIs
------------------------------------
Where we have contentious behaviour, could we please have a comparison of the
KDE approach against other well-known GUIs ? I've observed the ongoing
Quit/Close/Exit MDI/SDI discussion, and, while I'm not happy with the state of
the interface standards currently published, I don't feel that I can criticise
with authority (but I'll give it a go anyway; see below) until I've had a chance
to evaluate the approach of various GUIs: namely, MS Windows, Mac, BeOS, OS/2,
Nextstep. Not all of us conveniently have each of these OS's installed on our
machines :-)
My own GUI experience is Windows-based, and hence Windows-biased (not because I
think it's best; simply because it's mostly what I know). We all know (yes we
do, don't we ?) that MS flogged a lot of Apple's GUI ideas and implemented them
poorly in Windows (in some cases they seem to have copied the end result while
ignoring the motivation).
Apple are well known for performing extensive HCI studies to imporove their
designs. In that light, I would love to see a comparison of the Mac and Windows
approaches. I've noticed that KDE supports Mac-style menus (at the top of the
screen); it's been proved that these are much faster to access than menus
contained in the window.
Also of use would be a study of BeOS and OS/2. Remember that Be was started by
some ex-Apple staff, so they probably have some good ideas we can steal (no
point in reinventing the wheel, eh?).
- MDI vs SDI
------------------------------------
I think that we should define MDI standards now, even if the toolkit may not
support them for some time. If they are ever implemented, the standards will
ensure that we don't get inconsistent and confusing behaviour between SDI and
MDI apps.
IMHO, every SDI window should have a Close button/menu item, AND THAT'S IT.
Only MDIs have both Close and Quit (or Exit - how do we choose between the
labels "Exit" and "Quit", hmmm?).
Let's summarise first. I see three main classifications:
(1) Single window SDI
The classic example of this in MSWindows' notepad. This is where New/Open will
discard the current contents (a prompt is raised if there are changes to be
saved) and then replaced with the new file. I personally dislike this style.
(2) Multiple window SDI
This is where New/Open will open a new window with a blank/different document.
The current document is unaffected. I like this. MS are moving towards it;
check out Internet Explorer or Netscape Navigator. When you choose File->New
you get a whole new window (Open works a bit differently in that it replaces
the current contents with the new page, but then I also think that's wrong).
(3) MDI
As per MS Windows MDI. Does any other GUI/OS (e.g. OS/2, BeOS) provide MDIs ?
My only experience of these is via Windows. The expected behaviour is that
Close closes the current sheet (that's the child window which contains the
current document). Quit closes the MDI window, which, because it contains all
of the sheets, also closes all of the sheets.
I can't see the point of having Quit on any SDI app. You could argue that it
will close all the the open instances of that app, but I don't believe this is
useful behaviour. For example, imagine kwrite had Quit and Close. Would you
really want to close all other instances of the app at once ? The only time I
can imagine this is when you're shutting down, and anyway your window manager
handles that case.
- Application classification
------------------------------------
I read somewhere (Alan Cooper's "About Face" book I think, but can someone
confirm this for me ?) of a classification of apps into four classes. The
apps in each class have common interface requirements, which he also descibes.
I can't remember the four classes, but I'll try to give you some idea:
(1) Monitors/Daemons
Apps that are run once and left to run in the background. These tend to provide
a both a minimal interface to convey essential information and a full interface
to access all of the app functions. Typically an app which "docks" in the
system tray in MSWindows.
Examples: ppp-dialer, print monitor.
(2) Frequent use
Simple easy-to-learn apps with a few basic functions.
Examples: editors, CD-player, email, utilities (knotes, konsole).
(3) Soveriegn
These are large complex apps with many functions. The application tends to take
over the entire screen. In MSWindows these are often MDI apps.
Examples: word processers, spreadsheets, image editors, development
environments.
There's another class but I've forgotten it. Or maybe my classes are too
general, and I've combined some of them. I'm not sure where configuration
applets go e.g. system settings/control panel.
- Dialogs
------------------------------------
There are a number of points here:
(1) Dialogs should be modeless
(I'm not convinced that use of the term modeless/modal is correct in this
context, but I'll run with it...)
That is, you should be able to interact with the parent window while the
dialog window is open. No, you shouldn't. Well, it depends.
You should define two classes of dialog in the GUI standards: those that allow
interaction with the parent window, and those that don't. In MS Windows, these
are known respectively as popup and response dialogs. IMHO, simple
confirmation dialogs (Yes/No or OK/Cancel) should be "modal" (they take control
so the user cannot return to the parent window without responding), while more
complex dialogs may be "modeless": for example, Find and Spell Check dialogs.
In general, modal behaviour is not always a bad thing. See Jacob Neilsen's
Anti-Mac article on the www.useit.com website.
(2) Option for Yes No Cancel
Yes/No/Cancel is quite a common dialog. For example, an app could ask:
"Save changes before closing ? [Yes No Cancel]"
where Yes saves changes and closes, No discards changes and closes, and Cancel
cancels the close action.
(3) Dialog controls accessible by keyboard
Yes yes yes. However, there are no standards defined for shortcut keys on
dialogs. It is not specified how the dialog controls are invoked
(Ctrl-keypress, or just keypress ?) or indicated (underlined letter on buttons
?)
(4) Bad Interface example
This has been stolen verbatim from the www.iarchitect.com "Hall of Shame".
Perhaps you should just point people to this site instead ?
I disagree that applet window is a dialog (maybe these comments should be
directed at Isys rather than this list). It has nothing in common with a
dialog, except that it uses tabs (which are not exclusive to dialogs). I do
agree that it is a good example of poor design.
Alistair.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic