home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / humanfa / 2690 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  3.1 KB
  1. Path: sparky!uunet!pipex!ibmpcug!mantis!mathew
  2. From: mathew <mathew@mantis.co.uk>
  3. Newsgroups: comp.human-factors
  4. Subject: Re: Seperation of Church and Elevators
  5. Message-ID: <cwcJuB13w165w@mantis.co.uk>
  6. Date: Fri, 20 Nov 92 11:39:23 GMT
  7. References: <1992Nov19.163325.662@cine88.cineca.it>
  8. Distribution: world
  9. Organization: Mantis Consultants, Cambridge. UK.
  10. Lines: 67
  11.  
  12. bassi@cs.unibo.it (Bruno Bassi) writes:
  13. > In article <1992Nov14.213444.25253@magnus.acs.ohio-state.edu> sruland@magnus.
  14. > >however you rarely see them used, but on realy old Otis
  15. > >elevators 1940's (?) And the reasoning was that going up
  16. > >was a good thing (i.e. Heaven) and going down was a bad
  17. > >thing (i.e. red=hell).  The buttons usually carried the
  18. > >redundant colored lights in addition to the up and down
  19. > >arrows.
  20. > 
  21. > The main issue about this whole thing seems to me the following:
  22. > No matter how arbitrary the coding between an interface representation
  23. > or action and the thing it represents or the action it stands for,
  24. > you can *always* with some effort find some sort of "explanation" or 
  25. > mnemonic trick for it.
  26. > But: besides the one you find, there may be other interpretations that
  27. > come quite naturally to other people's minds, and that are misleading.
  28.  
  29. Quite.  In the UK, traffic lights have red at the top and green at the
  30. bottom.  I would expect people here to associate red with "top" and green
  31. with "bottom" for that reason.
  32.  
  33. > I want to submit an example, from interfaces as supposedly "good" as
  34. > Mac and Windows. Take a case in which I have to enter a number as a
  35. > parameter, e.g. to set icons spacing in Windows Control Panel. I get a
  36. > small box with the default value, and on one side of it there are two 
  37. > arrows pointing up and down. Now the idea is "push the up arrow to increment
  38. > the number (to get a higher one), and the down arrow to decrement it. 
  39. > Folks, I ALWAYS GET IT WRONG. I do exactly the opposite, and I just
  40. > can't learn it the right way, and no use in RTFM.
  41.  
  42. Actually, funny you should mention that.  I noticed myself doing just the
  43. same thing yesterday.  I had no idea why I would click on the "down arrow"
  44. button to increment something, but I did it without thinking.  So you are not
  45. alone!
  46.  
  47. > I understand that, presented with an up-down axis (suggested by the
  48. > arrows), I tend to imagine natural numbers disposed in a vertical row,
  49. > like this:
  50. > 
  51. >    0
  52. >    1
  53. >    2
  54. >    3
  55. >    .
  56. >    .
  57. > 
  58. > Try to see it this way, and you will understand how an "up" arrow could
  59. > naturally yeald a smaller number, and conversely for the "down" one.
  60.  
  61. Hmm.  Yeah, that makes some sort of sense.  But I think in this case, our
  62. brains are at fault; we're thinking too mathematically.  Probably we're used
  63. to seeing program line numbers or something...
  64.  
  65. > For this particular case, I think that a horizontal representation, with
  66. > "left" and "right" arrows, would do much better. I find it natural to think a
  67. > the "right" direction as the direction where things increase (probably
  68. > because texts grow rightwards). And, if you spatialise numbers, you get
  69. > 
  70. >      0  1  2  3  4  .  .  .
  71. > 
  72. > which also works.
  73.  
  74. Sounds like an excellent idea.
  75.  
  76.  
  77. mathew
  78.  
  79.