Teaching email

I remember my first lesson on how to write a letter: how to address an envelope, the rigid explanation of formatting differences between business and personal, the impressive-sounding terms for the parts of a letter (the salutation, the complimentary closing, the postscript).  It was in elementary school language arts class.  We wrote letters and the teacher marked them up in red pen.  Commas missed after “Dear Mr. President,” and things like that.

They understandably assumed that letter writing would be one of the most common ways that I expressed myself to other people.  Little did they suspect that letter writing would be almost entirely supplanted by the writing of emails.  In fact, letter writing is still important because it is so infrequent.  It is a way to get noticed.  Writing a letter, to a company which has pissed me off, to my senator, or to a company I want to hire me, is the epistolary equivalent of breaking out the big guns.  Far, far more pedestrian is the humble email to which most of my written communication is consigned.

As regular readers may have guessed, I’m often appalled at how bad some people are at communicating through the medium of email.

This is why I think that email should be an important part of elementary education.  And, it should be taught by teachers of language.  (Tangentally, in my day they called this subject “language arts,” which I suspect is a rebranding of the subject “English.” I have no idea what they call it these days.)  Email is (or should be) no longer any more mystifying to a 10 year old than the postal service—so we don’t need computer/technology teachers to introduce it.  Using language to communicate is what email is all about, and kids will need more guidance on how to write emails than they will on how to send them.

Letter writing and email writing share a similar core, but should really be taught as distinct media.  A fundamental reality of email in today’s world is the sheer volume that people receive, unparalleled by letter-writing that preceeded it.  Most people will decide in a matter of seconds whether or not an email is worth the time to ever 1) read or 2) resond to.  In order to have any hope of getting their message across, students need to know how to write emails that sound out clearly among the constant noise—not an easy task for beginning writers!  They need to know the importance of writing good subject lines, how to get to the point quickly in the body of the email, and how to make it clear (and easy for their recipient to respond with) what they want.

They should be taught the (only slightly) technical details of email, just like we did for letters: how to address it, the parts (To:, From:, CC:, BCC:, Subject:, then the familiar salutation, body, closing), how to format not only original emails, but forwards and replies as well, the difference between HTML and Plaintext.  They should be introduced to all the fun that can be had with formatting, colors, fonts, pictures, hyperlinks and the <blink> tag, have their little hearts broken when it doesn’t display like they intended on their friend’s email client, and then be gradually weaned away from all the bling to find styles that fit the tone and purpose of the email.

If there are any elementary school teachers out there, I’d love to collaborate on writing some lesson plans for this. Get in touch!

Photo by adam79

Xobni: funny name, good times with Outlook

It’s hard to come up with a decent name for your web startup. Believe me, we spent ages brainstorming, arguing, deciding everything we brainstormed was crap, and brainstorming some more before we came up with a name for the web startup that I was very briefly involved in. Whatever name we ended up with must have been underwhelming because I can’t actually remember it sitting here in front of my computer 3 years later.

Even the big boys—who can pay slickery consultants to sit in a room and pontificate on made-up words that will jive with whatever freaky internet talk them kids are sending down the tubes these days—come up with ridiculous names for services and websites. Please allow me to Joost up my Hulu-craft and so that we may partake in a Qoop down the Jaiku.

In a world where every English word is already registered on the .com top-level domain, the makers of Xobni can be forgiven for spelling “inbox” backward and calling it a day.

If you use Microsoft Outlook (2003/2007) for your email, then Xobni (even in its currently beta incarnation) is definitely worth a look. At its core, Xobni is an email-search tool, but it is decidedly different in its approach than what you’d get with Google Desktop or Windows Search. Xobni’s interface is people-centric. I don’t mean this in a dopey television ad way; Xobni’s interface is primarily organized to show you helpful information about the people you email. When you preview a message in Outlook, Xobni’s vertical panel shows you information about the sender, along with the most recent conversations you’ve had, and every file you’ve sent or received from that person. It automatically parses telephone numbers from mail, so you don’t have to go hunting, although this feature doesn’t always find them, in my limited experience so far.

It does take up quite a bit of screen real estate, and I feel like my preview pane is now slightly too narrow, but it does pack a bunch useful stuff into the small space. My geeky, data-visualization-loving side can’t help but appreciate the histogram of the sender’s emailing habits by hour of day, but I can’t yet to claim I’ve actually found this to be useful. One day!

Oxford’s upcoming groupware project

OK, so I’ve blogged previously about how much email at Oxford sucks. But, as I alluded to, and as commented by our friendly neighborhood Oxford-IT-guy (thanks for reading, BTW), Oxford University Computing Services has a plan! The call it the Groupware for the University Project, or just groupware. Groupware is software designed to help groups collaborate. It’s been around forever, even though the name is new; and I guarantee that you’ve used it.

Email was the original groupware. It was the first “killer app” for the internet, and the vast majority of traffic on the early ‘net was email. Groups of researchers used it communicate in those early days, and today it is as mainstream as chocolate pudding. Usenet came next, in the 80s. It was a kind of discussion forum arranged around categories called newsgroups. Although it is still in use today, it has largely been supplanted by newer developments like web-based forums. The point is that lots of software is groupware: instant messanging, wikis, etc. So we all use different types of groupware for different purposes or for different groups. Other than email, there has been no University-wide attempt to give everyone a common set of groupware applications.

OUCS plans to begin deployment, according to the project page, in June of this year. However, the user requirements document was finalized in February, so we already have a pretty good “high level” idea of what the University hopes to accomplish. Even though the document breaks up requirements into 8 “components,” from a user’s perspective, there are 5 main applications:

1. Email
2. Calendaring and Resource Booking
3. Contact List
4. Shared Data Repository
5. Interface to Student Information System (SIS)

(The other 3 requirements components cover all the applications and are: encryption support, remote web access, and mobile access.)

Email is pretty self-explanatory, but there are a couple requirements worth noting:

• webmail needs to support a range of functions “typical of leading/common current webmail clients.”
• must have the ability to synchronize with mobile clients (e.g. syncML, Blackberry, ActiveSync)
• support for shared mail folders

The last one is particularly important for on-campus student groups, who often want to have an email inbox for the group which can be monitored by all the officers.

Calendaring is the ability to keep and manage one or more calendars which are stored on the server and accessible from either the web interface, a mobile device, or a desktop calendar client (iCal, Outlook, etc.). This becomes groupware when you have the ability to share your calendar with people or groups to aid in scheduling. Unfortunately, there isn’t a requirement to be able to schedule meetings with a visual representation of people’s Free/Busy information (generated from their calendar, if they choose to share it). This is one of my favorite features of using a system like MS Exchange Server. Let’s hope whatever we get has this feature anyway. Resource booking means being able to see when resources, like rooms or projectors, are unscheduled, and the ability to reserve them from the groupware. That’ll save a lot of time in trying to book tutorials.

The contact list is just like it sounds—an address book. They’ve included some much needed requirements that it is straightforward to import and export from the contact list. They’ve also mandated that the groupware interact with something called the Core User Directory, which I can only assume is the central University Admin’s database of all the people at Oxford. This should hopefully mean you can find contact information for people who are members of the University very easily.

The Shared Data Repository is a fancy name for a place to upload files you want to share with people or groups. Notably, though, it is required to have version control (yes!), be searchable, be cross-platform, and have directory-level access control.

The interface to the Student Information System is an integration requirement with Oxford’s existing system. The SIS is where students can look up administrative information about their status and update their contact information with the University (among other things).

I appreciate that OUCS has been careful to include requirements about platform-agnosticism: there would otherwise be the potential of many a Linux user being left out in the cold. The requirement that all groupware functionality be fully available via the web, securely, from any internet connection is a bold one, and I’ll be interested to see what software vendors come up with. I’m also pleased that at least for the email and calendaring they’ve explicitly listed mobile access as a requirement. It would be nice to see for the contact list as well, but there is a requirement about the groupware being compatible with 3rd party interfaces like Intellisync, so I’m hopeful this one will also end up being in the final implementation. I’d also liked to have seen a standards-based (i.e. Jabber) instant messaging system. I know that everyone already has their own favorite IM service/client, but the integration with the user database would make it much easier to find and make contact with people.

I have one final complaint: no wikis?

I’ll end by noting that I’m on the email list for the User Consultative Group, and we’ve just been having a discussion about “use cases” to send to software vendors.  So, I remain somewhat skeptical about them having a solution shortlisted and then chosen by June. My guess is that implementation is delayed until late summer at the earliest—but this is Hofstadter’s Law-style pessimism, so take it with a grain of salt.

Why Oxford’s email sucks

I’m a student at the University of Oxford, and as is standard practice, they provide a email system for staff and students. It’s called Herald, and I assume it’s a home-grown email server that has evolved from code written in the 1980s.

It’s a piece of crap.

I kid, I kid! Admittedly, that’s probably dropping a little too much hate on its poor aged lines of God-knows-what language. It has basic features and gets the job done… most of the time.

But the internet means so much more to so many more people these days, and Herald isn’t equipped to let people make the most of it. Take webmail, for example: ugly, testy, difficult—these are words which spring to my mind when I think of Herald webmail.  You’re stuck sending and receiving in plaintext, and the interface is offensively bad.  It was never supposed to be this way—Herald was designed to be used via your email client of choice, a hulking server hiding in the shadow of a more carefully crafted interface.  But since the early days of Hotmail, Yahoo! mail, Netscape and the rest, webmail has been a primary avenue of accessing email.  Some people prefer it that way, and its easy to see why: one interface to learn which can be used on any computer with an internet connection and a browser, and no obnoxious setup steps (IMAP or POP3? SMT-what? SSL-port-who?).  And since gmail came on the scene a few years back, there’s simply no reason to believe that webmail can’t be a pleasant experience.  Something is deeply wrong when free webmail services outclass what’s provided to you by the people you pay £10,000 a year.

But still, armies of my classmates here at Oxford use Herald webmail as their primary email.  They hate it, even if they don’t realize it.  I know this because it shows.  They use Facebook to send messages to one another.  That’s right, Facebook.  Facebook, with it’s terrible message editor, iron-fisted threading, and walled-garden take on communication.

But I’ve just been informed of a project in the works at Oxford’s computing services to change all that, and finally move beyond email and into the realm of internet collaboration.  These services have existed for some time now, and what Oxford is proposing isn’t anything groundbreaking—but they’re a hell of a welcome (if overdue) change.

I’ll blog more about them soon.

Critical information shouldn’t go via email exclusively

Sure, email is an easy way to send important information out to a large number of people. It’s almost too easy, and many people’s definition of “important” borders on ridiculous. The marginal cost in computing resources and effort to reach additional people is so tiny, it can be neglected in any reasonably sized organization. In many cases, targeting a specific subset of an organization is significantly harder than blasting everyone. For this reason (among several others) everyone gets too much email in the sense that the majority of it is either straight up spam, “important” information that we’re not interested in, or poorly targeted emails which don’t apply to us. I get tons of the latter at The Department, “To all Post-doctoral Research Staff,” (I’m a grad student; you’d think they’d have separate lists).

It’s easy to get overzealous in clearing your inbox when you come back from an afternoon away from your desk. I’m very good about reading my email, but enough is enough. Anything with that stupid red exclamation point or the capitalized words IMPORTANT or PLEASE READ in the subject line is on its way to the Deleted Items folder faster than my average ping to icanhascheezburger.com. There are people who let emails sit unread and undeleted in their inbox for days, nay weeks. Which brings me, finally to my thesis:

You can’t depend on email to convey critical information, especially if it is time sensitive.

Yes, email is easy. Yes, finding other ways of communicating with your fellow humans feels so 1989. But email is a congested medium and people find that a lot of it just wastes their time. Don’t blame your users for this! The solution is not to tell them they need to pay more attention to their email. The solution is for you to pay more attention to them. Take a multi-pronged approach which is appropriate to your organization. Are there noticeboards? Information screens? Put notes in people’s mailboxes, or post extremely critical information on the door as they walk in. Like this guy:

This, on the door to our office, got my attention. They were going to shut down the power the next day–would I have seen the email in time? Maybe. Would I have realized it meant me before deleting it? Maybe. Alan in building services, well done.

Sometimes low-tech is better than high-tech.

Anti-virus Email Footers

Can I just say that among my email pet peeves (and believe me, they are numerous) is when anti-virus software appends a message to outgoing mail, along the lines of:

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.20/1259 – Release Date: 4/02/2008

I copied this from a friend’s email, I won’t say whom. Remember, this is the sender’s computer which is appending this message. If my friend’s computer were infected with a nasty virus, which was spreading itself by sending email unbeknown to him, the virus could very easily add a similar tidbit to the end. Rationally, seeing such a message at the end of the email should in no way affect my confidence about whether or not this email contains a virus. It’s the equivalent of writing “This is not a mail-bomb,” on the front of every package you send.