<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> <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-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; ">I see you use heavily different language modes for teaching in different</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">phases. Usability-wise it's usually worth being careful with modes since</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">they may be tricky for the users. I couldn't find much detailed information</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">from Wikipedia other than "Heavy use of modes often reduces the usability of</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">a user interface, as the user must expend effort to remember current mode</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 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-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Modes are often used for levels of advancement, too, which I find often</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">problematic. For example, you can sometimes see menu items, other times not.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 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-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; ">I've found another approach more practical. Take a drawing tool for example.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">To begin with, you have a visual toolbox for the most often used</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">functionality. You can start learning quite easily and manage to do basic</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">things. Excessive, visual complexity is hidden (unlike MS Word toolbars).</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Once you master that level, you can find more advanced functionality from</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 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 class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; 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; "><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></body></html>