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