Kevin Altis put it better than I could re: Outlook and Chandler in his weblog reprinted with permisision here.
What's New About Chandler?
Mitch Kapor made a post to try and better describe Chandler, partly in response to a lame WIRED article. My post below is in response to what Mitch had to say, but even more so to a point Ari Pernick makes in the comments section. So go read that stuff before continuing.
Ari makes a good point. Perhaps it might be more accurate to say that the object model and the way Outlook exposes its data seems cumbersome at best for the types of information management and sharing envisioned in Chandler. Despite its size, there are actually a lot of things you simply can't control or change with the Outlook object model. Not to mention that it is Windows OS centric. Even though my primary platform is Windows 2000, I want data formats, languages, tools, and standards that work on other platforms.
In addition, like most of the Office apps, Outlook has defaults that seem broken to a lot of people, designing new views, writing scripts to manipulate data, etc. is just not easy enough. Perhaps, because the default language to do scripting is VBA.
How many people have ever selected the Tools->Forms->Design a Form menu item? Chandler is probably going to have to duplicate that functionality, but Outlook users don't even know it exists or why they might care. Fewer people still have probably seen the Outlook object model docs or a book about the subject. There is a reason MS sells a pro version of Office and that people can make a living at building "enterprise apps" on top of Outlook/Office.
But the biggest problem with comparisons between Outlook and Chandler might be that Chandler is embracing a much larger set of goals. It will support data and document types that Outlook considers outside its scope. From the start Chandler is supposed to support group interactions which Outlook only has minor support for, unless of course, you have an Exchange server.
It may also be accurate to say that if you only want the out-of-the-box, single user, single machine, basic email, contacts, calendar, and tasks of Outlook or a similar app and that you are already happy with that app, then Chandler might have nothing to add because you would never use the extra features.
Of course Chandler is a platform, not just an app, so that too will take time for people to digest and accurately compare to Outlook/Office as a platform. Hopefully, people won't curse Mitch and the OSAF when they use Chandler the way they sometimes (okay, maybe often) curse Bill, Clippy, and MS if they use Outlook.
Posted by mitch@osafoundation.org at December 23, 2002 11:30 AMKevin implies that Chandler can't be fundamentally better than the current email tools, that all it can hope for is extra bells and whistles.
I believe that there are significant improvements still to be made in email clients. Furthermore, these improvements are relatively simple to implement. We don't need 3D interfaces to email, we just need tools that are smarter about how people actually use email.
DUCKY'S LAWS OF EMAIL
1. People are more efficient when related messages are grouped together and the groups are in rough priority order.
2. People want to be able to see all their "to-do" messages -- ones that they need to read, respond to, or act upon -- easily.
3 (or maybe 2b). When a message has no more pending actions, people want to remove it from their list of "to-do" messages.
4. People want to execute actions with one or fewer clicks.
5. Old messages are a valuable resource.
6. The faster and better a Search tool is, the less important it is to file messaages.
7. Fuzzy-logic or "scoring" filters are much more accurate than the "sudden death" filters that most email clients now have.
8. Most people won't customize their own setup, but are usually willing to import customizations that other people have made.
9. Messages that are to you and only you are usually more important than messages where you're one of many recipients.
10. Some people (e.g. customer service reps) answer the same questions over and over, but computers are not quite smart enough to be able to figure out which response is appropriate.
***
The common advice for grouping messages (#1) is that you should use filters to move messages into different folders. However, this violates #2 (seeing "to-do" list). What I've found works much better is to use filters to change X about a message, then sort the inbox first by X, second by date. Most email clients don't have anything they can use for X, but Category (mostly) does the job in Outlook and Label (mostly) works in Eudora.
I say "mostly" because Outlook Categories and Eudora Labels are not well-designed for this. (The shortcut "make a filter" actions don't make changing X easy. Eudora-Win only has seven labels. In Outlook, there is no standard View that groups messages by Category. Category is multi-valued, and if a message gets two Categories somehow, the group-by-Category View shows it twice. Replies inherit the Categories of the original message and are visible to the receiver, but you can't clear the Categories from either incoming or outgoing messages.)
*
To remove messages from their "to-do" list (#3), many people use the delete key, as it is a one-click operation (#4). However, this eliminates the old messages as a resource (#5). Many other people mark messages "unread" if they can see that they are still "to-do" (even though "read/unread" and "done/to-do" are different axes) and leave the message in their inbox. They bank on #6 (Search) to find old messages.
What would be better would be to have three buttons near each other for "show next message", "mark as done", and "delete", coupled with a view that doesn't show "done" messages. If the scroll wheel will scroll through the message body, users can happily hover their cursors over the three buttons and really whip through their messages.
*
Fuzzy-logic filters (#7), like those that SpamAssassin uses, are much much more accurate than what consumer-grade email programs have. However, if any popular email program has one set of built-in filters, the spammers will learn how to work around it. The best way to combat this is to have enormous diversity of filter sets, which will only happen if people can easily share (#8) their filters. While most consumer email clients have lots of customizations, most make it very painful to share them.
*
Most email clients make no visual distinction between messages based on how you were addressed, despite that being very important (#9). Some clients will let you customize the color of the message, but most users don't customize (#8).
*
Some people get the same questions over and over (#10). Canned responses help, and most consumer-grade email programs have some mechanism for saving common responses. (It's not always obvious, however -- with Outlook/Outlook Express, you need to use "Signatures".) While it's essentially impossible to write filters that are good enough to figure out which response to send, it is easy to write filters that are good enough to *suggest* which responses might be appropriate.
I once configured and used a system that would display checkboxes at the bottom of incoming messages, corresponding to different canned responses I could send. I could then edit, then send or send without editing. This sped up my responses by at least a factor of ten.
***
So here are a just few things that Chandler could do better:
+ Easy sharing of customizations.
+ Easy creation/importing of filters to group messages in the inbox.
+ One click to mark messages "done".
+ Built-in colorization of messages based on addressing method.
+ Filters to auto-suggest canned responses.
None of these is particularly difficult to implement, but collectively, they can have a huge effect on email efficiency. The current email clients **do* *not** have the ultimate (and might not even have the penultimate) email UI.
Posted by: Kaitlin Duck Sherwood at December 24, 2002 01:11 PM
What I want from a PIM
A lot of the ideas surrounding Chandler are very elegantly expressed in David Gelernter's "Lifestreams". Taking Lifestreams as an inspiration, here is what I would like my PIM to be:
- Data Import: It should manage all the pieces of information I use: email messages (via IMAP), files, directories of files, contact data (via vcard files and LDAP), bookmarks (via Mozilla bookmark files), short notes etc.
- Data Storage: It has to have a unified storage (a "repositiory"), but that storage might only need to be an additional layer of abstraction (e.g., files could stay where they are). I want to have a full text index of all the information that is stored in the repository and I want to be able to add keywords for better recall.
- Data Mining: Once I have my soup of information, any other grouping and relating of items is done via querying the repository. Bidirectional links are probably necessary (i.e., not only "what items are returned by that query?", but also "what queries return the item I'm currently looking at?"). Links between items would be enumeration queries whose presentation (see below) adds labels.
- Data Presentation: Once I have gathered all the items I need by constructing a query, I want to be able to present them in a variety of ways: As a graph, as a hierarchical list (great for outlining short notes and bookmarks), as a web page (the PIM would actually be a small web server, handy for dynamically integrating the bookmarks in the repository with any web browser), as a calendar (if a query only returns dates), as customized LaTeX source etc.
- Operations on the repository: On any set of items returned from a query, there are a lot of operations one can imagine: Eliminate duplicates, find new bookmarks that have been added externally (i.e., this is a kind of import+diff operation), find similar data. Applicability of an operation would be decided by some kind of typing system.
- Plugins: Any new data supported by the repository would be implemented through a plugin, as would be operations and presentations.
- Related work: There are many programs out there that perform one of the aspects mentioned perfectly, but none that integrate all of them. Examples: Six Degrees, Tinderbox, iData Pro, LaunchBar (Mac OS X). Microsoft Research's "LifeBits" project probably comes closest to what I have in mind. Complementary technologies: Ontologies, Topic Maps, RDF Site Summary (RSS).
- Final thoughts: Having a Google (but including the directory!) for the desktop is probably a good analogy, therefore a lot of energy would have to be invested into the data mining and visualization part. In my comments, I've completely ignored any groupware functionality, because I don't know what is needed there.
Axel Rauschmayer,
University of Munich
axel@rauschma.de
Posted by: Axel Rauschmayer at December 27, 2002 02:23 PM
Axel,
We're intending to do pretty much everything on the list -- not all at once, but over time. Good summary.
Posted by: Mitch Kapor at December 28, 2002 05:24 PM
Here are few things that I would like to see in a PIM system:
- annotations to e-mail messages (searchable, of course). How many times have I moved a mail message in to a "Action Needed" or "Useful Info" spool only to come back to it and not remember what it was I wanted to do with it or why it was noteworthy?
- association of to do items, address entries, etc. with one or more e-mail messages.
- rich filtering: regular expressions would be sufficient but unusable by the typical user. Its difficult with current popular mailers to express anything other than an AND involving multiple expressions.
- strong support for PGP -- mostly an awkward add-on in popular mailers. Better support exists in some unix MUAs. Today, using PGP breaks the normal workflow and can corrupt formatting of messages and can prevent searchability.
- True cross platform support. I would love to move freely between Linux and Windows using the same mail spool directory (probably on the windows partition). Sort of an outlier feature, but useful to dual-booters.
Finally, good import/export from other mail systems and PIMs. This is a major issue. Such import/export has to be able to preserve attachments (even if they are separated as in Eudora), header information, folders, etc. This is pretty important if you want people to take the step early to use Chandler. We need a way to move all data in to Chandler but know that we can back out and come back later if the system isn't ready without significant loss of data (or organizational meta data) and time.
Posted by: Jeremy Worley at January 2, 2003 09:16 AM
Regarding your quoted memo, I don't know who Kevin Altis is, but a head’s up to same: Kevin, you are already deep into Outlook Country when you call Mitch’s Wired article "lame". No matter what the content is, no matter how well known Mitch already is, this international level of PR puts you into the public view, not to mention the rest of the journalism world who look to Wired for leads. So what that they dramatize! That’s what editorial is, otherwise we’d all be reading the “Foreign Policy Review” instead of USA Today.
It is nerd arrogance to regard publicity this way, and it hurts your cause. Why do you think Outlook remains the only email program around, that it might actually be what Microsoft says it is [in official response to "Chandler"]: "It's because Microsoft continues to innovate and deliver the capabilities customers need that Outlook remains an industry leader..."!
Leave the code to the nerds, the interface to someone who has worked at Apple, and the PR to the publicist, and once you are in print, follow Jackie O's advice: "paste a smile on your face".
Thanks, because I need Chandler really badly, ASAP!
Posted by: Douglas Hopkins at January 4, 2003 11:07 AM
Hi Mitch
I was the "World of 1-2-3" man in the UK and was tied to the fortunes of Lotus for years. I knew Manzi, Ozzie et al. Anyway, I'm writing a quick tongue-in-cheek column for my daily 'Thought for the Day' at www.cw360.com but you can find my Blog through my website if you are interested. It was Akkadian that you were researching if I remember correctly? As I write about Linux and Open Source so was watching what you are up to with interest. Good luck!
Simon Moores
Posted by: Simon Moores at January 23, 2003 02:20 AM
I'm fascinated by all the conjecture here on what features will constitute an Outlook killer. Unfortunately, you're wasting your breath for the most part. First, Microsoft knows what Tibetian monks expect from an email application on odd days of the week. Everyone's cool features list sounds great, but won't stand up to Microsoft's legions of cultural antropologists and product managers who live on focus groups and qualitative research. Despite Outlook's shortcomings, it's more than adequate for the average user.
Second, you might be suprised by how many new 'workgroup' features are going into the next versions of Outlook, Sharepoint, and other MS apps. MS might actually be on a very promising track, especially given the incredible power of the dot NET platform (easily overlooked). With all the MS apps redeveloped on dotNET and exposing XML-enriched object models, MS will be able to introduce real and deep workgroup features that enable better collaboration and all the rest.
Believe it or not, there are a lot of people in Redmond who already know that Outlook is not up to par. BillG killed a superior email product developed internally because it presented a threat to the Outlook franchise. Think about it... Microsoft can't release anything that may pose a threat to Outlook, because that confuses customers and represents an open admission to the world that perhaps Outlook isn't good enough. You don't want your customers left with that thought. So instead, MS will continue to slowly add new features that place innovation second to keeping the product consistent and easy for existing users. But don't mistake this approach as an inability on Microsoft's part to totally revamp and extend Outlook. There simply isn't a good reason for MS to do so at this time. You don't play around with a product that pulls in billions a year.
I'm suprised that no one has mentioned the feature, or lack thereof, that has always drived me nuts in Outlook. Try managing loosely strucuted information, like meeting notes, in Outlook. Organizer had a great interface for organizing and managing your loose notes that I kept using for years after I moved my contact info to Outlook. Now that MS has announced the OneNote beta, it's time to think about this featureset and how it represents a weakness in Outlook that can be exploited.
Anyway, my intention isn't to beat up on the Chandler crowd because I've read some great ideas. The concept of one point of access to information is right on the money. How the basic filesystem, a construct about as old as dirt, remains the dominant paradigm for organizing files is pretty bizarre if you think about it. For most business users, email has replaced the filesystem as the main repository of critical information. However, nothing on the desktop or in Office software has evolved to reflect this big change in the way knowledge workers access info.
One other way to really beat up on Outlook is to exploit the promise of XML in enabling users to dynamically structure and define relationships among items of information. So when you push your files or information out to an intranet-type of collaboraton tool, you're not forcing everyone else to visually organize information the same way you do. Thinking about how XML lets users more dymically organize, access, and reference information is critical to beating Outlook.
By the way, if anyone knows of an app that lets your organize loose notes as well as Organizer did (other than Notes), I'd like to hear about it.
/ex borlander, microsoft alum, outlook skeptic
Posted by: Jon at February 4, 2003 01:30 AM
Well, I would have to agree with Jon that the thing that annoys me the most about Outlook is that it does not handle notes very well. I would say that it does not even handle email very well. Especially for things like emailed news articles. Now if Microsoft has some killer thing waiting in the wings, more power to them. But MS Outlook does not even do its main job well. Some examples:
-- Someone sends a meeting followup notice that has a bunch of todo's. I want to have most of the email hidden (accessible -but hidden) except for the things that are important to me.
-- An emailed news article often has just an a couple of paragraphs that are important. Everything else is fluff. I want to remember the statistics or the politician's quote. The rest I could care less about.
-- Above is also important when handling digests.
-- Handling links in email. It would be nice especially for news sites that charge for their old content to be able to snapshot and edit the article within the context of the email.
Posted by: Patrick at February 5, 2003 09:34 AM
I would like one design feature to be a single page for free-form entry of all items: appointment, name and address, task, journal, etc. My confession is that until last year I continued to use Lotus Agenda, which I consider one of the most efficient, inventively and usefully designed PIMs ever to be offered. Implicit in this suggestion is the parsing of information in the entry. I also desire the easy creation of one type of item - appointment or calendar entry- from another - say, task - and the association and historical "contact log" of individuals associated with an item. I also would value the seamless addition of a new contact while in a task/appointment/etc. to both the contact d/b and the item association.
Of these suggestions, the free-form entry of information with keyword/synonym parsing remains my principal delight.
Best regards,
Bill Blask
Posted by: Bill Blask at February 6, 2003 12:03 PM
I have heard many people describe information in hierarchical terms. One of my most often used tools is PersonalBrain (http://www.thebrain.com/), a graphically depicted relational database. I value the visual clues offered by this product, as well as its historical information. In PersonalBrain, parent/child relations can be established in any context.
Jon's final paragraph mentioning XML and the need to allow users their own view of an information collection I also believe is worth considering.
Best regards,
Bill Blask
Posted by: Bill Blask at February 6, 2003 12:16 PM
Stepping back a bit and thinking of this as a user, what I want from a new style of PIM is for it to be closely coupled with my own style of personal time/project management.
In my own case, that's David Allen's system (www.davidco.com). And on his site, you can buy an Outlook add-on that helps a little. Other people may have another style that works for them.
A PIM should morph according to the system you want to use. If I were designing Chandler, I'd insist on global skin-type thingies that implement different management styles. One of them could be an Outlook skin.
--
Reginald Braithwaite-Lee
raganwald@yahoo.com | http://www.braithwaite-lee.com
Whenever man comes up with a better mousetrap, nature immediately comes up with a better mouse. - James Carswell
Posted by: Reginald Braithwaite-Lee at February 26, 2003 11:50 AM
One of my major complaints about PIMs in general is that very few of them intelligently grasp and deal with what I call "households" and "organizations" -- simply, individual contacts who are associated with eachother by virtue of living together in a single home or working together in, e.g., a business.
A very common form of this type of association is a married couple who share the same home address. How many of us have had to do this:
1. You want to store your fictional friends, "Jim and Betty Jones" in your PIM. But you are loath to create two separate entries that are identical in street, state, phone, etc. but simply have different first names. What many of us do (as a clumsy workaround) is insert "Jim & Betty" in the First Name field, and "Jones" in the Last Name field.
2. This works okay for such purposes as printing an address label for Jim and Betty (I hope it will be possible to do this with Chandler [esp. for Mac OS X!]). It also works fine if they both use the same (and only one) e-mail address. But more than likely, each of them has at least one (if not more) separate e-mail addresses. They also each have separate work addresses. This is where conventional PIMs like Outlook and Palm Desktop absolutely go to pieces. They can't handle it.
3. God help you if, e.g., Jim Jones and Betty Smith are married or cohabiting and she decides to keep her maiden name!
4. Time after time I have had to create three separate entries in my PIM for one person. Why? Well, for one, I like addressing my e-mail to people individually (most folks do). If Jim and Betty Jones share the e-mail address "jbjones@domain.com", I still would rather my e-mail client not list "Jim and Betty Jones " in the recipient field if my letter is meant for Jim and not for Betty (although it better not be anything particularly private in that case if I know what's good for me).
In short, the hope I have for Chandler is that I will be able to deal with my e-mail, contact info, to-dos, etc. in a way that allow me to retain the various associations of a person (or address, or e-mail, or zip code, etc.) to other data or (temporarily) ignore those associations as I see fit.
From the entry for "Jim Jones", I should be able to:
1. Print an address label that includes his home address and his wife's name, all with one or two keystrokes;
2. Print an address label for his office that does not include his wife's name;
3. E-mail him with only his name in the To: field despite the fact that the e-mail address is commonly held by his wife (nothing against Betty here. After all, she is fictional).
4. Dial his home phone number (perhaps Chandler could mention to me that his wife, Betty, might pick up)?
5. Sync all of this to my PDA in some intelligent way (I know this is going to have to come from a third party and that's okay) that doesn't involve lots of duplicate entries.
-Sam Elowitch
Posted by: Sam Elowitch at April 23, 2003 03:00 PM