| |||||||||||
Metaphors make the operating system (NewsForge)Metaphors make the operating system (NewsForge)Posted Apr 30, 2003 12:08 UTC (Wed) by Wol (guest, #4433)In reply to: Metaphors make the operating system (NewsForge) by iabervon Parent article: Metaphors make the operating system (NewsForge) Look at studies of learning. GUIs are based on the studies of Seymour Papert about how children learn. So they are excellent for the casual user, who dabbles and never really learns how to use a computer. BUT, and this is a HUGE but, the more somebody uses something, the more their behaviour becomes automatic and learned, and the underlying behaviour changes immensely. This is why GUIs are so frustrating to experienced users. There IS no way for their behaviour to become automated - GUIs *obstruct* the learning process, forcing users to remain stuck in "learning" mode. Take reading. As a kid, we read phonetically, we read aloud, and we hear what's on the page. As an adult, when we meet an unfamiliar word we still do this (even if we don't actually say the word out loud) BUT for most words we read in "symbol" mode - we see a blur on the page with spaces round it, and the meaning goes from page to brain without the hearing system ever getting involved. That's why TEXT ALL IN CAPITALS, or an unfamiliar font, or spelling mistakes, all jar and slow us down - they change the shape, or "feeling", of the blur and knock us back in to "learning mode" to understand what's being said. When I started computing, all I had for programming was a line editor. Later on I got a full-screen editor, but it used the same line-editor's syntax in its line mode (bit like vi, really). As soon as I wanted to do anything complex, I always dropped back into line edit mode. The modern editors I use are immensely frustrating, precisely because they either lack a line mode (most Windows editors) or I can't get to grips with it (vi, emacs for example). In other words, I'm stuck with the learning interface, not the doing interface ... :-( Cheers,
(Log in to post comments)
Metaphors make the operating system (NewsForge) Posted Apr 30, 2003 18:11 UTC (Wed) by tjc (guest, #137) [Link] What Wol said. :-)I worked at a place about eight years ago maintaining a UNIX-based character mode customer service application. This thing was so primitive from a UI standpoint that the built-in editor for entering comments into the database was a subset of vi. Users moved from one screen to the next and selected menu items by pressing a single key. New users hated it, because it was hard to learn, but once they got used to it they could fly around the app with one hand while talking to a customer on the phone. They had a few other apps (written in some 4GL that I can't remember) for doing things that were outside of the main application, and using them was like jumping from a speeding train into a swimming pool full of Jello(TM). BUT for most words we read in "symbol" mode - we see a blur on the page with spaces round it, and the meaning goes from page to brain without the hearing system ever getting involved. One could navigate the screens in the above mentioned application by just glancing at the "shape" of the text menues on the screen.
Metaphors make the operating system (NewsForge) Posted May 2, 2003 21:36 UTC (Fri) by Baylink (subscriber, #755) [Link] .. and the name of this syndrome isWhat You See is ALL You Get. It's the most common problem with graphical interfaces in the context of trained users. Really, since the primary thing that GUI's make easier is *training*, they're tuned for high-turnover situations, and this is really not the proper approach, from a business standpoint. What you *want* to do is train and manage for retention... and when you do that, you'll find out what lots of mainframe houses already have when they tried to build CUA interfaces atop 3270 networks: you don't gain much and you lose a lot. Allied Van Lines did this: AVS was *much* easier to learn than CAMIS. But it was *slower to use* and took 7 times as many screen-transactions, upping their processor and FEP load something considerable. Enabling fast turnover is *not* the proper solution.
|
|||||||||||