I’m beginning to think about how to conceptualize the world of personal information management, and I’m finding some food for thought.

First of all, I was quite interested in a Viewpoint by Yoav Shoham in Communications of the ACM (not sure if non-members can read it, but the link is here).

Yoav and two co-founders started Timeful, a PIM company sold to Google in 2015.  His Viewpoint was about Timeful’s approach to generalizing time events.

What they zeroed in on was the intentional aspect of calendar events.  A meeting, a habit, a bucket-list entry, all have a time and calendar element, but they vary in other aspects, including their relationship to our intentions.  Timeful reified these as “Intentional Objects” or IO’s, which were the foundation of the Timeful design.

Sadly, all one can see of this design is a screenshot or two from Yoav’s papers, because Google, after it acquired Timeful, shut down its app and threw the cloak of secrecy over how the work would be developed within the ‘Plex.  Their right to do so, of course, but something of a pathetic move for a company with their stature and cash flow.

Timeful, I’m surmising, used the various aspects of an IO to plan automated scheduling for all of one’s time-based events: the weekly status meeting, the visit to the gym, the daily block of work on the Great American Novel.  A very interesting line of thinking, and an interesting app (although I must say my tastes run more to Intelligent Assistants than to Omniscient AIs: I would rather have the app perform as an amanuensis than as an opaque oracle, but maybe that’s what the Timeful team had in mind, or maybe that’s what Google has in mind.)

In any case, I started thinking about contacts in the same way that the Timeful team was thinking about calendar entries: think outside the box, try to generalize, try to see what human purposes are being served by maintaining a contact list.

A couple of reflections:

1. I have contacts in my contact list where I’m interested in the individual, where I’m interested in the couple, and where I’m interested in the household (e.g., neighbors).  Why do we have to treat these all the same way in a contact list, and how do we design a “Relationship Object” that will  capture the nuances of these differences and allow our software to work expressively with them.
2. There are lots of non-humans that want me to treat them like humans.  In particular, corporations and brands want me to Like them, to white-list them, and to store them as contacts just like my individuals, couples, and households.  Are these really the same thing?  Why not?  Is it because of the asymmetry in our relationship (they can yammer at me; I can’t really yammer at them, for example), or is it because of the power asymmetry?  Is there a power dimension to all contacts?  How to model that?
3. How about contacts that can order me around (IRS) or even kill me (Selective Service, for those of us who remember the draft)?  How do we model that?  Do their “requests” (demands, really) have more urgency than others’?  More importance?

Love your thoughts on all this, and on how IO’s and RO’s and <other>O’s would interact in the PIM of tomorrow…

So, some developments on the PIM front.

First, off, in conversation with Larry Fitzpatrick I’ve decided to bite off an actual project, as a way of jumpstarting my efforts to write the ultimate PIM as well as to re-start as a coder and — who knows? — feather my nest in other ways as well.

I had been thinking about a project of scraping social media — Facebook, LinkedIn, Pinterest, Twitter, etc. — to generate personal “Klout-like” stats.

Why scrape?  As I began to look into it, it seemed that most of these sites had APIs for business use — Fan pages, etc. — but nothing for personal use.  Want to figure out engagement for your Facebook pages?  They’ve got an API for that.  Wanto to figure out engagement with you as a person.  SOL.

Larry talked me out of that.  He said that there was a lot of “pumping out entropy” in any scraping effort, and I would end up with a needs-to-be-maintained-constantly hack which didn’t prove any concepts or really make much progress toward the goal of the ultimate PIM machine.

So he asked me to say the first thing that came into my head for a more substantive theoretical piece of the PIM pie, and I said “recurrent to-dos”.

I blogged about them here.  They’re theoretically interesting.  They actually lie at the heart of what makes me most interested in one or another PIM product (so they differentiate one’s hack).  And they are pretty kludge-y in most PIMs, from Outlook to Todoist to Toodeldoo and beyond.

So I started thinking about it.  I had also been reading some of Paul Graham’s essays (if you haven’t read them, they’re wonderful; go here), and he had written about using LISP for coding his ecommerce platform (eventually bought by Yahoo).

It was like Proust’s madeleine.  It took me back to an era where I wrote in LISP and, more importantly, thought in LISP.  And in LISP, recurrent objects are kind of trivial.

Trivial in the sense that there’s no difference between a function and a variable in LISP: generators look syntactically just like atoms (except that they may have arguments, etc.).  The language doesn’t make you jump through hoops to use a function where you might use a variable (or vice versa).

So maybe LISP would be a good medium for experimenting with how to do recurrent PIM patterns, since a PIM pattern may be nothing but a generator for to-do events (I say “may be” because one wants to undo recurrent to-dos, update them, and other operations TBD).

So I was wondering if Graham were really right and it would be possible to right a major server-side app in LISP.

And then it hit me: JavaScript treats functions just the way LISP does!

This could all be done in JavaScript.

So now I can kill three birds with one stone: get started re-sharpening my coding skills, come up to speed on JavaScript, and move forward on the PIM project.

Brilliant!

Next step is to do some experiments with a Recurrent_Generator class.