The Telephone in a Study of Interaction Design

I’ve started to read Donald A. Norman’s The Design of Everyday Things. He uses the modern telephone as an example where the paradox of technology is readily apparent. The paradox of technology as defined by Norman is the fact that the technology used to make more functions available and usable by users end up making the product more complex and often more difficult to use.

The typical office telephone is difficult to use due to the lack of visibility for its functions and the arbitrary mapping of functionality to seemingly unrelated steps. This is interesting for me as I had the luck to have used different telephone systems in my previous and current companies. I will refer to my previous company as Synergy and the current one as Opportunity as it sounds better.

Both Synergy and Opportunity have main doors that were controlled electronically and connected to the telephone system. This meant that the door could be unlocked by using the telephones. For the system at Synergy, it was a challenge to perform the task of unlocking the door via the telephone to say the least. The steps to open the door is actually different depending on which telephone you were using as only some were directly connected to the unlocking functions. It was not possible to know which sequence of steps to use unless the user memorised which phones were directly connected (which no one did, save the manager).

Here are the steps as I remember them for using telephones that were not directly connected:

  1. Phone emits intercom tone.
  2. Pick up receiver
  3. Dial 9 to connect tone to the telephone that’s directly connected.
  4. Wait for connected tone
  5. Dial 98 to unlock door (Door will unlock automatically in 2 seconds)

The list of steps are shorter for directly connected phones but there is no relationship between 98 and the action of unlocking the door. There was also no audible or visual cue that the unlocking action succeeded, the only obvious indicator of whether I succeeded was if someone walked in (success!) or if the same person uses the intercom again to ask why the door isn’t open (failure!).

All this conspired to make the action of opening the door via the telephone much more complicated than necessary. It turned out that after the telephone system was installed, most of us found it too confusing to use and simply walked from our desks to the door and unlocked it manually instead!

Doing this task is slightly easier in Opportunity. Thankfully, there’s only a single list of steps to follow in order to perform this action.

  1. Phone emits intercom tone.
  2. Pick up receiver
  3. Press the “flash” button.
  4. Door unlocks with audible beep

This time, there’s no need to remember which sequence of digits to enter. Granted there is still a conceptual disconnect between the action and the effect, it is easier for users to remember. There is no ambiguity over whether the unlocking of the door succeeded, the beeping sound will be heard by all staff (the office is enclosed and not very big, space wise).

The point that Norman tries to make in his analysis of the telephone is the fact that devices become increasingly difficult and frustrating to use when its available functions exceed the number of controls. In order to expose this additional functionality, the designers of the product often resort to using un-natural mappings such as the one in the example above. The difficulty in developing a good conceptual model that resonates with users increases exponentially with the product’s complexity.

Even so, there should be a concerted effort throughout the development lifecycle to think about how it will be used. It should be easy to perform a task correctly and difficult or impossible to do it wrongly.

Comments

Using Textmate for Actionscript

I've never liked the default code editor that comes with the Flash IDE, so when the I discovered that I would need to develop actionscript code for a project, my first thought was to use Textmate instead. Incidentally, some people are already doing this.

I've used MTASC to compile Actionscript files before, the most important difference that surfaces when comparing it to Macromedia's Actionscript compiler (MMC), which is the one that's packaged in every installation of Flash, is that MTASC is much stricter on enforcing proper syntax. This is intended to reduce occurences of hard to find bugs that arise from improper scripting. The other feature that MTASC touts is its faster compile speed, however I've not experienced a visible variance between it and MMC. I would think that this speed improvement would be more apparent when compiling large projects consisting of more than 50 Actionscript files.

I'm using dirtystylus' Textmate command for checking the syntax of my files, it took me a while to get it working as I organised the dependencies differently. Following my conventions in using MacPorts which is installed in /opt/local/, MTASC and XTrace were placed in /opt/local/managed/. The executable for MTASC was stored in /opt/local/managed/bin/ while XTrace.app was copied to the Applications folder. All supporting scripts were moved to /opt/local/managed/lib/.

This is the customised command that I'm using after trying for about 2 hours.

CODE:
  1. FLASHPLAYER=SAFlashPlayer
  2. MTASC=/opt/local/managed/bin/mtasc
  3. CLASSPATHS="-cp /opt/local/managed/lib/mtasc/std/ -cp /opt/local/managed/lib/mtasc/std8/ -cp /Users/douglas/Library/Application\ Support/Macromedia/Flash\ 8/en/Configuration/Classes/"
  4. SOURCE="$TM_FILEPATH"
  5. OUTPUT=test.swf
  6. VERSION=8
  7. TRACE="-trace com.mab.util.debug.trace"
  8. TMPFILE=/tmp/as-compile.err
  9. compileResult=`$MTASC -main "$SOURCE" -wimp -version $VERSION -strict $CLASSPATHS $TRACE 2>&1`
  10. echo "
  11. <style type="\'text/css\'"> body {margin: 10px; font-family: Monaco; font-size: 14px;} a {color: #000000; text-decoration: underline;} a:hover {color: #666666;} </style> <script type="\'text/javascript\'"> function closeWin() { self.close(); } </script>"
  12. if test -n "$compileResult"
  13. then
  14. errorLine=`echo $compileResult | sed 's/.*:\([0-9]*\):.*/\1/'`
  15. echo "<a href="txmt://open?url=file://$TM_FILEPATH&amp;line=$errorLine" onclick="closeWin();">$compileResult</a>";
  16. else
  17. echo "
  18. fi

3 Comments