02.17.09

Dangers of email

Posted in Email, Too Much Information at 4:59 pm by admin

This happened back in late 1994 or early 1995, but thinking about it still makes me laugh…

Ben Johnson, a graduate student at the University of Illinois developed a wonderful, wonderful webmail tool called @ATS to help NCSA provide email support for Mosaic, the first graphical Web browser.  I was good friends with Mitch, who was in charge of Macintosh tech support for Mosaic, so I heard about it.  I could see that it would be immensely helpful answering all the email questions I got in the course of my job as www.uiuc.edu webmaster, so talked NCSA/Ben into letting me use it also.  Ben warned me that it was still quite new and under development, but I didn’t care — it made my life much easier even in that early stage.

Back in those days, there wasn’t nearly as much spam.  The very first commercial Usenet spam had only come out in January 1994.  Thus I was a little surprised to get a message to the webmaster account with an extremely pornographic subject line, and a body that was a word salad of dirty words.

I forwarded the message to Mitch, and asked in the body of the message, “Do you get messages like this frequently?”  I got back a message from Mitch saying that yes, he did sometimes get messages like to the Mosaic support email address.  Fine.  I forgot about it.

The next day, I saw Ben.  He said that he had needed to do some troubleshooting of @ATS, and had to go into my account to check something out.  I had developed a webmail system myself, so empathized.  This seemed perfectly understandable and reasonable to me.  He continued by assuring me that he was only there for a moment and emphasized vigorously that he did not look in any of the messages, only at the subject lines.

I think he was puzzled but relieved when I burst out laughing.

I did explain why Mitch sent me a message with the subject

Subject: Re: verb your feminine-noun

and let Ben know that he didn’t need to inform the higher-ups about potential sexual harassment. :-)

11.19.08

email tool

Posted in Email at 8:01 pm by admin

I spoke a while back with Jason Gallic, the Product Marketing Manager for Email Center Pro.  They have a product designed for improving email-based customer service, including automatic reply templates.

Fourteen years ago, I got to use a webmail system @ATS, developed for the National Center for Supercomputing Applications by the talented Ben Johnson.  (Ben?  Email me!)  @ATS let you set up filters that would suggest a response if the condition you specified was met.  When you read a message, after the message at the bottom, there would be a few checkboxes next to titles of suggested responses. I had the option of selecting any or none of the checkboxes, then pressing either a “Send as is” button or “Edit response” button.  @ATS would include the responses that I checked, and send/let me edit it.

For example, I had one filter set up to suggest the “Undergraduate admissions” answer if the word “admissions” was in the body of the message.  I had another filter which suggested the “Graduate admissions answer” if the word “admissions” was in the body of the message.  By reading the message, I could sometimes tell if they were interested in graduate or undergraduate admissions, in which case I would click the appropriate box and send it on.  Sometimes I couldn’t tell, so I would click both boxes and send it on.  Sometimes I wanted to add a little extra information that I happened to know — if, for example, they asked about who would be a good advisor for research on hydrogen embrittlement in high-carbon steels — I would check the “graduate admissions” box and add the additional information before sending it on.

I ranted to Jason about how useful auto-suggest is; we’ll see if he manages to get it into his product.

06.12.07

Email overload

Posted in Email at 10:37 pm by admin

I’ve been watching the blogosphere “discover” email overload recently. Merlin Mann has recently posted about email overload on 43folders about Larry Lessig declaring email bankruptcy, and Itzy Sabo has an entire blog about email overload. Boingboing.net just posted that one of their authors will be interviewing Mark Hurst about email overload.

I’m a bit bothered by an implicit characterization that “email is the problem.” This isn’t fair to the medium. Your problem is that lots of people give you stuff to do. (“Read my message” falls into the category of “stuff to do”.)

People have been overwhelmed by the amount of stuff that other people give them to do since long before email. Before email, I would get overwhelmed by phone calls, memos about so-and-so getting promoted, packages from HR detailing the new benefits plan, people stopping by my office, presentations, meetings meetings meetings and more meetings. The fact that all of the stuff to do now arrives via email does not make it email’s fault.

Yes, it is true that more people send me things by email than used to send me paper documents. However, I don’t have to go to nearly as many presentations as in the days before email. Once upon a time, back when I started working in 1984, it was routine to go to a meeting where someone would present information in almost a lecture format. These were pretty boring because only about 20% applied to me, but I had to sit through the 80% that applied to the other people in the room.

The only alternative to presentations was for the presenter to instead write a big thick report and either make 20 copies and put them in everyone’s snailmailboxes or have one copy with a distribution list written on it. When the one person read it, he or she would check off his or her name and pass it on to the next person.

The big thick report would have to be big and thick because, like the presentation, only about 10% applied to me. Unfortunately, the big thick report had to cover not only everything that any of the readers might be interested in, but it also had to anticipate any questions that any of the participants might have, because it wasn’t easy to ask questions later. I couldn’t ask the bigthickreport, and I probably would have a hard time finding the author to ask a question. He or she was likely to be in a meeting, and in 1984, we didn’t even have voicemail. I could write a message, walk over to their desk, and leave it on their desk, but that was a pain. Now, with email, what reaches me tends to be more focused to me and doesn’t have to answer every single last question, so tends to be shorter.

Similarly, I save time from not having to prepare presentations or to write big thick reports. Instead of sending out a monolithic memos later, I send out smaller, more targeted messages sooner. I can also leave out things that my audience probably doesn’t care about. If they need clarification, they can send me email.

In addition, if you are an online celebrity (like Larry Lessig), of course you are going to get lots of email — just as you would have gotten lots of snailmail if you were a celebrity before 1994. Getting fan email is as much the dark side of being an online celebrity as it is the dark side of email.

Furthermore, the problem looks worse than it is because the people who are most widely-read are (by definition!) on-line celebrities, and who will unsurprisingly get more email than most people.

If someone doesn’t have a problem with email overload, they probably aren’t going to say so. I debated for about five minutes whether I was brave enough to say this: I do not have a problem with email overload. I hesitated before writing that because I was worried that

  • my friends might take that as carte blanche to forward me that stupid joke about the cat and the polar bear.
  • friendly strangers might feel free to ask me what the joke about the cat and the polar bear is. (There is no joke about a cat and a polar bear. I made it up.)
  • grumpy strangers might take it as an invitation to flame me for what they interpreted as me saying that they don’t really have a problem. (For them: you do have a problem, really!)
  • I wouldn’t look as interesting. If I admit that I don’t have a problem with email overload, then people might think that I must be a total loser with no friends, a slacker whose boss doesn’t give her nearly enough to do, and not at all famous or interesting.

(I finally decided as the author of a book on email overload, I really should be brave enough to admit that I don’t have a problem with email overload.)

Now, I will freely acknowledge that email programs are not good at helping you get through your email. There are lots of things email programs could be doing better. But that’s the program’s fault, not the email messages’ fault.

(Side note: basically, email programs don’t realize that your email inbox is a to-do list. Mark Hurst advocates emailing your action items to his to-do tool gootodo.com, but that merely shifts your to-do items from your inbox to somewhere else. What I heard over and over again when I was doing research for my email overload books was that once a message moved out of the inbox, they forgot about it. I am concerned that messages you send to gootodo.com will be similarly out of sight, out of mind. The one thing that might save gootodo.com is that it is the one to-do list manager that will let you defer messages.)

I will also freely admit that there are idiots in the world who send you messages that they shouldn’t. But that’s your correspondent’s fault, not the email messages’ fault (and not your fault, either). Furthermore, those idiots were also the ones who used to call pointless meetings, ambush you at the water cooler, stop by your office and drone on and on, etc. If I have to choose between a meeting that turns out to be pointless and an email message that turns out to be pointless, I would much much rather have the pointless message. If I know someone is an idiotic time-waster, I can trash their message pretty quickly.

I am convinced that in balance, email has saved a lot more time than it has wasted.

(Props to Itzy Sabo, who also has a “don’t shoot the messenger” post that I didn’t discover until after I had written this.)

01.22.07

Dreaming in Code

Posted in Email, Technology trends at 9:57 pm by admin

This is a response to Joel Spolsky’s review of Dreaming in Code, a book about the development of Chandler at the Open Source Applications Foundation.

I was at OSAF for two years. Many of the things Joel says are consistent with my view of how things happened, some are not, and some are fully correct but don’t tell the whole story. Some of the things people on the discussion group are speculating are wrong. I’m going to write responses down in no particular order with no particular story arc. I’ve tried to boldface the thesis topics of each idea.

(Note that I haven’t read Dreaming in Code yet, so am not commenting on the book, just Joel’s review of it and the comments on the discussion group.)

There was an implication that the people at OSAF were lazy and interested in doing as little as possible to keep getting their paycheck. I think that is a grave disservice to the people there. Getting a paycheck isn’t usually that difficult — especially for people of the calibre that OSAF could attract. Top coders want to ship stuff!

However… in a normal company, you have the VP of Marketing representing the customer’s interests and the VP of Engineering representing the developers’ interests (i.e. could it actually ship). The two act as check and balance, so that the customer gets something they want in a reasonable timeframe. Unfortunately, Mitch was acting as the VP of Engineering, and the VP of Marketing, and the customer, and the venture capitalist.

Furthermore, Mitch had been very successful. It seemed reasonable to believe that if he thought we should do X, we should do X. This meant that Mitch didn’t get particularly fierce pushback when perhaps he should have. For example, he was adamant that we should do Chandler peer-to-peer, without a server. Doing a collaborative calendar without a server is really, really, REALLY hard. He eventually clarified that by “server”, he meant “something difficult to administer”, and so OSAF started working on a server.

Mitch has many many many fine points. He is a good and caring human being. He is clever. He has an ambition to make the world a better place. However, he has also been very very wealthy for a very long time, and I think that Mitch’s environment has taught him that that he does not need to be particularly clear in his instructions.

If my husband says to me, “please get me a cake”, I’m going to insist that he tell me what kind of cake, what event it is for, how many people it is for, and when it needs to be ready, and where it needs to end up. However, if my Powerful Boss says, “oh yeah, and order a cake” right before she hops in a cab to go to meet with the President, then I’ve got to figure everything out myself — and I have strong incentive to do so. I’ll go find my boss’ calendar, look through upcoming events on the schedule, guess at which one is likely to need a cake, and phone the boss’ cook to find out what kind of cake the boss likes. If I am really on the ball, I might phone the other participants’ people to find out if there are any food allergies, likes, or dislikes. If I am good, my boss will come back and find out that in fact she did not need to give clear instructions; if I am not good and there is no cake, I most likely would (eventually) find myself no longer employed by Powerful Boss.

This vagueness might be acceptable for cakes, but it’s death for developing code efficiently. For example, Mitch said that by “server”, he meant “something difficult to administer”. Either he changed his mind or he just never realized that he needed to be clear that he meant “something difficult to administer” instead of “always-running software that responds to requests from other computers on the network”.

I think Joel was right that too many designers slowed us down. Something that made it even worse was that the team grew person by person, i.e. was not wholly in place at the onset. Every time we got a new person on the team, there was a significant adjustment period while they lobbied for their own ideas for how things could be done better. For example, Lisa Dusseault is a big WebDAV person. After she started, she lobbied for doing more with WebDAV, saying that Life Would Be Better with WebDAV. She convinced us, and we started doing a lot more with WebDAV. She was probably right, Life Probably Is Better. But changing things around certainly cost us some time.

I think Joel was too harsh on stamping. He is right that being able to send things around by email is not exciting. It’s going the other direction that is more interesting: taking email messages and being able to turn them into things easily. An email message might also be a task: “Could you please frizbat the hongtholt?” An email message might also be a calendar item: “Can we meet next Thursday at 12?” Yes yes, with Outlook you can drag an email message onto your to-do list or calendar, but you still have to (had to?) fill in all the to-do information by hand. Tedious. The text recognition was supposed to do that for you.

I have said before that current to-do list managers suck rocks, and email clients could be much better. Chandler in the Grand Vision would have / could have addressed those. However, we found out very early on that people didn’t care about to-do managers or email clients: in 2003, people’s pain was centered around calendaring: you really had to buy Outlook and run an Exchange server to get halfway decent one, and even Outlook was only halfway decent. There was not a way at the time for a small business or non-profit without an IT staff to coordinate calendars. Period. So we focused on calendaring, which IMHO was the least exciting and revolutionary part of Chandler.

Something that Joel doesn’t mention as being a barrier to getting help from the outside world was that in the time while I was there, we never had a contributor agreement/license in place. So Jane wants to contribute some code: what sort of agreement governs the code that Jane contributes? For most open source projects, that issue is just not thought about because there is no money involved. But with OSAF, there was serious money involved.

First, Mitch Kapor was (is) a wealthy man, and wealth attracts lawsuits. Second, OSAF pays genuine salaries. Third, the plan was always for OSAF to become self-sustaining by providing different (i.e. non-GPL) licenses in addition to (not instead of!) the free GPL licenses.

Hence, we couldn’t really accept much code without a contributor license. That didn’t get done, in large part because our counsel, Mitchell Baker was stretched waaaaay thin also running the Mozilla Foundation. (She’s now only running the Mozilla Foundation, and appears to be doing a fine job of that.)

(Side note — I was absolutely amazed at how much volunteer support we got for NON-coding tasks. From help installing our phone system to CSS stylesheet help on our wiki to advice on video capture tools, the open source community was breathtakingly generous.)

Chandler is an open-source cathedral, not a bazaar. It’s a very different way of doing an open-source project, but that is not inherently wrong or bad. You need cathedrals sometimes.

Finally: Chandler most definitely does have a mascotone of Mitch’s dogs. :-)

N.B.  I have zero negative connotations associated with the word “boss”.  It means exactly the same thing as “manager” to me, except is less formal and fewer syllables.  I thus forget that some people attach a negative connotation to it.  I meant no negative connotation in the Powerful Boss paragraph.

10.22.06

mini-review: The Perfect Search Engine Is Not Enough

Posted in Email, Mini-reviews at 3:31 pm by admin

This is a mini-review of The Perfect Search Engine Is Not Enough: A Study of Orienteering Behavior in Directed Search (2004).

The authors looked at how users looked for information in electronic documents (Web pages, email messages, or files in a file system) and found that people didn’t always use search (what they called “teleporting”), but frequently took a sequence of smaller steps to get to their goal. For example, a user went first to a math department’s home page, then clicked a few links to get to a specific faculty member’s home page.

They concluded that there are advantages to orienteering:

  • keyword searches often fail
  • orientation has a lower cognitive load (i.e. you don’t have to figure out what a good search query would be)
  • orienteering allows people to use meta-information that keyword search does not (e.g. who a message is from)
  • orienteering gave people more context (e.g. they knew they wanted the oldest file in a directory, but didn’t remember the name of the doc)
  • orienteering helped people maintain a sense of location during the search (e.g. they could edit a URL directly to get to a slightly different Web page)

They suggest that search tools allow people to search on meta-data, learn which sites a particular user trusts, and steer search results to those pages, clustering information, and/or suggesting refinements.

I found the title slightly disingenuous: their users didn’t have the a perfect search engine, and it isn’t fair to extrapolate that the users would still orienteer if they had the perfect search engine.

An observation that I didn’t see them make explicitly is that orienteering can reduce the search space and thus increase precision. I do this frequently; for example, when searching for a file in the file system, I go a directory that I’m pretty sure is above the file I am looking for, then do a find:

find . -name emailCartoons

Instead of navigating to some subdirectory, I could do the find from / or from my home directory, but that would give me way more information than I need.

The authors also don’t say what operating system their test subjects used, nor which email client they used. Different email clients have radically different search capabilities! In particular, I remember that when I was researching my book, people told me that the Outlook search was so slow that it was too painful to use. Gmail, on the other hand, has search so fast that I almost never orienteer to find a message. While I have never tried it, I hear that Google Desktop is a whiz at teleporting.

I also have to think that better training on search engines would help people teleport more.  For example, instead of typing the URL for the University of East-Central Illinois at Hoople’s math  department, then clicking around to the faculty page to get to Sabrina Aguilar’s home page, someone could instead search Google for

aguilar site:math.ueci-h.edu

but a lot of people don’t know about the site: feature.

The Google Guide by my friend Nancy Blachman has good information on how to search better, including this advanced operators cheat sheet.

02.10.06

Microsoft should fear Google, part 3

Posted in Email, Technology trends at 10:06 pm by admin

I thought Google should start competing with Outlook; now they are doing it.

10.13.05

Microsoft should fear Google, part 2

Posted in Email, Technology trends at 9:16 pm by admin

Two months ago, I wrote an essay on why I thought GMail could seriously impact Microsoft’s Outlook/Exchange business by bundling a (so far non-existent) calendar and Gmail into their search appliance.

I had another idea for how the Google bundle could be superior to Outlook/Exchange.

Gmail — in its current Web service incarnation — has ads along the side of the pages. Presumably, a corporation would get annoyed if they paid good money for a network appliance and they still had to look at ads. So the appliance version of Gmail should lose the ads…. or should they?

Google is good at figuring out which text items are related to which other text items. So what if they (automatically) figured out what things inside your company were related to which other things at your company and displayed them? Scenario: You get an email message from your colleague David Jones about purchasing floss recyclamators for the Cobra project. When you read the message, you see various links in the sidebar:

  • David Jones’ home page
  • the Cobra project home page
  • a page listing your company’s approved floss recyclamator vendors
  • a page on this week’s cafeteria menu
  • Mabel Garcia’s home page

David’s page, the Cobra page, and the vendors page all make sense to you. (The cafeteria menu is odd, but you shrug it off. Even Google makes mistakes.) But you’ve never heard of this Mabel Garcia person and have no idea why she showed up on your list. You click on her home page, and you find that she’s a new hire, and her resume shows that she spent ten years working at Floss Recycling Incorporated. Hot diggity! You can sure use some of her expertise!

If Google could do that, I could imagine people abandoning Outlook/Exchange in droves.

08.13.05

Microsoft should fear Google

Posted in Email, Technology trends at 9:13 pm by admin

If I were Microsoft, I would be afraid of Google. Very, very afraid. Just as Netscape was unable to compete with free products, I don’t think that expensive Microsoft can go head-to-head over the long-term with Google’s “free” services. Microsoft won’t go bankrupt, but I do think Google will significantly eat into their margins.

Outlook is very, very vulnerable. In all of the interviewing I did about email habits, I never found anybody who was passionate about it, nobody who said, “I used to use Brand X, and Outlook is soooooooooooooooo much better!” People used Outlook because that’s what their company told them to use, and companies used Outlook because it’s calendaring system, while not something people were enthusiastic about, was better than anything else from the Information Technology Department’s standpoint.

However, even the IT department didn’t much like Outlook. Exchange (the server component) was a royal pain to maintain, and it was a nightmare to back up. Outlook stores all its information in one big .pst file. Thus if today you get one piece of email, you have to back up not just today’s mail, but all of your saved email messages, all your filters, all your Views, all your Options. This means that the IT department has to put disk quotas on their users’ email — even though the cost of disk space is in the vicinity of US$1 per gig. This places quite a high productivity hit on their users, since they must periodically go through their email and triage their messages.

Gmail is really nice. It doesn’t have every feature in the book and its address book is pretty pitiful, but they got two of the most basic things really right: the users don’t have to periodically delete their messages, and they are absolved from having to decide which folder to file the message in. One big fat button that says Archive, and boom, that message is out of their face.

If Google does shared calendaring, Outlook is suddenly very vulnerable. The Google calendar needs to have enough access control to allow/disallow particular Google users to add/modify/delete events, have repeating events, and to send reminders when things are due. It doesn’t need to do anything fancy like delegation, it just needs to work. (If they do want to make it better than Outlook, there are quite a few things they could do to make it better. OSAF has an exhaustive list of calendar features, but I’d be delighted just if I could have a “home” timezone on the left and an “away” timezone on the right.)

Before you argue that companies won’t like giving all their private data to Google, let me point out that Google already sells a Web search appliance. It shouldn’t be hard for them to provide Gmail- and Gcalendar-in-a-box, perhaps even in the same box as their search appliance. If they provide intelligent backup utilities — which they probably already have, since Google has to back up Gmail already — then Google could eat Outlook/Exchange for lunch and have leftovers for dinner.

Furthermore, I have no reason to believe that Google wouldn’t do a better job at calendaring than Outlook. They have a lot of very bright people, they understand user interfaces, and they are unencumbered by a krufty old code base. They can use the latest in research, and they can search the Web for good ideas on what to do with calendars. Because they are a web service, they can do a rapid rollout, rapid bug fixes, rapid upgrades, and get rapid user feedback. Microsoft, meanwhile, is shackled by the weight of an installed base and by conventional software delivery/sales.

I’ll put my money on Google.