Intentional Objects and Relationship Objects

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…

Starting up the “Recurrent Tasks” PIM project

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.


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

Make-ahead Lunch Weeks 3, 4: Ham Bone, Greens, and Bean Soup

Well, make-ahead lunch week 3 got eaten by Snowzilla here in DC.  Couldn’t get out for ingredients.  Too much shoveling to make lunch on Sunday.  Didn’t get out to work a couple of days that week so no lunch needed.

Existing stocks of Peruvian Vegetable Soup and Burritos tided me over the days I did go to work.  All goodness

So this Sunday the snow was largely melted, the game was on again, and so I found a soup recipe that was 1) fibre-tacious, 2) within my capabilities, 3) would freeze easily.

Indirectly, an article on soups that freeze led me to this Melissa Clark recipe for Ham Bone, Greens, and Bean Soup.

A bunch of kale, a half-head of cabbage.  All good.  Used canned beans instead of dry.  Okey-dokey.

The ham bone itself was a problem.  Our Whole Foods doesn’t do deep dish butcher-y things like cut ham bones in three.  I sometimes even think they make meat without any bones, innards, or waste.  Well, not really, but they give a good simulation.

In any case, Debbie was at the Whole Foods while I was doing stuff at the hardware store, and she got a already-cooked ham hock with bone in.

So I figured with the canned beans and the already-cooked ham there was excess cooking time in the recipe.  I went straight to the cabbage and kale after bringing the ham to a boil, and thus reduced the cooking time by 1/2 hour.

Oh, and I used chicken stock instead of water.  I prefer stock to water most of the time anyhow, and who knows what would happen with an ersatz (or at least jury-rigged) ham bone.

It was a huge amount of soup  I froze four portions and there were still 3-4 portions left for the fridge.  I had some for breakfast this morning.  Pretty tasty.

The make-ahead scheme for the year is taking shape.  Each Sunday make one new dish and have enough portions of the previous dish(es) left over to insure that there’s A/B variety each week.

This is all quite feasible in soup season, because these soups are actually pretty easy to make.  I don’t know how it’s going to go once we get to salad season, since salads seem at least much more hard to keep than freeze-able soups.

I’m improving in my ability to eyeball a recipe and see if it’ll taste good and be within my powers to prepare.  I guess it’s like sight-reading music.  If you do it enough you build up a skill for it.  Unlike sight-reading, you don’t have to do it in real time.

I’m also very marginally improving in my abilities to prep food quickly and efficiently.  I can chop a bit better, particularly since I’ve begun to sharpen my knives a bit more diligently.  If you take the time to put a decent edge on them they keep the edge better, so you get more effortless chopping and less holding-and-separating between chops.  But maybe I should take a course in food prep or something.  Couldn’t hurt.