Chandler Vision

This is a draft, a possible replacement for ProductRoadmapNov2004.

Chandler is an open source Personal Information Management (PIM) client application with innovative design and ambitious plans for sharing, extensibility and cross-platform support. This vision overview or roadmap (Jim McCarthy would call it a "technology plan" or "a Tomorrowland that has credibility") explains our high-level ideas for achieving these ambitions.

Contents

Target Users and releases

Our 1.0 release targets info-centric users. This means we're not trying to optimize information management for somebody who receives ten emails a month or even ten a day -- Outlook Express is in no way the model for Chandler and neither is Mail.app. Info-centric users receive and send lots of email on a variety of topics and often collaborate heavily with other users. Their need to find better ways to manage their information is what will drive them to try Chandler, and we are working on features that will make them keep Chandler once they've tried it.

Info-centric users who are also early adopters of new technology are likely to be the first users of Chandler. These users may introduce Chandler into their workgroups and spread adoption. Since many other people in the same workgroups are not early adopters (or not info-centric workers) we realize that Chandler will have to integrate and communicate reasonably well with existing mail and calendar software.

The "Westwood" release, after 1.0, will target university use cases, possibly students as well as staff.

The "Pasadena" release is the first release that might possibly be targetted to a truly broad audience including managed corporate usage.

Design of PIM Objects and Views

The key features for a Personal Information Management (PIM) tool are email, calendar, tasks and contact management.

Email features

Although Chandler 1.0 must be a usable email client, we do not envision replacing classic IMAP-folder hierarchically-oriented email clients feature by feature (e.g. Mac OS X Mail.app, Thunderbird or Eudora). IMAP (and POP3 and SMTP naturally) will be supported for interoperability but Chandler's design will not be driven by the needs of the protocols.

The basic features of email will naturally be available early:

• View new mail (classic table view) and read individual mail in pane or new window
• Compose mail, reply/forward or new mail, including maintaining drafts
• Synchronize mail for view/use offline (IMAP accounts only of course)
• Read, save and create attachments
• Read S/MIME (encrypted or signed) mail
• Detect and manage spam
• Import and export mail to files

Instead of the classic file-to-organize folder model, we envision a more user-centric design built from the observed workflows of email processing:

• When an email has been seen and nothing more needs to be done, the email can be trivially archived. For more detail see the section on Triage and the Dashboard view.
• Any resource in the Chandler repository can be sent to other users, not only just by attaching the resource to the email but also by marking the resource as having been mailed. Users will benefit from closer integration between resource storage and email history by being able to quickly see who a file has been sent to and when.

The section on Stamping also relates closely to email features.

TODO: Say something about rules...

Calendar features

A basic calendar application requires the following features:

• Views of events by day, week and month, and navigation by time period
• Detailed view of event, ability to add and remove events
• Recurring events

Info-centric users have a few additional needs just for managing their own events

• Separate calendars (e.g. my "soccer games" calendar in addition to work events/meetings) and calendar overlays
• Selection of timezone by view for use while travelling or scheduling meetings that span timezones

Several other important calendar use cases are discussed in the collaboration section of this document.

Notes and Tasks

With Chandler, users don't need to distinguish carefully between whether they want to create a note or a task since the boundaries blur so easily. With one click the user can create a new item and start entering text -- at this time the user has a note. Later on if the user wants to add reminders, a due date, a start or end time or recipients, stamping can be used to turn the note into something even more useful.

See below for more information on stamping, triage and the dashboard to see how integral task management is to the design of all the core Chandler views and workflows.

Contacts management

Many PIMs have contact information (Outlook, Opera) and it's recognized as an important part of the user's personal information. Some of this is essential to being able to use email and calendaring functions:

• Recipient fields in email need address auto-completion
• Scheduling workflows may need email address auto-completion as well -- or may need CalDAV address auto-completion
• Sharing workflows require WebDAV or CalDAV address auto-completion

To achieve this auto-completion functionality we need to provide ways for users to create at least minimal contact records and add addresses, remove addresses or remove contacts.

Chandler will also help users manage, view or find email according to who sent or received the email, as well as events by who organized or is invited to the event.

Contact information like phone numbers, addresses, birthdays and other personal information is important too, but managing that kind of information is targetted after Chandler 1.0. In Westwood or Pasadena we'll improve Chandler's functionality in this area and work on features such as address book import/export and using VCards in email, events and sharing scenarios.

Part of the interesting work in contact management (still post 1.0) is integrating some of the explosion of new work in identity management. It's difficult for users to correlate some collaborator's email address with their general WebDAV share location and the location of their work calendar share. We are tracking this work and looking for innovative ways to automate the correlation of different addresses for the same collaborator.

Resources

Since email systems and file systems are treated as two disjoint repositories (not technically but from the user's point of view), users are left with the management challenge of manually correlating information in each system. The user might be able to go to the file system to see when a file changed last, but have to go separately to the email application to find out when the file was last sent out for review. Chandler will provide users with the ability to bring file management into the Chandler repository in order to manage these resources together with collaboration/communication workflow.

Information Processing

Stamping (Multi-typing)

Email-only applications and calendar-only applications are nearly unable to do decent event scheduling. Beyond that, there are many benefits to a combined application for users whose lives aren't always cleanly divided by mail/event/task application boundaries. Chandler takes a couple steps to integrate several traditional application areas well:

• Collections can contain objects of any type. Users can collect tasks, emails and events together in the same collection. Users can manage work by project rather than by application.
• Searches can cross all applications and object types. At the same time users can quickly filter by application to narrow the search or view result or use specialized views.
• An object can be more than one type of thing at once. For example, an email can be a task too. There are many more possibilities inherent in multi-typing.

Stamping is the OSAF term for multi-typing items. In 0.6 a note can be stamped as an email, then as a calendar item. An event created through the calendar view can then be stamped as an email to send it to somebody.

One of the most compelling use cases for stamping is that since so many emails trigger follow-on work (anything from reply later to launching a new project), it should be trivial to turn a received email into a task. In traditional email clients an email can be flagged, a simplistic prototype of a combined email and task, and this is tantalizingly close to being useful for many users. Chandler will offer gestures for users to stamp an email with task properties in one click. It's a really simple decision making process with just one click: all the user has to know is that there is probably something to do, sometime, to turn the email into a task. Later the user can reverse the process, assign a date, or add more details to the description of what has to be done.

Find an image of a stamped item, an EmailTask^?

First Triage with the Dashboard

Triage consumes a large chunk of users' time with incoming emails and upcoming tasks/events. In the traditional email triage model, the user must perform a certain workflow with every email, even those requiring no action:

• Select and read the email
• Decide that there is no action to be taken
• Decide where to file the email -- typically, which IMAP folder

Some users simply refuse to file emails, leaving tens of thousands of emails sitting in an enormous IMAP inbox. By taking this shortcut, however, these users fall prey to having to review emails over and over again to determine whether there's something to be done. This is contrary to the advice given by books like Getting Things Done^? and training organizations like McGhee. Both systems advise students to deal with each received email a small number of times and keep backlog low. Ideally the user would review new email only once and decide immediately whether to delete, file, deal with now or plan to deal with later. However, users consistently fail to deal with email in this manner, even after taking productivity training, and part of the blame can be laid on email tools.

With modern search functionality, it shouldn't be necessary to file emails into hierarchical sets of folders just to archive them. Email systems like Opera and GMail show that it's actually fairly easy to find uncategorized and unfiled emails later. GMail currently does the best job of this, automatically marking viewed emails as read but also giving the user the explicit choice to archive emails.

Chandler plans to allow this kind of quick triage and more with the Dashboard view. This is the view of what's up "now" in the user's information space. In this view in particular, Chandler will provide users with gestures to archive email quickly, including text shortcuts and drag-and-drop actions. It will be trivial to make the distinction "done" and "not done".

The other one-third of triage is "do later". Studies of email usage show that users can't deal with all incoming email as it arrives and then be done with each item -- many items can and should be dealt with later. It should be easy for the user to defer action on email and have the client remind the user later. Our OSAF terminology for this is that we give the item a tickler, a trigger that will return the item to the dashboard later. When an item has a tickler it has essentially become a task -- this shows how stamping permeates the design. The word tickler comes from the David Allen task management system which suggests a manual technique for maintaining a set of reminders and a habit of looking at them to see which are due -- an obvious candidate routine for PIM software automation.

In addition to triaging emails, we can allow users to triage notes, tasks and events in the same workflow and even in the same view. Some examples of use cases justifying this generalization of functionality:

• User can take notes very quickly and later, while triaging, decide what to do with the note -- archive, leave in the "now" view, or defer for later attention.
• A task reminder can pop up for a task that the user now realizes can or should be deferred again to a yet later date -- or if the task has been dealt with the user can archive the task.
• A recent event might remain in the user's dashboard until the meeting notes have been published -- then the user triages the event as done/archived.

Finding information

There are two approaches to finding information. One is to do brute searches for it without preparation. The other approach is to organize information ahead of time, by categorizing, classifying or tagging information. Brute searches are conceptually simple, so there's just not much to say about our plans for search functionality in Chandler -- it's just work. Much of the planned search functionality is in the 1.0 plan or done already.

Organizing information is a much more interesting topic. There has been much work in this area, from library classification systems to folksonomoies created through uncontrolled tagging. Our research and http://wiki.osafoundation.org/bin/view/Projects/OrganizeDesign^? persuades us that a combination of classification (without much hierarchical navigation) and unstructured labelling, with some important pre-determined structured facets (such as kind, triage status and when), will be a big win for users trying to locate the information they want at a given moment. What does this mean in practice?

Users may (but aren't forced to) categorize items. This is done through the classical approach of dragging the item into a collection. Collections are most likely topical (as opposed to being based on status, sender or time period).

Collections don't contain collections hierarchically -- we promote alternative ways of handling or reducing complexity, so users shouldn't need so many collections that they need to create a hierarchy. One way of decreasing the number of collections is to make more use of facets. For example, rather than create a collection of "todo" items and "done" items for Project A, Chandler treats status as a facet of every item. Thus, a single topical collection for Project A can be viewed according to "what items are not done yet".

Another example of facets limiting the proliferation of collections can be found in mailing list traffic handling. Users shouldn't need to create new collections for every mailing list if it's easy enough to filter a topical collection based on which list the email came in on.

In 0.6 Chandler already has a classification-capable Sidebar with the ability to quickly apply Kind filters. In 1.0 we also need to extend our search capability so that users can find information without organizing it. We plan to support full-text search on any collection/view and on the entire repository.

Collaboration and Communication

In addition to sharing information simply by sending it (email), we have ambitions for Chandler to make it easier to share and collaborate in many other ways. At the same time, Chandler must remain completely usable if the user takes the application offline at a moment's notice. Users no longer accept (nor should they have to) manual synchronization choices and degraded offline behavior when it's possible for offline behavior to work well.

In contrast to our intention to do the best interaction design we can, we intend to do an adequate job at collaboration. We are willing to make compromises in this area particularly for the 1.0 release. Note however that we believe that many existing calendar and email products are actually not good enough (for example iCal is not good enough at sharing calendars collaboratively) so our level of ambition here still rises slightly above the average.

Messaging standards

Chandler supports basic IMAP, POP3 and SMTP now and we have more work to do to finish this support and make it broadly interoperable in Kibble. To a certain extent we rely on pre-existing protocol libraries for this work but we've found those need some testing and investment on our part.

We expect to encounter some difficult challenges, particularly in supporting IMAP and offline synchronization together with the innovative workflow and information management techniques offered above. For example, when an email is given a status or another facet in Chandler, we haven't yet figured out how or whether to persist this information in the IMAP server, and whether other email clients will be able to handle those facets.

Some of the emerging email standards are very interesting. Annotations, in particular, offer the ability to synchronize custom information, provided that server implementors decide to add support for this once it becomes an RFC.

Serious work on email, messaging standards and messaging interoperability will continue in 1.0 and into Westwood.

Server-hosted sharing

The emerging standard for sharing calendars is CalDAV, based on the general Web-authoring and file sharing protocol WebDAV. Chandler support for WebDAV began in 0.4, with sharing experimentally functional in 0.5. In 0.6 we are adding the first steps of CalDAV support and improving the sharing GUI.

In 1.0 we must

• iterate the sharing GUI experience until it's usable
• Finish CalDAV support
• Decide which WebDAV servers to support and test and fix interoperability
• Decide whether to do ACL or tickets for sharing permissions
• Decide what to do with servers that don't support ACL or tickets)

This work allows people not only to share their calendars but also to share group calendars and (if they have permissions) add events to shared calendars. People can also share collections of email, tasks, resources or heterogeneous collections.

In Westwood and Pasadena we are not sure yet how we will extend sharing though we have ideas for very secure sharing, based on public key exchange and encrypted shares.

Calendar (and task) Collaboration

Some calendar-related collaboration functionality is extremely specific to calendar uses cases.

Chandler 1.0

• View another user's calendar
• Send and receive iMIP invitations
• View free-busy time for other users in order to schedule appropriate meeting times
• Possibly (depending on standards progress) invite via CalDAV

Westwood: advanced group calendaring

• Delegation/ designation
• Scheduling via server
• Room and resource booking

Pasadena or beyond?

• Assigning tasks to other people
• Views specialized for multiple-person task systems (project management)
• Innovative scheduling workflows

Identity

Identity, authorization and authentication has turned out to be one of the most challening parts of this sharing work. Traditional solutions suck -- it's hard for the user to manage their own accounts in various locations, let alone manage the email, IM, blog and sharing addresses of all their contacts. Much work on identity is going on now, and has even been called a big-bang. We are tracking this work.

The 1.0 release will only include very basic authorization work due to the identity problems

• Ability to manage IMAP, POP3, SMTP, WebDAV and CalDAV accounts
• Tickets to share with others who don't have accounts on the same sharing server
• Probably very basic WebDAV ACL management to share with others who do have accounts

Westwood

• Support for Shibboleth or some single-sign-on solution for universities -- note challenges here due to lack of standardization of HTTP authentication mechanisms beyond Basic and Digest
• Further ACL work related to WebDAV and CalDAV servers
• Support for creating groups of principals (for sharing or invites)
• Contacts management

Westwood or Pasadena or beyond

• Figure out how to correlate identities: somebody's email (to send an invitation) with their sharing server sign-on (to grant them permission to view event)
• Linking contacts to other concepts of identity
• Ways to manage (auto-configure?) accounts more usably
• Browsing users

Other collaboration

Instant messaging is not in the plan before Pasadena. Maybe somebody will write an instant messaging parcel.

Cross-platform

The decision to make Chandler a native cross-platform application has been an expensive decision and will continue to be so. However, it's part of OSAF's vision not only to make this succeed, but also to improve the state of the art in this area, creating the infrastructure as necessary to make an application look terrific on all supported platforms, and contributing any infrastructure improvements back to the Open Source community.

GUI widgets

The choices for Python GUIs were not extensive. We examined the possibilities (yes, including XUL via pyXPCom) in 2003 and decided that wxWidgets already basically worked on our target platforms (though Mac support had problems) and had a strong ongoing development effort and support system, and supported Python through the wxPython wrapper. We knew from that point that we would need to contribute to wxWidgets and wxPython:

• to bring the Mac support to the level we required
• to add brand-new widgets
• to make existing widgets work in slightly new ways
• to fix bugs

Since hiring a full-time developer dedicated to this work in 2004, our investment has continued steadily and we're seeing serious improvement. In addition to the full-time resource we sometimes allocate other developers (including a summer intern) to this work.

High levels of investment in wxWidgets must continue through the end of Kibble and most likely well into Westwood. The alternative would be an extremely costly and disruptive switchover to another system that would itself require investment to support our unique GUI designs.

Higher-level GUI control

Because wxWidgets is a moderately-level display and interface framework, we've had to design a high-level framework to use it -- the Chandler Presentation and Interaction Architecture (CPIA). The "customer base" of the high-level framework includes both parcel developers and those who develop core Chandler GUI. In the long run, a well-designed CPIA will speed development of new GUI. In the short term it's a significant investment to develop the framework itself.

CPIA development work began in 0.1 and continues to be a constant investment of a resource or two for each point release up to and including 0.6. [TBD: evaluate ongoing load].

Libraries

Because everything in Chandler must work across platforms, we are often in the position of being unable to use libraries or capabilities built into an operating system. For example, we can't use Windows system calls to select or list timezones, because Windows does timezones slightly differently than Mac and Linux do. Instead we must find or develop a Python library or a Python wrapper for another library. Then we must integrate that into our build, download and install -- and manage upgrades to that library.

Because of our extensibility ambitions, we must also consider how libraries that we use may be used by parcel developers.

Library usage and integration work is a continuing ongoing load spread across OSAF (with significant investment by our build engineer) and will continue through Westwood and Pasadena.

Extensibility

What makes open source projects not just good, but great? One factor we've seen is a capability to accept contributions, not just to the main code-base but also through extensions. QuickSilver^? has quickly become a necessity to many of its Mac adopters because each user can download the extensions that match the way they work best. Eclipse will maintain high relevance as an IDE because not only are its Java plug-ins excellent and extended with new features as Java itself grows, but because outsiders have also created plug-ins to edit and develop Python code and XML files. We believe this model is particularly appropriate for a PIM because although there is a core of functionality found important by many users, there is also a long list of features that only a few users find to be critical. Features that are critical to a few and unused by most are ideal for development as extensions.

Email, task lists and calendars in particular are areas where users demand specific functionality. Many users today have become stuck using a particular email client because it provides some key feature that becomes necessary to their minute-to-minute use patterns. Yet the same user may be well aware of the limitations of that client (lack of search functionality or support for meeting scheduling requests). An upgrade path might become possible if only there were a way to recreate that one critical feature in the new email client.

Extensibility is a section unto itself in this roadmap because this dream not only involves a significant fraction of effort directly involved in making extensibility possible, it also affects how we do other work.

Parcels

Our vision for Parcels is to have an easy mechanism to contribute new areas of functionality to Chandler. We plan to support not only parcel development but also parcel distribution through centralized services. The user will be able to easily install or remove parcels.

The parcel framework was begun early and somewhat updated in 0.4 and 0.5 releases. At the end of 0.5 it was possible to quickly develop parcels to share photos on Flickr or view bugs in Bugzilla. In 0.6 we seriously rethought and reworked our parcel definition architecture. We are eliminating XML, reasoning that for a parcel developer, learning an XML data definition format in addition to learning Python simply increased the barriers to creating parcels. Instead we developed an API for quickly defining parcel data types and GUI elements in Python.

Looking beyond into Westwood and Pasadena, we have less clear plans. Maintaining a set of public APIs for parcels will certainly require ongoing maintenance work.

Data models, content models

Careful modeling work makes complex systems understandable. In Chandler we pay attention to the data model (the raw repository, or how to store arbitrary items and how to find, see, move, delete, change or extend them) and to the content model (what is an email, what is a task, what are the attributes of a shared thing). Modeling is a difficult task or at least one that OSAF has found very challenging. The needs of the moment encourage special-casing, inconsistency and complexity. Yet the long-term needs of enabling third-party extensions (and making them understandable and coherent in our user interface models) requires that we keep our models simple, clean, consistent and rigorous. In fact even without parcel APIs, it's a long term boon to maintenance and internal extensibility to do rigorous modelling.

In the point releases leading up to 0.4, an extensive content model was created before we had code or clear specifications to back it up. That has mostly had to be rewritten in 0.4, 0.5 and 0.6. In 0.5 we rethought attribute indirection and stamping models. We have many clues to lead us to believe that this rework is not done -- in fact we should explicitly plan in the remaining Kibble point releases to allocate the time to look at the big picture (more than once) and ask ourselves

• How have our models evolved?
• Did we overlook any major simplifications?
• Have we degraded consistency and do we need to clean up?
• etc.

It's very important that the data and content models be in excellent shape and well-documented when we release Kibble because this is the point where we plan to officially encourage parcel development.

Looking towards Westwood and Pasadena, we expect that new features will often involve new content modelling work. We can't predict the need for rework beyond saying it's a possibility.

Repository and Extensibility

If we were building Chandler within an enclosed team we would have a smaller need for a custom repository. We could use some existing tool like a traditional or object database without abstracting that at a higher level. Instead, the need to support parcel developers requires us to create abstractions. With an abstraction customized to Chandler use cases:

• We can handle permissions internally instead of making them the responsibility of the parcel developer.
• We can share arbitrary items without making that the responsibility of the parcel developer.
• We can display arbitrary items in summary views and repository browsers without making the parcel developer do extra work.

This is not an exhaustive list but provides an idea of the costs we'd impose on parcel developers if we used a naive storage approach.

The repository has been reworked in significant ways early in Chandler development and at the moment has quite stable interfaces but has not yet achieved acceptable performance.

In the remaining Kibble point releases we need to continue working on repository performance and also add to and refine the search/filter capabilities as the features exposed to the user make more demanding use of those capabilities. This is expected to involve the continuing investment of two developers full-time.

In Westwood and Pasadena we do not yet know what additional demands new features will put on the repository.

Communications and Extensibility

The idea that any item in the Chandler repository can be shared, imported/exported and can be emailed imposes a burden on us to integrate communication support deep into Chandler's content model -- yet not so deeply that we can't support multiple protocols easily (e.g. WebDAV vs. CalDAV, POP3 vs. IMAP). In addition, we need to make these features available to parcel developers in such a way that they can extend sharing and email without having to rewrite or replace the functionality we've already created.

We haven't yet figured out how to make this work so we expect it will be a significant amount of work for Kibble and Westwood. Adding new protocols (like LDAP and instant messaging) in the Westwood and Pasadena timeframes will add to the burden.

Enabling hacks and exploration

The choice of Python for Chandler development was in part to enable contributions, both to the core code-base and through optional extensions (parcels). Python is a scripting language, which will allow us to someday enable trivial extensions: a user can create a half-dozen line of code to be run every time an event changes, for example. These kinds of mini-extensions are accessible even to non-programmer users if the programmer shares the few lines of code (and where to put them) publicly.

Other features we develop enable exploration along with scripting. We already have a repository viewer tool which allows a scripter to explore and view the results of a script execution and easily iterate on their work.

CPIA Script is another such tool... [TBD]

Our plans in this area are quite vague and really should be called ideas. However, Chandler developers are well aware of the goals here and well positioned to throw something together that works. Often a tool will have immediate use within Chandler development, and if we polish it a little it will be useful externally as well. We expect a couple projects or other efforts in this area in the Kibble timeframe but haven't had to close down on exactly what this will involve.

Community development work

Building a community, communicating with it and dealing with contributions, will become a serious amount of work:

• Documenting APIs
• Designing and running tutorials and sprints at conferences
• Involvement in public mailing lists
• Reviewing contributions

We certainly hope the community will grow and thus our time spent involved with the community ought to increase. This could easily happen at the end of Kibble (if we are successful in building something people want to start building on, and if we succeed in making Kibble a relatively stable platform).

In Westwood and Pasadena we expect continuing community load but also hope for a return on this investment.

Unplanned and out-of-scope work

A laundry list of features and a rough indication of how unplanned or out of scope they are. These are all naturally candidates for independent parcels or for other open source organizations to tackle.

Even if these ideas are out of scope for OSAF to work on -- and perhaps particularly because we don't intend to work on these ideas -- these may be great ideas for Chandler parcels or for standalone projects that integrate well with OSAF's work.

Feature	Characterization
A version of Chandler for mobile devices	Out of scope
Kiosk mode -- a way to run Chandler on a shared machine without compromising personal information	Out of scope -- see Scooby? for alternate solution to underlying problem
Instant messaging client	Probably out of scope
Advanced event recurrence management (beyond the level of what's in iCal for example)	Out of scope
Signatures and email templates	Not in the plan
Contact management approaching CRM	Out of scope
Peer to peer	Not completely ruled out of scope but doesn't have a clear place in the plan.
CAP support (old calendar standard)	Not in scope
many more things to add...

---

Challenges and other notes

Innovative design

Most of the innovative design currently planned for Chandler is being implemented in Kibble. Many features depend on each other in some way (stamping can't work at all without heterogeneous collections, and triage depends on task management in order to be useful).

Westwood will see an iteration on the innovative work planned for 1.0, and we can't yet predict what other design work will be done in Westwood or in Pasadena.

• We haven't seriously tackled the design challenges of making Westwood and Pasadena features usable (for example, finding people in your organization, on your server, or elsewhere, to share with -- or more fundamentally, making identity usable).
• Innovative design requires serious GUI widget work which is extending our schedule well beyond what was originally imagined. We address this in part by hiring more GUI developers but there is a limit to the practicality of simply adding developers.

Supporting quick filtering by facets

We have a significant amount of work remaining to do in Kibble to enable quick filtering and selection of the remaining built-in facets. One challenge presented by this innovation is that we can rarely make use of existing GUI controls -- the traditional hierarchical tree GUI does not at all meet our needs, and thus we must develop rich widgets specially for Chandler.

*Stamping and heterogeneous collections

• Already we have reworked the stamping implementation at least once because of dissatisfaction with the first programming model. Making stamping work together with extensibility requires getting this right.
• We need to put extra thought and work into combined views. It's more difficult to appropriately display email, calendar items and tasks together than it is to display them separately. We are concerned with showing the appropriate layout (tables?) and the appropriate information in each column for emails, events, tasks, and for stamped (multiple-type) items.
• We need to make sure filtering by kind works well -- quickly and easily. Because we allow a mix of item types, yet we know that sometimes the user will be searching for an event or an email, we need to allow the user to quickly eliminate from view the types of things they are not looking for.