ADVANCED LOOK AND FEEL
Advanced look & feel features
This document describes some advanced look and feel (L&F) features, that I
would like to see in a Graphical User Interface (GUI). Some of the features already
exist in various GUIs, but I have never seen any GUI that has all of these
Here is an introduction to the concept of pluggable L&F. I like the idea
that a user of a GUI can install his/her own favoite L&F in the
entire GUI in an operating sytem. It should only be necessary to install this L&F
once, so that all applications on the same system will use that L&F. For instance
some people might like the L&F of Windows95, while others may prefer the L&F of
BeOS. Ideally it should be possible to install a different L&F for each user
in a system.
To do something like this, a standard interface will have to
be defined for general L&F possibilities. Such a standard should preferably
work on any modern operating system with a GUI and open up the possibility
for implementing features like those listed through the rest of this document.
However, since the evolution
of software these days seems to be moving backwards at times, pluggable L&F will
possibly remain a dream for a long time, unless some serious work is started.
I am very interested in participating in a project to define such a standard,
so you should send me an e-mail
if you share this interest. I know about
which will, alas, be a Java-only API. I also know about
which might be a good place to introduce a general crossplatform standard.
Pluggable elements in a GUI with pluggable Look & Feel
- All standard GUI-Controls should be replacable. This includes buttons, checkboxes,
radiobuttons, textfields, listboxes, comboboxes/popuplists, menus etc.
- Standard dialogboxes should be replacable. This includes font-dialogboxes, dialogboxes
for opening files, color-dialogboxes etc.
- All features listed below should be replacable.
Concrete Look & Feel features that I find useful
- The The BeOS font-dialogbox is very cool.
It allows a font to be both scaled, rotated and italicized in realtime - all
at the same time. This gives realtime feedback on how the selected font will
look without any effort from the user.
- It is good when popupmenus and dialogboxes always popup at the location of
the mouse pointer. This saves the effort of having to move the mouse to make a
menuselection or to answer a question in a dialogbox. Many GUIs
always display dialogboxes in the center of the screen which seems completely
crazy to me.
- In some cases it would be good to have the menubars of an application
right justified. For instance in a wordprocessor application the text
is usually left justified. If the menubar was right justified in
this case, the menus would cover up less of the text which is important.
- I like when all GUI-Controls are highlighted as the mouse travels over
them. Notice that when highligting for instance a listbox
there should be both a highlighted item and a selected item. It is not always
desirable if the mouse just selects what it is dragged over. This can be very annoying
when moving the selection with the keyboard while scrolling the list with the mouse.
- I like radial popupmenus a lot. I have only seen them used in a 3D modelling
PowerAnimator from Alias|Wavefront.
Here are 2 hand drawn images of radial menus
with an Alias|Wavefront like L&F:
Radial menus popup at the location of the mousepointer, where the mousepointer
starts in the centre of the menu. This means that the mouse will only
have to be moved a very short distance to make a selection. This makes radial
menus very efficient, easy and fast to operate. It is even possible to make
hierarchial menus by popping op new radial menus when submenus are selected.
Here is an alternative look for radial menus:
- A cool idea for fast and easy operation of a radiogroup, would be
to allow the user to hold down the mousebutton and drag up and down to
change the selected radiobutton in realtime. If the selections also have
realtime feedback, this will make it
faster and easier to try out all selections in a radiogroup.
This is an alternative of having to click on each radiobutton
to see the effect of that option, which is the only thing possible in all GUIs that
I have ever seen.
- It would be good if the user could modify and customize hotkeys in
applications. This will allow users to choose their favorite hotkeys
for features that are often used.
- It would be cool to have some standard "menugroups" as part of a L&F.
Examples of menugroups could be: An "edit" group
for "cut", "copy" and "paste", a "selection" group for "select all" and
"select none", a "file I/O" group for "load", "save", "save as" and maybe "new (file/project)".
By making this an integrated part of the L&F it would be possible to have more consistent
menulayouts across multiple applications. If the user could also specify
hotkeys for those standard menu groups, there would also be a more consistent
use of hotkeys across multiple applications.
- It would be cool to merge the features of icon palettes, menuitems and tearoff
menus. It could be done if all menuitems could be dragged into toolshelves for
customization of the GUI, and if tearoff menus would be the same as a
predefined toolshelf. It could be made possible to put toolshelves/torn off menus
into other toolshelves for hierarchial organization of toolshelves.
The layout of menuitems and items in toolshelves could be toggled between icon-only,
text-only and icon+text modes. It could be cool if toolshelves/torn off menus could be
attached both to the outside of a windowframe and to the inside of a windowframe. It
should also be possible to detach it, so that it will be floating around independently.
- It would be good if more applications took more advantage of multitreading.
In The BeOS it has been
made common to have a separate thread for each window in the application.
This is because that it has been made easy for developers to create
a trhead for each window, which I think other development tools should too.
- It is attractive to have window-modal and non-modal dialogs as a
common feature in a GUI. This makes it possible to do something else
before answering a modal dialogbox, instead of having to answer the
dialogbox immediately as is the case with application-modal dialogboxes.
This feature will require an application to be multithreaded.
- In many cases it is desirable to have asynchronous GUI functionality.
For instance a very computationally expensive operation triggered by a button
should have it's own thread. This ensures that the user will not
need to wait for the operation to finish before something else can be
done. To make this a common feature, GUI development
tools will have to provide this option with as little effort as possible.