Jason Hong considers how software companies could effectively incorporate first-rate design into their products.
Simplistically, function tops design, and content tops design - two sides of the same coin. Here are the examples from my "technical" life.
1) Dartmouth Time-Sharing System vs. IBM (or GE) Mainfame: Time-Sharing (with BASIC) almost always won in spite of the limitations on program length and the expressive limitations of BASIC (another whole story). The sense of community and re-use that emerged around the Dartmouth Time-Sharing system was stunning. This observation was reinforced when I got to grad school elsewhere and found only main frames, initially. Computer scientists and computer engineers found the whole BASIC in a time-sharing environment offensive. In your words, BASIC+TS was "without design". Yet, I soon abandoned mainframe FORTRAN for BASIC+TS, because of function. In today's lingo is was highly available and a tool of communication and collaboration, in a way that my deck of punch cards and mag tapes were not. The fact that BASIC ignored Algol proved irrelevant, then.
2) The Internet - Prior to email, the internet wasn't used much. The internet+email changed the world. Externally both the internet and email were ugly, but the function was unbeatable, then. The internet had some good stuff under the hood, and email just needed to work reliably for folks to use it.
3) UNIX as a Homogeneous Programming Environment - Ken Thompson once told me that he rewrote the code for the "pipe" mechanism 10 times from scratch. That's design! (Compare it to the way pipes were implemented, later, in MS DOS. The C programming language was more for system programmers than "users" but it helped make things portable - so that UNIX ran on everything but the Coke machine. Unix was so good, so powerful and so productive to use that we inflicted it on beginning students, for whom it was not designed. In the end most of them thought it "cool".
4) Bit-mapped interfaces - Because of the Mac and Sun workstations interface design had a brief ascendency. HyperCard was a wonderful direct manipulation programming environment. But, the Web blew all that out of the water. Ubiquity, low cost, and rapid evolution, even of brain-damaged interface behaviors, beat any fancy interface that didn't have "Web" capabilities. I remember someone trying to give me a "Lisp Machine" - nominally an expensive piece of technology; I turned the offer down.
5) In the interface hey day, designers would say things like "if it doesn't have a good interface no one will use it." Two important counter-examples were: Really ugly access to MEDLINE - evolving from punch cards to RJE to other abusive command-line interfaces; but I saw doctors learn how to use it; and access to laboratory results - from a 40 character, upper-case only, red on black screen, the worst possible thing you could imagine. But the docs thought it was wonderful!
6) Early relational databases - Query languages were counter intuitive because, for example, they were based on the lamda calculus. "Badly" written queries ran slowly, and query optimizers were thought to be too complex to ever be helpful. Instead what I saw was users learning query languages by example, and query optimizers "training" sophisticated users in the art of query writing that led to queries that would finish in a productive amount of time.
To me, I see all these things a function trumping design and content trumping design. My iPhone is a not very good phone, but I use it for all the functions it has. My Mac laptop is expensive, but it's reliable and easy to use. I'm learning to use Mathematica's functional programming paradigm because it's powerful - it can execute huge computations quickly, with little investment in code, but the code is not easy to write, and the resulting programs are hard to read.
Still, I hope you continue to teach your students the difference between good design and less good design, but temper whatever you say with case studies - where good design either did or didn't win out, and why.
Great points. I argued recently, in a position paper for a CHI workshop, that many interface design practitioners are isolated in several ways from the interface design community. They do not have the breadth of knowledge, connection to the latest developments, or the ability to play a decisive role in product design. The isolation can be due to current CS education curricula, corporate structures, management practices, the primacy of domain knowledge, and other issues. If you are a junior programmer who was assigned to interface development because you took a class in computer graphics, it is hard to know what to do. Even if you are well-trained and skilled, if you are a lone voice in the wilderness of your company, it is hard to create good interaction design.
We need to continue the discussion, strengthen interaction design as a part of CS education, and continue to reach out to management with the argument that good products have good interaction design.
The workshop was "Researcher-Practitioner
Interaction" at CHI 2010. Lots of interesting points of view.
Workshop page: http://research-practice-interaction.wikispaces.com/
Position papers: http://research-practice-interaction.wikispaces.com/Position+Papers
Displaying all 2 comments