Status Distinguish between additional label collections and intrinsic attribute-value collections. Also add something about the item in Chandler not actually representing the Email, but just representing the item that has been emailed. And how that's consistent with the idea of being able to edit the Email. Also include the idea of having an icon next to each To: field person to show the method of transport: Email, IM, Sharing.

This all has to do with separating technology as a tool from the user's data.

For a while now, I've been suppressing a nagging feeling that collections as a "special-case-hybrid" thing that was both a collection and an attribute value didn't quite sit right.

Most applications that deal with information management have 2 notions of collections. One is explicit (ie. playlists, folders). The other is query-based (ie. smart playlists, smart folders).

In Chandler, we tried to conflate the two, why have both when you can just have one? (See ItemCollectionDesign for more background.) Chandler collections are a hybrid of playlist and smart playlist. They can start out with a rule and then continue to be tweaked manually with inclusions and exclusions OR vice versa. Periodically however, as with most things, I have doubts as to whether this was such a smart idea. After all, smart people were behind smart folders.

For example, do I really want to make a collection (which we're saying is really the user's Topic or Category dimension in the Chandler information management universe) every time they want to save a shortcut to a query? Isn't a saved query, fundamentally different from a Topic?

Well let's look at what constitutes a Topic. Topic is really just a subject matter. It could be a sphere of life (ie. Home, Work, Soccer, Knitting). It could be an area of Work. For us at OSAF, Work topics might be Sharing, Interoperability, Extensibility, Task management, etc. It is not status. Status is orthogonal to Topic. It is not Kind.

Now let's look at what saved queries might be.

1. All things that mention the word: Tuareg
2. All things that are more than 2 weeks old
3. All things having to do with Sam or Jim

Well the first query example probably does fall into the category of Topic. It's basically all things having to do with the topic Tuareg. The second and third examples aren't. The second query has to do with Time. The third has to do with People. We've talked about adding People or Organizational entity as a 4th dimension to the Chandler information management structure. (See ContactsTheFourthDimension). We have yet to talk about adding Time as a 5th dimension. However, both are equally legitimate ways to organize information. And both are essentially orthogonal to Topic.

What does that mean for the UI? Well I think we can still stick with the notion of a single hybrid-half-smart-half-explicit collection. However, we may need to expand our notion of what can be a collections to include all attribute values. Right now, collections are the only attributes that are both collections (as in groupings of items) as well as attribute values. Which leads me to ask, well why can't all attribute values be collections as well? Just as an user might want to see all items under the topic collection Civil Engineering in the 19th Century, users will want to see all items with a calendar date of December 12th, 2004 or all items having to do with Sam or Jim. Another way of saying it is that ultimately, collections aren't just 1 dimensional. In addition to topic collections, we should also have timeframe collections, people collections and whatever other attributes users come up with.

In such an universe, our user can save queries 2 and 3 as attribute-value collections. Query 2 is a timeframe collection where timeframe = more than 2 weeks old and Query 3 is a people collection where people = Sam or Jim. And like all collections, these collections can start out as queries and then be tweaked manually with inclusions and exclusions. So the people collection: Sam or Jim might contain all items with people-like references to Sam or Jim (ie. where Sam or Jim appear in the To, From, CC or BCC fields), or any items explicitly DnDed into the people=Sam or Jim collection (ie. An email from Mary Margaret to Genevieve discussing Sam and Jim). The same holds true of the timeframe collection.

So in both of the examples above, users saved queries as new user-defined attribute-value collections (ie. people and timeframe). These attributes are always defined explicitly by users. They're essentially labels. What happens when users save queries as attribute-value collections to intrinsic attributes (ie. To or Date received). these are attributes with values that users don't traditionally have the power to change. (See also ItemCollectionDesign for a more detailed discussion of the conceptual differences between label attributes and instrinsic attributes.)

We can deal with this inconsistency in a couple of different ways:

1. Disallow users to tweak the rule for or manually tweak intrinsic attribute-value collections. (ie. you just can't label an item as To=Jumbo if the item was never sent to Jumbo.) Instead, all instrinsic attribute-value collections are translated into label attribute-value collections. So, if a user creates a query To=Jumbo, they can save the query as a people collection where people=Jumbo which has the rule: To=Jumbo populating it. Now they have a label-attribute-value-collection they can tweak the rule for and manually tweak with inclusions and exclusions.
2. Allow users to create tweakble intrinsic attribute-value collections. Which means that an item that wasn't actually sent to Jumbo could end up in the collection To=Jumbo. However, I can imagine an UI which could differentiate between items that were actually sent to Jumbo versus items that were labelled To=Jumbo after the fact.

You might ask, what's a use case to justify such pollution of meta-data. Well, A Task that was never actually sent to Jumbo, but was verbally communicated or sent in a different email client is a perfect candidate. It's a perfect example of why we need to make meta-data more flexible. Why we need data models that can bend to the user's will...because we can't assume that the computer knows best even when it comes to seemingly incorruptible attributes.

Now we could say that the To field really means Emailed to and so if the Task was actually emailed to Jumbo, it shouldn't pretend like it was. However, again, that's a fine distinction that computers might be good at maintaining, but for your average lazy user, they don't really care how the item got to Jumbo, they just want to know that it got to Jumbo.

On some level, maintaining a distinction between label attributes and intrinsic attributes seems like a good thing. But it causes a couple of wrinkles in the UI that multiplied across the thousands of items that the typical user will have in their repository, could turn into giant impediments.

1. It causes duplication of attributes in the Detail view. For every item the user sends to Jumbo, they will see both that it was (emailed) To=Jumbo AND that it belongs to the People=To Jumbo collection.
2. It forces users onto a detour in order to maintain distinctions that the user is clearly not interested in maintaining. If the user wanted to distinguish between items Emailed to Jumbo from items that are simply To Jumbo, they can always save the query as a people collection where People=To Jumbo. However, if a user wants to label an item simply as To=Jumbo even though it wasn't actually sent to Jumbo using that email client, then why stop them?

Separating the information item from the technology-driven instantiation of the item

Chao introduced Agenda to Sheila and I, since both us missed Mitch's dynamo demo in early January. In Agenda, users have ultimate control of their information items. They are free to label them whatever they please. They are free to define their own labels. And best of all, the labels themselves can be used to generate reports that show you all items of that label. In other words, in agenda, all attributes are label attributes and all label attributes are collections. This is primarily because in Agenda, all items are user-generated.

Today, most applications present information items as machine or application-generated items where users perform more of a midwifery role in invoking the creation of new items. This layer of indirection simplifies workflows on the one hand by automating a lot of things so that beginner users don't need to invest a lot in construction and customization just to get started in basic things such as sending email and scheduling events on their calendar. However the automation also means that users lose a lot of control over their item.

Once a mail client generates a mail item, the attributes you see on the mail item are hard-coded into the item and not something users can take away from, change or add to. Sometimes, the attribute values are set by the application and not-editable by the user. (ie. Date received, Incoming v. Outgoing mail).

At one level, this hard-coding makes sense. It serves as a forcing function to prevent users from accidentally changing intrinsic attributes they don't mean to change and getting confused.