Posted by: Alexandre Borovik | September 12, 2010

How good software makes us stupid

An article by Dave Lee on the BBC website: the title sums it up perfectly. It quotes an earlier article by Bill Thompson Between a rock and an interface, which, in its turn, quotes a research paper by Christof van Nimwegen on user interfaces, The paradox of the guided user: assistance can be counter-effective (2008). I quote an abstract:

This project investigates the conditions under which externalizing interface information by interface controls influences users’ performance in solving problems requiring planning. Our main research question was: in tasks where planning is required, which interface style leads to more plan-based behavior, better strategy, and consequently better task performance? And besides immediate performance, which interface style causes better knowledge of the tasks and solutions afterwards in a transfer situation (with altered task/interface circumstances), or when a severe task interruption occurs? To answer our questions, two series of controlled experiments were conducted using two interface styles: one version in which certain information is externalized onto the interface (Externalization) and another version where this is not done (Internalization). In the Externalization version the operators in the interface conveyed information, in the Internalization version this was not the case. The first series of experiments used a computerized isomorphic version of the well-known “Missionaries & Cannibals” problem, called “Ball & Boxes”. The second series of experiments used a more realistic office-like application called “Conference Planner”. Immediate and delayed performance when using the Externalization interface, was worse than when performance use the Internalization interface. Also transfer of skill was worse for users of the Externalization interface, both to another task, and to another interface. These users were characterized by display-based behavior. Subjects that used the Internalization interface imprinted relevant task and rule knowledge better and were not affected by a severe interruption in the workflow, whereas Externalization subjects were. We conclude that users who internalize information themselves behave more plan-based, are more proactive and ready to make inferences. This in turn results in more focus, more direct and economical solutions, better strategies, and better imprinting of knowledge. This knowledge is easier to recall at a future point in time, and is better transferable to transfer situations where the interface, the task, or both were different, less vulnerable to a severe interruption, and better applicable to transfer situations. Human-computer interaction designers can take advantage from considerations that go beyond plain usability, even when they go against common sense. In designing interfaces we have to take care with providing interface cues that give away too much information, and must design in such a manner that the way users (should) think is optimally supported, which in turn could help the software to achieve its specific goal. Examples are situations where risky and complex tasks are performed, and where a user suddenly is confronted with a new situation. One can also think of situations in which interruptions are commonplace, or where operations come with a cost and direct solutions without deviations are the aim. Based on our findings an interaction framework is proposed that can guide decisions regarding interface design.

I had a similar experience when I used two software packages in my classes. I will write about it shortly.


Responses

  1. Hi Sasha, you said you would write more, “shortly”. I don’t know when that may be, but I have trouble understanding the abstract you quote. The BBC articles that you cite are helpful, but it’s hard to see that the abstract is talking about what is in those articles. The terminology of “internal” and “external” is not well chosen, I think. I thought at first the distinction might be that between, say, writing a tex or html file directly, “by hand,” with all the tex or html codes visible and so “external”, as opposed to writing with a wysiwyg program, where the codes are “internal”, hidden from the writer. But this may be the reverse of how the terminology is intended in the abstract, where it seems “external” means simply giving hints, and “internal” means not.

    Beyond this, the abstract is badly written, with sentences like “This knowledge is easier to recall at a future point in time, and is better transferable to transfer situations…”
    Why not say, The knowledge is easier to recall and more transferable? I know you didn’t write the abstract, but you quoted it!

  2. Point taken. I’ll try to respond.

  3. @David: the abstract that you are so critical of is an a abstract of a Dutch equivalent of a PhD thesis written by a Dutch computer scientist. You should not be too harsh on his use of English. But the thesis is very interesting indeed. I’ll write on it later.


Leave a reply to David Pierce Cancel reply

Categories