The fish have started to reappear

The fish have started to reappear, and the mystery of what they've been up to all summer is solved: I'm pleased to announce the patter of tiny fins.

Andrei Alexandrescu, Modern C++ Design

Most good computer books enhance your understanding -- of theory, of practice, of process, whatever.  It's rare to find one that transforms your understanding.

Alexandrescu's thesis is simple: that modern C++ is expressive enough to be used as a design language instead of an implementation language.  His first example, policies, illustrates how the language enables you to express design choices -- for example, whether to create objects via operator new or from prototypes, or how a smart pointer should manage ownership or thread-safety -- as template parameters.

This in itself is a pretty dramatic step forward for C++, but Alexandrescu then combines it with the concept of typelists, a way for code to talk about types themselves instead of just object instances.  Armed with policies and typelists, Alexandrescu goes on to provide generic implementations of design patterns such as Visitor and Abstract Factory.

Think about this for a minute.  With Alexandrescu's techniques, you can express a design pattern directly in code.  It's no longer a matter of recognising the pattern and manually implementing the code for it.  Once you've made the design decision -- for example to use Abstract Factory -- you can express it directly in the code via Alexandrescu's AbstractFactory<> template.  And because AbstractFactory<> is parameterised by the list of types and the creation policy, you can equally easily express the design decisions of which types the factory creates and how it creates them.  The language allows you to directly express these design decisions instead of implementing them.

This, for me, is a transformational change.  I'm used to C++ as a language for expressing low-level choices.  I'm used to vocabularies for expressing design choices at a documentation level.  What's new is the way Alexandrescu's C++ gives us a vocabulary for expressing and executing design choices directly at the code level.

In the interests of realism, I should point out that Alexandrescu uses advanced language features that are currently poorly supported by some popular compilers.  (Oh, all right, let's name names: the Microsoft compiler isn't up to the job.  To be fair, Microsoft's C++ team have said that compiling the Alexandrescu library is one of their top priorities: but for the time being, if you're using Visual C++, you're out of luck.)  But this is almost beside the point.  Compliance will come, and pioneering yet practical work like Alexandrescu's is exactly the incentive the compiler vendors need: who wants to be the only vendor who can't handle AbstractFactory<>?

In any case, this would be worth reading even if no compiler were ever to implement the parts of the standard Alexandrescu needs.  It is worth reading whether or not you are interested in C++, just like Structure and Interpretation of Computer Programs is worth reading whether or not you're interested in Lisp, or Object-Oriented Software Construction is worth reading whether or not you're interested in Eiffel.  For the most part, it's not about libraries or C++; it's about the issues of writing programs at the level of design rather than implementation.  (There are some bits about how to abuse the C++ compiler to achieve design-level goals, but these are relatively few and far between.)  It is a manifesto as much as a cookbook, and it's certainly made me think about the expressiveness of code in a whole new way.

The Beaufort scale of cruft

Verity Stob develops a Beaufort scale of cruft: "Cruft Force 3. Lived-in. Description: One time in seven when the user starts Word or other Office 2000 app, instead of running, it pretends it is installing itself for the first time and starts a setup program. Directory count in C:\ up to 17, and something has pooed a Paradox lock control file there, too."  When I sent this round the office, you could hear the muttering as people fired up Explorer and started counting... and yes, she was right about the Paradox files, too.

Not Your Parents' System Tray

Microsoft Research (via Sam Gentile): "As we work, documents are updated, information on web sites is modified, databases are changed, and the people we depend on come and go... Sideshow is an awareness interface with the goal of helping people stay aware of large amounts of dynamic information without overloading or distracting them."

Well, and so was the Windows 95 notification area (aka system tray).  Having a little bit of the screen where applications could notify users of interesting things was a good idea, but: (a) the tradeoff between compactness and rich information, while reasonable in 1995, has shifted the other way with larger screens and more things going on in the background; and (b) greedy applications have now put so much rubbish in the tray that Windows XP now has to hide it all again.

Sideshow tries to fix these problems by allowing a lot more space for notifications -- so applications can provide information like how many emails are high priority and how many are low, or what the stock price actually is, or which of your IM contacts are online and how active they are, instead of just a 16x16 icon -- and by putting the area under user control rather than letting any old app fill it with "I am running!" messages.  (Would you believe my mouse driver puts an icon in the notification area?  Does anybody seriously believe for one minute I want notifications from my mouse driver?)

It's an exceptionally rich environment: lots of information and options packed into a very thin strip of space.  Richer info than the tray is clearly a key issue: users cite knowing who their mail is from and whether it is marked as high priority.  The personalisation story is strong too: the authors suggest an example whereby an eBay auction could provide a link to "watch this item in Sideshow."  It's easy to imagine that all the background activity that interests the user could flow through Sideshow.

So does the road to Longhorn begin here?  Well, it's cosmetically similar to some of the rumours going around, and instinctively I'd leap from my seat and say "Microsoft can't pass this up;" but actually I'm not so sure.  The Longhorn UI has been trailed as "task-centric" -- in the tradition of XP's task panes and Whistler's aborted Activity Centres -- whereas Sideshow is more data-centric.  (Yes, you know and I know that this is a spurious distinction, but will that be enough to stop Microsoft marketing?)  And Longhorn has to sell into countries with poor connectivity: the UI can provide easy ways for users to access the Internet (the "Print My Photos" kind of link), but it can't demand always-on connectivity.  Even in the wired US, this could be impractical in the laptop market.  And it's certainly not the whole UI: Sideshow is about notification and awareness, not working with specific documents or applications.

Frankly, it's too early to speculate where this research effort might eventually fit into Microsoft's UI strategy.  Who knows what the connectivity landscape will look like in 2005, or whether Microsoft will be trying to sell different "editions" to home, business and mobile users?  In the meantime, the Sideshow project looks like a good resource for anyone designing an "awareness" interface.  The authors' conclusion, that users do value awareness but it must be appropriate to them, is useful and encouraging for anyone designing "dashboard" style interfaces, and the paper is worth reading for the design goals alone.

By the way...

...I particularly liked the article which, describing Sideshow, explained that "the company has developed an application that displays a series of windows with useful information on a user's desktop."  Nice to see someone striking out against the flow of only displaying windows with useless information.

...The prototype version of Sideshow was put together in Visual Basic by an intern.  If it's good enough for Microsoft Research UIs...

Information architecture and morality

Matt Goddard dispenses justice to someone asking about the usability of Dynamic HTML: "Since when do usability architects focus on technology and not the user?  It doesn't matter what technology you implement a feature with, as long as the user can easily determine how to use it."

Since blaming Jakob Nielsen is now the done thing, let's see if we can lay this one at his door as well.  Nielsen has spend quite some time savaging Flash for its appalling impact on usability, and quite rightly so.  Now Nielsen's condemnation was not directed at Flash-the-technology, but at Flash-the-design-school: the graphic design marketroids who believed the Web was a platform for them to wow their art school chums, and if the proles had to learn a different scrolling technique for every site they visited then that was a legitimate sacrifice in the name of Art.  Nielsen's work for Macromedia trying to educate Flash designers in usability clearly demonstrates that he understands the distinction.

Unfortunately, his constituency does not.  They read headlines like "Flash: 99% Bad" and conclude that Flash-the-technology is inherently unusable.  By extension, other technologies that are easily abused to create unusable interfaces are also unusable.  Hence the supposed information architect asking for information about DHTML usability.

Ten years ago, we mocked user interfaces where every button was a different colour and a different font as "Visual Basic interfaces."  Did those interfaces make Visual Basic a bad UI technology?  Should UI experts today insist on hearing about VB usability before agreeing to it as a development tool?  Of course not.  VB made it easy to create bad UIs.  It also made it easy to create great UIs.

The problem, then as now, was that there are more bad UI designers than good UI designers.

There are legitimate questions about the usability of popup menus and other complex artefacts on Web pages.  I would certainly like to know how the tradeoff between lengthy static menus, search facilities and fiddly popup menus works for different user profiles.  But to cast this in terms of whether Dynamic HTML, as an implementation technology, is "usable" or not is to miss the point.

Post scriptum: It's worth mentioning that there are often usability issues with particular technologies.  For example, Visual Basic's drawing performance used to be awful.  This would have a huge effect on the usability of a graphics-heavy user interface, and the UI team should be aware of this and should either choose a more suitable technology or find a UI that was practical given the technical constraint.

Naturally from a UI point of view we would prefer option 1, but sometimes it's not realistic to tell a room full of VBers, "Okay, chaps, we need to learn C, and we need to learn it by Tuesday."  But it would be wrong for the UI designer here to ask, "Are UIs developed in VB usable?"  The right question is, "Given the practical constraints on the technology, what is the best UI?"  Design is often about trading off ideals against practicalities, and UI design is no exception.

Iraq and terror

New Scientist: "An influential think tank has warned that an invasion of Iraq could worsen the terrorist threat, not reduce it. They fear it could disperse weapons stockpiles - and the scientists who can build and use them - into the murky world of global terrorism."  In all the debate over Iraq, this is the first time I've seen this brought up, and it's terrifyingly plausible.  This needs wider public debate, but nobody's talking about it.

Weirdest pop lyrics

"Everybody wants prosthetic foreheads on their real heads."  Frankly unsubstantiated market research from They Might Be Giants, We Want a Rock.

"The image of the female self subverting the male dialogue with his dick."  Sex, yes, violence, yes, angst, yes, but post-structuralism?  Pop enters unknown waters in Katell Keineg, Leonor.