Montana Code School–Week Four

Our class had its first marathon weekend this past weekend, the first of six. We spent all day Saturday and Sunday as a class working on coding projects. Given their intensity, I’m glad these sessions are only held once per month. But it’s helpful to have some extended time to work on projects since our three-hour weekday classes just seem to whiz by.

Mob and Pair Programming

We’ve been spending a lot of time in class working in pairs and groups. The instructors introduced pair programming and mob programming to us in the first week of class, but now that we’ve been starting projects we get to put these ideas into practice. In pair programming, a technique associated with Agile software development, two people sit together and work at one computer. One person serves as the “driver,” the other as “navigator. ” The navigator sits to the side and helps by talking through the ideas that could get turned into code. Her role is strategic and keeps the pair connected to the program’s “big picture.” The driver sits at the keyboard and does the actual typing. His role is tactical as he figures out how to turn the ideas into actual code. Every so often the two rotate so the driver gets to navigate and vice versa. Mob programming is similar to pair programming, except that there are four or five people instead of two, and the team may be sitting around one or two larger computer monitors. All teammates rotate through the driver and navigator roles, switching roles every 15 minutes or so.

I confess that before being introduced to pair and mob programming techniques, if you were to have mentioned computer programming to me, I would have immediately thought of the solitary guy in his bedroom cranking out code. Having grown up in the 80s, that guy would look a lot like Matthew Broderick in War Games or Anthony Michael Hall in Weird Science. While coders still often work alone, pair and mob programming techniques do a lot to turn programming into a collaborative endeavor. Programming with others has additional advantages. The code produced by pairs or teams is usually of higher quality. Navigators have to make others understand their ideas before they can be programmed which leads to better communication and more accurate code. Drivers have teammates who can check for typing mistakes and syntax errors. Team members also report greater job satisfaction when pair or mob programming is used. The diversity of experience that is brought to pair or mob programming enables greater creativity too. For this reason, mob programming has been found to be especially valuable in the early stages of project development when the need to generate lots of ideas is greatest. These cooperative arrangements are ideal for coding novices. By watching and learning from experienced coders, beginning programmers can be incorporated into the programmers’ “community of practice” while contributing to work on real projects.

Not all situations call for group coding. Although it promises higher quality code, group coding is more labor intensive. The amount of code produced per person is less, which increases labor costs. When all the programmers are familiar with the software, as with an application that has already been in production for a while and where the main goal is program maintenance rather than idea generation, group coding is less advantageous. Experienced coders may also become impatient and domineering when paired with novices unless they are made to understand the benefits of coding in groups. Nevertheless, for those like me who may have veered away from coding because of the “lone wolf” stereotype, knowing that independent work can be combined with more cooperative modes makes the possibility of working in tech all the more enticing.

JavaScript libraries: jQuery and P5.js

One of the projects we worked on over the marathon weekend was a simple “to-do list” web application. For this app we had to work with basic structural and form elements in HTML so that users could add tasks to the to-do list. Additionally, we had to add CSS to style the page and make it look pretty. Then we had to work a bit with jQuery, a JavaScript library, to make the page more interactive. Most of our time was spent trying to figure out how to create balloons and have them release when someone checked off a completed task on the to-do list. To make the balloon shape we worked with a different JavaScript library called P5.js.

A JavaScript library is a collection of pre-written code that makes working with JavaScript easier. When using JavaScript libraries you aren’t always reinventing the wheel each time you write a new program since some of the base code has been written for you. P5.js, for example, allows you to jump in and use JavaScript easily to create dynamic shapes and designs. jQuery is one of the more popular JavaScript libraries because it makes working with the DOM—Document Object Model—more efficient. Since the HTML structure and CSS styling of a web page are essentially static, if you want to make the web page interactive or to include animations, you need a way to manipulate the HTML and CSS without permanently changing it. Since the DOM is a representation of the HTML document, you can work with DOM elements and create temporary changes to the HTML and CSS without altering the original files. For example, if you had a button on your web page that you wanted to turn from black to orange and to expand in size when you clicked on it, you would target the button element in the DOM rather than in the HTML file. Then you could program a JavaScript “event” that would be associated with that button element in the DOM and that would result in the button turning from black to orange and expanding in size when the button on the web page was clicked. In this case, the original HTML and CSS remain the same and the change in color and styling is only temporary. If you were to refresh your web page the button would go back to its original size and color.

While you can use HTML to target the DOM, using jQuery makes for a cleaner and simpler process. jQuery scripts, since they are based on JavaScript, can be kept in the project’s JavaScript file, allowing you to keep your programming of dynamic events separate from the static structures and style definitions in the HTML and CSS files. As opposed to JavaScript itself, jQuery works quite nicely across different web browsers so no matter which web browser your user has likely there won’t be any problems running your jQuery scripts.

After a lot of work, our group got our balloon-themed to-do app running quite nicely with a thousand balloons released each time a user checks an item off the to-do list.  No one is going to use our app for actually tracking completed tasks (the app’s a bit too basic for that), but we had a lot of fun inventing tasks and crossing them off just to release all the balloons.

For a look at our balloon-filled To-Do app, click here.

For additional reading on Mob programming:


Montana Code School–Week One

Just as I was finishing my last post, I decided to turn in an application to the Montana Code School to see what happened. Once I submitted the short, online application (which was handled by Submittable – a Missoula tech company!), I went back and took another look around the Montana Code School website and realized that they had a part-time bootcamp scheduled to begin right away, as in the following week! Within a half-day of submitting the application I received a phone call from the school director wanting to set up an interview. So I went in for the interview on Friday and heard later that day that I’d been accepted to the part-time program.

While I’d been thinking of doing some kind of coding bootcamp, I wasn’t exactly prepared to act on the idea quite so quickly. I decided to jump on the opportunity for several reasons. For one, the price, while still significant, was much better than the online course I was considering. The timing also was good—I’d get to start on it right away and since it was part-time I could work on other projects at the same time. Possibly more importantly I’d be able to work with local classmates and get the support of the local tech sector through networking and other events. Since I’m only freelancing and doing odd jobs at the moment, I haven’t been as connected to the Missoula professional scene as I have wanted to be. I’m hoping that doing the code school will help in this regard.


At the same time the school sent the acceptance letter, they also sent a list of “pre-work” that they asked I complete. Probably about 40 hours of work altogether. Most students who had enrolled earlier than I had had already been working on it and were expected to have it finished by the first day of class. Since I wouldn’t get it all done before the first Tuesday, they said I’d be a bit behind for the first couple of weeks while I finished it but encouraged me to hang in there. The “pre-work” consisted primarily of a few online tutorials, mainly on the basics of Javascript, HTML and CSS, but mostly Javascript since it’s more complicated to understand than the other two. Javascript, as I learned, is a programming language used heavily in front-end (user-side) web development, though apparently it has some back-end uses too. Since it loads right into the user’s web browser, the user’s computer doesn’t have to continually call information from a remote server every time it wants to execute a Javascript function. This apparently cuts down on the wait time especially for certain complex web actions like animations.

image of compter and server interaction

How the HTML, CSS and Javascript code gets to your web browser.


The class meets regularly in a room at MonTEC (Montana Technology Enterprise Center), an office building which houses a number of local tech companies and startups. There are about 11 students in the class, many working full-time already and doing the boot-camp on the side. The first part of class was spent both on introductions and on going over some of the productivity methods that get used frequently in web development and that we’ll be using in the class, such as Kanban and Agile. We were then given a stack of sticky notes and asked to write down our “goals” “values” and “resources” as they related to the bootcamp. It was clear from some of the responses, especially for “values” and “resources,” that people were both excited and anxious about the learning ahead. A number of the “goals” that people stated were to be expected: earn more money, have a more meaningful work life, be creative. Others’ reasons were a bit more surprising initially, but made sense. One person mentioned the desire to combine tech with social justice. Amita, the school director, then mentioned that this was a reason more women are getting into tech. As an aside: I think this is actually key. If more people think first of what kinds of questions they can solve or explore through programming, they might be more interested in seeing coding not as an end in itself but as a means to other ends.

Our assignment for Thursday was to start creating a website with the HTML and CSS we had learned so far.


Austin, our instructor, introduced GitHub, the command line and then had us continue work on our basic websites. I’ve known about the command line (Terminal on macs) for a while, but it’s always been super intimidating and I’ve been convinced I’m going to break something or lose something if I use it. Apparently there are a lot of advantages to getting used to the command line though, such as saving time when navigating through your folders and files. It’s also how Austin wants us to “push” our work to GitHub. I’m still scared of the command line, but now that I know a few commands it’s a bit more accessible. One thing you probably don’t want to do from a command line is to remove something. Unlike dragging it to the trash on your desktop, removing a file in the terminal will probably delete it permanently—as in forever. Scary.

I’d played around with GitHub for a short time before the class started, but found the workflow hard to grasp. Basically, GitHub is an online repository for coding projects. That is, it’s a kind of cloud storage for your project files, but also serves as a version control platform. Every time you make changes to your files on your home computer and then “commit” and “push” those changes to the repository in GitHub, it stores a version of those changes that you (or others) can later access. It’s useful if you make a change that results in your code “breaking” (a.k.a “not working”). You can go back to an earlier version to help identify which changes were responsible for the code breaking. It’s going to take me some time to get used to GitHub, but I can see where it can be super useful, especially for collaboration.

Career Change + Coding

When I started this blog I said I would share my experiences and learning about instructional design as a career field.   I also promised to tell about my own career transition with the hope that something in my experience might be helpful to others. In the end, it may be this latter goal that becomes the more significant one. In the two months or so that I’ve been looking into the instructional design field my thinking has already shifted, both in terms of my understanding of the field as a whole and of how I want to position myself within it. Since the ending to this career transition story isn’t written yet, it’s entirely possible that instructional design is not the area I want to move into. Only time and more experience and research will tell. Consequently, I think it will be instructive, both for me and for my readers, to explicitly reflect on my learning process from time to time. And so with this in mind, let me tell you about my current adventure! This will be a story without an ending (at least not yet) as it is still unfolding. But before I begin recounting my current saga, I have to take us back in time a little bit.

Exploring Web Development

I first thought about moving into the instructional design field back when I was still employed at the University of Arizona. I had been using the Desire2Learn learning management system (LMS) heavily for my courses, was experimenting with “clickers” (Classroom Response Systems) and was getting some exposure to the technologies in use in higher ed. Mostly, though, I was not a techie. I’d never coded, never played or been interested in gaming, and didn’t really know the first thing about digital technologies. Outside of what I was doing for my classes, the closest I’d come to working in the digital space was creating a couple of WordPress travel blogs (you can see them here and here) and playing with my iPhone. When it became clear I wouldn’t be staying in my faculty position (a blog post for another day), I started reflecting on my options. I figured it couldn’t hurt to have some technical knowledge regardless of my ultimate path, so I looked online for some free resources to help me learn more about HTML (Hypertext Markup Language) and CSS (Cascading Style Sheets). I found Codecademy and started working through its HTML tutorial. I didn’t get very far into it when I got offered and then accepted a job teaching high school in China. With an overseas move on the horizon, I put off learning more about web development.

Flash forward to this past summer. My high school teaching contract was up and I decided to come back to live stateside. For personal reasons I’ve ended up in Missoula, Montana and have decided to make a go of it here one way or another.   After another side excursion into educational consulting (another blog post for another day), I have come back to the idea of teaching and learning, and especially instructional design and educational technology. Given my self-imposed geographical restrictions, I thought working in edtech would both allow me to remain connected to education and be something I could work on remotely if needed. I’ve also always loved planning and design work. Developing courses, planning and writing curricula and creating learning activities have been the aspects of teaching I’ve always had a passion for, so I thought some kind of edtech development work might be a good fit for me.

To learn more about instructional design and digital learning I set up a couple of informational interviews, both with professionals involved in online learning in higher ed. From them, and then subsequently from reading websites like O*Net Online, it’s become clear that I’m not going to get very far without some background in multimedia production and/or web design. And so I’ve been investigating several different learning options to see which might work best for me in my current situation. So far I’ve narrowed it down to three different paths: studying on my own with books and websites, taking a class or two in Media Arts at the University of Montana, enrolling in an online coding bootcamp like Bloc, or attending a residential coding bootcamp like Montana Code School. I still haven’t made a decision about which of these to choose, though at the moment I’m leaning toward just self-study with some media arts classes or an online coding camp. While a residential camp isn’t off the table, it would have to be Montana Code School since I’m not willing to move for it. The costs associated with relocation added to the cost of a coding bootcamp make the whole thing prohibitive, at least for me. Independent study, while certainly the least expensive option in the short-term, has its drawbacks. Not yet having a technical background or many contacts in the tech industry, I do worry about getting the kind of mentorship that I need. Finding good mentors was always a challenging proposition, yet I’ve learned the hard way that mentoring is crucial to getting you where you want to go. It also ties in with what I’ve learned about collaborative learning and communities of practice in the Coursera eLearning Ecologies class I’ve been taking. While I’m sure I could learn quite a bit just by reading on my own and building my own projects, I think I will need someone I can ask questions of, who can critique my work and who can give me an insider’s perspective on the web development industry. Mainly for this reason I’m thinking hard about online coding bootcamps. I’m especially interested in Bloc because it offers a special designer track where I could get training in both user experience (UX/UI) design processes and applications and some front-end development (the user side of the web). But I’m also trying to talk to a few people I know in the tech world to see whether they think it is worth the money since, like other bootcamps, “they ain’t cheap.” In the meantime I’m starting my own self-study program with books and websites. Even if I decide to do a camp, I’ll still do my own reading and investigation. So you can look forward to future blog posts from me that provide more detail on my web design learning! If anybody has any experience with coding bootcamps, especially the online ones, please leave a comment and tell me about your experience.



Book Review: Design for How People Learn

Julie Dirksen’s book, Design for How People Learn (San Francisco: New Riders/Pearson, 2016), came recommended by Connie Malamed on her list 12 Instructional Design Books You Should Know About. Since Ms. Malamed has also written a review of the book, I won’t go into details about the content. You can read Ms. Malamed’s review here.

Modeling Good Instruction

In many ways, the strengths of Ms. Dirksen’s book lie in how she models the very design strategies she recommends. Her presentation style is conversational and engaging and easily serves as a Dirksen_book_imagemodel for how to communicate information well. The relaxed tone, combined with sometimes irreverent humor, lighten and enliven the theoretical points she has to make. Likewise, her frequent use of scenarios helps illustrate the more abstract design concepts. She is adept at combining text, graphics and a range of explanatory techniques to present complex information. For example, to give the reader a clearer picture of cognitive functioning she builds on a curious, but effective analogy. First proposed by Jonathan Haidt in The Happiness Hypothesis (2006), this analogy suggests that an elephant rider can stand in for the conscious, verbal thinking part of the brain and the elephant itself acts like the emotional, visceral brain.
Through a serious of humorous photos, image captions and explanations, Ms. Dirksen both discusses the analogy in more detail and considers the implications this understanding of the brain has for learning [124-27].

Ms. Dirksen regularly integrates graphics of various kinds (e.g. photos, line drawings) into the text. They are often deployed in ways that reinforce the contrasts or progressions she is describing. Additionally, she uses headings and subheadings liberally. These, combined with the graphics, help chunk the content so that the reader isn’t overwhelmed with large amounts of text. A book intent on introducing brain science and instructional design methods could easily get caught up in abstraction and technical descriptions of research. A strong point of the book is that Ms. Dirksen avoids the technical jargon while still firmly basing her points on the relevant psychological and brain science research. I also appreciated the amount of time Ms. Dirksen spent discussing design techniques for enhancing motivation and emotional engagement. As a new teacher, I remember being primarily focused on the ability of my students to acquire knowledge and build skills. I soon learned, however, that very few students were going to acquire any knowledge I had if they weren’t first motivated to learn it. By devoting several chapters to these learning challenges and the design solutions for them, Ms. Dirksen clearly demonstrates her understanding of key conditions for learning.


The title, Design for How People Learn, suggests that the book could potentially address learning in a very broad sense. Indeed, the focus in a couple of the early chapters on memory and brain functioning could be useful for anyone with a beginning interest in cognition and memory. Nevertheless, it becomes clear that Ms. Dirksen is addressing a particular audience and has developed her book with new trainers and instructional designers in mind. Given Ms. Dirksen’s own experience with corporate training environments, it’s not surprising that she frequently includes stock photos featuring office work and creates scenarios that involve trainers and sales staff. Her choice to appeal to this audience and to focus primarily on the corporate context, however, leads her to make several key assumptions about the goals of learning that are problematic. Consequently, her design solutions don’t really speak to the true range of adult learning situations.

One working assumption in the book is that learning is primarily individual and cognitive. That is to say, learning is about a person getting knowledge into long-term memory. As has become clear to me through my own humanities research and through engagement in the Coursera eLearning Ecologies class, memory and learning are highly social and environmental. I’m reminded, for an immediate example, of the studies that show how a person’s ideas of acceptable body type (and ability to gain or lose weight) can depend on whom they socialize with. While it is certainly important for workers to commit information to memory so that it can be immediately accessible, most work (and living) is not done in isolation. The collective wisdom of teams is often of greater accuracy than individual memory anyway, so it makes sense to leverage it in learning too. For example, one would expect an EMT to be able to recall certain information from his long-term memory. In a life-threatening situation it doesn’t make sense for an emergency worker to be looking to a job aid or reference card. But really, how often do EMTs work alone? In most cases, I would imagine, emergency workers have to work with a partner or as part of a team. In training EMTs, then, wouldn’t it make more sense to focus on ensuring that the EMT can work with his partner so that their collective knowledge can be used most effectively? To concentrate primarily on developing individual cognition is to ignore the real contexts in which people work and live and remember.

The belief that learning is about individual memory, however, rests on another set of assumptions: that improved workplace performance is the goal of learning and that tracking individual performance is the best way to understand if it is happening. Assessing employees’ performance depends on having an accurate understanding of how learning interventions have worked. Companies usually rely on measuring of one kind or another, since social science and business researchers typically use quantitative methods in their analysis. If we accept that a person is a definable base “unit,” individuals become easy to track. One could measure the performance of larger groups (and I’m sure companies do), but the makeup of teams and groups can change and the quality and quantity of individual contributions to group work may be very diverse. This makes evaluating workplace performance difficult, particularly if the goal is to identify talent for promotion or to pinpoint areas of individual weaknesses. Unfortunately, this approach operates on an unsophisticated understanding of the nature of individuals. Biologically it may be fairly easy to identify an individual. But, as much humanistic, sociological and brain science research has shown, people are tied up with other people and the environment in ways that make it very difficult to see the lines of division between them. Developing learning interventions that are measurable may still be a worthy goal and yield important information about the quality and extent of learning. It is important to understand, however, that there are many other possible goals of learning beyond improved workplace performance and that there is likely quality learning happening that will never be revealed through quantitative measuring.

Consequently, the design solutions provided in the Design for How People Learn work best for shorter-term training programs whose effectiveness needs to be evaluated for external reasons. They do not really address the development arc of fundamental skills, such as critical thinking or the so-called “soft skills,” that require more instructional engagement over a longer span of time. To her credit, Ms. Dirksen recognizes that the atomized interventions she mainly describes are not intended for this kind of learning [73-74]. While she also does pay attention to social and informal learning and to designing learning for the environment, she views them primarily as supports to other kinds of formal instruction rather than being primary methods of learning. Given the corporate concern with team work and a growing breakdown of traditional reporting structures in modern business environments, however, it would seem that helping workers learn through collaboration would be part of a trainer’s basic job description.

In any case, Design for How People Learn is a worthwhile read. Many of the design suggestions are easily transferable to a range of instructional contexts. I would go so far as to recommend this book to anyone interested in communications and marketing as I think her recommendations for increasing motivation and supporting habit formation could be used to increase audience engagement generally. Nevertheless, it’s important to keep in mind that a different world of learning exists outside the corporate environment, that learning isn’t always easily evaluated, and that learning has value regardless of its ability to contribute to an organization’s profitability. If a reader looking for an introduction to instructional design can keep these caveats in mind, she will find much of use in this book.

Branched Scenarios with Twine

Twine is a open-source tool that allows you to tell stories and present scenarios in which the reader takes an active role in determining the outcome.  These types of non-linear narratives have certainly existed before (remember “Choose Your Own Adventure”?).  While the narrative can still be complicated to write well, the affordances of the digital environment and hypertext make this kind of storytelling much easier.

I stumbled across Twine a few years ago, but didn’t have the time back then to play around with it.  I came back to it recently as I was doing some reading about branched scenarios.  Scenarios can be great for students who are learning to work with new knowledge. By working through made-up, but realistic scenarios first, students can make errors and self-correct, all without having to worry (yet) about real-world consequences.  Since learners are practicing in a virtual space, they are free to experiment and try things out. And because the consequences of their choices are temporary and reversible, students may in fact be more willing to engage  with the material than if they didn’t get the scenario practice.

“Choosing a General Topic” Scenario

Having taught basic library research methods to new researchers (high school/early college students), I decided to create a scenario for students that would help take them through one of the more difficult steps in a research project: choosing a general topic.   Students stumble in this first step for a variety of reasons, but a big one is just that finding a research topic is a very “wide task” (Don Norman‘s terminology, meaning “lots of possible choices”). And students know that this task is just the gateway to a series of “wide” research tasks, each one of which requires significant decision making. Being able to handle so many choices at each step of the research process is a hallmark of an expert researcher. New researchers, however, are likely to get overwhelmed and become uncertain about exactly where to start. When overwhelmed, students tend to procrastinate. When procrastination happens at the beginning stage of a research project students get in trouble.  By waiting to make decisions about topic focus students reduce the amount of time they have for the other stages of research.

To play the scenario, click here:

Badass Research: Choosing a General Topic

By creating a branched scenario I wanted to give students a chance to explore different possible paths to a good, general research topic. I also wanted to show them how some paths are more efficient and effective than others.  The branched scenario could be used as a kind of application exercise. For example, the student could first read about finding and fact tools in a guidebook like Mary W. George’s The Elements of Library Research: What Every Student Needs to Know. They then could work through the scenario to explore the kinds of research help those tools provide. I conceived of the scenario, however, as an exercise students could complete before even discussing differences between reference tools or the steps of a research project.  By using the scenario to get some exposure to how the tools can be used and what searching for a topic can look like, students may have an easier time later when they are asked to explain how different kinds of reference tools are connected to the research process.

Using Twine to Create Branched Scenarios

On the whole, I found Twine fairly straightforward to use. The user interface is kept pretty simple, and there are only a few things you can do in the main story editor: create a new passage, edit an existing passage, test a passage (to see if it displays they way you want),  and play the scenario.  Individual passages within the story are created with a click of a button. Once you get the hang of it, you can create choices within a single passage that then automatically link to new, discrete passages (this is the branching part).  In the story editor, curved arrows indicate the direction of the linking.  Another good thing about Twine is that it is free.  You can download a version of it to your desktop, or work with it online.


The difficulty with Twine comes when you want to do something more than create a simple branched narrative.  There are three built-in style sets, but if you want to choose different fonts and colors, you will need to know some CSS.  Similarly, if you want add variables or special data  you will need to know some basic markup language. Since I have very little experience with these, I chose not to make my first Twine project too complicated.  However, I did manage to learn how to make a numbered list!  The current version of Twine also isn’t easily set up for embedding multimedia.  Hopefully that will come along in a later version.

The other difficulty I came across had less to do with the software and more to do with writing a non-linear narrative.  The more branches I added to the scenario, the harder it became to keep the different lines of the story straight.  I wished there were some way of highlighting (or color-coding) different lines in the story, so that I could follow the progression more closely.  Without this, however, I’ll need to come up with a better solution for keeping track of how passages are connected.   I read somewhere that it’s best to start with your scenario endings, limiting them to three or four.  I tried to do that, but it still seemed to get a bit convoluted in the middle. If anyone has suggestions for keeping track of the narrative lines, please leave me a comment!



Book Review: The Psychology of Everyday Things

Even though I’ve dabbled in educational technology and pedagogy in the past, I decided that if I’m going to focus on this seriously I’d better up my game. I’m currently looking into formal instructional design certificates, but in the meantime I thought I’d read independently, take a free online course or two, and do some informational interviews.

I’m starting out with independent reading. I recently googled books about instructional design, elearning and project management that instructional designers and technologists have recommended.  From these, I then compiled my own list in Goodreads. I plan to add to it as I go along and to report on some of my thoughts and impressions in this blog.

Book Summary

design-of-everyday-thingsThe only book on my list currently available from my local public library is The Design of Everyday Things, by Don Norman (rev. ed. New York: Basic Books, 2013). While the book doesn’t speak to instructional design per se, its insights into how we use objects certainly has had carryover when designing computer-based objects. In creating its user interface, Apple seems to have applied many of the suggestions on usability and functionality discussed in the original 1988 edition (the version that I read). So I was not at all surprised to learn that the author, Don Norman, served as a Vice President of the Advanced Technology Group at Apple from 1995-1997.

Norman’s main thrust in the book is to apply what he has learned from cognitive science and psychology to come up with a better understanding of design and of what makes an object function well. He presents a list of several main principles of good design: visibility, having a good conceptual model, mapping and feedback. In Norman’s view, well-designed objects provide visible clues to how they should be used (he later includes aural clues in his definition of “visible”). A door with a visible indicator, such as a flat, rectangular plate, is an example of good design because you can intuit both that it should be pushed (not pulled) and where it should be pushed. Badly designed doors leave you wondering what it is you are supposed to do when you see a door (push? Pull? Left side? Right side?).

Providing an accurate conceptual model of the object is also a principle of good design. When the conceptual model is in alignment with the way in which the object actually works, the user can easily predict what effect his action on the object will have or identify where an interaction with the object went wrong. If something doesn’t work as expected and you have the wrong conceptual model, you might not correctly deduce where the problem lies and then become frustrated, thinking it’s you that’s the problem and not the design.

Correctly mapping an object’s controls to the object’s movements is also important. For instance, knobs on a stove should correspond accurately to the stove elements they control. If the knobs on a stove are not clearly mapped to the elements (as illustrated in the image below), then the user has no clear idea which knob corresponds to which element.


Example of bad design: User is unclear which knob goes with which stove element

Norman’s point is that in good design there is not confusion about how the controls and movements are related—users intuitively know because the spatial arrangement of the knobs reflects that of the stove elements (“natural mappings”).


Example of good design: Spatial arrangement of knobs corresponds to the arrangement of the elements

Feedback is also essential. The user should have immediate access to information that lets her know the results of her actions. Without accurate feedback the user is likely to attribute the results of the action to something other than the real cause.

Another major thesis of the book is that there is “knowledge in the head” (memory) and “knowledge in the world” (text, symbols and other mnemonic clues) and that understanding when and how we use each knowledge set can help us better design for functionality. Norman asserts that good design lessens the mental effort a person must expend to use an object correctly by simplifying what “knowledge in the head” a person should remember. By using constraints that reduce alternatives and by incorporating explanation into the design (thereby taking some “knowledge in the head” and making it part of the environment), the designer can help a person use an object quickly, effectively and with the least amount of mental taxation.

My take

I appreciated Norman’s understanding of how the use of memory is central to how we interact with the physical world. Even while we can use this knowledge to optimize design, it started me thinking about the role of the designer in constructing a user’s experience.   One thing that is out of the scope of Norman’s book that designers need to consider is how they use their design knowledge and to what end.   The assumption in Norman’s book is that designing for usability and functionality is the desired end for everyday objects. Even if we accept this premise for many objects (e.g. teapots, television sets, telephones), it quickly becomes problematic without a clearer understanding of what “everyday objects” means and what kinds of objects it includes. In the case of instructional design and computer-based learning objects, there may be different design goals in operation simultaneously. In an online course, education is the primary goal so we may want the LMS navigational tools to be as clear and straightforward as possible. This helps the student focus attention on achieving learning objectives. But there may be learning objects within the online course for which an “easy experience” is not the goal—quite the opposite. For example, maybe one learning objective asks students to design a computer game and the student is asked to use software like MIT’s Scratch. In these cases, we actually don’t want to fully limit the user’s options or provide full explanation, we want the user to assume the role of the designer in creating his own knowledge. Mental effort is desired.

I also see a problem here when these design principles are applied to objects that may be seen as “everyday,” but whose use has much broader social implications. In Norman’s analog world of 20th century telephones, we weren’t able to see the person with whom we were communicating and thus we couldn’t see behaviors that could facilitate communication, such as gestures. In this case, the constraint is absolute and it also only impacted individual, person-to-person communications.  With digital technologies, however, much more is possible in design in terms of what individual and social behaviors a technology can constrain or afford. For instance, the incorporation of emoticons to facilitate emotional expression in Facebook was a choice.  If the goal is to facilitate communication, this decision can be a good one in many instances. Emoticons can help the user represent his own emotional state or interpret that of a friend more accurately than relying on text alone.  However, decisions have consequences. You can “like” or use an emoticon to respond to a post in a second. In order to respond in a more thoughtful, deliberate manner, however, you must expend additional energy to actually compose a written response. In this case, the platform is made to favor automatic emotional reaction (easy) over reasoned thought (more difficult).  On top of that, your “like” of your friend’s post can be seen by all of his friends too, and someone who may not have sufficient context for understanding your reaction may choose to respond.  While such affordances can facilitate individual communication, they may actually create miscommunication at the social level.

It is important to note, however, that users do have agency in their use of the technology. It is possible that someone external to the technology could “hack” it and impose an additional constraint that would afford a different kind of behavior, such as a teacher who monitors a student’s posts and requires thoughtful, written reflections for a grade in a class.  Individuals also have certain controls within technologies like Facebook over how their posts appear and to whom. However, it is important to understand the default state of the technology because, for better or worse, that is what will be most usable to the greatest number of people.

There are certainly advantages to promoting ease of use for both the user and technology companies.  Greater usability ensures that the platform is widely accessible, which in turn can make it more financially successful. However, these choices can also have downsides. These downsides may often go unrecognized in an era where technology on its own is seen as playing a salvific role in society. The main concern, as I see it, is making sure technology and instructional designers are aware of the assumptions about optimal use on which a particular technology is based.  So, while I value the design principles Norman puts forth in this book, before technology creators take usability as their main design goal they need to reflect on the larger forces driving that goal, the many implications their design choices might have and start asking if there aren’t other possible design goals with greater social value.





This is my first post to this blog.  I titled it why because I figured anyone who reads this blog will want to know my reason for starting it.  There are a couple different reasons actually…

First, I want a space to experiment with new design methods and digital tools, to reflect on what I learn, and to get feedback from others. I am of a generation that has had one foot in and one foot out of the digital world. As a high school and college student I used long-hand to take course notes and I typed college and scholarship applications on a typewriter.  My use of computers was limited to word processing. The move to internet, iPads, and apps has taken place since I’ve been out of college.  In the intervening years I have played around with social media, started a travel blog, and tested a variety of online platforms and technologies.  Nevertheless, none of this inquiry has been very systematic. Starting with this blog, I aim to be a bit more thorough in my approach by documenting and reflecting on the design ideas and tools I encounter. I also hope to hear back from others on their own experimentation with digital technologies and thereby expand my view of what’s out there and what’s possible.

Second, I’m currently in the middle of a career transformation and want a way to share my experiences with others.  My career transition has been underway for a while, and while I’m homing in on a particular field (instructional design and e-learning), the transition process is not yet complete.  I’ve personally benefited from online forums for career changers, such as The Versatile PhD.  By sharing my story I hope I can provide some help and support to other career changers, especially ABDs and PhDs looking to move beyond academia, even if their paths are different from mine.

While I still feel like I’m in the midst of great change, I’m coming to realize that moving into this blog and into a career in e-learning and instructional design is less a break from the past than I initially thought. I’ve long had interests in design and in the way people combine different modes–text on tangible objects, video with text, audio with image and text–to communicate with others or to represent themselves to themselves.  There are actually many examples of representation and communication where modes are combined (think books-on-tape or illustrated manuscripts). In fact, much of the work in my “past life” concerned how oral, visual, and written modes were combined in ancient times, how cultural works were redesigned using material from the past, and how those redesigns impacted how early cultures understood who they were and where they came from.  I’m actually quite excited at the prospect of learning how design theories might help me articulate ideas about cultural formation that I’ve worked on previously. At the same time, I look forward to applying my knowledge of literacy and multimedia, gleaned from the study of the pre-modern period, to help solve more contemporary problems and issues.