The following is a meditation on design, and what might happen if enticing delight were a deliberate goal rather than a rare accident of our software and systems designs.
I recently had the pleasure of setting a man's watch for him.
The man was delighted by this act, expressing a joy that might have seemed out of proportion with the result. He told his friends throughout that day that his watch was now fixed and running with the correct time. Each time he retold the story, it was accompanied with this same animated delight.
The watch was only off by four minutes, so not hugely wrong. Apparently, however, it had been wrong for three years. And for three years this man had shared the story of his chronographic offset with colleagues and friends alike. Many, the story went, had tried to fix this watch and reclaim the lost four minutes. The record of hopes raised only once again to be dashed had grown long. But amazingly, this man had not abandoned hope: he kept *wearing* this watch despite the fact that each time he glanced it he had to be mentally adjusted by four. It was not as if he could not afford a replacement. It was almost as if it had become more important to continue to believe in the possibility that one day someone would fix this watch than to find its replacement. Until that day he would continue to offer the watch to anyone who would have a go, just so that *if* that person did succeed, he would be there to savour the delight in having it work again.
Now, since it has been reset, each time he looks at this watch he can re-animate that delight for himself by remembering how long he had carried it with this offset and how happiness could now be felt in such a simple thing as accurate time-keeping. He can also tell his friends his problem has been solved, and they too will share the joy of their good friend's relief. After all, some of them had been there to experience this regular tiny desolation in their colleague's life.
So the delight has not simply been in a watch running with the correct time - that is common - but that *this* watch now runs on time. The surprise and delight tied within the satisfaction that the man's hope or belief in the possibility of restoration of that which was lost was not misplaced all contribute to the delight in the re-set time piece. Such is perhaps the nature of delight: an internal state that is ready to be surprised by the unexpected becoming possible.
The trouble is, that with digital systems it seems that the unexpected is usually to do what should be normal.
Why is being able to set a watch to run on time (what one would hope to be normal) experienced here as extraordinary? What would happen, therefore, if we designed with delight as deliberate goal rather than if we experienced it as a side effect?
Technorati Tags: culture
Consider the parable of the watch: the repetition of the mistimed watch left open the possibility of delight and surprise should what was accepted as "normal" - the wrong time - become the very simple "right."
Computing is filled with examples of coping with the wrong time all too often being the normal.
Imagine the delight in changing that normal-ness of the wrong thing to the right thing. For instance, how frustrating it normally is when trying to get shipping information from an online store, where one has to add the thing to one's cart, register on the site, even provide payment information etc etc all just to find out shipping costs and times - something that will determine whether or not we wish to purchase from that site. Imagine how *delighted* a potential customer would be if the shipping quote was simply available at any point the person wished to know it? Changing the normal expectation of the online store hassle to the right action of giving the customer what they want when they want it may lead to delight and loyalty. They, like the man with the watch, may tell all their friends about their terrific experience with this store, this digital system.
In work we've been doing between MIT and Southampton in projects like Jourknow, we've been looking at imagining a world where one doesn't have to fill in a form to create a note about a phone call or a meeting or the name of a friend or any other kind of information. They simply jot it down, however they like to jot "meeting @ 3 c mc" or "3pm remember to get to meeting with mc" - the note is there; it's also now in the calendar. No forms with clicking and tabbing through 16 fields just to record one event.
It may be that as this potentially delightful way of doing things becomes the new norm, the delight may diminish. For those who would know no other way of interacting with a computer (once we get there) such natural interaction may not invoke delight - it will only be retrospective for those of us who have suffered with previous wrong time "normal."
So, are there attributes where delight may not be dependent on challenging normal so that a design might delight constantly? When was the last time a computer delighted you? Did it keep delighting you? or did what was once delightful become mundane? or did it continue to fold between the mundane and the delightful? I imagine that there will be times when the man looks at his watch and sees the time; at others remembers how it used to be and how it is, and re-kindles that delight for himself - hence a folding between the mundane of a proper normal and the delightful.
For me, my most profound and enduring moment of computer delight was witnessing the Flying Toasters screen saver. Toasters. With wings. Wings that flapped. And made thwap thwap thwap thwap thwap wing flapping sounds against the Ride of the Valkyrie as sountrack. Utterly absurdly gratuitous graphics and absolutely delightful. I remember about five of us huddled around a prof's computer just starring and laughing and poking each other watching the infinite progression of flying toasters across a computer screen.
The normal of the computer was work-based applications; the occasional game. This screen saver used the computer in a completely non-utilitarian, or non-computer or non-normal way. It turned a several thousand dollar piece of hardware into something whimsical. So even when flying toasters were no longer new - we had our own copies of the software - they did not lose their capacity to delight. At any point in the day, if things got a little too intense, well, there was always always flying toasters. There was always this reminder of the difference between the mundane and the unordinary as possible.
Flying toaster moments are all too rare with digital systems.
Why is that?
What would it be like to design deliberately to achieve delight? At least some of the components of delight are afforded by contrast between the expected and the actual; between the normal and the other. Delight takes the expected out of context. The watch that never tells the correct time, tells the correct time. The computer that's meant to be serious does whimsy. Delight is also pleasurable.
With these traits of difference from the expected, the norm, can we use them as motivators for design? Can we construct reverie? It seems that while the perhaps purer delight of flying toasters may be the harder kind of delight to design deliberately, that of addressing the more all-too-common wrong-normals are legion enough to provide an ecstatic revery of delight if only a few of them were tackled with intent. Let us not forget the classic example of the frustration of machines: setting of the VCR to record a program. Was not the delight of the first TIVO not only that commercials could be skipped but that what once was an horrendous process of setting the time on a vcr and then setting the parameters for recording a show became absolutely trivial: here's a program guide; click the show you want right in that guide. Voila - recorded. One may argue that well, we had to arrive at a place where we could get online program guides to be able to click them and send the correct info to a system to translate that into recording information. Right. So what. There are squillions of opportunities for better design where we do indeed have all the technology we could want to make effective systems possible, and just don't do it. It's easier to fill in a form than eliminate it.
Indeed, it's rather sad that there are SO MANY opportunities for this kind of delight in our regular daily interactions in our world. Why, after all, was the man's watch such a gordian knot to those who attempted to fix it? It's just a WATCH. Like filling in forms are what make things simple for computers, crappy watch setting design is what makes setting the time simple for the digital device, not the person using the device.
This is not to say that everything has to be simple. As designer and ACM CHI Fellow Bill Buxton has said, the piano has a very simple interface but it is not "easy" to master. The cost/benefit relationship of learning to master the device can be great, however. But a watch is a watch. The result is simply that it tells the time; it is not a direct intermediary to the muses. It should be simpler to set a digital watch than learning to play a Prokofiev symphony, no?
The moral of the story seems to be that the source of our delight around are devices is all to often when the wrong normal for a fleeting moment behaves as we would hope and expect such a device to behave. And while in part when such behaviour results we have a story of hope fulfilled, as in the man and his watch, that same story is also one of failure: failure of design, of imagination to produce technology that supports us rather than requires us to support it.
Perhaps if we designed with delight as a goal, we would be more likely to achieve something as simple as a digital watch that a human could set without having to be a phd in computer science.
The most popular current Web 2.0 representation is geography: putting everything on a map. It's a powerful thing to do: when we can SEE how close registered sex offenders are to schools and day cares, we have certain reactions about where our psychic sense of "too near" or "too far" meets the legal/phyiscal interpretation of "appropriate distance." A little bit of information, as has been said many times, can be a dangerous thing. This particular offender/schools mash up does not provide a brushing interface that, say, relates re-offender statistics based on various distances from schools to help confirm whether our sense of dread is well-founded our not.
It is with this caveat in mind that, our group has been thinking about how adding not just mapping but temporal mapping might be for a project we have called musicSpace to integrate a variety of musicology sources for easy exploration. More recently in a project called continuum we'd been looking at how to map rich data sets like classical music onto timelines so that the visualization doesn't implode. That is, if there's lots of stuff going on at the same time in a time line, all the info looks like a big blob, or if you zoom out, you lose the surrounding context. Our challenge was to solve the "too much info=blob; too little=not enough information" dilemma. Inspired by that work, we'd like to take what we learned there and think map thoughts.
Mapping Time
What we are calling Temporal Mapping is not unknown but it's not common. to be clear, temporal mapping has one meaning in discussions of disease tracking for instance that doesn't involve visualizations; spatio-temporal mapping has another meaning in computing. The kind of temporal mapping we're considering is more akin to an example from the Land Cover Institute which on a map over a relatively stable geography shows how population density has grown and spread over 200 years. Other work shows how the geography of a place itself (such as a river valley) changes over time.
'Istanbul was Constantinople now its Istanbul" - They Might Be Giants
Our sense of temporal mapping it turns out is more complex than these example because it turns out we are looking at a variety or parameters that change: in terms of locations, borders change; names change and even the geography can change. One way to reflect this change is to use maps that can present borders/locations that are accurate for a given period - this assumes that various places recognize the same borders/place names. Consider the mapping of Taiwan as a political representation issue. To use the music examples, if a composer created something in the 1700s, the borders of the domains were different and the place names may be too, so we need to have maps with borders and place names that are accurate for that time. As we discuss below, there are other issues that come into play when, to coin a phrase, wanting to co-map points that cross times, and thus cross representations of locations.
Even if we don't want to co-map, but restrict ourselves to single maps, there are some challenges: if we know where a piece was composed we map that; if we know where a composer was born we map that, if we know where a composer first performed a piece we map that.
There are a few data subtleties there: do all objects in a classical music repository now need Lat/Long data associated with them, as well as a date? Even there the temporal bit is not so obvious: there are kinds of dates and kinds of locations: how tease these out so they are clear in the UI? so it's clear a person is choosing to see performance dates/locations rather than composition dates/locations. What happens if a work was known to have been taken out and put away over a range of places and times? How is that stored in an object in order to be represented?
If we put aside that question of the back end data representations and UI finesse for the moment, let's assume whatever it is we want to map in music we can map, the more glaring, basic challenges are how both borders and place names have changed not just over the centuries but even within decades. Maps that only map against geography lat/long have it somewhat easier than mapping against historically/politically accurate representations.
And as always, the question of how to represent the information is non-obvious. For instance, how handle multiple names or boundaries for a place? Only show the appropriate name for the specific time? Show all versions to provide context not only of place but between times? These kinds of decisions become critical when crossing domain representations. For example, what happens when looking for a location in europe that produced the most major compositions of the Romantic Era relative to location(s) in Europe of most significant performances in early 20thC. The borders and place names from the 1700s and indeed even between 1914 and 1920 change several times.
So Temporal Mapping is?
Perhaps a fast way to begin to think about temporal mapping in arts and humanities data that involves people, places and times is to be able to accurately reflect these places as they were interpreted both in their times, and in ours, and to be able view these comparisons from any variety of perspectives - comparatively, relatively.
Animation and Insight
A potential benefit of developing temporal mapping approaches for arts/humanities data is in meaning that is communicated through animation: if we can step through the various places by time of where Beethoven worked - see who else was in the neighborhoods at various points, and correlate that with specific works, and perhaps specific historical events and their key locations, can we begin, almost at a glance, to get a new appreciation of a domain space? Do seeing these patterns animated over time and space and politics and whatever else let us ask new kinds of questions - questions that would have been potentially intractable to ask before?
These are early days for our investigations, but from early scenarios domain experts have given us, the ability to step through time, and to see events of interest comparatively across time and space, is a thing devoutly to be wished. These representational desires are driving our current UI research efforts.
I've been pondering what the paradigm for the Semantic Web is:
if the Web is like a page + links, what's the analogue for the semantic web?
Where i've come to recently after thinking "star trek next generation's computer in conversation with Geordi LaForge" is a researcher's notebook + memex: a place that blends work in progress with internal and external associations/contexts that become explorable for building new knowledge. The key to the analogy of the notebook is the notion of work in progress, where notes include scattered fragments of information where context/structure is often implicit, and can reach out to external sources, knowledge, references.
I've discussed this analogue in more detail (with pictures) in a blog piece called
"What is the Analogue for the Semantic Web? If the Web is like a Page+Links, the SW is like a..."
Technorati Tags: hci, interaction, mit, semantic web, southampton
In the vein of stating the blindingly obvious:
designing useful and usable tools isn't just about good widgets. There can be great widgets that will let a person carry out a task.
But what if the person doesn't want to carry out that task?
For insance,
In the UK there's a requirement to make publicly funded research publicly available - many places are turning to repositories like Eprints that will enable this process to happen. But right now, getting papers into Eprints is a manual, tedious process: filling in fields and fields in forms.
The "pro bono" argument is that increased access to the data will enable better access to cutting edge research.
A slightly more self- interested benefit is that there is research to show that openly available papers are more than twice as likely to be sited than those that are not.
But that petition to self-interest to leverage future benefit to off-set current pain does not have an immediate, perceivable benefit for the person stuck with uploading papers. We've seen that people just don't do it.
As Alan Dix might put it, the perceived cost is higher than the perceived benefit. The What's in It for Me effect only works, it seems, when that benefit is immediately perceivable. For instance: take these steps now to upload these papers and you'll never have to add them to your cv again: they will automatically update; also, one line in a web page will let you publish all your papers formatted anyway you want.
So either the benefit must outweigh the cost or the cost must be reduced to the point where future benefit is sufficient to cost. Seems obvious, eh? But the idea does suggest that usability is about perceived usefulness as well as usable-ness.
about "what's in it for me - NOW" not just "what can i do with it"
This might also be seen as where affect meets effect. This again is not new in the design community: Dillon's proposed model for assessing applications, Process, Outcome, Affect, formalizes the role of affect - how the user feels about their experience in using a system: do they feel empowered. Ethnography has also always looked at what is the cultural context of the planned artefacts to be developed?
One thing that may be new, however, about using "what's in it for me" as a design query, is that it asks the question of affect before the system is developed - but i won't claim that for certain. What i will suggest is that putting design issues in terms of "what's in it for me" is an easy way to translate the iimportance of effective/affective design to non-hci specialists (ie, software engineers).
If your software cannot pass the test of what's in it for me? of the perceived cost being balanced by the perceived benefit, then it's time to rethink the design.
i was at a talk lately where an interesting tool was presented that all the people in the audience said "wow that looks really complicated to try to set up" - and these were rocket scientist type people. The challenge to the presenter was "would it perhaps not have been better to talk with your stakeholders about how they already do what they do and then design the tool to support that, rather than what seems to be the other way around: designing a tool and asking the community to adapt to it?"
The response was a gob-smacker: that if we had designed for one community, then we would have a custom tool not a general tool.
Perhaps having a tool that was useful and useable by one community would provide a path to a tool that was more generally useable - rather than a tool which now is general but that puts the fear of god into anyone who goes near it - where the what's in it for me - the perceived benefit - is (a) unknown and (b) not even approached because the perceived cost is far too obvious.
So, take away: start with finding a me to whom you can ask "what is in it for me" - and test the answers against the push back of cost. it'll likely end up being pro bono, too.
Like most folks, i get a ton of email. I get a ton of attachments with email. And those attachments are evil. For the most parts they have only generic names like "my assignment" or "Job Application" or "invoice". The mail client will add a number to the name so that one file doesn't overwrite another, but that's for the file system's benefit, not mine, the human being trying to make sense of these files without having to come through associated emails.
So whose problem is this? people's for not using more descriptive name identifiers?
I blame the System.
But to be proactive, we suggest alternatives...
It's not right to ask people to who have some kind of file template to come up with nice rich file names - especially when some folks are still getting over the legacy of 8char file names plus three character extensions.
But those days of short file names are G O N E.
So we need file systems to step up to the plate and help name these suckers in meaningful ways. There's lots of simple stuff a file system could do: it could automatically prepend all files with a user id; it could develop a bunch of project codes/names that a person could use (like course numbers or business names) for specific files, and have defaults set up which a person only changes as they need - if the system can't determine the context from other cues in the data itself.
With more operating systems deploying technologies for rapid content indexing, such reading of documents for labeling cues isn't that unlikely.
Simple selections with well chosen defaults could take a load of effort of people for creating reasonable labels for files both for their own later retrieval and for sharing. These same file names could be decoded on the recipient end for multiple categorization of these resources, too. So i could say for instance "show me all the files associated with comp6012 from Alistair" without having to reef through file folders.
I know this kind of listing is just what Apple's Spotlight is aiming at in OSX Tiger due out April 15, but index retrievals alone are not enough. we still like to be able to look at where things are in relation to other things, so we need to make these labels apparent to us, not just derivable by the system.
In the myTea project, we're looking at this kind of approach of assistive file naming for bioinformaticians (see the short paper on this), whose biggest challenge it turns out is not coming up with new insights into genes, but is managing the hundreds of files they get on their desktop which are generated by the various Web processes they run.
We can do this. And more than just improve personal data, we can get that data into sharable forms which makes it feasible for people to share the parts of their work they wish to share with the world or subsets of the world, where this information is meaningful. Community. We can do this. It's time to be liberated from the file systems and provide interaction that frees us from naming files and lets us get on with what we want to do: have fun, create knowledge, share.
What if starting with technologies currently available, we were to rethink how to support mail electronically? would we end up with email?
What if, instead of taking a purely functional, or task oriented view to email, that of getting a note from here to there, we were to think about the affective properties of mail, and of letters in particular? What if our design goals were to incorporate both the functional and the affective into this new digital mode of communication? what would this new digitized form of communication be like?
These are the questions the Masters students in COMP6012 are considering in order to think new thoughts about existing technologies that are based on 30+ year old, command line systems. Sure the GUI has brought new features to email: multiple concurrent open windows, embedded HTML, graphical icons to
replace text typed smileys, new ways of connecting contact and date information from email into contact managers. great.
And, to be sure, email is not physical mail. It's become a whole other communication medium.
But these are just the differences that the group is looking to tease out. What has been lost in comparison to physical mail? what's been gained? do we want to reconsider whether what's been lost needs to stay gone? are other modes of communication taking up the parts missing from email that were once a part of physical mail, of letters or cards in particular?
The question makes me think about blogs again. As i wrote recently, my casual survey of blogging in our group suggested that blogging has two core purposes: journaling, and letting family and friends know what one's up to.
There's something letter-ish, to be sure, about those kinds of blogs: extended entries, the possibility of multiple people looking at the same arifact. But why not email the thing to everyone with a cc to all? Perception? In email, one looks at their own copy of a cc'd missive. In a blog, despite the technical reality of one downloading a local copy of a web page (similar to email), there's the affect of sharing the same artifact: everyone goes to the same URL. Is that a similar experience to passing around the same letter? that social experience then enforced by the medium (paper) replicated in the sharing of the URL?
I still think there's something voyeuristic/exhibitionist about exposing communication supposedly primarily intended for oneself or one's friends to the world (and why help identity thieves?) but there is something undeniably social here that does seem to be both missing in email and present in physical letters.
Other attributes do not seem to be echoed in any other digital manifestation right now, though perhaps new IM client features are moving towards them. If a letter pisses one off, it can be returned, torn to shreds. If it is treasured, it can be carried in a special place, saved in a favorite book, close to hand, secret. Where's the digital equivalent here? Where's the social equivalent of everyone seeing that you remembered to send the birthday card that is happily displayed on the wall, or kept on the fridge? How emulate any of these effects? Do we need new hardware to support such display or effect- like the digital picture frames now available for displaying changing favorite photos? How emulate texture, beauty of hand crafter paper, fountain pen scrawl? the suspense of the envelop, waiting for discovery.
There's another side to the consideration of the reinvention of digital letters: is their anything new the computer can bring to textual communication besides what it already has (filters, search, indexing - effectively archiving and file management)? To answer this question, do we need to think not about mail, but about what we cherish in asynchronous exchanges?
There's a scene in Minority report the main character obsessively watches a 3d video of his son on the beach. The video is shot from the father's perspective. We can hear his voice off camera as he asks his son questions. In the now of the film, the son is dead and the father, in his darkened appartment, steps into the position off himself then so he can seemingly look into his son's digitized eyes, and mouth the same questions along with the video. This is a human moment (a pain cry for therapy to be sure but poignant nonetheless), enhanced, enabled by the lifelikeness of the digitally captured, infinitely repeatably copy of the moment.
It is a precious digital artifact, kept (referenced) on a special lucite-clear disk. The disk is inserted into a player to initiate playback. A techno geek may scoff, oh come on, all that would be on a server: no need for the plastic disks. And yet, and yet. From an interaction point of view, that marker, that disk (perhaps only a URI pointing to an associated file on a server?) gets at some of the preciousness of the physical, tangible, of older familiar beloved, personal atifacts, like letters, and blends them with the potential evocativeness of the pure(ly) digital replication.
Projected video, however, is an easier mapping here to tearing off a moment of real life to replay. Letters are abstract, textual, imaginative. What is the role of the medium for something abstract, always translated from signs?
Which comes back to the question: what do you treasure of physical letters? what do you wish you could do with email that you can't?