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

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


  http://humanized.com/weblog/2006/12/07/is_visual_feedback_enough_why_modes
_kill/


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


  []'s

  Rodolfo Carvalho



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


    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


    _________________________________________________
     For list-related administrative tasks:
     http://lists.racket-lang.org/listinfo/users


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