<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="text/html; charset=us-ascii" http-equiv=Content-Type> <META name=GENERATOR content="MSHTML 8.00.6001.19120"></HEAD> <BODY style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"> <DIV><SPAN class=187511906-19082011><FONT size=2 face=Arial>I think what is rather exceptional in student language mode thinking, is that you are trying/ being able to create a  kind of<BR>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. </FONT></SPAN></DIV> <DIV><SPAN class=187511906-19082011><FONT size=2 face=Arial></FONT></SPAN> </DIV> <DIV><SPAN class=187511906-19082011><FONT size=2 face=Arial>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</FONT></SPAN></DIV> <DIV><SPAN class=187511906-19082011><FONT size=2 face=Arial> - Wanting to create a new lane of learning for a special purpose or experimenting whether some other order might be more optimal</FONT></SPAN></DIV> <DIV><SPAN class=187511906-19082011><FONT size=2 face=Arial> - Learning through colleages outside the lane ("ok, you don't have that feature available, yet... What I usually do in these situations...")</FONT></SPAN></DIV> <DIV><SPAN class=187511906-19082011><FONT size=2 face=Arial></FONT></SPAN> </DIV> <DIV><SPAN class=187511906-19082011><FONT size=2 face=Arial>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).</FONT></SPAN></DIV> <DIV><SPAN class=187511906-19082011><FONT size=2 face=Arial></FONT></SPAN> </DIV> <DIV><SPAN class=187511906-19082011> <DIV><SPAN class=187511906-19082011><FONT size=2 face=Arial>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. </FONT></SPAN></DIV> <DIV><SPAN class=187511906-19082011><FONT size=2 face=Arial></FONT></SPAN> </DIV> <DIV><SPAN class=187511906-19082011><FONT size=2 face=Arial>br, jukka</FONT></SPAN></DIV></SPAN></DIV> <BLOCKQUOTE style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px"> <DIV dir=ltr class=OutlookMessageHeader align=left><FONT size=2 face=Tahoma>-----Original Message-----<SPAN class=187511906-19082011><FONT face=Arial>  </FONT></SPAN><BR><B>From:</B> Stephen Bloch [mailto:sbloch@adelphi.edu]<BR><B>Sent:</B> 19 August 2011 04:32<BR><B>To:</B> Jukka Tuominen<BR><B>Cc:</B> users@racket-lang.org<BR><B>Subject:</B> Re: [racket] About modes<BR><BR></FONT></DIV><BR> <DIV> <DIV>On Aug 18, 2011, at 9:11 PM, Jukka Tuominen wrote:</DIV><BR class=Apple-interchange-newline> <BLOCKQUOTE type="cite"> <DIV style="MARGIN: 0px; MIN-HEIGHT: 14px">I see you use heavily different language modes for teaching in different</DIV> <DIV style="MARGIN: 0px">phases. Usability-wise it's usually worth being careful with modes since</DIV> <DIV style="MARGIN: 0px">they may be tricky for the users. I couldn't find much detailed information</DIV> <DIV style="MARGIN: 0px">from Wikipedia other than "Heavy use of modes often reduces the usability of</DIV> <DIV style="MARGIN: 0px">a user interface, as the user must expend effort to remember current mode</DIV> <DIV style="MARGIN: 0px">states, and switch between mode states as necessary."</DIV></BLOCKQUOTE> <DIV><BR></DIV>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</DIV> <DIV>(a) nobody is expected to switch "modes" often -- my students won't switch out of Beginning Student for a month or two, and</DIV> <DIV>(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.</DIV> <DIV><BR></DIV> <DIV>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.</DIV> <DIV><BR></DIV> <DIV> <BLOCKQUOTE type="cite"> <DIV style="MARGIN: 0px">Modes are often used for levels of advancement, too, which I find often</DIV> <DIV style="MARGIN: 0px">problematic. For example, you can sometimes see menu items, other times not.</DIV> <DIV style="MARGIN: 0px">Sometimes the functionality is there, another times it isn't.</DIV></BLOCKQUOTE> <DIV><BR></DIV>Is this really a problem when the "advancement" is one-directional -- almost nobody ever switches back to an earlier mode?</DIV> <DIV><BR> <BLOCKQUOTE type="cite"> <DIV style="MARGIN: 0px; MIN-HEIGHT: 14px">I've found another approach more practical. Take a drawing tool for example.</DIV> <DIV style="MARGIN: 0px">To begin with, you have a visual toolbox for the most often used</DIV> <DIV style="MARGIN: 0px">functionality. You can start learning quite easily and manage to do basic</DIV> <DIV style="MARGIN: 0px">things. Excessive, visual complexity is hidden (unlike MS Word toolbars).</DIV> <DIV style="MARGIN: 0px">Once you master that level, you can find more advanced functionality from</DIV> <DIV style="MARGIN: 0px">menus....</DIV></BLOCKQUOTE> <DIV><BR></DIV></DIV>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. <DIV><BR></DIV><BR><BR> <DIV><SPAN style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; ORPHANS: 2; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0" class=Apple-style-span> <DIV>Stephen Bloch</DIV> <DIV><A href="mailto:sbloch@adelphi.edu">sbloch@adelphi.edu</A></DIV> <DIV><BR class=webkit-block-placeholder></DIV></SPAN><BR class=Apple-interchange-newline></DIV><BR></BLOCKQUOTE></BODY></HTML>