This is an extension to the idea of mutually exlusive options rendered as “Link Sets”, which I wrote about here.  It’s the notion of allowing AND interactions with the set:

This sequence (1 – 4) has the user stipulate a number of AND options
[“View as: this AND that AND other”]

The primary behaviour is the same as the basic link-set, but with the addition, only

With the addition of a +.  Clicking the word has the typical exclusion behaviour (only that item is selected), however choosing the + will add the item to the group of selected items (an AND relationship).  Once added, the + changes to a –, which allows the item to be removed from the selection set.

Here’s me (conviently blurred), courtesy of Dave’s camera phone, sitting before the super great, wickedly smart Kathy Sierra yesterday at Sam and Trent’s place in Welly.

She’s talking about “Suck Thresholds”, Kicking Ass, and Flow glorious FLOW.  For the uninitiated, Kathy’s approach is about designing software so as to create “passionate users” – and a central set of ideas necessary for achieving this can be summed up in the following graph:

Now if you look closely you’ll notice some important distinctions illustrated in this schematic.  Firstly, the user evolves from a green newby, who doesn’t even have ears, into Elvis.  These transitions mark moments in the evolution of skill level – and to be a “Passionate User” you need to be in the Elvis zone of “I Rock”.  The finer point here, is that “Flow” can be achieved throughout this entire evolution by evenly balancing the user’s level of skill with a corresponding level of difficulty.  This will allow them to remain absorbed in the task – challenged, not overwhelmed with difficulty, but also not bored (not too heavy, not too light, just right).  Oh, and “flow” is good because people report their moments in “flow state” as being the happiest moments of their life.

Here’s where Kathy’s lecture turned into a dialogue, as this is the area she wants to have an ongoing discussion around – the area where there are no great answers (or no pat answers at least) – the furtile ground for design.  The conversation here turns to “how” do you design interactions that effectively move users through that middle ground between sucking and rocking?

This is a vexing question of course, and one I want to think about, but first I want to juxtapose Kathy’s model with something similar but different from the Cooper school of thought.  Cooper similarly illustrates the skill-level distinctions over the user-population – but does so like this:

This is explained in the following way: in the beginning everyone is a “beginner” – but beginner’s never stay beginners for very long.  They either give up, or they progress to the level of “Intermediate.”  This is because absolutely no one likes being green with no ears.  Intermediates know what they need to to get the job done fast, or well, “enough” – but that’s where it stops.  Then in the rare occasion, you have an intermediate progress into “Experts” who know everything – and would be at the “I Rock” stage in Kathy’s schematic.  They metomorphesize like butterflys into Elvis.  Experts, however, tend to be (1) thin on the ground proportinate to intermediates, and (2) temporary, in that to remain an expert you need to be constantly pushing yourself with the product – and when you stop, you atrophy back down into an intermediate.

Now this is all highlighted to point to the question “who do we design for” – and the answer from Cooper is “the perpetual intermediate” BUT (and here’s the thing) Elvis is disproporiately important, because what he says has an immensely strong effect on the intermediate users.  If Elvis likes it, then the intermedate guy will keep slogging – and may even become “like” Elvis one day too (this in Kathy’s parlance is a “passionate user”).  But if you don’t cater for Elvis (but do cater perfectly for the intermediates) Elvis is likely to say “oh now, this product sucks” (when what he means is “this product sucks for an expert like me”).

So here we have two models that share very similar values.  Whereas it appears Kathy places emphasis puerly on the expert – in fact I think they both point to the need to focus on the intermedate – and challenge the designer on how to progress users in a smart way up to expert [and for me, smart means not relying on manuals].  How do we do this?  That’s what Kathy wants to know.  Me too…so let the conversation begin.

We all know Moore’s law, right…but what about Mooers Law?  Formulated by Calvin Mooers in 1959, six years before Moores law – the force of nature that has fuelled us to the point where Mooers Law is now highly relevant:

An information retrieval system will tend not to be used whenever it is more painful and troublesome for a customer to have information than for him not to have it.*

There’s now soooo much information.  It’s accessible in ways never dreamed of before (and we’re working on opening up more of it in better, better faster and easier)…but do we always want this?  Mooers says no…less is more.  Never underestimate shadow and self-deception.  It’s an interesting angle to think about when thinking about email searching.

* Remarks by Calvin N. Mooers during a panel discussion at the Annual Meeting of the American Documentation Institute, Oct 24, 1959.  Source: Ambient Findability, pg 44, Peter Morville – O’Rielly

Tanya’s next event, this time not for kids:

If you’re anywhere near Waiheke ‘round the 3^rd of June then get your butt along to this.  For the better part of the 3 million years we’ve been human beings, we have sat around camp fires telling stories.  It’s only in the last fleeting seconds of evolutionary time that stories have been relegated to ‘just for kids’….so here’s your chance, and you don’t have to sit in a cave.  Oh no, how about the world renowned Goldwater estate – with a sumptous meal, and lashings of fine wine to boot??  Then “climb into bed with Tanya Batt” for some adult stories…um I mean “Bedtime stories for grownups” (sorry, no smut here, she’s a very classy gal!).

At what point would you admit that the interaction of your inflight entertainment system sucks?

The other week, flying to San Fran on the new AirNZ 777, the lovely old lady sitting next to me asked for help getting a movie going.  Then on the flight back, an elderly gentleman walked down several rows and asked me to help him with the system (what’s that about?? Is that my computer karma catching up with me?)

Both were asking “how do I change the channel” (their mental model) – and wanted to “know how” to do it themselves.  But after spending a minute attempting to convey how the navigation keys related to a cursor moving around the screen, that then needed to have the “select button” pressed at specific intervals – it quickly became apparent that rather than ‘teach a man to fish’ in this case it would be easier and more time efficient to come to their aid two or three times and set the desired movie playing.

This was fanstastically ironic because the first interaction design project of D4 (Dave Fore, my first instructor on the Cooper course), was the in-flight entertainment system for Sony that was outlined in The Inmates are Running the Asylum.  If you ever want to see a beatiful piece of interaction design (with sliding monoclines and all) check this puppy out.

Anyhow, seems Sony must have locked it up pretty well in patents, as AirNZ can’t hold a candle to it.  Funnily enough the air-steward, when I talked with him about it, defended the design.  Perhaps he had the knack for teaching complex navigation idioms to elderly people whilst serving peanuts and cocktails.

Well, I’m flying out to Canada in an hour….let’s see if my computer karma draws more victums of bad design my way.  Hope so, it’s interesting to see how people think when presented with such a problem.  Of course, they all think it’s they’re fault, and they’re being dumb.  The first thing to do is correct them on that fallacy.

Rod just pointed to the new Google calendar release, and comment’s “this is signicant.”  Given that despite an impoverished web-input control for composing messages Gmail is, more me, a signicantly more pleasant and useful experience than Outlook, I wonder: how long will it be before people start diverting their work Calendaring schedules to this – and demanding that their colleagues follow suit?  If Google make it easy to bounce calendaring information from Outlook to this new system this is one more (“significant”) chink in the armor of MS Office.

Interesting comment by D4 (Dave Fore), the VP of consulting at Cooper on the course last week in San Fran.  He was reflecting on how common it was to encounter the “because the law says you can’t do that” variety of excuses for not implementing a design, when what’s really meant is “that’s technically hard.”

In response, D4 says he doesn’t believe any legal argument until 3 lawyers tell him the same thing.

One of the things we were asked to consider last week at Cooper training, was “what’s a good piece of design” and correspondingly, “what a bad design.”

I’ll save my “bad design” example for another post, it’s hilarious…and anyhow, it’s easier to find example of badly designed interactions.  For now, the good are far more rare, and that’s why this was such a delight:

So simple…yet it fundamentally improves the experience of crossing busy roads in a busy city.  By considering the question every pedestrian asks themselves when the cross-sign turns red (“Do I risk it, or do I not”), feeding a single simple piece of information back to the user (remaining time) allows them to make an informed decision about whether to hoof it.  Apparently the accident rate has dropped dramatically since the design has been installed (as you would expect).

I love the simple ones!

One of the most significant takeaways for me from the Cooper interaction design training I participated in last week in San Francisco was the clear distinction Cooper makes between the two roles involved in the design process.  These are:

Now most people, apparently, come to the table with skills on both sides of the fence.  But Cooper has found over the years they have been practicing, that breaking these two roles out across two individual people, who work with each other over the long term, yields better results, faster and more consistently.

This team size of two shakes out as optimal (Cooper have experiemented with different approaches, and this is where they have got to).  This week has been invaluable both learning in the classroom about how this team-dynamic is applied to the Cooper methodology, AND being able to hang out with the elite team of designers at the Cooper design house and talk with them about the nuts and bolts of the everyday business of designing behaviour in this way.

For instance, and this was interesting to me – design teams only ever work on one project at a time.  Only one.  There’s just too much complexity to deal with effectively, if you’re designing something properly, to split your ming across multiple concerns.  That said, there is an extreme pragmatism to Cooper’s teams – and it’s feasible, and in fact highly desirable to design well ahead of implementation time, and in a best case sceanrio, start getting blueprints squared away and on the shelf for future coding (in a sensible, rationale, and predictable manner – which is one of the things a “Form and Behaviour” specification allows you to do.  Without it [an MRD on it’s own for instance], timelines are mostly just guesswork, wild speculation, or optimistic marketing events).

Here’s kind of a staggering metric:

Based on research, corporate users send and receive an average of 133 messages per day and this number is expected to reach 160 messages by 2009. – Radicati Group [Source]

The question I have, is that if that is an average – how much “deep thought” can be going into any of those.  That’s 133 business letters everyday.  Or is it?  I think that this is probably misleading, as we’re seeing email get used a lot like IM.  Tens of emails, with one-line responses, which cumulatively constitute a block of thought.  And as Russell Beattie notes in his recent post “Rethinking Email”, even if the format of email is not technically the most useway to deal with this style of dialogue – it has become a cultural norm – and therefore the opportunity for us is to understand that, and explore ways in wich we can give users better tools to manage this IM-like style of email-communication.

I’ve just discovered a fascinating idea from the famed visual-information theorist Edward R. Tufte, who incidentally taught me the single most useful principle I have had the good fortune to discover: “Smallest Effective Difference” (perhaps I’d better write another post on this some time).  But before I get into this new idea of Tufte’s, here’s a little side background from my context:

Despite the “network effect” upside of desiging apps that run in the browser, there is much that sucks with making detailed interactions dance in the DOM.  So what you can do is go and play with WinForms, and more precisely GDI+, discover the boundless control you have over rendering to screen….but at a painful price.  The “flow” characteristic of UI’s depicted in HTML is lost.  You have to position everything explicitly, and relative placement (especially complex relative placement) is really hard.  But it’s that ‘relative flow’ which turns out to be one of the most powerful characteristics of Web UI’s, and therefore, what’s interesting with WPF (Windows Presentation Foundation, aka. Avalon) is that this flowy goodness is what has been bought over to the WinForms camp with the declarative language XAML.

So this leads into the device Tufte describes in his new book: Sparklines (Intense, Simple, Word-Sized Graphics)

There is a magnificent overview by Tufte of the theory behind these visual devices here.

The rub of course is that creating these Sparklines is not going to be trivial in a web-app, you’d have to have some kind of server-side processor to produce the image, but once you’ve got it, embedding it into the flow of the document would be trivial (that said, here is just such a server-side sparkline creator).

But in a smart-client app, the sparklines could be both generated client-side (using the clients CPU, not the server’s) and potentially much more dynamic and manipulatable.  But it’s going to be a bitch to implement from a flow perspective…until that is, we start working with XAML.

This is an exciting idea, and I can really some some exciting uses for it given making it so will be a fiarly triveal job with WPF.

Here is a nugget of pure gold.  Anyone involved in making a hi-tech product, please watch this frank conversation with the 4-star general of interaction design (Alan Cooper) in a conversation with Scoble and a few other Microsofters at a recent Patterns and Practices Summit.

His physical appearance, and the force of his delivery reminds me of some kind of military leader – but there is also a calm, bitingly intelligent quality to what he’s saying.  He’s not scratching at the surface problems of software creation – he’s going deep down (below “conventional widson) to the heart of the issue – and he does so with some serious cred.  Not just a designer, he’s a hard core programmer in his own right – and in fact the essential design of today’s Visual Studio can be traced back to his original conceptions of an IDE.

I’m fortunate enough to be heading up to San Fransicso in a couple of weeks to study at his design house.  I am so looking forward to getting up there and meeting the guys that are pioneering this field!

Nic’s just made some interesting comments on an new article by Joel ("On Software")  about usability, where Joel’s central tenet is:

“Something is usable if it behaves exactly as expected”

The example Joel holds up is the difference between Mac and Windows – where of course “we all know” (or are told by the black-turtle-neck brigade) that the Mac is far easier to use than Windows.  But Joel paints an accurate illustration of a PC user getting frustrated with the Mac because little things (window resizing etc) are all slightly different, and the user therefore incorrectly concludes that the Mac is a hard and clunky thing to use.

Well the point is dead on.  And what I think is useful to highlight here is that both systems had to be “learnt.”  There’s nothing intrinsically intuitive about either of them (in the sense that evolution did not genetically prepare us to know how to use a mouse or resize a window).  But as with any good idiom, we pick it up quick, and we don’t easily forget it.  Joel’s point though, is that if that idiom changes ever so slightly – we get ruffled real quick.

But this a diagnosis of the problem, and not a prescription for how you might solve this most vexing problem – making something “behave exactly as expected”.  The article is part of a series of essays by Joel, in which he promises to answer this question…and whilst I’m eager to see what he says, I can point to some answers that come from the field of interaction-design.

Namely the notion of the mental-model, the implementation-model, and the represented model.

Our mental model is our “cognitive shorthand” for how something works.  It’s the way we think it works.  And with complex systems like software, the way we think it works is almost never the way it actually works (that’s the implementation model).  Electricity doesn’t run like water throught the cord to our toaster – but if you think that way, that’s good enough to solve the problem of getting your toaster working.  There’s no advantage (in fact there’s only dis-advantage from a usability standpoint) in forcing the user to understand the true oscillating nature the electric current before they can get the toaster toasting.

And here’s the thing…in order to use it, most software forces the user to understand the way it does things by mapping it’s implmentation model straight onto the interface.  The weird, strange, prickly, arcane, processes that are convenient and optimized and natural for a machine are dished straight up to the end-user.  But your grandma wouldn’t expect to have to save the letter she’d just penned to C:\...\MyDocuments\MyLetter.doc, and then if she scribbled a PS on the bottom, to re-save it so as not to lose the changes….but then again, nor would you until you’d been told you had to.

We learn these things, and bend our mental models to the way the computer works – and forget we ever thought differently.  But if we want to make something that gives the “illusion” of being intuitive…we discover the way people actually think about something – then we design something that maps closely to that way of thinking (we construct an abstraction called the represented model).  And the user will encounter it…and they will have to learn it…BUT, if it maps closely enough to their world-view (it behaves as they expect it), they’ll learn it quickly, they won’t forget it…and if you’re really lucky…they’ll think they always knew how to do it – and run around telling their friends that your software is “intuitive” (not true, but who’s gonna complain?)

In conclusion, this in and of itself doesn’t explain how to make something “behave as expected”, but I’ve found it to be a useful model to get you thinking in a way that can allow you to include the user’s thought patterns in a way that relates intelligently to the software creation process.

What’s even cooler about this is that Rod grew up using Macs. His first computer experience as a boy was an Apple II, and it sent him on a trajectory to the heart of the software game, a trajectory that would ultimately put him in a position to play Segway Polo with Woz himself. 

“A butterfly flaps its wings in New York…” :)

There’s a feature of the iPod whereby if you pull out the headphone jack while listening, the device automatically pauses.  Whilst this at first appeared to be a cute flourish to the design, I’m finding that is has become an [un-internded perhaps] primary interaction. 

If I’m walking around with the iPod in my pocket, and quickly need to pause to talk with someone or deal with something in the environment, the simplist and most rapid way to do this is simply to “pull the plug”.

Analysis: Here’s why this is so good.  Firstly it’s a gross “manual affordance,” which has the added avantage of a cord leading my fingers right to it.  It also has zero cognitive friction.  There is only one resulting action – the track is paused.  There is no multi-mode aspect to this…I can’t pull it one way to pause, and another to resume etc. 

Pulling the Plug = Stop (period).

[As a side note, one of the most beautiful things I find about the iPod’s physical design is that you can actually reach into your pocket, and be able to navigate the basic functions of the player simply by feel.  The orientation of the wheel can be derived from the relationship of center “nodule” to the device-base/play-button…but in the context of this discussion, to pause this way is to incur higher cognitive friction.  The pause button must (1) be found on the wheel, and then (2) it has multiple states, it will either play or pause based on how many times you press it (the toggle behaviour of the button changes it’s action based on the current state of the device)]

Finally, the argument might be that to resume you have to put the plug back in, and then hit play.  A two handed operation.