On 17.06.2008, at 11:15, MacArthur, Ian (SELEX GALILEO, UK) wrote: >>> Kidding aside, I don't find myself defending this kind of design >> (mass overloads of widgets) very often, but in some cases it's >> really the situation calls for, especially real time stuff like >> show control and audio/video production. >> >> But as a general rule, yeah, it's usually wrong. > > It seems to me (observing the guys who do this well) that they really > *don't* register all the controls - their mind blocks them up into > groups, and only a few key items from each group (maybe a slider > position) even registers in the brain. > (And I've seen this fail - where some of the "minor" knobs were in the > "wrong position", and the operator had a big problem noticing this, > even > when it was obvious to me - he just didn't even see this controls > until > there was the "logical disconnect" in his internal model, I guess.)
This is why stepping back from a problem for a while an comming back later often solves the problem. To diverge a little: loosing the oversight in a complex UI and focusing on only very few settings is really hard to fix with a GUI design. Some attempts (like the bouncing paper clip that tries to guess your problem) went awefully wrong. The military solves some of this by giving the soldier a strict order by which to test settings and pounds that into the brain, so that even under extreme stress a procedure is followed, designed to systematically solve problems. Missing an important setting is not possible that way. A GUI could aid this by providing an "I am stuck" button which then starts a tutorial style run-down of all settings, highlighting the controls in the UI in that order. Matthias ---- http://robowerk.com/ _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
