Hello Jukka,<div><br></div><div>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:</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't feel Racket's student languages (*SL) suffer from modes (as the examples described in the post above).</div> <div><br></div><div>[]'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"><<a href="mailto:jukka.tuominen@finndesign.fi">jukka.tuominen@finndesign.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br> Hi,<br> <br> 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> background.<br> <br> I see you use heavily different language modes for teaching in different<br> phases. Usability-wise it's usually worth being careful with modes since<br> they may be tricky for the users. I couldn't find much detailed information<br> from Wikipedia other than "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." 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> <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> <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'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'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'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> <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't.<br> <br> I'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'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> <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've seen some high level professionals using mouse<br> only where possible.<br> <br> <br> br, jukka<br> <br> <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> |<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> <br> <br> _________________________________________________<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> </blockquote></div><br></div>