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

From: Jukka Tuominen (jukka.tuominen at finndesign.fi)
Date: Fri Aug 19 03:17:04 EDT 2011

1. Is the mode determinable before the user takes action?
2. Is it hard for the user to ignore feedback about the mode?
3. Does the user actively maintain the mode?

What bothers me in this example, is that the need for modes in the first
place is bypassed and the emphasis is on how to make it tolerable or how to
make the best out of it. I have no idea what were these modes. But if you
think for example a "landing mode" that you only need for a short period
during flights. You could reserve a physical area for meters and functions
dedicated for that 'phase' or in GUI terms, have a menu category dedicated
for it. If you need consulting over the phone, you cannot miss it.

Sometimes we have encountered situation where the GUI can be modified
excessively, considered as a good feature towards clients. Think about the
same flight situation but so that each airline company have their knobs and
meters customised for positions, alarm colours and even error messages.
Because of some company legacy reason or just because it feels better. Try
to help them over the phone; "Is the button on the left blinking purple?"

br, jukka
  -----Original Message-----
  From: Rodolfo Carvalho [mailto:rhcarvalho at gmail.com]
  Sent: 19 August 2011 06:15
  To: Jukka Tuominen
  Cc: users at racket-lang.org
  Subject: Re: [racket] About modes (was: match in Advanced Student?)

  Hello Jukka,

  I don't know to which extend my contribution is useful to the list, but I
remembered about a post from Aza Raskin about modes:


  There might also be writings from Donald Norman on this subject.

  Still, I don't feel Racket's student languages (*SL) suffer from modes (as
the examples described in the post above).


  Rodolfo Carvalho

  On Thu, Aug 18, 2011 at 22:11, Jukka Tuominen
<jukka.tuominen at finndesign.fi> wrote:


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

    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
    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
    states, and switch between mode states as necessary." at
    Propably deleted for not being a noticeable issue.

    So, instead here are some rules of thumb out of my head that I have
    useful. I appreciate that these are the best practices for building an
    application rather than lession structures which I know very little
    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
    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
    strong reason not to. Sometimes the same people may need to switch
    modes or if possible have the range of functionality for the roles one
    rights to. It's not a good idea forcing to learn many different ways to
    the same thing. Especially difficult are the cases when the change is
    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
    Sometimes the functionality is there, another times it isn't.

    I've found another approach more practical. Take a drawing tool for
    To begin with, you have a visual toolbox for the most often used
    functionality. You can start learning quite easily and manage to do
    things. Excessive, visual complexity is hidden (unlike MS Word
    Once you master that level, you can find more advanced functionality
    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
    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
    shortcuts (or add a button on the toolbar). On top of that you may learn
    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
    and there is never need for unlearling things. It also gives flexibility
    learn things in a different order, if necessary. Additionally, it is a
    question of personal preference who wants to use mouse instead of
    and in what situations. I've seen some high level professionals using
    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

     For list-related administrative tasks:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20110819/7e3ade9b/attachment.html>

Posted on the users mailing list.