Re: [Sugar-devel] two kinds of delay (was: RFC: Kill the delayed menus for good)
> There are two kinds of delay. Type 1 is stuff like drop-down menus > that remain even if the mouse briefly goes out of bounds. This kind > of delay normally doesn't waste a nanosecond of the user's time. > Type 2 is stuff like start-up animations, sliding menus, and these > delayed menus. Type 2 is in the critical path of user interaction. > It's normally a source of frustration, permanently preventing users > from becoming efficient. The second delay is not only slow, but non-intuitive. I've failed to discover that functionality myself until someone told me about it. :( I think, that if the first delay shows only info (a tag, description, or whatever), and the second one (which for an extra dash of frustration might exist or not) adds the interaction, it would not harm to simply show both together in just one small delay. That way it is easy to use and non obtrusive. My two cents. pgpLGSfCf83M8.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] two kinds of delay (was: RFC: Kill the delayed menus for good)
Michael Stone writes: > Good suggestion for discoverability, inadequate suggestion for > fast access to the actually rather important information hidden > on the secondary palettes (e.g. disk space availability, battery > status, etc.) That trumps all. There are two kinds of delay. Type 1 is stuff like drop-down menus that remain even if the mouse briefly goes out of bounds. This kind of delay normally doesn't waste a nanosecond of the user's time. Type 2 is stuff like start-up animations, sliding menus, and these delayed menus. Type 2 is in the critical path of user interaction. It's normally a source of frustration, permanently preventing users from becoming efficient. Type 2 delays are almost never acceptable. The only case I can think of is when something is about to cause a sudden screen change that may be disorienting to the user. In that case, a very fast transition effect (perhaps 0.1 second) can help the user follow what is happening. I doubt the XO-1 hardware is capable of providing this; certainly the current software situation is far too slow to even attempt it. Since the delayed menus are a type 2 delay with no excuse, they really need to go. Right now, users are forced to be essentially incompetent. You'll never navigate quickly in sugar no matter how proficient you are. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
