THe postings here have moved.

All of the postings here have moved over to my other blog: http://biggerwrench.blogspot.com/

PIM Manfesto

Personal Information Manager Manifesto

A manifesto is a declaration of principles. It may sound grandiose, but this declaration of principles is important to me because it is the distillation of at least 7 years of thinking about what the future I want to create really is.

Principal: The PIM is an expression of how people live their lives.

The things users talk about in real life correspond to the things they manipulate in their PIM. For example if a person thinks in terms of anniversaries, holidays, meetings than those are the things they schedule rather than something called an event.

The actions users talk about in real life correspond to the actions they take in their PIM. If they think in terms of making and keeping promises than the PIM makes it possible to make and keep promises.

Principle: The PIM has a very minimalist design.

It displays what the user needs when it is needed rather than overwhelming them with all the information they might need.

Principal: The PIM is designed to use and make available connections between the things the user deals with.

The PIM makes available the connections between the data when the user needs them. It is easy for the user to lay out the communities in their lives the way they think of them. Adding and subtracting people from a community should be easy.

Principal: The PIM allows users to recognize what is available from where they
are rather than remembering.

Having the user be able to get the information they need when they need it and recognize its availability rather than remember where it would be.

I will probably add to or simplify this over time but I wanted to get it down in writing and out there.

Going Mobile

For years now I have had a love-hate relationship with mobile PDAs. My first Palm Pilot (I vaguely remember that it was sometime in the 90s) was a revelation! It was simple and straightforward and while it didn't do huge amounts; what it did, it did well.

Unfortunately, as my scheduling needs grew, the Palm's did not. Multiple calendars were just not in the cards and synchronization via WiFi never seemed to work out.

Eventually, I gave up on the Palm devices and my wife gifted me with a Dell Axim. And I started a different love-hate relationship. Well, mostly hate. It is a Microsoft-based device after all. This meant I dealt with crashes and the necessity of clicking many things many times to get to where I wanted to go.

And then there are the Dell specific gotchas. I especially like the fact that even while in the case it is easy for the Axim's sound record button to be bumped and for the device to record a nice long audio recording that fills up the disk space.

Overall, it really wasn't that much better a device then the Palm devices. Though it does have the cool Bubble Breaker game.

And then I tried the many different ways to sync up to a single repository of calendar and other information. To mention a few: GooSync, MultiSync, the various SyncML -based solutions like ScheduleWorld. During this period I spent more time recovering from synchronization failures of many different types than I did doing actual work.

Until recently when Google released a Windows Mobile OS 5.0 application that allows me to sync between my Google Calendar and the Axim. That, in combination with MilkSync, for syncing with Remember The Milk has allowed me to achieve a basic minimum level of keeping my mobile calendar and my desktop calendar in sync.

So what does that leave me with as a solution? I have my Dell Axim, which allows me to capture information while I'm on the go including scheduling information and sync it up with my desktop calendar. Of course, notes and tasks are not synced up by default and need special handling. I have my cell phone, which gets notifications from Google Calendar so I have reminders of what needs to be done without depending on the Axim's erratic notification methods. And of course, I have the Google calendar.

It works, but it is hardly ideal.

Of course, being an incredible optimist, I have hopes that the new android-based devices will provide for a more total solution. But I have seen very little in the ways of reviews of their PIM capabilities.

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.

Incomplete thoughts on displaying PIM data

Modeling calendars, agendas, projects and so on as views into the data.

Examples:

A calendar could be considered a view into a timestream populated with events and tasks and anything else that can be located in time allows organizing chronological events in terms of days, weeks, months, years, etc..

A timeline could be considered a view into a timestream populated with the events, tasks and anything else that can be located in time.

A timetable could be considered a view into a timestream populated with the events, tasks and anything else that can be located in time in a tabular form.

The daily agenda could be considered a view into a timestream populated with events and tasks and anything else that can be located in time.

A Gantt chart could be considered a view into a set of actions that can be tracked and have a due date. A to do list could be considered another view into a set of actions that can be tracked and have a due date.

A contact list could be considered a view into a set of information about people, organizations, companies and so on.

So far, so good.

Taking on that there is a view into a otherwise undifferentiated set of data has the potential to give great results. That is effectively what ECCO allowed you to do on a limited scale.

And it seems to me that there are two parts to this. There are the constraints or criteria that gives the list of items to be displayed such as show me all the items that can be located in time and whose date occurs somewhere within the next month. And some of the criteria could be tags and or "all items referenced by the following taxonomy..."

So that gives us some common views that may be of use:

1. For sets of items that can be located in time => calendars, schedules
2. For sets of items that can be tracked and/or have a due date there are projects, to do lists, agendas, checklists.
3. For sets of items that are contact information of various types there are contact lists, mailing lists, and directories.
4. For communications and messages there are threaded conversations.
5. For events that have happened in the past there are journals and audit logs.

So if we now look at how those views could be created we start having to pull together all the previous notes and discussions.

Say for example we needed to create a mailing list for a specific community such

as the extended family. Of course the criteria would be something like: please

display contacts referenced by the "family" tag/taxonomy.

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.