Design thinking is not rocket science

OH on the ABC Radio National By Design podcast (00:56): In the field: Paul Bennet

For us the idea of small ideas that people can actually connect together and actually implement are very big ideas.

And I'm sure you've heard people describe design thinking as sort of a combination of rocket science, string theory and calculus.

It isn't. It's not rocket science at all. It's actually very very straight-forward.

It's looking in the world, being inspired by people, co-creating with them, prototyping and then iterating. And it has to be impactful. It has to work.

Designing for Interesting Moments

(blogarhythm ~ Moments Not Words - F.I.B)

Some deep thinking and analysis of how to design for interesting and effective interactions..

Designing for Interesting Moments

View more documents from Bill Scott.

gource - cool and not totally pointless

Run gource on a source code repository and it animates the code's evolution. I think I first saw it used to illustrate the history of Python development since 1990, and I must admit my first reaction was cool but probably pointless.

Recently @dmm6319 ran it over our own project, and inspired me to play around a bit with it too.

So after watching our animation a few times I'm sheepishly revising my opinion of gource.

Yes, you probably need to have something invested in the particular code-base to care, and it certainly helps if you avoid the obvious cliche of using an "atmospheric" soundtrack.

But there are some real, big-picture insights that come through very clearly in the animation that you wouldn't necessarily get if you just looked at the source - for example, the shift from Cucumber to RSpec as our primary testing framework.

Blogarhythm: Asik Veysel - Joe Satriani

The CSS Zen Banger

Ever need to try some simple CSS tweaks on an existing website? I needed to do something like that again recently, and a little hack I used to do the job just turned into the CSSZenBanger.

CSSZenBanger is a simple tool for previewing style modifications on an existing web site—mainly intended for web designers who want a quick way to review stylesheet changes without the trouble of setting up a project environment.

This is certainly not a new idea, but I googled in vain for something similar. And while it's pretty easy to make on-the-fly changes with tools like Firebug, sharing the results with others is tricky.

So here it is... if you ever need to test some css fiddles, maybe it can help you too.


Blogarhythm for this post: Cobrastyle - Robyn

jTab 1.1: Guitar tab for the web gets an update and a mailing list

I announced jTab back in July, and there have been some nice improvements over the past month which I just tagged as a "1.1" release.

jTab is a javascript-based library that allows you to easily render arbitrary guitar chord and tabulature (tab) notation on the web. Automatically. It is open source (available on github).

I've also established a mailing list for jTab. All are welcome to join in to discuss internal development issues, usage, and ideas for enhancement.


Some of the key new features:

1. All chords can be represented in any position on the fretboard e.g. Cm7 Cm7:3 Cm7:6


2. Now allows shorthand tab entry of 6-string chords e.g. X02220 (A chord at nut), 8.10.10.9.8.8 (C chord at the 8th fret)


3. jTab diagrams now inherit foreground and background color of the enclosing HTML element


4. When entering single-string tab, can reference strings by number (1-6) or by note in standard tuning (EAGDBe)


5. The chord library with fingerings has been extended to cover pretty much all common - and uncommon - chord variants (m, 6, m6, 69, 7, m7, maj7, 7b5, 7#5, m7b5, 7b9, 9, m9, maj9, add9, 13, sus2, sus4, dim, dim7, aug).


6. It has been integrated with TiddlyWiki: jTabTwiki combines the guitar chord and tab notation power of jTab with the very popular TiddlyWiki single-file wiki software. Together, they allow you to instantly setup a personal guitar tab wiki/notebook. No kidding. And it's free.

KISSWorld - applying good design to mundane matters

Must be at least two years ago that Singapore Airlines changed the layout of their KrisWorld inflight entertainment magazine and it has bugged me ever since. The update coincided with a revamp of the entertainment on offer (a staggering 80 movies and hundreds of CDs). Unfortunately, the magazine suffered.

I've been waiting for SIA to "fix" KrisWorld, but last I flew it was still the same. Maybe one day. Do let me know if you see a new layout on any of their flights!

But it had me thinking, and I thought worth discussing because it seems a good example of how marketing-driven design changes can have unintended usability consequences despite everyone's best intentions.

Don't get me wrong, SIA remains my favourite airline of all, but it is disheartening to see that even the best airline in the world is susceptible to getting stuck with "bad design". Makes you wonder if there is any hope for the rest of us.

My gripe is with the layout of the CD selections.

How do you select an album you might want to listen to?

• You might recognise the album cover
• Maybe you like certain artists, but not know the specific albums available
• Or you might be looking for a certain album title
• And for some, you don't recognise the album art, title or artist but are attracted to sample it because of the genre or the cover

When looking through a long list of albums, chances are that all of these methods of recognition and selection are at play.

The trouble with KrisWorld is that they have separated the album cover display from the listing of artist and album name. The only thing that links them is the artificial numeric code that is applied to each.

On the left is an approximation of my actual scan pattern when trying to make a selection.

First I scan the album covers. Many I don't recognise and skip over.

I find something I think I recognise. To be sure, I then cross-reference into the album list and start another search using the special code number.

At this point I'm wondering if eye exercises are a safety feature designed to prevent DVT, or just intended to make the flight pass more quickly.

Maybe Joanne Wang is a little too sedate for how I'm feeling now, so I start another search through the album/artist list.

Down we go. Some I recognise (but without the album cover I'm not 100% sure).

Ahah, Wu Bai. That's more like it. But which album is this? Cripes, time to find the matching album cover to make sure.

Finally. Time to listen. A good thing this is CD and not a movie, because my eyes need a rest now..

Why do I need to work so hard? How to solve this usability nightmare?

Well, one suggestion is to just keep it simple. Cover art, album title, and artist are bits of information that both separately and in combination help me search the listings the most effective way. So just put it all together in the list. For example:


The eliminates all cross-referenced look-ups, is simple and direct, and does not require significantly more space. Best of all, as a "user" it is effortless.

Funny ... isn't this exactly how the layout used to be designed?

The lesson? Sometimes, designs must be seen to change for marketing or other business reasons, letting you loose in a requirements vacuum. The danger is that in the absence of specific functional or usability needs, other factors such as aesthetics and branding will expand to fill the void. Done carelessly, you can inflict untold collateral damage on the product through the process.

The solution? Consciously re-introduce at least a usability/functional benchmark into the design process - "be no worse than it was before". Better yet, ensure usability improvements remain a key objective - no matter how good you might think it was before, perfection is always one better.

And yes, usability applies as much to the printed page as it does to the web!

jTab - Guitar Chord and Tab Notation for the Web

Guitar tab (notation) is all over the internet, but it is usually in either a fixed/non-interactive form, or painstaking ASCII format.

I've always wanted a better way, and two things I've looked at recently inspired me to think it might be possible: Dmitry Baranovskiy's fantastic work on the Raphaël SVG library, and Alex Gorbatchev's syntaxhighlighter.

So now I can introduce the result of my latest weekend project:

jTab - newly minted and ready to rock and roll!

See the project home page at http://jtab.tardate.com for more examples and information about how you can use it too. jTab is open source, with the master source code repository on github .

What does it do?

jTab is a javascript-based library that allows you to easily render arbitrary guitar chord and tabulature (tab) notation on the web. It handles implicit and automatic rendering of any page elements given the special class name 'jtab'. It can also be scripted for more sophisticated or interactive effects.

Bottom line: jTab turns this..

<div class="jtab">Bm $3 4 4h5p3h4 5 $2 3 5 7 7h8p7 5/7 | A $4 7 9 $3 7 6 $5 9 $4 7h9 7 $5 9\7 5/7 | </div>

..into this:


Grab it, use it, help me improve it, or just let me what you think...

The Software Architect's Professsion. Or Delusion?

That was a happy age, before the days of architects, before the days of builders. -- Seneca c.4BC-65AD I hesitated as I reached for The Software Architect's Profession: An Introduction (Software Architecture Series) on the library shelf. Did I really want to read another treatise on the role of the software architect? Hasn't the term architect been so abused as to now be worthless, even downright counter-productive? In this, I think I am one with Jeff Atwood and Joel Spolsky who discussed the questionable value of the title "Software Architect" on StackOverflow podcast #44. Nevertheless, my hand followed through. I think I was persuaded by the unimposing nature of this concise little 100-page book.

I was pleasantly surprised; this is a great little book for stimulating some thinking around the role of an architect for the advanced reader. But I worry that it attempts to position itself as "An Introduction". A novice, unprepared to read the text critically, may easily be mislead by the book's definitive statements about what a software architect is and what they do.

Personally, I believe the book is fundamentally flawed in three important aspects:

1. Are we really in Crisis because we lack a Software Architecture Profession?

Firstly, the premise that today's Crisis in Software -

[the] parade of failures and half-failures that has grown over the years as a result of a world without an established profession of software architecture

- is wholly unsupported by any direct evidence. The authors' central argument is flawed by asserting an apparent causal relationship when in fact only coincidence had been established beyond doubt. A number of well-known software runaways and failures are mentioned, but I don't know of any where the original case studies attributed the failure primarily to the lack of "an established profession of software architecture". The authors get around this problem by redefining the conclusions and suggesting that all faults may eventually be explained by architecture. It seems to me self-serving and circular.

2. A Flawed Analogy with Building Construction

Second, the authors attempt to reinforce their argument with the proposition that the analogy with building architecture is self-evident. Buildings need architects. Software is like building. Therefore software needs architects. Hmmm. I am reminded of Bernard Rudofsky's book "The Prodigious Builders" which celebrates the history of vernacular architecture. That is, architecture without Architects (unfortunately a stunningly boring book for what ought to be a highly inspirational subject).

I particularly disagree with the authors' contention that software is not developed: it is built (with a sense of finality). The Google-inspired trend towards the perpetual beta is the most visible evidence to the contrary. The authors object to the notion that to develop implies to unfold, uncover, and make known. On the contrary, I find this a most apt description of what we do within the software profession: the youth and continuing innovation within the field does mean that software development and the architecture it requires is more akin to exploration, invention and discovery than to a formalised application of the tried and true.

Strike two.

3. Premature Specialisation

I began to renew my hope for the book as it explored the historical foundations of architecture. Michelangelo can truly lay claim to the title of Architect ("master builder"); his work on St Peter's Basilica epitomizes the unltimate balance between function, beauty, and structure,

Vitruvius is famous for asserting in his book De architectura circa 50BC that a structure must exhibit the three qualities of firmitas, utilitas, venustas — that is, it must be strong or durable, useful, and beautiful. A sense of proportion and harmony is represented in Leonardo Da Vinci's famous illustration of Vitruvian Man.

Such ideas begin to shape the conventional definition of an architect. A master who not only understands structure, utility, and beauty in order to successfully render a design into plans, but has the practical experience to supervise their realisation through construction.

At this point, I think the authors are getting onto the right track. However they stumble at the last post by then inexplicably turning this into an argument for a limited and specialised concept of a "Software Architecture Profession", where the architect only retains responsibility for venustas (design/beauty). Utilitas (function/utility) is the client's problem, and firmitas (form, materials, logistics) is the province of the engineers, scientists and code monkeys.

Time for the Renaissance?

The authors' call for the codification and ossification of a software architecture practice is I think at least 50 years premature.

What an "Architect" needs to be concerned with is still going through successive waves of tumultuous change. Up to the green-screen era, computer system architecture necessarily had a strong hardware component. Come the GUIs and increasing processing power in the 90s, it seemed a singular focus on "software architecture" as a technical discipline was a valid vocation. Now the waves of web-driven innovation and the emergence of the "Rich Internet Application" is again challenging our notions of what architecture entails. And again, the "real world" is encroaching the pure software realm with the rise of increasingly powerful and widely available mobile computing platforms (think iPhone, Android), and the revolution in pervasive automation (think Arduino).

I think the Java Posse were spot on when they discussed the growing need for cross-fertilisation and collaboration between designers and developers on podcast #247 - Design and Engineering. This is a time of divergence, not convergence, in the business of producing software & technology-based systems.

In truth, I question how appropriate both words are in the term "Software Architect":

• Software - it is perhaps only in the last 10-20 years that it has been possible to construct computer software at the level of complexity that warrants the existence of an architect in the classical sense. And I suspect that in another 10 years it will seem ludicrous to suggest that you can be an Architect of only software ("just a turn-of-the-century fad"). Software is just one component of a "built environment" that encompasses everything from the information infrastructure and systems technology to the psychology, art and design of human interaction; ultimately leading to a desired collaboration between people and machines in the context of real-world objectives.
  
• Architect - the common use of the term in the computing field has stripped this word of it's more noble dimensions. No longer is the architect "the person with the vision and skill to make dreams a reality". They are more likely to be the person in the corner who produces nothing but paper, leaves no fingerprints on the pages of history, and is generally ignored by those who are really making things happen.

I don't know what you should call the people who have the experience and ability to lead others to do amazing things with the information technology we have at our disposal.

I'm just pretty sure that "Software Architect" doesn't even come close to being adequate. And building a "profession" around a woefully inadequate definition is a one-way ticket to irrelevance and obscurity.

Like you scroll wheel? You want KatMouse!

I just heard about KatMouse on Security Now! #182.

I type fast, but love my mouse ( ... and there has been lot's of controversy about the numeric keyboard getting in the way too).

That means I'm a scroll-wheel addict. Till now, I just accepted the fact that it doesn't kick in all the times I would naturally expect it to work, like old applications, or in controls or windows that don;t have focus.

As soon as I heard Steve talk about KatMouse I knew I just had to get it. Two minutes later, it is installed and I'm loving it!

Best feature: when I have overlapping windows, I can scroll whichever window the mouse is over. Doesn't have to be in focus. Beautiful! This is how the scroll wheel should have worked all along;-)

Best Practices in Web Form Design

I'm humming and hahing over some form designs at the moment. These days you have so many options, especially when you are getting smart with ajax and scriptaculous tricks.

Having options is always a double-edged sword. Yes, they allow you to do amazing things. But they provide a great recipe for procrastination.

.. just the situation where some thoughtful, concise guidance on leading practices from someone who knows their stuff can be a goldmine.

Thankfully I stumbled upon this great presentation on web form design by Luke Wroblewksi. It's a classic, and now I see he has a book out on the topic which instantly went on my "must read" list.

A380 - how to spend €billions and still get simple things wrong

lancerlord@tomorrow.sg picks up on a Telegraph article asking "why are there still ashtrays in the Airbus A380?"

Good question, but not the only example of seemingly stupid "missed opportunities" to innovate in the A380.

One of the first I noticed was the new positioning of the inflight entertainment controller in the seat back. At first it seems perfect, since it avoids the accidental activation which is a real problem when the controller is built into the armrest (which is the case in most other cabin fitouts I've seen).

But then consider the way it is oriented - mounted on the side. This results in a classic failure to "get the mappings right" (one of Norman's design rules in "The Psychology of Everyday Things"). If you use the controller without removing it from its holder (which turns out to be a very handy usage), then you need to transpose the controls 90°. Up means right, down means left etc. Ironically, when the controller is mounted in the armrest, the horizontal layout tends to "get the mappings right" if you use it in-situ because of the way the hand is positioned.


It could have been so perfect if the controller designers were collaborating with the seat designers, with a clear focus on usability. The controller could be mounted vertically, or redesigned for a side-side layout.

As it is, a missed opportunity to produce the very best design. And a very, very minor usability problem is one of my lasting impressions of my first A380 flight, overshadowing all the billions of euros invested in the plane.

What else? Well, I'm surprised they persist in using the special 2-prong audio jack. I'm sure there's some weird logic about discouraging passengers from nicking the headsets (even though policing headset issue and collection still seems to rate as one of the cabin staffs' most important duties!)

But as I look around the cabin more and more people are using their own earphones. The ones that aren't probably forget to bring the special adapter. For planes like the A380 starting their service life in the 21st century, I'd expect it would be the norm for most air travellers to be carry a headset of some description, and it would make sense for cabin designers to take advantage of the fact and use standard audio sockets, and provide headsets "by exception". Win-win: passengers get to use their own familiar headsets without needing an adapter, and cabin crew get to save time for more important things.

See, I can get cranky about the smallest details;-)

Expect users to be just as critical, nitpicking and cranky about the software we give them! And rightly so... it doesn't really matter how much time and money has been invested if you don't get the simple things right.

Desktop Keyboards Stuck in Design Limbo

Keyboards are terrific examples of how bad design can get stuck in a rut, unable to overcome inertia. Everyone says qwerty is a bad idea, yet I couldn't imagine using anything else now since it's use is so ingrained.

But another aspect of keyboard design that has me really grumpy is the whole numeric keypad appendage on desktop keyboards. It is a holdover from the days when users were "data entry clerks". But we are stuck with it (Microsoft only have two keyboard models without it, while ALL Logitech models are saddled with this cancer Postscript: Dean Chu corrected me here; Logitech's diNovo models don't have the numeric keyboard).

This started to really annoy me of late, because I've been switching between a laptop during the day, and a desktop at night.

Working with a desktop keyboard again was feeling really strange and difficult, but after some reflection I realised the problem. My right-hand is used to shifting all the time between jkl; and the mouse. On the laptop, this is a subtle and effortless gesture. On the desktop, its like playing table tennis.

The fact that virtually all laptop designs eschew the separate numeric keypad should be proof that it is evolutionary dead wood.

So this is my grumpy call for all keyboard manufacturers to wake up their snoozing product managers/designers and actually innovate for once. Fix this ergonomic nightmare! At least give us some choice ... integrate it with function keys like laptops; use separate USB numeric keypads; even consider sticking it on the left-hand side of the keyboard.

And for all those poor souls who really are still data entry clerks, I'm sure there will be no-brand outfits from China knocking out standard 102-key designs for years to come.

Is it just me? Did I get up on the wrong side of the bed today, or do others feel this way too?

Postscript 9-Feb-2009 ... hat tip to mqt for linking Trevor Blackwell's solution: just chop it off! If you gotta take a bandsaw to a product to make it fit-for-use, then something's wrong, right?!!