As mail messages and addressbook entries are stored in the same database, the same tools are available for both types of objects – addressbook entries can be flagged and categorized just like email. Personally, I would identify my contacts as friends, colleagues, managers, people I play soccer with, etc. These categories are definitely not disjoint; surprisingly enough, your colleagues and fellow footballers can be friends too.
Once we have assigned attributes to addressbook entries, we can use them in lots of interesting ways. One very powerful use would be to generate lists of recipients, for example to
- Send a message to all people marked as soccer players to organize a match.
- All people who are both soccer players and colleagues to organize a game against another company.
- Find messages from your managers that need a response.
- Find a list of friends that we haven't emailed recently.
There are some unfortunate consequences to storing messages in the way described above. For example, as objects are not uniquely categorized, a given object can exist in multiple places in our hierarchy. If a user is used to the old folder paradigm, he will be surprised when "copies" of an object are updated when he updates one instance. This is not much of a problem for immutable objects like email messages, but may be a problem in other cases.
There is a related problem that appears when we want to delete an object. Does the user want to delete the object from the database, or does he just want to remove it from the current categorization? In the old paradigm, these two were synonymous. Perhaps we want to provide both mechanisms to the user, but he may find this confusing.
Taking these thoughts further, does this API mean that the user is less likely to delete messages? Will we get enormous mail databases with items squirreled away in obscure categories? Do we need to give the user tools to help him clean up the database?
Finally, there is one major piece missing from the above. What do we do if the user wants to search for a word or phrase in the subject or body of one of the messages? This is arguably the most useful feature, yet it is not obviously provided by a database based message store; it can just as easily be provided by a traditional email datastore. So is the whole complex edifice described above useful enough to warrant working on an implementation? If we can't convince the user to maintain and use the user attributes, the answer is probably no.
Mail Client UIIn my opinion, defining the database and inventing some examples of how it could be used is the easy bit. The UI is another matter entirely. After all, we can have the most advanced database in the world, but it will not be used unless the interface to it is simple and intuitive. User interface design is not my strong point, so I won't belabor this issue, but I'd like to briefly suggest some approaches that I think might be fruitful.
First of all, we should define the problem: There are three aspects of the UI to a database message store:
- Schema modifications – introducing new attributes and attribute values.
- Attribute maintenance – viewing/modifying an object's attributes.
- Specifying queries – using the attributes to find messages in the database.
Schema modifications are relatively straightforward. For example, when adding an attribute to the schema, the user just has to specify an attribute name and type, and perhaps a set of allowed attribute values for enumerated types. This is ideal material for a simple wizard.
Attribute maintenance is slightly more tricky. Most attributes are intrinsic to the email messages or maintained by the mail client itself, so will never need to be updated by the user. Most of the rest can be modified using straightforward UI widgets – message flag attributes can be set via buttons or tickboxes, enumerated attributes via selection boxes etc.
The message category is another matter. A typical user may want to use many different categories, forming a deeply nested category tree. In addition, he may want to assign two or three categories to a message. This means that the usual solution – a drop-down selection box – is probably not useful.
One option would be to allow the user to drag a message from a "message list" panel to a "folder list" panel in analogy to the way he would move a message into a folder in current mail clients. This is a good solution, but does not make it obvious that multiple categories can be assigned to the message. Also, many of the "folders" would be like the virtual folders in current mail systems, so could not be used as a target. So this interface may not be intuitive.
Another option would be a tree view of the available categories with tick boxes adjacent to each category. Boxes would be ticked for each category that the message was assigned to. This is the most complete representation of the category information, but would be rather tedious to use.
Another option would be a text entry box with autocompletion, like the addressbar in a web browser. This would be good for typists, but perhaps not so good for everyone else. I'm sure that there are many other solutions too. This is one area where some experimentation may be required to discover which one is best.
Finally, we come to the UI used to specify queries into the database. Essentially, we want to create a UI component to replace the "folder view" found in current email systems. This would be the primary tool for finding messages in the database, so is the most important component of the new mail client UI.
We can conceptually divide message location techniques into the following:
- Find messages based on a few fundamental message properties, e.g.,
- Recently arrived and uncategorized messages, i.e., an Inbox folder.
- Messages queued up to be sent, i.e., an Outbox folder.
- Messages currently being prepared i.e., a Drafts folder.
- Messages marked as sent i.e., a Sent messages folder.
- Find messages based on their category. As discussed above, this is the equivalent of the traditional folder hierarchy, and can be displayed as such.
- Find messages based on message thread or other intrinsic or client attributes.
- Find messages using a query language.
- Virtual folders that remember useful queries.
One simple query interface hinted at above is the query tree; here we build a hierarchy using simple attributes. At each level of the hierarchy, the user selects which attribute to use by, for example, clicking on an icon where the "[+]" and "[-]" icons usually are in current folder browsers. Each time the icon is clicked, the tree is expanded using a different attribute and the icon is changed accordingly. Each entry in the expanded subtree corresponds to one value of the chosen attribute.
Not all attributes are suitable for such a query tree, particularly attributes with many distinct values, e.g., dates and the message subject. Also the user would only be able to do very simple queries in this way. But this might be a simple enough interface that it might be used by everyday people. Again, more research is required.
- "DB fs, Page 1/3"
- "DB fs, Page 2/3"
- "DB fs, Page 3/3"
