Hello Jukka,<div><br></div><div>I don&#39;t know to which extend my contribution is useful to the list, but I remembered about a post from Aza Raskin about modes:</div><div><br></div><div><a href="http://humanized.com/weblog/2006/12/07/is_visual_feedback_enough_why_modes_kill/">http://humanized.com/weblog/2006/12/07/is_visual_feedback_enough_why_modes_kill/</a></div>

<div><br></div><div>There might also be writings from Donald Norman on this subject.</div><div><br></div><div><br></div><div>Still, I don&#39;t feel Racket&#39;s student languages (*SL) suffer from modes (as the examples described in the post above).</div>

<div><br></div><div>[]&#39;s</div><div><br clear="all">Rodolfo Carvalho<br>
<br><br><div class="gmail_quote">On Thu, Aug 18, 2011 at 22:11, Jukka Tuominen <span dir="ltr">&lt;<a href="mailto:jukka.tuominen@finndesign.fi">jukka.tuominen@finndesign.fi</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

About language/UI modes. Since my contribution to CS is thin due to lack of<br>
CS education, I hope I can contribute in usability instead, with some more<br>
I see you use heavily different language modes for teaching in different<br>
phases. Usability-wise it&#39;s usually worth being careful with modes since<br>
they may be tricky for the users. I couldn&#39;t find much detailed information<br>
from Wikipedia other than &quot;Heavy use of modes often reduces the usability of<br>
a user interface, as the user must expend effort to remember current mode<br>
states, and switch between mode states as necessary.&quot; at<br>
<a href="http://en.wikipedia.org/wiki/User_interface#Modalities_and_modes" target="_blank">http://en.wikipedia.org/wiki/User_interface#Modalities_and_modes</a><br>
Propably deleted for not being a noticeable issue.<br>
So, instead here are some rules of thumb out of my head that I have found<br>
useful. I appreciate that these are the best practices for building an<br>
application rather than lession structures which I know very little about,<br>
but I hope you still find them useful.<br>
Modes are reasonable for example in cases where there are different types of<br>
users, (say, basic user, administrator, developer..) where for example users<br>
never get to use certain functionality, i.e. it&#39;s a question of access<br>
rights rather than level of experience. So in user mode, you could hide<br>
these functions but leave the basic UI otherwise similar if there isn&#39;t a<br>
strong reason not to. Sometimes the same people may need to switch between<br>
modes or if possible have the range of functionality for the roles one has<br>
rights to. It&#39;s not a good idea forcing to learn many different ways to do<br>
the same thing. Especially difficult are the cases when the change is very<br>
subtle, so that seemingly things are the same but not quite.<br>
Modes are often used for levels of advancement, too, which I find often<br>
problematic. For example, you can sometimes see menu items, other times not.<br>
Sometimes the functionality is there, another times it isn&#39;t.<br>
I&#39;ve found another approach more practical. Take a drawing tool for example.<br>
To begin with, you have a visual toolbox for the most often used<br>
functionality. You can start learning quite easily and manage to do basic<br>
things. Excessive, visual complexity is hidden (unlike MS Word toolbars).<br>
Once you master that level, you can find more advanced functionality from<br>
menus. You don&#39;t need to know things by heart, they are all listed<br>
logically. If a menu item is sometimes unavailable, it is left in place but<br>
disabled, so you can still see its existence and on the other hand,<br>
navigation is easier when items have fixed places (position memory). After a<br>
while you notice yourself doing certain things repeatedly, so you check<br>
either the toolbox tooltips or menu tooltips for visual hints about keyboard<br>
shortcuts (or add a button on the toolbar). On top of that you may learn new<br>
tricks from the online help, colleages, Internet etc.<br>
What is important in the latter case, is that the full functionality is<br>
there all the time, unchanged. In this way, all learned is valid ever after,<br>
and there is never need for unlearling things. It also gives flexibility to<br>
learn things in a different order, if necessary. Additionally, it is a<br>
question of personal preference who wants to use mouse instead of shortcuts<br>
and in what situations. I&#39;ve seen some high level professionals using mouse<br>
only where possible.<br>
br, jukka<br>
|  J U K K A   T U O M I N E N<br>
|  m a n a g i n g   d i r e c t o r  M. A.<br>
|  Finndesign  Kauppiaankatu 13, FI-00160 Helsinki, Finland<br>
|  mobile <a href="tel:%2B358%2050%205666290" value="+358505666290">+358 50 5666290</a><br>
|  <a href="mailto:jukka.tuominen@finndesign.fi">jukka.tuominen@finndesign.fi</a>  <a href="http://www.finndesign.fi" target="_blank">www.finndesign.fi</a><br>
  For list-related administrative tasks:<br>
  <a href="http://lists.racket-lang.org/listinfo/users" target="_blank">http://lists.racket-lang.org/listinfo/users</a><br>