And that seems to be the theme. Anyone who is using an electronic PIM seems to have done some significant adaptation to the PIM itself. It may be simply accepting that you can only have 15 categories for all Tasks, Events and so on. It may also involve managing things in multiple applications and sharing data between them.
Some of the issues people have adapted to:
- PIMs that have only one calendar.
- PIMs that require you to share the same set of categories among events, contacts, and tasks.
- PIMs that only allow you to set one category for each contact.
- PIMs that assume tasks can only have a due date. If you want to reserve a time for doing it the user needs to schedule it seperately as an event.
- PIMs that don't allow you to schedule an event until everything is known. When and how long , etc..
- PIMs that make it difficult to move the information in and out.
- PIMs that only allow you to track the members of an organization, not the organization itself.
I could go on but the basic idea seems to be that the limitations appear to be arbitrary and sometimes they appear counter intuitive. Yet it seems unlikely to me that everyone involved in the development of a PIM is making arbitrary decisions for the fun of it. There are some very smart people working in this space. Just look at the teams working on Chandler, the KDE PIM or Evolution.
As far as I can tell the issue seems to be how the PIMs choose to manage complexity. All PIMs atempt to manage complexity for the user. Many of them do so by making assumptions about what a user needs.
The tension is between making managing the complexity that gets presented to the user and making the underpinnings flexible enough to support the whole range of activities.
No comments:
Post a Comment