Category Archives: Software Engineering

The Fountainhead of Open Source

Just watched the The Fountainhead movie from 1946 (yes, from netflix).

Howard Rourke hacking Open Source code

Howard Rourke hacking Open Source

Here is the plot summary, brought up-to-date:

  • Open Source is represented by the protagonist, a brilliant architect named Howard Rourke. Rourke is idealistic, does his own thing, is uncompromising, and is not driven by money or recognition – and certainly not by Big Business.
  • Big Business is  represented by newspaper magnate Gail Wynand. Wynand wields substantial influence and is in perpetual pursuit of any means to incite the populace – an energized populace buys more product.
  • Consultants and Certified Vendor X Developers and Vendor Partners are represented by  architect Peter Keating. Keating goes with the flow, producing whatever the powers that be say is desirable. At one point, he mentions to Ms. Francon he’s polling folks on what they think of Rourke’s latest building to which she responds (with some disdain) “why, so you’ll know what you think of it?”

Lessons:

  • Talent != influence. Keating’s influence is limited to those who recognize his greatness. Most only recognize as great what they are told to recognize as great.
  • Passion can be directed constructively (Rourke pours his love into his life’s work) or destructively (Wynand devotes his career to controlling the masses through his newspaper).

The movie is based a book of the same title. The author, Ayn Rand, became well known for her Objectivism philosophy of life, exemplified in the movie by Gary Cooper who played the lead character, Howard Roark. [I wonder what Richard Stallman thinks of the book?]

I wonder how many professional software developers identify more with Howard Rourke or Peter Keating? And which is more desirable?

Any my clean analogies fall apart when one considers the combinations of Big  Business and Open Source. Microsoft just announced CodePlex.org and the CodePlex Foundation “to enable the exchange of code and understanding among software companies and open source communities.”

A dirty little secret of Eclipse, Linux, Apache and other high-profile projects is that they also have professional, full-time staff – sponsored by Big Business (like IBM) – since the success of these endeavors is strategic for their business.

Maybe Open Source isn’t as pure as the romantic notion of developers from around the world contributing since it was a nice thing to do. The world-wide altruistic contributions may still be there in some cases, just supplemented by Big Business. Which is okay with me, though might not be with Howard Rourke.

Continue reading

Advertisements

Jared Spool on what makes a UI Intuitive

Jared Spool spoke at a Refresh Boston user group meeting on Thu May 28 in Cambridge, MA. During his talk, which was titled What Makes a Design Seem Intuitive?, Spool delved into some common ways User Experience (UX) goes wrong and some ways to make sure this doesn’t happen to you. My personal notes/interpretations follow; if you think I got it wrong or want to offer alternative interpretations, feel free to comment.

Executive Summary

  • Understand your users and their levels of skill/knowledge 
  • Understand the skill level needed by users of your software
  • Identify any gaps between the actual and needed skills (see two points above)
  • Design the software to bridge these skill gaps (which may vary from one user to the next)
  • Test your assumptions with real users to make sure you did everything right (Yogi Berra was right when he said You Can Observe A Lot By Watching!)

How to Create Non-Intuitive User Interfaces

First, some counter-examples – easy paths to UX Failure – how to be Non-Intuitive:

  • Do the unexpected: Spool showed an example of a site that used * (asterisk) to indicated those field “not required” which is opposite of popular convention. UX Fail.
  • Implement non-standard & sub-substandard behaviour: Spool showed a beautifully designed (visually appealing) site  with custom scrollbar that didn’t work right (pretty but not functional). They had implemented their own scrollbar functionality to get the look they wanted – but a fully-functional scrollbar is really hard to do well – theirs was jerky and unpredictable. UX Fail. (Plus a bonus Form Follows Function Fail.)
  • Be non-intuitive: Spool showed “Hay Net” – a very simple site to help sellers and buyers of hay find each other. This site had two main choices on the front page – “have hay”, “want hay” – but user testing showed that about half the time “have hay” was chosen to find someone who has hay, and the rest of the time chosen when I am the one who has the hay. (This might qualify as what my old friend Julianne would call “Escher words” – where the meaning flips back and forth in your mind between alternative viable interpretations much like certain of M. C. Escher‘s artwork). Wording was not intuitive, even though it was very simple. UX Fail.
  • Add non-core features until your application is large and complex: The larger and more complex an app, the harder it is to keep it intuitive. This was a general comment from the Q&A, supported by examples in his talk [Wang dedicated word processors were very complex (requiring 1-2 weeks of training to use), supplanted by WordStar, supplanted in turn by simpler Word Perfect, later supplanted itself by simpler Word (after Word Perfect had grown more complex), and now Word is really complex – tens of toolbars, including one for editing 3D graphics]. But simple does not imply intuitive (see “Hay Net” example above). UX Fail, again and again.

Different Kinds of People

  • Key point: Intuitive is personal – maybe it works for me, not for you — it is unlikely that all possible users have identical knowledge
  • Prior experience of the user matters – where are the on the Knowledge Continuum?

What is this Knowledge Continuum you speak of? Imagine a continuum where the left-most end is “No knowledge” and the right-most end is “Full knowledge” and your UI is designed for users somewhere on that continuum. If the user’s current level of knowledge is less than the level to which you target your design, your software has a problem – there is a gap that needs to be overcome.

A design is intuitive if the Current Level of Knowledge = Target Level of Knowledge, or if the gap is small enough such that it can be bridged with good UI design. If the gap is too large, you may need training (whether online on in-person).

Two types of Knowledge

  • Tool Knowledge (for a specific tool – Word, Visual Studio, TurboTax)
  • Domain Knowledge (independent of this (or any specific) tool – writing, developing in C#, creating personal tax return with weak tax-code depth)

Techniques for Creating Intuitive Designs

  • Field Studies (watch your users in action)
  • Usability Studies
  • Personas
  • Patterns (reuse known good patterns)

Specific Examples for Creating Intuitive Designs

  • Bring Target closer to Current w/o resorting to training or help. This means your software needs to target the right knowledge level – find that target using the techniques listed above – remember: Developer/Designer does not have same knowledge level as User (at least mostly true).
  • Wizards can reduce target knowledge requirements (bridging that knowledge gap).
  • If your user base consists of very different Current Knowledge levels (e.g., home tax preparation vs. professional tax preparers) you can create two (or more?) specialized/targeted applications.
  • Every six weeks, every member of design team needs to watch users using the design for two hours.
  • Don’t hire an agency to design your experience. (Spool thought it was fine to have an agency implement your application, but you need to design it first if you want to be successful.)

Further Information

Here is an older article by Jared Spool on the same topic as this talk: http://www.uie.com/articles/design_intuitive/ (thanks Joan).

UIE Resources