[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/a1e06d3e/attachment.html>