[the following is a response to a thoughtful and provocative essay by the wonderful folks at Johnny Holland, where Stephen Anderson attemps to outline an informatics-based behaviour influence/modification system for email, and I contend, arguing that it's technology, not behaviour, that needs to be fixed. you should read the article, followed by my comment and Stephen's response in order for the following to make sense.]
Stephen writes:
If I was designing a new email platform from the ground up with these things built in, the execution would probably be different– I’d build some of these ideas into the architecture of the system– take a “break away from the conventional ideas that have got us in this mess, ” to quote the article. But, that would introduce a bigger problem: asking people to change their email platform (which is a much, much more daunting challenge than the gaming I describe in the article!)
Yes, its a tricky business1. Create a temporary fix on a broken system and risk cementing it even further, or create an entirely new system and cause upheaval? I don't have any good answers, but I suspect a redesign of email needn't cause much upheaval at all, and in fact might make things even more invisible.
Stephen further comments on context:
Your comment about context seems to me the more challenging one– and a critical consideration.
Context is a tricky business. Paul Dourish has written extensively on context; if you can survive his invented terminology ('technomethodology'?!!) - and 'where the action is' is an excellent read - he has interesting things to say about context, the most consequential of which is that context is created through interaction. What this means for our email quandary is that email software could become much better at knowing what to support by paying attention to its interactions with the user.
To elaborate: most (desktop) software at present is usually state-ful but path-agnostic. If you think of software as something that's a set of states (displaying email, writing email, downloading attachments etc), then interaction is a path through software states. [most web software is actually stateless on the server side, which is why cookies are used to track state on the client side].
Most software doesn't actually track the path through a particular state was reached. For instance, when composing a new email, it doesn't matter if you are replying to an existing email or starting a new thread, whether you were just viewing a project folder or your inbox. The email compose window functions the same way, and what it does and presents to you are largely identical in all cases (if you use the postbox email client, the sidebar always shows all attachments, regardless of who is involved in the email.)
But if email software were to act differently depending on the path taken to the current state, then each state has actually a lot more information to act on, and this makes for opportunities to better understand what the user is doing and adapting accordingly. So, if you were viewing a project folder and composed a new email, that email could get automatically put in the project folder. Or if an email is referred to repeatedly during the course of a day to then suggest showing it in a more persistent view. Or when responding repeatedly to emails from a particular person, to prioritise new mail notifications from that person. (these are just crude examples: actual behaviour would probably have to be a lot more sophisticated)
These are ways to be path-sensitive (and hence interaction-sensitive, and context-sensitive) within an application. But the notion of context extends a little further than that - full context-sensitivity must, I think, consider:
-
interaction paths (whether within or across applications)
-
contemporaneity (what else is being interacted with/running/happening)
-
tendencies (what happens more or less often - this is where most personal informatics focuses, and its the idea behind gmail labs' ‘Bob’ features - ‘Don't forget Bob’ and ‘Got the wrong Bob?’ and Firefox's awesome bar)
-
interaction patterns (sequences that are semantically meaningful, even if not constantly repeated)
-
organizational structures (or information relationships)
[This is not even taking into account the place (say, a meeting room), the people involved (and their relationship to you), and the actual content of the email (or whatever else) itself. Which is a discussion for another day.]
This is where we can return to the central quandary posed by the personal informatics behaviour modification system Stephen proposes: bandage a broken system or force re-learning? I think that this may be a non-issue: if email clients are ‘smarter’ in this sense, we might be able to use the same interface to deliver much more complex behaviour. So, when Stephen writes
For one person, 10 emails a day is the norm. For someone else, juggling several 100 emails a day may present no problem
he's actually thinking of how to make an interface that has to work for different people with different behaviours. But this notion of context-sensitivity suggests interfaces that behave differently depending on, say, the number of emails a day, and so work for the same person when they receive 10 emails a day equally well as when they receive a hundred. (That's within-subject, not across-subject variance, for you psych geeks).
Which also brings us to the issue of whether normative behaviour modification when it comes to email is a good idea in the first place: email use co-evolves with the existence of other collaboration & communication tools, and some of the reasons for behaviour modification (or context-sensitivity, for that matter) might no longer exist, and the associated behaviours might simply cease to be.
This is a worthy experiment. Are there any interaction designers, inspired engineers or tinkerers who want to take this on? I'm interested in developing this further.
Notes:
1. Gratuitious arguments using the Chandler Project will be summarily ignored.
