index.md (5485B)
1 --- 2 title: "The design of everyday programs" 3 description: Even command-line programmers should think more like designers. 4 date: 2016-10-22 5 categories: 6 - Programming 7 - Data Science 8 tags: 9 - Design 10 - Git 11 --- 12 13 Several fellow researchers at the FAA have backgrounds in cognitive 14 neuroscience and are new to applied research. We recently started a book club 15 through the [South Jersey chapter of the Human Factors and Ergonomics 16 Society](https://southjerseyhfes.wordpress.com/) to learn more about human 17 factors and user experience research. Our first reading was [The Design of 18 Everyday 19 Things](http://www.jnd.org/books/design-of-everyday-things-revised.html) by Don 20 Norman, and it’s already influenced how I think about design. Norman focuses on 21 how designers can apply concepts from psychology to the design of “things”, but 22 these lessons apply to any interaction—such as the use of the popular revision 23 control system (RCS) [Git](https://git-scm.com/). 24 25 Git was created to meet the needs of programmers working on the Linux operating 26 system. Other interfaces are available for it, but it primarily exists as a 27 collection of command-line utilities; this strongly informs its design. People 28 typically associate design with graphical and physical interfaces (e.g. web 29 pages and control panels), but good design helps everything. Command-line 30 arguments and prescribed sequences of separate commands are “design decisions”, 31 and poor decisions have made Git harder to use. 32 33 In The Design of Everyday Things, Norman stresses the importance of conceptual 34 models. Norman defines a conceptual model as “an explanation, usually highly 35 simplified, of how something works.” A “highly simplified” conceptual model 36 isn’t *exactly right* but it’s good enough to get the job done. People don’t 37 need to know how the accelerator pedal of a car changes the flow of air and 38 fuel to the engine; it suffices to understand that pressing the pedal makes the 39 engine—and therefore the car—go faster. However, bad models cause problems, and 40 people who are new to Git are likely to have a poor conceptual model of the 41 program. 42 43 Users who’ve switched to Git from another RCS (e.g., CVS or Subversion) are 44 accustomed to systems that use a central repository; the repository is “home” 45 to the code and programmers sync their work to it. In contrast, Git is designed 46 for decentralized work; each programmer has their own full repository and 47 merges their code with everybody else’s. While a conceptual model based on a 48 central repository is inappropriate for Git, users without previous RCS 49 experience are in even more trouble. Most [follow a sequence of commands 50 learned by rote](https://explainxkcd.com/wiki/index.php/1597:_Git) with little 51 intuition about how the system works. In the case of Git, bad mental models 52 cause users to make mistakes that they can’t fix (see [Oh Shit, 53 Git!](http://ohshitgit.com/) for common examples). 54 55  56 57 In the open source community, the solution to bad mental models is tell users 58 that they need a better understanding of how the system works. When I shared my 59 frustrations with experienced Git users, they recommended that I read the free 60 online book [Pro Git](https://git-scm.com/book/en/v2) by Scott Chacon and Ben 61 Straub. The book did alleviate my frustrations, but I also spent a lot of time 62 reading about inner workings of Git that aren’t relevant to my work. It was 63 like learning how internal combustion engines work just to find out which pedal 64 makes a car go faster. 65 66 The key to bringing good design to command-line programs lies in understanding 67 users’ mental models. Instead of expecting users to learn the details of how a 68 program works, developers should focus on helping them build a simple “good 69 enough” conceptual model. In their book, Chacon and Straub introduce excellent 70 metaphors for several concepts in Git, but follow these with details about the 71 system. Good introductory documentation would focus on these metaphors and save 72 the detail for users who need it; Git’s documentation is notoriously useless 73 for non-expert users (the [Git man page 74 generator](https://git-man-page-generator.lokaltog.net/) parodies the 75 experience of reading Git’s docs). 76 77 Developers should also understand how people learn to use their systems. Norman 78 calls the signals that tell people how they can interact with things 79 “signifiers”. A command-line program will necessarily rely on textual 80 signifiers, and developers should focus on making them easy to find and 81 understand. For example, the “git-status” command does a good job of explaining 82 what actions users can perform on files in their working directory, but doesn’t 83 explain what these actions mean (and this is arguably the most user friendly of 84 Git’s commands). Git also uses many of the same commands as CVS and Subversion, 85 but from the perspective of the user they often serve different functions in 86 each system. We can consider a well-known command such as “checkout” to be a 87 signifier; it's bad design that it does something different in Git vs. 88 Subversion. 89 90 Developers must understand that *any* interface they create for their program 91 is design work, and that good design will make their program easier to use. 92 Norman warns readers that “designers are not typical users”; developers should 93 take note. The time users spend learning the intricacies of a program would be 94 better spent using it. 95