[racket] About modes

I think what is rather exceptional in student language mode thinking, is
that you are trying/ being able to create a  kind of
laboratory environment where each learning step can be controlled. Hard to
say whether it is a good idea or not per se, but the problems seem to raise
when you try to step off the lane. It is a unique situation to be able to do
that.

If new features are introduced as you move further (gaining new skills in
games :) but never go back, then it should be mostly OK, except that it may
make the of-the-lane learning more challanging. I could think of two
situations like that
 - Wanting to create a new lane of learning for a special purpose or
experimenting whether some other order might be more optimal
 - Learning through colleages outside the lane ("ok, you don't have that
feature available, yet... What I usually do in these situations...")

The drawing tool was just an example, and programming languages propably
need a slightly different approach in some areas. Where is has proven
usefull in our experience are GUI building tools, for example. Placing all
the commands in the menus is likely to be a bad idea (and even dynamically
expanding according to new definitions).

Since you are using this kind of methods, it is likely that the pros are
higher than cons. I'm not even suggesting any radical changes, I'm just glad
that it's all conscious decisions.

br, jukka
  -----Original Message-----
  From: Stephen Bloch [mailto:sbloch at adelphi.edu]
  Sent: 19 August 2011 04:32
  To: Jukka Tuominen
  Cc: users at racket-lang.org
  Subject: Re: [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/20110819/d54a0cbf/attachment.html>