Configurability

[Kero van Gelder <gelderk natlab research philips com>]

Hello all!

You have been busy this weekend. So busy I took all comments home in
order to distill a careful and (hopefully) complete answer.

First: I am talking about configurability, not directly about
UI-style-guides. Any *default* configuration should adhere to strict
ui-style rules.

Everything should be configurable. Menus and keystrokes. A toolbar is
nothing but a horizontally aligned menu, a button is nothing but a
final item in a menu. Whether an item is text, a picture or both, I
don't care; it's a clickable item in a menu-structure.

I'd like to see all items to be put in a menu-structure as the user
likes. From top-menus down to the 76th sub-menu, the user can
determine it, including the names or pictures on the (sub)menus (Foot,
"File", "or", "whatever").

Since the user can determine it, the administrator and the programmer
can't. The administrator has nothing to do with user-configurability,
apart from providing the default configurations (disabled features
should be handled by the application gracefully). The programmer will
have to rely on the libraries to enable the functions.

A call like add_func1() will simply add an item in the menu-structures
the way the user defined it. If the user-config does not supply a hook
for that particular function, a program-default must be chosen (and
added to the user-config accordingly, with communication to the user
via dialog-boxes; an undo-feature must be present (these are
ui-styleguide items)).

Now I don't know what ``self-adjusting'' menus are (sounds horrible;
the user should be in control). Perhaps I misunderstand tearable menus
(are the menus as a whole tearable, like is already implemented, or
does it mean I can tear the menu apart?) Anyway: when configuring a
UI, you need to be able to configure graphically. I can imagine
clicking with the fourth mouse-button (or another button, keystroke,
whatever) on a menu-item enables it to move to another (sub)menu. No
problem.

All of this will end up in a readable textfile. So I can edit it by
hand (Yes, that's the way to start and it's the way I like it; the
graphical editability as in the previous paragraph comes later, as
comes a separate config-util). This config-file is of course
transferable to any other user on any other machine. Configurability
is of no use without portability.

Changes that can be reverted are just other config-files, but care has
to be taken no old config-file is deleted before the user
acknowledges. A config-util would make this easier.

---

Some sentences I have to comment about:

``Why fix what ain't broken?''

The current stuff works, but it's not final. Configurability as I
propose is not a fix, but a new feature.

``What for?''

Ehm, why do I need a command-line? I can do it all with a GUI, in
theory. I want a command-line because *I* can work faster with a
command-line. Frankly, I don't care that my grand-mother does not
understand "kero@chmeee:~/Gnome[42] " Therefore, because *I* want to
be able to configure my UI, I am going to advocate configurable UI's.
(Hey, I could even ask the question why my grand-mother is using a PC
at all.) When enough people agree and enough people want to sit down
and code the stuff, there it is.

``The API must/should/could be changed''

Not changed, extended. add_func1() isn't in it, yet. (I am not going
to mention which library this will be; I have no idea at this point)
The programmer will need it, as I hope is clear by now.

When programmers get used to the new functions they have to call, we can
always deprecate the former create_menu() stuff and hide it internally.
(Guess it will take some time before that actually happens :-)

``... It has not contributed absolutely nothing to [...] the UI-guidelines.''

Not directly. But there is place for it in the configurability, in the
defaults. AFAICS, these default-configs save the programmer from
worrying about some of the guide-lines. This includes from the 8
points by Schneiderman as told by Sungod:
 - consistency. Config is valid for all applications.
 - enable frequent users to use shortcuts. You can define any keystroke or
   sub-menu route towards a command. You can make these short.

It does not include:
 - informative feedback
 - design dialogs to yield closure
 - error prevention, handling and rollback
 - permit easy reversal of actions
 - support internal locus of control
 - reduce short-term memory load

That's only 2 out of 8, but I think consistency is not the least
important one. Besides, I do not see a way to enforce informative
feedback, while the deprecation mentioned above _does_ enforce
consistency.

Bdw: configurable UI is about gui's and this list is ``gnome-gui''
after all. So where else should the discussion have been posted?

---

So, that's it for now I guess. I do not know how the config-file is
going to look, but that can be figured out once it is decided to
actually implement this configurability. If it doesn't make it into
Gnome, I'll do something with it in my own Java-applications.

Quite a long posting now, hope you enjoyed reading it.

Bye,
Kero.

+--- Kero ------------------ kero@dds.nl ---+
| I ain't changed,                          |
| but I know I ain't the same               |
+--- M38C --- http://huizen.dds.nl/~kero ---+