[racket] About modes

On Aug 18, 2011, at 9:11 PM, Jukka Tuominen wrote:

> 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."

Yes, there are a lot of usability problems with modes.  I would argue  
that the series of student languages in DrRacket avoids most of these  
problems because
(a) nobody is expected to switch "modes" often -- my students won't  
switch out of Beginning Student for a month or two, and
(b) each "mode" is a SUBSET of the next one, so anything you learned  
how to do in the first week of the class will still work in the last  
week of the class.

The only things you lose by going to a more advanced language are  
training wheels: if you learned to depend on DrRacket catching a  
particular mistake of yours, it may no longer do that in a  
subsequent, more permissive language.

> 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.

Is this really a problem when the "advancement" is one-directional --  
almost nobody ever switches back to an earlier mode?

> 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....

Toolbox and menu user interfaces are great when there's a small  
number of possible operations -- small enough to fit into a menu, or  
at most a two-level menu, which gives you an effective limit of about  
a hundred.  Most programming languages have FAR more possible  
operations than this, so it's not clear how this UI guideline can be  
applied to programming.  The BYOB and Alice people have tried, by  
restricting the language to a few dozen operations so they can drag-n- 
drop them; this gives those languages high points for  
"discoverability" and "not overloading human memory", but low points  
for extensibility and scalability.



Stephen Bloch
sbloch at adelphi.edu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20110818/5aaf038f/attachment.html>