Steve Jobs

stevejobs.png
Then sing, ye birds, sing, sing a joyous song!
        And let the young lambs bound
        As to the tabor's sound!
We in thought will join your throng,
      Ye that pipe and ye that play,
      Ye that through your hearts to-day
      Feel the gladness of the May!
What though the radiance which was once so bright
Be now for ever taken from my sight,
    Though nothing can bring back the hour
Of splendour in the grass, of glory in the flower;
      We will grieve not, rather find
      Strength in what remains behind;
      In the primal sympathy
      Which having been must ever be;
      In the soothing thoughts that spring
      Out of human suffering;
      In the faith that looks through death,
In years that bring the philosophic mind.

 

William Wordsworth, Ode: Intimations of Immortality from Recollections of Early Childhood

What's Wrong With Schooling

| 8 Comments

When others find that my wife and I have decided to homeschool our children inevitably they ask, "Why?" I've always tried to answer this question with tactful precision and achieved a varying degrees of success. Today I discovered a description that defines how I feel about what's wrong with public schooling in a wonderfully clear and precise way. It's found in The Cambridge Handbook of the Learning Sciences and authored by R. Keith Sawyer:

By the twentieth century, all major industrialized countries offered formal schooling to all of their children. When these schools took shape in the ninetieth and twentieth centuries, scientist didn't know very much about how people learn. Even by the 1920s, when schools began to become the large bureaucratic institutions that we know today, there still was not sustained study of how people learn. As a result, the schools we have today were designed around commonsense assumptions that had never been tested scientifically.

Sawyer goes on to outline these problematic "commonsense assumptions" as follows:

  • Knowledge is a collection of facts about the world and procedures for how to solve problems. Facts are statements like "The earth is titled on its axis by 23.45 degrees" and procedures are step-by-step instructions like how to do multidigit addition by carrying to the next column.
  • The goal of schooling is to get these facts and procedures into the student's head. People are considered to be educated when they possess a large collection of these facts and procedures.
  • Teachers know these facts and procedures, and their job is to transmit them to students.
  • Simpler facts and procedures should be learned first, followed by progressively more complex facts and procedures. The definitions of "simplicity" and "complexity" and the proper sequencing of material were determined either by teachers, by textbook authors, or by asking expert adults like mathematicians, scientists, or historians - not by studying how children actually learn.
  • The way to determine the success of schooling is to test students to see how many of these facts and procedures they have acquired.

This traditional vision of schooling is known as instructionism (Papert, 1993). Instructionism prepared students for the industrialized economy of the early twentieth century. But the world today is much more technologically complex and economically competitive, and instructionism is increasingly failing to educate our students to participate in this new kind of society. Economists and organizational theorists have reached a consensus that today we are living in a knowledge economy, an economy that is built on knowledge work (Bereiter, 2002; Drucker, 1993). In the knowledge economy, memorization of facts and procedures is not enough for success. Educated graduates need a deep conceptual understanding of complex concepts, and the ability to work with them creatively to generate new ideas, new theories, new products, and new knowledge. They need to be able to critically evaluate what they read, to be able to express themselves clearly both verbally and in writing, and to be able to understand scientific and mathematical thinking. They need to learn integrated and usable knowledge, rather than the sets of compartmentalized and decontextualized facts emphasized by instructionism. They need to be able to take responsibility for their own continuing, lifelong learning. These abilities are important to the economy, to the continued success of participatory democracy, and to living a fulfilling, meaningful life. Instructionism is particularly ill-suited to the education of creative professionals who can develop new knowledge and continually further their own understanding; instructionism is an anachronism in the modern innovation economy. (R.K. Sawyer, The Cambridge Handbook of the Learning Sciences, Cambridge University Press, 2006.)

It's not that instructionism isn't good, it's that it's incomplete. It was never designed to be more than an instantiation of, and a response to, these fundamental "commonsense assumptions" about what it means to be educated.

I believe there are probably as many different approaches to education as there are people, but this approach, embodied in instructionism is the problem. As long as any educational pursuit approaches learning from this perspective alone, young people will continue to enter the global workforce unprepared for the demands of the modern economy.

I want my children's minds to be factories for new ideas, not just warehouses of facts and procedures.

What Left Xerox PARC

| 1 Comment

This year marks the 40 year anniversary of the Xerox Palo Alto Research Center, usually called Xerox PARC, or now just PARC. Ethernet, Laser printers, the mouse, the Graphical User Interface (GUI) and even the Dynabook all came out of this uncommonly innovative place, and then promptly left the building. In many ways, Xerox PARC is more famous for the innovations that it couldn't hold onto, than the ones it could retain and capitalize on. Today, PARC will celebrate the start of their fifth decade at its Palo Alto headquarters, and I think it's worth looking back to see what can be learned.

What Left

The Dynabook started as a concept created by Alan Kay in 1968, just a few years before PARC was established on July 1, 1970. While the focus of the Dynabook was to give children access to computing, the Dynabook proved to be the forerunner to both the laptop and now the super-successful iPad. In 1973 Xerox released the Xerox Alto which some say was originally called the interim Dynabook.

When the Xerox Alto was released with it came Ethernet, a Graphical User Interface and the novel mouse used for pointing and clicking instead of the then popular command line user interface. This was the beginning of what we think of as modern computers. Surprisingly, it wasn't until 1981 that these amazing inventions were put into a commercial product: the Xerox Star. In fact, the Alto was never intended to be a commercial product! Ethernet has now become the hardware layer of the Internet and a bit-mapped display and graphical interface the standard for modern human-computer interaction. If that wasn't enough, the Alto included the first WYSIWYG document preparation systems, new advanced programing language, Smalltalk, and one of the first network-based multi-person computer games! Of all those iPhone and iPod touch games everyone is playing these days, almost every one of them is largely written in Objective-C which was an attempt to bring Smalltalk like constructs to the C programming language. All these inventions in one place, at one time!

On the bright side, about 1 year before PARC was founded, Gary Starkweather (Mac greybeards will know him as the father of Colorsync 1.0) modified a Xerox copier and invented the first laser printer. Eight years later, in 1977 the Xerox 9700 was released and this technology quickly became a multi-billion dollar business for Xerox. Leading up to this, a legal misstep led to Xerox being forced to license their entire patent portfolio to competitors. Xerox's market share of the U.S. photocopier market was said to drop from almost 100% to around 14% in 4 years. While certainly a problem for Xerox, I count the laser printer on the bright side of things because they were actually able to see the future and produce something commercially viable. For laser printers at least, Xerox was able to take the idea and make it reality.

All this background should convince you that when it comes to taking the future of technology to the masses, the stakes are high and yet still this company found it difficult to capture the brilliance of their ideas and make them into actual products. There are probably many and multifaceted reasons as to why Xerox PARC fumbled, but I'd like to focus on one particular facet, that of transferring knowledge from one human to another.

The Social Side

In 2000, John Seely Brown published a book entitled, The Social Life of Information with his colleague Paul Duguid. Brown was a director of Xerox PARC for 10 years. Now, I've watched and enjoyed the melodramatic Pirates of Silicon Valley. I've worked at Microsoft in the Macintosh Business Unit for 10 years. Currently, I'm an iOS consultant and developer. I've read and experienced part of the Mac folklore. But his explanation for why Xerox lost their crown jewels to Apple and others was both new to me and very applicable to everyone in the tech industry.

If Only Xerox Had Known What It Knew...

Brown begins the argument that in tumultuous times, moving knowledge in a company is critical. In fact, much of the knowledge a firm needs to stay ahead of competitors already exists in the firm! Sadly, this knowledge can not always be found, and when it is, it is often impossible to move it to where it can make a difference. In contrast, other firms find that their problem isn't finding the knowledge already present, but keeping it from moving out the door! Sometimes knowledge is sticky and sometimes knowledge is slippery. To quote Brown, "What knowledge the firm can hold on to, it can't use. And what it might use, it can't hold on to."

A side note: For most of the time that I worked at Microsoft the MacBU was located in building 115 which was next door to a huge part of the Microsoft Research facilities. I often took advantage of this by attending the tech talks and technology demonstrations open to all employees. It was a wonderful experience to just talk to those brilliant engineers and have them show me "their baby" and enjoy their enthusiasm. It wasn't until the years brought with them the realization that so much of what I saw, would never make it into any product from Microsoft. When ever I saw another company, big or small, bring to market something the likes of which I had already seen in MS Research I would ask my self, "Why? Why can they do it and we can't?" I never discovered a satisfactory answer to this question, but continued to watch billions and billions more of Microsoft's money be poured into Research. To this day, I think Microsoft's core competency is throwing money at problems and hoping the planets align and something comes out of it.

Now to the part about Xerox and Apple:

Yet most of the extraordinary knowledge generated at PARC never crossed the boundary between the scientist in Palo Alto and the development engineers in Dallas or the management in Stamford. The engineers found the scientists arrogant and almost unintelligible. Management found them naïve and unrealistic. The scientists, for their part, regarded almost everyone in the corporation outside their own community as "toner heads" -- unable to think of the world beyond photocopiers.

The story and the knowledge, as everyone knows, did not end here. For the essence of what had been invented by Xerox in Palo Alto ended up being put into production by Apple down the road in Cupertino. In 1979, Xerox managers invited Steve Jobs, one of Apple's founders, to PARC. Once inside, Jobs was able to see what Xerox management could not, the potential of what PARC had generated. So Apple licensed what it could and replicated what it could not. The knowledge that stuck within Xerox leaked readily through its front door.

Who to blame?

So was it that the management had no vision or that they couldn't work with the brilliant scientists? Was it that the manufacturing engineers couldn't "speak" the language of the scientists? Was it the arrogance, naïveté and unrealistic expectations of the scientists? Of course the answer is: Yes. But the answer could just as easily be, that the folks at Apple understood the folks at Xerox in a deep and fundamental way because they were working on the same problems! For the Xerox scientists, they were dying for someone who understood them, and when they found that the Apple engineers "spoke their language" the knowledge flowed freely. It was a social thing.

The point isn't so much recognizing that people make mistakes and often find others difficult to work with. The point is that developing something new, harnessing knowledge and transforming it into a product is just as much a social challenge as it is a technical one. Getting the right people technically is just part of it, and in many ways Microsoft and now Google are living proof that a high-density collection of brilliant people do not innovation make. The social chemistry between the people is at least as important as their raw intellectual horse power.

But things get really tricky, really quick. Anyone with a modicum of experience knows that Engineering is the study and application of trade offs, but how do you know what to trade and what to off? I've been in meetings where a new and "naïve" developer has proposed massive and sweeping changes to a large code base. The old guard, for good reason, had plenty of ammunition and experience to shoot down the new ideas, but what if? What if the changes turned out to be critical? What if, the short run loss would be far outweighed by the long run gain? The Xerox manufacturing engineers in Dallas I'm sure had many good and intelligent reasons to stand by the successes of the past against the uncertain possibilities of the future. But what if...

It's not just that technical judgement is tricky, it's judging people too. My coworkers who have found me hard to work with might enjoy this story. I was 18 when I first started working at Microsoft. Gary English, a former manager on Apple's QuickTime team had been hired at Microsoft and was looking for another Quality Assurance Engineer, to use Apple's parlance. Grant George over on the Office team had seen my resumé and sent it to Gary. He looked at it, brought me in for an interview and I was hired. A few months later, he, my Dad and I were having lunch and my Dad asked, "Why did you hire my son?" (I never quite know what my Dad is going to say...) I'll never forget Gary's answer, "Well, he had about half of the technical qualifications, but when I found out he was an Eagle Scout and understood the patrol method and came from a large family I knew he would get along with people, and more than half of my problems are people problems, so I knew I'd come out ahead." Now, I'm not about to defend Gary's logic in every case, but the point is that he was making a decision based largely on the social dynamics of the candidate, not on just the technical capability alone. What can I say? I'm glad he did. :-)

Since then as I have been in a position to hire people on my team and observe team chemistry in other teams. All I can say is that the social environment has been for me the number one factor in my personal job satisfaction as well as the explosive X-factor in both success and failure on the teams I have had the opportunity to closely observe. I'd go one step further and say that for an engineer, one hires very often for technical ability not just because the job requires it, but because there's an internal desire to have one who can "speak the language" and really relate to. This socially driven sub-text cannot be ignored in the hiring process. You've got to belong too.

There's yet another problem, and that is that so much of organizational theory set to attack just these sort of knowledge transfer and team problems have as their unstated premise that the people in the firms are homogeneous in nature. Talk of "cross functional teams" ignore the reality of the deep social impact these kinds of teams cause, and therefore, more often than not, the "cross" becomes dysfunctional. I have worked with and stood in awe of brilliant engineers and I can tell you from first hand experience, there is a huge range in the quality of engineers. But it's not just the range, but that the best are so much better than the rest. However, if you have found a few rock stars, a sure way to lose them is to put them on a team where the chemistry is wrong. When rock star engineers leave, their knowledge goes with them. Managing team dynamics is way more important than assigning and organizing the work.

Specialization and Silos

Brown makes the point that, as Adam Smith emphasized, division of labor leads to specialized teams developing specialized improvements to their processes and jobs. But as these teams focus, that very focus often causes them to "develop away from other groups" creating problems of coordination. Management then steps in to "solve" the coordination problems with "process" which in turn often has the unintended side-effect of quelling the creativity! If at this point, you haven't witnessed this kind of behavior in an organization first-hand, well, I'm happy for you, and you haven't been at your current job long enough. ;-)

Tightening controls for coordination almost always leads to reduced creativity, except maybe at Apple. ;-) Certainly their "skunk works" project to develop the Macintosh was an example of loosening control to encourage creativity, but I speak of the current Apple. Apple's organizational secrets are just that, secrets, but one thing I have continued to hear over the years is how organizationally siloed they are. Each team has very little knowledge of the other teams and only a select few interface between the teams and can see the "big picture." While this design might be simply a result of Apple's penchant for secrecy, it might also be one of the key factors in Apple's ability to bring to market new ideas successfully.

The downsides of this super-siloed organizational design is of course that all coordination must be managed by a few and those few will take an extraordinary amount of heat as a result of the friction between groups. On the other hand, over time this very friction could develop into a set of defined boundaries and expectations that leave the several groups fully able to innovate and be creative without the overhead of internal group process. Their process then is their people who skillfully manage the teams both technically and socially. Of course only a few know a great deal about what makes Apple a place where knowledge and creativity can stay and flourish. But who knows, maybe Apple learned one more thing from Xerox way back then, and that one more thing wasn't technical at all, it was the social nature of ideas and development.

Environment

A major reason Xerox lost what they did to Apple was that the Xerox PARC scientists found in the Apple engineers people who looked at the world in a similar way. This similarity in practice and desire to conquer similar problems created an instant social bond and identity between the two groups. It was this social acceptance and mutual understanding centered around a common practice that made it work. But, keep in mind, all it did was make the knowledge transfer happen, there was still a long way to go to turn invention to product innovation. Apple saw the future in 1979, but it wasn't until 1984 that they could actually begin to make the ideas reality. Speaking of this delay Brown says:

This is not a criticism of Apple. Rather, it is an acknowledgment of the organization required to take even something as appealing as the GUI to the marketplace. Within Apple there were many bridges between communities and practices to build. The Macintosh was for a while something of a pariah. The larger Lisa and the older Apple II drew most resources. There are accounts of pitched battles between the old and the new, where the lines of confrontation resemble those between the photocopier stalwarts and PC visionaries within Xerox.

In these conditions, the journey from new invention to robust innovation required hard work, tough decisions, contentious resource allocation, power struggles, hard-won organizational commitment, leadership, and a great deal of trust. It took an organizational leap of faith to build the multidirectional, cross-communal links from R&D, through engineering, manufacturing, sales and marketing, to the market itself. Nothing was preordained. Indeed, the organizational effort was significant enough that developing the knowledge redeveloped the corporation. In all, moving from initial idea to market involved much more than taking it from PARC to Cupertino.

It's easy to sit back and observe large corporations succeeding and failing and take time to opine as to why and what they should have done. The social angle that Brown takes on this interchange between Xerox and Apple brings so much more richness and color to the challenges of any corporation trying to take an invention to market. Certainly, as Brown says, nothing is preordained. When we see successes and failures in the tech industry, the lesson of Xerox is that there is more than meets the eye. This world turns on very small hinges. So many small, but significant things have to go right, so frequently, that it's a wonder to me that anything makes it at all. I suppose maybe that's why you have to love this stuff so much to keep at it. The challenge is so difficult, that only those who love it, stick at it long enough to begin to sense the subtle signs of success.

Names

| 2 Comments

Only hours ago the 1.0 release of Names hit the App Store. Names is an iPhone app that helps teachers quickly learn student names. I wrote this app because I'm great at remembering faces, but terrible at remembering names.

Icon.png

For the last 7 semesters I taught a non-accredited iPhone dev class at BYU Idaho. We never had more than 25 students, which made it even worse when I would forget a name. I remember one semester a student walked in, named Brandon, but for some reason, to my brain he was named Joe. I would constantly call him Joe, and he eventually stopped coming. I felt terrible. I knew I needed to find a better way. That was the genesis of Names.

How It Works

Editing Picture Name

On the first day of class, as the students leave the classroom, you stand by the door and using your iPhone or iPod touch snap a picture of each smiling face. Add the pictures to Names and practice until you've got them all down. It's that simple.

Here are my favorite parts of this app:

Clean Design

List View

I know this is biased, but I really like the look and feel of the app. I'm not doing anything visually stunning, but with basic controls and simple views I think I've distilled this application down to its essence. This is hard work! Maybe some day I'll show all the iterations and ideas that lead to this, but even though the visual flair could be improved, this app doesn't get in the way and I'm very happy with that.

Casual Review

Review Screen

The review screen comes from talking to and watching teachers trying to learn student names. Frequently they would simply arrange student photos with names on the table. Others would use computer printouts and quickly scan the photos with names right before class. This screen allows for quick review and editing of photos. You'd be surprised how different students look from the student record photo taken years before. The subtle edges of each photo before and after hint when there's more to see.

Practice

Practice Screen

When you enter the practice portion of the app, you have a stack of faces and need to select the correct name from three nameplates. While this might seem obvious, it's really a rare solution. First, it's fast. Tapping is all that is needed and you can move through a huge class super quick. Flip transitions that simulate actual pictures or flashcards are slow and lose the connection between the two sides of the card. Second, it mimics real life. In the classroom, a teacher is looking at a face, and then trying to recall a name. That's the scenario and this arrangement helps you perform in the scenario in which you will need the recall. And third, the smooth animations reinforce correct and incorrect guesses without taking too much time. The animations draw the eye to the connection between the name and the face and reinforce the learning.

Focus

One could say that this is simply a flashcard app and in a way, that's right. On the other hand, I'd recommend that any college professor try to use any other flashcard app out there, on the iPhone, iPad, Mac or Windows and see how the experience compares. You see, it's the focus that makes this app great. Sure, you could use Names to memorize anything that has a picture and a name, and I don't go out of my way to make that hard. However, this app is about learning people's names fast. Making a general purpose flashcard app makes it hard to nail that core scenario because you have to add other clutter to support the general use. With a focus on the core scenario, the UI that doesn't matter just disappears. Simple focused solutions. That's what I love about building iPhone applications and Names is no exception.

I'll write more about Names later, but for now check it out for yourself!

app-store.png

Special Event Sep 2010 Predictions

When Apple announced the September 1st Special Event last week, I was finishing up a project, (yes another iPhone app!) and I couldn't take time to fill in the rumors for Prediction. Once the app was solidly on it's way in the review process I took some time to back fill the rumors for Prediction and to my surprise, found 29 rumors, going through my neglected RSS feeds! The last time I had that many rumors for an event was when the iPad was announced at the beginning of this year, and then there were 38 rumors. My point in saying all this is simply that tomorrow's special event is going to be big. It also marks the first Apple keynote to be streamed live for a very, VERY long time. I hope the Internet can handle the load!

Here's the info for the live video stream: http://www.apple.com/pr/library/2010/08/31alert.html

Here are the rumors I've come up with along with my predictions. If I've missed any, please let me know!

My predictions for Special Event Sep 2010

  1. iPod Classic Retired: Wrong
  2. New Apple TV Remote: Correct
  3. iOS 4 for iPad: Wrong
  4. Liquidmetal: Wrong
  5. Redesigned iPod Nano Announced: Correct
  6. Touchscreen iPod Nano: Correct
  7. iPad mini: Wrong
  8. iMac touch: Wrong
  9. Apple TV 1080p Video: Wrong
  10. Electronic Wallet and Payment System: Wrong
  11. Longer iTunes Song Samples: Correct
  12. iPhone 4 Antenna Revision: Partially Correct
  13. 99 cent iTunes TV rentals: Correct
  14. Game Center for iOS Released: Correct
  15. iOS 4.1 Released: Correct
  16. Next Gen iPod touch Released: Correct
  17. Next Gen iPod touch Announced: Correct
  18. New Apple TV: Correct
  19. Apple TV renamed iTV: Correct
  20. Apple TV App Development: Correct
  21. Wi-Fi Sync: Wrong
  22. iPod touch Front-Facing Camera: Correct
  23. iPod touch with Retina Display: Correct
  24. Web-Based iTunes: Wrong
  25. iTunes Music Subscription: Wrong
  26. A4-Family CPU in iPod touch: Correct
  27. 5-Megapixel Camera with Flash: Correct
  28. Verizon iPhone Announcement: Wrong
  29. Apple Announces an iTunes Web App: Wrong
What are your predictions?

Antennagate

Earlier today Apple held their iPhone 4 press conference to address the issue of iPhone 4's supposed reception problems. You can watch the full video, but it doesn't include the Q&A. You'd have to find the transcripts for the Q&A elsewhere. After watching it one part really sticks out to me and you can find it about 25 minutes 30 seconds into the video. Here's the quote:

"A lot of people have told us, 'The Bumper solves the signal-strength problem.' Consumer Reports is the latest one this week. We've heard it from a lot of people. Why don't you just give everybody a case? Okay. Great, let's give everybody a case." - Steve Jobs

You really have to watch this quote to appreciate how the last line, "Okay. Great, let's give everybody a case." is dripping with disdain. Jobs seemed pretty forceful, even angry, during this whole presentation, but this part was exceptionally so. It's like Jobs sees this "free case" response as a concession and certainly isn't happy to announce it.

Why did Apple choose to give all iPhone 4 users a free case? I don't think the force of their presentation would have been lost had they omitted the free case. Since Apple can't handle even the current demand for their cases, using other vendors and reimbursing previously purchased cases will be complicated. It will cost them millions of dollars in lost revenue, arguably close to 100 million dollars. So why would they do it? I can think of two reasons:

  1. Apple wants to avoid jumping the shark.
  2. Apple wants to minimize their legal liability.

The first reason stems from Jobs repeated claim that this issue has been blown out of proportion by the news media and bloggers. Apple, like any company, wants to remain in favor with both media and their core customers, and responding to the market this way shows they care in a tangible way. I think this is reason enough, but Jobs utter contempt in announcing this "solution" makes me think this wasn't the driving force in the decision. If it was, he'd have presented it in a more upbeat manner.

I think the real reason for the free bumper concession was Apple's legal department. With class-action lawsuits being filed against Apple over the antenna problem, Apple's press conference today was more of a preemptive defense and a legal facts driven presentation than it was an attempt to quell the controversy. At such a high price tag, this preemptive and public defense, while painful, underscores just how successful they expect the iPhone 4 to be. There will be more iPhone 4 phones out there than any previous model and with that kind of large user base coupled with Apple's phenomenal success make them a larger target than ever. The sub-text behind today's presentation was a legal defense and that is why I think Jobs showed so much contempt for the free case give away.

Usability

| 5 Comments
matches.png

When designing any kind of product it's important to be able to "get into the head of the user." A key to this kind of thinking is learning to observe how you and others interact with things. Donald Norman often used this approach in his classic book, The Design of Everyday Things. When I first read his book it changed the way I looked at things. Every once in a while, I'm particularly amazed by designs around me. Recently I recognized a few and what follows are three real world objects that I think are interesting from a usability perspective.

The Failure: Uni-ball Jetstream Pen

How can you ruin the usability of a pen? It's easy: make it so the user can't get to the ink-dispensing mechanism. Here's a picture of the Uni-ball Jetstream pen:

pen.png

It looks innocent enough, but when I hand this pen to someone, they do the following, almost always in this order:

  1. Try to write with it, only to discover there's no pen tip exposed.
  2. Try to press the clip end with their thumb in hopes it will "click" to expose a pen tip. It doesn't.
  3. Try to twist the clip end hoping this will reveal the pen tip. It doesn't.

At this point, they will do one of two things: Look at me with an expression that says, "Okay, how does this work?" or they will try to pull the pen apart. If they pull hard enough, the cap will come off revealing the writing end and annoyed they will try to remember what they needed the pen for in the first place. Here's what the pen looks like without the cap on:

penNoCap.png

The user could be a child or adult anyone who wants to write or draw, but to succeed, they must discover the end which dispenses ink. Over time and through our experience with pens we have learned to identify which end of a pen is the writing end. This pen fails because the end without the tip looks like it should write and it doesn't. I think it's the metallic look and cone shape that suggest that it is the end you write with. These 2 simple design choices: shape and material provide a subtle hint that is strong enough to cause significant confusion if not failure in using the pen for its intended purpose.

How could this problem be fixed? The fix is to make the end that doesn't write look like it doesn't write. A change to the color so that it's not sliver would work. Another option would be to make the end cylindrical rather than conical. Either of these would fix the problem. I recently went to the store to see if I could get another pen like this one and I discovered they had changed their design, here's the new look:

newpens.png

The new version replaced the silver end with a black one, while keeping the exact same shape, but this small change significantly improves the usability of the pen. This example shows how even the simplest of tools, a pen, can be affected by poor usability design. It also shows how even the smallest design change can make an object that was frustrating to use, so usable it simply disappears.

The Marginal Success: In-Sink-Erator Pro 17 Disposer

A marginal success is something that the targeted user is likely to be successful using, but due to various constraints, it is not living up to its potential. The awesomely named "In-Sink-Erator" disposal in my kitchen falls into this category.

A kitchen disposal is used to grind up bits of food that might plug up your kitchen sink drain or worse: the pipes leading to the sewer. During the normal use of a kitchen sink, leftover food inevitably ends up in the sink. Without the disposal, the user must carefully remove the messy food scraps and throw them into the trash by hand. Because a disposal is composed of mechanical blades that move at high speed, it is a dangerous device. An arrant utensil sent "down the drain" while the disposal was running could harm the machine or user or both. Care must be taken because almost all family members--children and adults--could be interacting with the device.

insinkerator.png

Does anyone see a problem here?

stuckfood.png

The on/off plug switch and stuck food.

The drain plug rotates either left or right to turn on and off the disposal. When it's on, there is only a small opening around the plug that lets water through. The plug has 3 functions: 1) turn on and off the disposal, 2) keep hands, utensils, etc. out of the device while it is on, and 3) plug the drain entirely so you can fill the sink with water. All of these are fairly easy to discover and accomplish with rotation of the plug at different levels.

The real advantage of this plug-activated design is that it is impossible to turn on the device and accidentally drop anything into it while it is running. This is a great safety feature, but it comes at a cost. First, the user must reach down into the wet sink to turn on the unit at the very least getting his or her hand wet. This means that before going onto another task, hands will need to be washed and dried again. Second, the opening on the plug is small, which means it gets clogged, filling up the sink. To fix this the user must reach down, turn the plug and pull it out to allow the water to drain. As the water rushes in the disposal cavity the air must escape and as it does, it sprays the user with dirty water. Using this disposal is always safe, but potentially very messy.

Certainly the user doesn't want to lose a finger or bend a fork in the disposal blades, but neither does the user want to get dirty while rinsing dishes in the sink. This device does its job, but the constraint of ultimate safety is at odds with the users immediate goals and makes the device less enjoyable to use.

An alternative solution would be to, have the switch that turns on and off the disposal without the need to reach down into the murky water. For additional safety the switch could be located in a place that requires the user to step away from the sink just enough that if something was ejected from the disposal, like a spoon that had escaped down the drain, the user would be out of range. A single purpose plug could be provided to fill the sink when needed. Rubber baffles around the drain could minimize splashing. This is a compromise on safety, but I think it's the better compromise since the users goals are more focused on cleaning and draining the sink.

This example shows how important it is to design with the context of the user in mind. Their context can expose their goals and desires. It also shows that in an effort solve one problem, you can create secondary and unintended side effects that can be worse than the original problem being solved. Great restraint must be used to avoid this pitfall. Not every problem is worth fixing.

The Runaway Success: Dodge Grand Caravan Door Handle

Finding a "Runaway Success" in usability can be difficult because they tend to be invisible. They are so easy to use that it is difficult to imagine that they could be designed in any other way. My Grand Caravan door handles fall into this hall of fame category.

door.png

Obviously the external door handle is used to open the door. That is the user's goal. Young or old, tall or short, all who want to enter the car must first open the door.

This is a successful design for several reasons. First it's simple. You see the door and you know how to use it: you pull and it opens. The handle that you grab onto hinges out mimicking the way the door opens. The keyhole is placed next to the handle and relates to and inhibits the handle hinge movement when locked. You can operate the door from below, for example in a wheel chair or a child's height or standing. In a rescue situation a solid handle provides a clear place to securely pull on the door. When in the dark because the door handle material is a different color and is not flush with the door, you can easily find the handle, and once you have found the handle, you have also found the keyhole for unlocking the car. Also, because the handle is a durable plastic, your constant opening of the door minimizes scratched the paint.

slidingdoor.png

There is one thing that could be better in the sliding door handles. The sliding doors slide back away from the front door, but the hinge on the handle swings forward, not back. This makes sense for when closing the door, but not for opening the door and closing the door is easier than opening it in most cases and often done from the inside of the vehicle. My children regularly can't get the door handle open because they are pulling back toward the rear of the car and are not able to achieve sufficient outward pull on the handle. If the hinge on the handle would follow the opening of the door like in the front doors, this problem would be eliminated.

Conclusion

We can learn from the good and bad all around us, but we must take the time to observe. This skill of careful observation is a key to better understanding, compassion and humility when designing something truly usable. Great usability begins with what we see.

Comments on Comments

It seems like almost annually John Gruber must defend his choice to disallow comments on his popular blog Daring Fireball. In a way I'm sort of dispassionate on the issue generally. If John doesn't want comments on his blog, that's his prerogative, it is his site after all! Further, from a free market perspective, John doesn't seem to be suffering due to this omission. What's interesting to me are the reasons people give for allowing comments on a website.

Some people say you need comments so you can respond to criticism with the same reach as the original post. I think that's what Joe Wilcox is really complaining about. If someone has 50,000 readers and says something bad about you, your personal blog response to your 50 readers doesn't really give you an equal voice to defend yourself. I suppose that with some constraint on information, this could be true, but there's really no monopoly on information online. If what John or anyone writes is wrong or misguided, I believe over time folks will discover this. Perhaps I'm too much of an idealist here, but that's really how I think things work online, and I think it's wonderful.

Some people suggest that you need to have a conversation and actively engage readers and without on site comments you can't do this. John's response to this critique is basically that you can have a conversation without on site comments, and in his case he uses Twitter and Email to great effect. Clearly, a conversation doesn't require some technical implementation to be called a true conversation. The point here is that feedback is good and communication is good, so make sure you have good feedback and communication. Pretty hard to argue with that. (I think a case can be made for building a website that is valuable without a conversation, but that's probably more of an academic argument.) What's most harmful to this argument is that there are examples of on site comments that are wonderful and on site comments that are terrible. Similarly, there are email lists that tend toward a conversation that is positive and productive and email lists that tend toward shouting matches. It turns out, there are phone calls that are productive and engender communication and phone calls that make understanding, a distant goal, even more distant. I hope you see the point, it's not the technology, it's the people.

There are of course other problems with on site comments, for example dealing with spam and the extra work involved with moderating and responding to the comment threads. That said I think there is an even larger problem with on site comments and it has to do with the way it affects the author, not the audience. I first heard this idea from Seth Godin, another popular author that doesn't allow comments on his blog. He said it this way:

I think comments are terrific, and they are the key attraction for some blogs and some bloggers. Not for me, though. First, I feel compelled to clarify or to answer every objection or to point out every flaw in reasoning. Second, it takes way too much of my time to even think about them, never mind curate them. And finally, and most important for you, it permanently changes the way I write. Instead of writing for everyone, I find myself writing in anticipation of the commenters. I'm already itching to rewrite my traffic post below. So, given a choice between a blog with comments or no blog at all, I think I'd have to choose the latter. So, bloggers who like comments, blog on. Commenters, feel free. But not here. Sorry.

I don't think Seth is alone in feeling negatively influenced by comments. It's natural. People love validation, and putting yourself out there is a scary thing. But the very feedback that comments allow can cause you to change your voice, and that is the most destructive thing of all. Love him or hate him, John Gruber has a voice. He is not a me-too artist. Is it because he doesn't have on site comments? Hard to say for sure, but I think it has helped. Over the years it has been one less distraction that has allowed for that little bit of extra focus.

Prediction for WWDC 2010

PredictionBanner.png
It's that season again: WWDC 2010 begins June 7th. Just like with the iPad announcement, I have created a Prediction Score Card for WWDC. Download it, print it out and take it to lunch. Amaze your friends with your prognostication prowess!

Also, if you'd like to play the same game, but on your iPhone, iPad or iPod touch, you can download the free Prediction app at: http://itunes.com/apps/prediction. With the app you will receive push notifications when new rumors and information are added as well as your final score. Have fun!

Prediction Score Card.pdf 

Engineering

| 1 Comment
Sometimes I find a quote that precisely describes how I feel about things. Today, I discovered this quote about engineering:

"Engineering is the art of modelling materials we do not wholly understand, into shapes we cannot precisely analyze so as to withstand forces we cannot properly assess, in such a way that the public has no reason to suspect the extent of our ignorance."
- Dr. AR Dykes, British Institution of Structural Engineers, 1976.

If this doesn't accurately describe software engineering, I don't know what does.