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
[email protected]
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
