How many objects do we need?

One of the interesting, and potentially invaluable concepts that the Chandler project brought to light (i.e. to my attention ) was the idea of "stamping". The concept of stamping is the idea of defining incoming data by assigning it a type. When someone is simply typing in some information quickly, it by default goes into a note and then allows the user to stamp it as an event, or a task, or whatever else is needed.

A typical (though narrow) implementation of this concept is in the ability to take an e-mail that is an invitation and have the information be put into the calendar at the appropriate time. Microsoft Outlook allows e-mail's to be scheduled this way.

As far as I can tell, the Chandler project does this by displaying different facets of information in different contexts. This implies that the information is stored and "stamped" with several different types.

For example: someone may send you an evite to an event. You respond to the evite but keep the e-mail around as a reminder. If you liked the restaurant that the event occurred at you may decide to keep a note about the fact that you like that restaurant and you may also want to put the address of that restaurant into your contact list. In the Chandler world this is done by stamping the same piece of information twice. The first time it is stamped with the type "note" and the second time with the type "contact".

My apologies in advance if it turns out that I am misinterpreting the design notes for Chandler.

I think, the same thing could be achieved by creating new objects from the initial object and then maintaining associations between them. This would allow someone to create an event from an e-mail and the event would have a reference back to the original e-mail.

Context is decisive

Context is decisive. What ever context you have for piece of information governs

your understanding of that piece of information. So context is decisive.

I have had thoughts about context going around and around in the back of my head

for days now. And since they are getting in the way of my other work I am

putting them into the blog in the hopes that they will leave me alone.

One of the most common requests I have bumped into is for the PIM to take into

account the context in which you are running the application. So, in other

words, if you are at work it would only show you by default the tasks and events

pertinent to you being at work. If you are on the road it would only show you

those items that are pertinent to you being on the road.

The GTD methodology recommends setting up tasks list with tags such as @phone

and @office so that when you are on the road you can simply list those tasks

that you have the resources to perform. Is this something that makes sense to

model in a more sophisticated manner.

In other words, what does knowing the context make available in terms of work?

Should it be modeled and if so how?

It was Col. Mustard in the library with the candlestick

One of the big questions in any enterprise development project is who gets to muck with the database or data repository.

This is significant even in the case of the PIM.

When looking at how to deal with pushing data out to other repositories such as Google, polling data from other repositories such as Google or RSS feeds, and just the general headaches of synchronizing to and from other devices is clear that who gets to touch the database and how is a critical question.

For now, I am assuming that all of the tools that feed to and from other data sinks/sources will do so by operating against the database rather than having the PIM up and running and managing those operations.

Kitchen sink modeling

The more I work with user stories and scenarios for PIMs the more it is becoming clear that there is simply a sea of information that only the user has any sense of. Most of the things that we are modeling have specific meanings to the individual (i.e. must a promise have a due date?). For some people the answer is yes for others the answer is no.

It is clear that for most people there are clear distinctions between the different types of data they have. In other words most people have a consistent way they mentally model meetings versus tasks versus holidays. And the way they model it is quite closely tied to the way they work. So people work and live in a world of pieces of data that have clear types and clear behaviors.

The collections (i.e. projects, agendas, to do lists, checklists, etc..) people use to manage those different types of data ( i.e. to do list items, tasks, promises, calls, errands, chores, etc..) are just as individualized as the data items themselves.

For example: For some people a task may be committed to to the extent that somebody has said "I will do that sometime next week". And they put a sticky note in their calendar so that when they are looking at that week they know what things they promised to do that they haven't put into "space and time" yet.

Other people maintain tasks on lists that don't count them as real until they are scheduled on a calendar. Until that point they are on the "Not Doing Now" or "Unscheduled" list.

So clearly, the majority of everything to be modeled needs to be customizable. so, after walking through user story after user story this is what I see:

1) Every thing to be tracked in a PIM has one or more behaviors.

The behaviors are

• Locatable in time (LIT)
• Can Occupy time (0T)
• Locatable in space (LIS)
• Has a lifespan (SPN)
• Has trackable progress (TRK)
• Has a due date (DUE)
• Requires resources (RR)

The different types of items can have the behavior or not have the behavior. If they do have the behavior then they can either have the state of having a fixed value or not having a fixed value.

For example, a promise can have the behavior of being locatable in time, but it may not yet have been fixed in time.

2) Everything is versionable.

There are many areas where tracking the changes to a scheduled item (who generated them and when) is critical to fixing something. This is specially true when you're dealing with synchronizing schedules with multiple calendars.

3) All items tracked in the PIM are associated with a specific type and that type has associated properties and each type has default values for those properties and behaviors.

For example, an event can have the behavior of being locatable in time and may have the behavior of occupying time and the default time it occupies is 15 minutes.

4) Context is decisive: context such as home -- online or home -- off-line or work -- online etc. have resources available such as (phone, computer, Internet, e-mail, etc.)

Many methodologies such as GTD take into account the context in which you were working. For example there are some things that should only be done from home, there are some things that should only be done from work, and there are some things that can only be done when you have a phone available. The user's context governs both what they should be doing as well as what they are capable of doing given the resources available.

5) Taxonomies (hierarchies) go from wider towards narrower ( i.e. Extended Family => Immediate Family)

In looking at all the different ways people navigate through hierarchies and the way they create their own private taxonomies (using file folders, categories, tags, etc.) it is clear that most people navigate from wider and narrower.

Going to and fro

The other part of the last few months has been looking at importing and exporting and synchronizing.

Spent a great deal of time looking at the iCalendar specification and all of the recurrence rules. And then I read all of the use cases for recurrence rules interoperability that have been put together by some incredibly diligent groups of people. The people that work on those specs definitely come under my heading of unsung heroes.

As often appears to be the case in the area of calendaring, there are really no clean answers. And, going back and forth between the icalender format and a more flexible internal model is going to require a great deal of detailed work. But, it is very clear that iCalendar is the de facto standard for now and I see nothing on the horizon yet that will replace it.

And personally, I think it gives the biggest bang for the buck. If I can support CalDAV and ICalendar to any significant degree I will be able to publish calendars to and from Google Calendar , as well as many others applications.

So my immediate attention is to support import/export for ICalendar , and then support using CalDAV to publish.

- Jim

When things don't fit into a neatly modeled the world

I am back after a long hiatus. A combination of work plus a course I'm teaching has kept me very busy.

But always in the background I am thinking about the PIM. That's how we referred to it in my household "The PIM". I would wonder if I'm a little obsessed except I'm having so much fun.

I've been coding some commandline utilities to test the data model and, as I expected, I have run into the limitations of my original model. I had originally started with calendars, and agendas and so on being first class objects. What I mean by that is that they have some distinct existence in the real world , and that is why I am modeling them. What I have discovered is that calendars, address books, task lists, journals and so on are all simply semantically themed collections of stuff we care about.

There are few assertions I can make about what a calendar is that are universal enough to be easily recognizable to everyone.

So I stepped back and thought about it for a bit and this is what I have come up with: we have an ocean of first-class objects that we would like to track (incense, tasks, promises, contact information, little notes) and so on. And then we spend our time trying to organize them into multiple collections they give us easy access to what we want to do when we want to do.

So I am experimenting with having any of these collections simply be taxonomies. Just like described in an earlier post. This would mean that many calendars have a relationship to each other. An example would be the calendar I maintain for my children's schedule all together which could have two related calendars ( one for Aidan and one for Trent ) . both Trent and Aidan's calendar would refer to events in the Boy Scout calendar.

The same would be true of address books. I could have an address book that references my friends and a related address book that only has the subset of my college friends.

The same appears to work well for journals, agendas, sets of conversations, and the collection of resources and notes that I refer to as Data Mines or just Mines.

What activities should a PIM support

When I first started this blog I naïvely thought that because I have been thinking about this for so long that I had it all firmly clear in my head, and it would pretty much come out in some sensible order.  

Instead I have discovered that along the way I will end up going back and documenting something that seems so self-evident that I have forgotten about it completely.

One example of that is really documenting what are the activities I expect to be able to do with the PIM. This is implicit in a lot of the previous posts, but it is definitely worth making it explicit here.

Basic activities that I expect a user to be able to do include the following:

Capturing and evaluating input: Being able to triage and classify events, tasks, contact information, and other references and notes as they come in. Being able to quickly decide what needs to be handled immediately, what can wait, and if something needs to be scheduled immediately the user should be able to do that quickly even if it means classifying it or scheduling it approximately. "oh look, a dinner invitation, I don't even need to look at it until next week,  so I will throw it into next week.". Being able to throw a note down into the system to be converted to an action or a task later.

Organizing: Going beyond the initial triage to the point where tasks and events are being scheduled in time (or at least the order is being set), as well as coordinating with others. Being able to overlay your own taxonomy/ontology/organizational structure onto the raw objects in the domain ( events, tasks, promises, actions, contacts, etc.). Being able to extend the raw objects of the domain so that they can be personalized to carry the information that the user needs.

Collaborating: Not only sharing calendars, but tracking conversations associated with shared activities.    Tracking the status and progress of projects from organizing your grandmothers birthday party all the way to coordinating the training of a large group of people.

Squirreling things away so the nuts can be found again:  one of the biggest battles for users of a PIM  is storing the data (documents and pictures and other information) associated with an event, a task,a person, or a group in such a way that it can be easily found when needed. 

Finding: Looking through information that you stored off to the side with the intention of finding it again.   Being able to reconstruct timelines based on e-mail conversations and scheduled events. 

Presenting: Visualizing and reporting on the data in a way that is natural for the user. Being able to generate reports on the status of projects from scheduling birthdays and tracking who is coming all the way to larger projects like the implementation of a training regimen for a group of trainers.