Open source moving toward individual vision, away from design by committee

An economics podcast is an unusual place for a discussion of UI design, but this conversation with Eric Raymond (The Cathedral & the Bazaar) includes the usability of open source software.

Open source development works when,

1. Capital goods required to do the work are cheap.
2. The limiting factor on the work is human creativity and attention.
3. The work is intrinsically rewarding.
4. There is an objective metric for success that everybody in the hive mind can agree on without too much effort. Without that condition you get thrashing.
5. Zero-cost communications.

Any designer knows Item 4 is a problem: different types of users with a wide range of experience, conflicting goals, etc.  The open source community is starting to recognize that UI design requires a single vision. They are appointing “UI dictators” within each project who “get their way.” “It’s better to have a flawed individual vision than try to do it by committee.”

EconTalk: Eric Raymond on Hacking, Open Source, and the Cathedral and the Bazaar
(program notes and audio)

Agile 2008: Personas and XP

I have recently returned from the Agile 2008 conference in Toronto.  I had a great time, and met some great developers, as well as some people I have only known vicariously through email lists.  It was nice to actually see some of these individuals face to face.

I am making my presentation available here as a download.

This link is a PDF file, but if you want the original, please just let me know and I will get a copy to you.

Using Personas with XP at LANDesk Software, An Avocent Company

Scott Berkun on Innovation

Scott Berkun has put together a small article on how to innovate right now.
http://www.uie.com/articles/innovate_right_now/

He mentions that every innovator’s tool kit includes these three things:

1. Questions
2. Experiments
3. Self-Reliance

Key points include:

• Borrowing ideas from the Past – look at ways others have solved the solution before you then try variations on them
• Ask a lot of questions
  • Why is it done this way?
  • Who started it and why?
  • What alternatives did they consider?
  • What are my or my friend’s biggest complaints about how it is now?
  • How has this been done in other locals, cultures, or throughout history?
  • What assumptions were made or constraints did they have?
  • How can I apply any of the above to what I do?
• Try things yourself
  • There is no substitute for first hand experience when trying things
  • Don’t be afraid of risk – the bigger the innovation, the greater the risk
• Try, Learn, and Try again
  • This could be called iterating your design
  • Remember what Edison is attributed for saying "I haven’t failed, I have found 10,000 ways that don’t work"

Building Software will always be hard

Recently, Brian Kernighan gave a lecture at Princeton talking about “The Changing Face of Programming”.

(Warning: PDF Link) The Changing Face of Programming – Brian Kernighan

(Warning: MP3 download) The Changing Face of Programming – Brian Kernighan

At the end he references Fred Brooks and his 1986 article “No Silver Bullet”

No Silver Bullet

Kernighan quotes:

“There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.”

Brooks also states that he believes the hardest part of developing software is always going to be the design/conceptualizing stage.  He says:

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.

If this is true, building software will always be hard. There is inherently no silver bullet.

Embrace the Sketchy Prototype

We tend to really like paper prototypes in our line of work.  We often find that by just doing three or four prototypes that we have significantly increased our knowledge of what the client needs up front.

Techniques and tools are discussed at introspectiveH.

We think it’s worth examining.

Creating Advanced Web Application Deliverables

User Interface Engineering (UIE) has an interesting podcast discussing some of the problems when using wireframes for complex designs. They cover issues like preserving context, explaining why interface elements are there (or not), and setting priorities for what can be cut.  Keith Robinson call his solution the Page Description Diagrams which describe what the wireframe is trying to accomplish.

The UIE Podcast

Example at Keith Robinson’s blog

Bill Moggridge on Interaction Design

Tech Nation interview with Bill Moggridge of IDEO.  The key to successful interaction design: make a prototype and try it with people.

Full interview (30 minutes)

Contrast and Text Readibility

I am including a series of links that I ran across while doing research into contrast and text readability.

• Reading light text on a dark background
• Line length and readability
• Screen font for captioning and subtitles
• Text Readability and Contrast

The Positive Spiral: Six Keys to Success

University of Toronto business-school dean Roger Martin on how Milton Glaser and Massimo Vignelli think about design and its relevance to business.

1. they don’t confuse what they presently see with reality, and therefore don’t see the present state of a thing as immutable.
2. they don’t fear the ambiguity that’s created by models or concepts that conflict with one another. Rather, they see the benefits of such conflict and ambiguity in spurring their creative juices.
3. they believe that there’s always a better design out there…
4. they’re confident that they can always find a design solution that meets their high standards.
5. they’re unconcerned about wading into the necessary complexities that one must grapple with before coming to an elegant design solution.
6. they refuse to rush to choose one side or the other of the conflict inherent in their task, or to race through the difficulties without giving themselves a chance to develop a new and better insight.

This six-part mental stance propels its adherent along a positive spiral. A person with such a stance naturally develops tools for handling ambiguity, complexity, and conflicting models, and is inclined to garner experiences that deepen skill and sensitivity.

Full Article

“Design as Strategy, Design as Execution”

Link to full story

Luke makes some great observations about “design thinking” and how companies often fail to realize that placing the design team in the middle of their “assembly process” changes the way that designers can think about a product.  This can often lead to stagnant, barely changed designs.