I was forcibly reminded yesterday that many aspects of software that we consider intuitive and automatic are actually cultural, and have nothing whatever to do with GUI design. My mini-Waterloo? Calendar management and responding to meeting invitations.
I was baptized early in my career in the religion of managing a calendar. Early on it was the Franklin Planner, which really is a religion. Then it was the calendar system in Lotus Notes. At Microsoft, of course, it was Outlook. —Of course, Microsoft takes calendar management to dizzying heights. Invitations are sent to secure half-hour chat times with someone down the hall. People spend hours looking at shared calendars for multiple individuals to find ideal meeting times. Calendars are blocked off with “work time” appointments so that you don’t get pulled away by someone who has observed that you don’t have anything scheduled for the afternoon before something is due. When you can’t find a time for everyone to meet together, you start triaging meeting attendees and making calculated decisions about who can reschedule their conflicts and who cannot be moved. And finding spare time in a conference room becomes an art in itself. All of this is done through Outlook’s interface without ever speaking to anyone.
With that as background, it is perhaps a little more understandable that I forgot that the calendar culture is a culture, and not everyone understands its rules. So I shouldn’t have been surprised when no one RSVP’d for a functional spec review for which I sent out an invitation two weeks previously. I was a little irritated that day when no one showed up, however. I spoke to my counterpart in engineering about it, and he was sanguine: “I don’t use Outlook’s calendar,” he replied. “I view the meeting invitation as a reminder about the time, and then I delete it.”
Computing is a cultural artifact. Things like the “Accept,” “Decline” buttons on invitations only have meaning in a shared context where everyone agrees on how they are used. This is one of the reasons that specs are important, of course—they provide a formal definition of an agreed shared context for how something appears and is to be used. But we can never forget that specs and user interfaces and user scenarios are just the beginning. As William Gibson wrote (several times) and I am continually relearning, “The street finds its own uses for things.” It is how your users interact with the software that defines what it can do, not what is written in the spec.
Others on the Outlook culture of meeting management: Jeremy Gilby on meeting request filtering and Kirk Allen Evans on taking a Microsoft class on using Outlook more effectively. Allister Frost is practically a computer anthropologist’s dream. Read these posts and ask yourself why you would want to filter the Outlook 2003 calendar by labels, think about sending information as tasks vs. calendar items, integrate tasks and the calendar to block out free time, memorize a keyboard shortcut to transform emails into calendar appointments, or use Outlook as a backup brain to remind yourself what you have been doing.
