[racket] About modes (was: match in Advanced Student?)

From: Jukka Tuominen (jukka.tuominen at finndesign.fi)
Date: Thu Aug 18 21:11:27 EDT 2011

Hi,

About language/UI modes. Since my contribution to CS is thin due to lack of
CS education, I hope I can contribute in usability instead, with some more
background.

I see you use heavily different language modes for teaching in different
phases. Usability-wise it's usually worth being careful with modes since
they may be tricky for the users. I couldn't find much detailed information
from Wikipedia other than "Heavy use of modes often reduces the usability of
a user interface, as the user must expend effort to remember current mode
states, and switch between mode states as necessary." at
http://en.wikipedia.org/wiki/User_interface#Modalities_and_modes
Propably deleted for not being a noticeable issue.

So, instead here are some rules of thumb out of my head that I have found
useful. I appreciate that these are the best practices for building an
application rather than lession structures which I know very little about,
but I hope you still find them useful.

Modes are reasonable for example in cases where there are different types of
users, (say, basic user, administrator, developer..) where for example users
never get to use certain functionality, i.e. it's a question of access
rights rather than level of experience. So in user mode, you could hide
these functions but leave the basic UI otherwise similar if there isn't a
strong reason not to. Sometimes the same people may need to switch between
modes or if possible have the range of functionality for the roles one has
rights to. It's not a good idea forcing to learn many different ways to do
the same thing. Especially difficult are the cases when the change is very
subtle, so that seemingly things are the same but not quite.

Modes are often used for levels of advancement, too, which I find often
problematic. For example, you can sometimes see menu items, other times not.
Sometimes the functionality is there, another times it isn't.

I've found another approach more practical. Take a drawing tool for example.
To begin with, you have a visual toolbox for the most often used
functionality. You can start learning quite easily and manage to do basic
things. Excessive, visual complexity is hidden (unlike MS Word toolbars).
Once you master that level, you can find more advanced functionality from
menus. You don't need to know things by heart, they are all listed
logically. If a menu item is sometimes unavailable, it is left in place but
disabled, so you can still see its existence and on the other hand,
navigation is easier when items have fixed places (position memory). After a
while you notice yourself doing certain things repeatedly, so you check
either the toolbox tooltips or menu tooltips for visual hints about keyboard
shortcuts (or add a button on the toolbar). On top of that you may learn new
tricks from the online help, colleages, Internet etc.

What is important in the latter case, is that the full functionality is
there all the time, unchanged. In this way, all learned is valid ever after,
and there is never need for unlearling things. It also gives flexibility to
learn things in a different order, if necessary. Additionally, it is a
question of personal preference who wants to use mouse instead of shortcuts
and in what situations. I've seen some high level professionals using mouse
only where possible.


br, jukka


|  J U K K A   T U O M I N E N
|  m a n a g i n g   d i r e c t o r  M. A.
|
|  Finndesign  Kauppiaankatu 13, FI-00160 Helsinki, Finland
|  mobile +358 50 5666290
|  jukka.tuominen at finndesign.fi  www.finndesign.fi




Posted on the users mailing list.