Learning more about direct manipulation and reducing the ‘gulfs’

“Direct manipulation” is one of those Human-Computer Interaction (‘HCI’) terms that sounds intriguing. During the online HCI course instructed by Scott Klemmer which I did recently, I learned a bit more about what direct manipulation means.

Direct manipulation is a HCI method which involves continuous representation of objects of interest and rapid, reversible, and incremental actions and feedback. I guess the essence of direct manipulation is to allow users to manipulate objects that are presented to them, using actions that resemble – to varying degrees – the physical world.

An example of direct manipulation is the resizing a graphical shape, such as a rectangle, by dragging its corners or edges with a mouse. As Wikipedia explains: “Having real-world metaphors for objects and actions can make it easier for a user to learn and use an interface (some might say that the interface is more natural or intuitive), and rapid, incremental feedback allows a user to make fewer errors and complete tasks in less time, because they can see the results of an action before completing the action, thus evaluating the output and compensating for mistakes.”

In the lecture, Scott talked about “The Gulf of Execution” and “The Gulf of Evaluation” as introduced by Don Norman and Bill Verplank; how can a user interface bridge the gap between the user ‘knowing what to do’ (“The Gulf of Execution”) and the user ‘knowing what has happened’ (“The Gulf of Evaluation’)? In essence, direct manipulation is about making the interaction between a system and its users as easy and seamless as possible (see Fig. 1 below). Scott went on to talk about how easily users can do certain tasks, as outlined in Don Norman’s The Design of Everyday Things (see Fig. 2 below).

Amongst other things, I learned how you can use design to reduce these gulfs:

  1. Affordances and signifiers – Don Norman introduced the terms “signifiers” and “affordances” in his book, The Psychology of Everyday Things. A “signifier” is some sort of indicator, a signal in the physical or social world that can be interpreted meaningfully. In design, you can use signifiers to convey critical messages to the users. “Affordances” are all about the perceived and actual properties of a thing which determine how this thing can be used.
  2. Reducing the gulfs – Apart from providing visibility through affordances and signifiers, Scott mentioned a number of alternative ways to reduce the ‘gulfs’ in users knowing what to do and knowing what has happened (see Fig. 3 below).
  3. Graphical User Interface (‘GUI’) vs command line  It was interesting to hear Scott compare the pros and cons of a graphical user interface (‘GUI’) against those of the command line interface. Initially, I was strongly inclined to think that a GUI would be much more intuitive and better from a direct manipulation point of view. However, Scott explained that the command line interface tends to work better when the direction it offers is a benefit rather than a drawback (see Fig. 4 below).
  4. Gestural interfaces – At the end of the lecture Scott talked about how all of this direct manipulation stuff applies to gestural interfaces. These interfaces can be a good remedy against menu creep because as a designer you’re almost forced to keep the gestural interface as simple and as minimal as possible. With natural gestures tends to come immediate and clear user feedback.

Main learning point: I didn’t find direct manipulation the most straightforward of topics within the HCI course. However, after spending a bit more time understanding concrete examples and the ways in which the “Gulf of Execution” and the “Gulf of Evaluation” can be reduced, I felt a bit more confident about direct manipulation and specific things to look out for.

Fig. 1 – Design framework around the “Gulf of Execution” and the “Gulf of Evaluation” by Richard Buchanan (Taken from: http://www.dubberly.com/articles/what-is-interaction.html)

execution_evaluation

Fig. 2 – The making of gulfs (as outlined in Don Norman’s “The Design of Everyday Things”) – How easily can someone:

  • Determine the function of the device?
  • Tell what actions are possible?
  • Determine mapping from intention to physical movement?
  • Perform the action?
  • Tell what the system is in?
  • If the system is in its desired state?
  • Determine mapping from system state to interpretation?

Fig. 3 – The reducing of gulfs (by Don Norman and Jakob Nielsen – Gestural Interfaces: A Step Back In Usability) – In order to reduce gulfs, provide:

  • Visibility – Using perceived affordances and signifiers
  • Feedback
  • Consistency – Standards
  • Non-destructive operations – The importance of “undo”
  • Discoverability – All operations can be discovered by systematic exploration of menus
  • Scalability – The operation should work on all screen sizes, small and large
  • Reliability – Operations should work; events shouldn’t happen randomly

Fig. 4 – Comparing the direct manipulation aspects of a GUI vs command line interface (by Scott Klemmer)

GUI: (see Ben Shneiderman – Eight Golden Rules of Interface Design)

  • Constant feedback
  • Immediate feedback
  • Input – output
  • Visible
  • Consistent

Command line interface:

  • Better for abstractions
  • More geared towards programming purposes

Related links for further learning:

  1. http://en.wikipedia.org/wiki/Direct_manipulation_interface
  2. https://engineering.purdue.edu/~elm/projects/surrogate/surrogate.pdf
  3. http://www.dubberly.com/wp-content/uploads/2009/01/ddo_article_whatisinteraction.pdf
  4. http://www.interaction-design.org/encyclopedia/gulf_of_evaluation_and_gulf_of_execution.html
  5. http://en.wikipedia.org/wiki/The_Design_of_Everyday_Things
  6. http://jnd.org/dn.mss/signifiers_not_affordances.html
  7. http://www.interaction-design.org/encyclopedia/affordances.html
  8. http://www.jnd.org/dn.mss/gestural_interfaces_a_step_backwards_in_usability_6.html
  9. http://faculty.washington.edu/jtenenbg/courses/360/f04/sessions/schneidermanGoldenRules.html
  10. http://cleo.ics.uci.edu/teaching/Winter10/231/readings/1-HutchinsHollanNorman-DirectManipulation-HCI.pdf

What on earth is “mob programming”!?

The other day I heard Woody Zuill – an Agile Coach at Hunter Industries in San Diego, US – speak about “mob programming”. At first, the simpleton in me thought this meant writing code dressed in fancy suits, wearing shady hats and stylish sunglasses … Woody corrected this presumption fairly swiftly: “mob programming” involves having about 5 developers share one computer and collaborate on writing code.

The main principle behind mob programming isn’t completely new;  there’s the concept of pair programming whereby two developers work together on a single computer. One person will act as the ‘driver’ and writes the code, whilst the other people review each line of code as it gets written and ‘navigate’ the person who’s coding.

One could say that with “mob programming”, the number of people involved in pair programming has simply been cranked up a bit. I quickly learned that there’s more to it:

  1. Working together on a single task at a time – The basic concept of mob programming is that you’ve got a team working as a team together on one task at a time. The team will have one keyboard and one screen (perhaps supported by additional screens just so that everyone can see what’s going on).
  2. Real-time collaboration – The area where I can see mob programming potentially breaking down is the active involvement of the entire team. I can imagine that with a team of 5 developers, some of them might not feel particularly engaged and might start ‘floundering’ a bit as a result. With pair programming this is less of a risk since there just two people sitting next to each other. Also, I can imagine that with mob programming the main task of a dedicated  “navigator” is to ensure that people get a chance to give their feedback and stay involved.
  3. Everyone in the same place at the same time – Ideally, it wouldn’t just be developers forming part of the ‘mob’. If done in a structured way, I can see mob programming working really well if for example product planning and design is done in the same room. Having a UX person, a QA tester and/or a product person in the same room as the developers (as they’re writing code) could be very helpful in terms of removing noise and getting direct feedback.

Main learning point: I guess the thing that I find most appealing about “mob programming” is the collaborative aspect of it. The idea of having a team of people in a room working on the same thing can – if executed well – really help in achieving efficiencies and cross-functional input. Mob programming might not be appropriate for a simple bug fix, but I can definitely see its value when kicking off a new product or when experimenting with new technologies. Feedback and engagement around a particular project/product will be real-time as opposed to operating in silos or having long feedback loops.

Fig. 1 – “Mob Programming, A Whole Team Approach” (talk by Woody Zuill at Oredev Conference 2013)

Fig. 2 – A Day of Mob Programming by Woody Zuill

Related links for further learning:

  1. http://mobprogramming.org/
  2. http://zuill.us/WoodyZuill/
  3. http://mobprogramming.org/mob-programming-basics/
  4. http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/
  5. http://startupproduct.com/mob-programming-comes-to-twitter-a-startup-product-talks-sfbay-meetup/
  6. http://en.wikipedia.org/wiki/Pair_programming
  7. http://www.extremeprogramming.org/rules/pair.html
  8. http://llewellynfalco.blogspot.co.uk/

Seeing the Toyota way in action

After having read a lot about the Toyota way of doing things, I had a chance to visit the Toyota plant in Burnaston, Derbyshire. Every now and then Toyota open up their factories to public visits and I went in there a few months ago to see things for myself. Reading books like The Toyota Way To Continuous Improvement and Developing Products in Half the Time is all well and good but places like the Toyota plant in Burnaston is where they live and breathe “continuous improvement” on a daily basis.

Unfortunately – but understandably – I wasn’t allowed to take pictures. Some of the videos by Toyota UK should help make up for that (see Fig. 1-3 below). Also, I managed to take some notes whilst being driven around the factory:

  1. ‘Bottom up’ approach Even though there’s a clear hierarchy within factory personnel and the individual assembly teams, everyone in the factory is ‘entitled’ to make improvement suggestions or to stop the production process at any given time. When it comes to pausing the production process, employees can simply pull the “Andon” cord to (temporarily) bring things to a halt. It’s an easy way of escalating things, making sure that a problem or bottleneck is dealt with before proceeding with the assembly process. This process is also referred to as “jidoka” which means that the process is stopped automatically in case of any abnormalities (see outline in Fig. 5 below).
  2. Just In Time (‘JIT’) – Toyota operate a “pull” system which means that it only builds to customer orders (see Fig. 5 below). Thus the level of production ‘waste’ is significantly reduced since every component or man hour feeds directly into a car that has already been purchased. Waste is further reduced by being very process driven; our ‘tour guides’ Simon and Julie explained that the Burnaston factory assembly shop alone has about 825 processes, with over 2,000 quality assurance checks throughout the entire production process.
  3. Toyota Production System terminology – During the visit I picked up a whole lot of new terms, some great Japanese words as well as some production specific terms (I’ve included a short glossary in Fig. 6 below). Good examples are “hoshin kanri” and “takt time”. Hoshin Kanri is all about including everyone across the organisation in the strategic planning process (see the visual representation in Fig. 7 below). “Takt Time” is derived from the German “Taktzeit” and is best translated as “meter”, using this as a measure to ensure that production cycle times exactly match customer demand (see Fig. 6).
  4. Toyota Production System artefacts – As I was being driven around the Toyota plant, I noticed some interesting artefacts of Toyota’s approach to “continuous improvement”. For example, I spotted a “process pace maker” board which presumably monitors the state and health of the various processes. I also saw a number of “dojo” areas where Toyota employees can be trained on new/ improved processes and boards indicating “actual” versus “plan”.

Main learning point: Seeing Toyota’s famous production system in action was a great experience. It was awesome to see “lean” and “continuous improvement” being put into practice so consistently and effectively. Not only did I get a sense of the practical implementation of lean manufacturing processes, I also got a real flavour of “lean” on a people level, having employees collaborate around the underlying lean principles on a day-to-day basis. If you are able to go and visit a Toyota factory near you, I’d definitely recommend it!

Fig. 1 – Factory to Forecourt – Introduction to the Toyota Production System (taken from: http://www.youtube.com/user/ToyotaUKTV)

Fig. 2 – Factory to Forecourt – Paint Shop (taken from: http://www.youtube.com/user/ToyotaUKTV)

Fig. 3 – Factory to Forecourt – Assembly Shop (taken from: http://www.youtube.com/user/ToyotaUKTV)

Fig. 4 – Pulling the Andon Cord (taken from: http://www.leanblog.org/2013/06/nice-toyota-production-system-intro-video-from-the-uk/)

andon-pull

Fig. 5 – Key underlying values of the Toyota Production System (‘TPS’) (taken from: http://leandynamix.com/manufacturing.php)

TPS House 1

Fig. 6 – Short glossary of terms relevant to TPS

  • Andon cord – A system to notify management, maintenance, and other workers of a quality or process problem. The centrepiece is a signboard incorporating signal lights to indicate which workstation has the problem (i.e. where the Andon cord has been pulled).
  • Cycle Time – Cycle time covers the time from when the actual work begins on the request and ends when the item is ready for delivery. In comparison, Lead time covers the time from when the feature request is made and ends at delivery.
  • Hoshin Kanri – The main guiding principle behind Hoshin Kanri is that “each person is the expert in his or her own job, and Japanese TQC [Total Quality Control] is designed to use the collective thinking power of all employees to make their organisation the best in its field.
  • Jidoka – If an abnormal situation arises the machine stops and the worker will stop the production line.
  • Poka Yoke – A device that helps to avoid (“yokeru”) incorrect parts from being made or assembled, or easily identifies a flaw or error (“poka”).
  • Takt Time – Sets the pace for industrial manufacturing lines so that production cycle times can be matched to customer demand. For example, in automobile manufacturing, cars are assembled on a line, at a certain cycle time, ideally being moved on to the next station within the takt time so as to neither over or under produce. The cycle time to complete work on each station is often less than the takt time in order to ensure that the customer is never shorted of product.

Fig. 7 – A visual representation of “Hoshin Kanri” (taken from: http://www.hoshinkanripro.com/hoshin_kanri_explained.html)

hoshin_kanri_explained

Related links for further learning:

  1. http://www.good.is/posts/giving-ideas-not-money-a-new-type-of-corporate-philanthropy
  2. http://en.wikipedia.org/wiki/Andon_(manufacturing)
  3. http://www.leanblog.org/2013/06/nice-toyota-production-system-intro-video-from-the-uk/
  4. http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/jidoka.html
  5. http://leandynamix.com/manufacturing.php
  6. http://en.wikipedia.org/wiki/Hoshin_Kanri
  7. http://www.isixsigma.com/dictionary/poka-yoke/
  8. http://en.wikipedia.org/wiki/Takt_time
  9. http://leanandkanban.wordpress.com/2009/04/18/lead-time-vs-cycle-time/