<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> <META name=GENERATOR content="MSHTML 8.00.6001.19120"></HEAD> <BODY> <DIV><SPAN class=208210007-19082011><FONT size=2 face=Arial>"</FONT></SPAN></DIV> <DIV><SPAN class=208210007-19082011><FONT size=2 face=Arial><FONT size=3 face="Times New Roman">1. Is the mode determinable before the user takes action?<BR>2. Is it hard for the user to ignore feedback about the mode?<BR>3. Does the user actively maintain the mode?</FONT></FONT></SPAN></DIV> <DIV><SPAN class=208210007-19082011>"</SPAN></DIV> <DIV><SPAN class=208210007-19082011></SPAN> </DIV> <DIV><SPAN class=208210007-19082011><FONT size=2 face=Arial>What bothers me in this example, is that the need for modes in the first place is bypassed and the emphasis is on how to make it tolerable or how to make the best out of it. I have no idea what were these modes. But if you think for example a "landing mode" that you only need for a short period during flights. You could reserve a physical area for meters and functions dedicated for that 'phase' or in GUI terms, have a menu category dedicated for it. If you need consulting over the phone, you cannot miss it.</FONT></SPAN></DIV> <DIV><SPAN class=208210007-19082011><FONT size=2 face=Arial></FONT></SPAN> </DIV> <DIV><SPAN class=208210007-19082011><FONT size=2 face=Arial>Sometimes we have encountered situation where the GUI can be modified excessively, considered as a good feature towards clients. Think about the same flight situation but so that each airline company have their knobs and meters customised for positions, alarm colours and even error messages. Because of some company legacy reason or just because it feels better. Try to help them over the phone; "Is the button on the left blinking purple?"</FONT></SPAN></DIV> <DIV><SPAN class=208210007-19082011><FONT size=2 face=Arial></FONT></SPAN> </DIV> <DIV><SPAN class=208210007-19082011><FONT size=2 face=Arial>br, jukka</FONT></SPAN></DIV> <BLOCKQUOTE style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px" dir=ltr> <DIV dir=ltr class=OutlookMessageHeader align=left><FONT size=2 face=Tahoma>-----Original Message-----<BR><B>From:</B> Rodolfo Carvalho [mailto:rhcarvalho@gmail.com]<BR><B>Sent:</B> 19 August 2011 06:15<BR><B>To:</B> Jukka Tuominen<BR><B>Cc:</B> users@racket-lang.org<BR><B>Subject:</B> Re: [racket] About modes (was: match in Advanced Student?)<BR><BR></FONT></DIV>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 style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote><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></BLOCKQUOTE></BODY></HTML>