Part of my addiction to Personal Information Management (PIM) is constant flirtation with platforms I haven’t tried… or even ones I have tried but want to revisit.

Waxing philosophical for a second, that probably goes with the territory.  Part of the obsessiveness that goes with an interest in PIM is FOMO, Fear of Missing Out.

“What if there’s something to that alternative GTD software I didn’t try?  I owe it to myself to just take it for a spin, just trial it.”

Well, there’s no such thing as “just trial it” with PIMs.  You have to actually run a decent simulation or you don’t find out what you need to know: does this PIM system have something new I can add to my bag of tricks.

And so I’ve frequently been in the situation of running two PIM systems simultaneously, one as my standby and one as a trial run.

And so it was, at the end of November/beginning of December.  I spent two weeks running BuJo and MLO side-by-side, trying to see what I could learn about either.

“MLO” is my standby, MyLifeOrganized, which I’ve been using for a few years.  I blogged about my crush on MLO some years ago here.

But a bigger and bigger % of my day and week is going into MLO daily and weekly planning and support.  I found myself wondering if there were something… leaner?

Enter BuJo, which is the shorthand for “Bullet Journal”, a wildly different PIM approach described on the bulletjournal.com site.

1. Biggest surface difference: BuJo is analog.  You keep your accounting in a paper notebook and you fill in stuff with pen or pencil.  It’s really analog.
2. Core BuJo is not particularly supportive of GTD.  The core of GTD — putting everything into the system, managing all open loops, organizing stuff by context, picking next actions — can be done in BuJo to some extent, but the system doesn’t really support it, and probably isn’t meant to be used in that way (FULL DISCLOSURE: I’m of course not a BuJo adept and I’m sure there are many decent implementations of GTD using the BuJo “platform”
3. The standard system has no weekly review.  This was a big conundrum for me, because I’m deeply addicted to weekly review as the main tool for constraining what I work on.  “Native” BuJo has a daily flow and a monthly flow but no weekly flow.  I suspect this is by design, although the core Bullet Journal text has a nod to weekly review as something you can implement if you want.

But the promise of the system is that it’s lean.

1. You take lean notes (the term “Bullet Journal” comes from the bulleted telegraphic style in which Ryder Carroll, the inventor of BuJo, advises you to take notes).
2. You struggle to exclude “stuff”, not include it.  Part of the methodology calls for regularly “migrating” entries from one place to another (to Next Month, to the Future, to the Next Day, etc.)  The virtue of migrating by hand is that you take a hard look at what goes forward and what does not.  Migrating is core to the smooth operation of a BuJo process.  (One of the core tenets of GTD is that putting everything into the system — instead of trying to keep it in your head — makes your life easier.  My guess is that Ryder Carroll would not agree.)

The lean “promise” was appealing to me.  My MLO implementation has gotten more and more… involved.  My Saturday and Sunday planning (yes, I do some planning on each day) probably takes 2-3 hours all in.  My morning routine probably takes an hour.

I guess I was hoping that I could scale some of the kruft off my MLO practice with some hot ideas from BuJo.

So what happened?

I dug in, I read the book.  I decided that a few things in my and monthly reviews could be streamlined.  I decided that I liked the telegraphic BuJo note-taking format and would try to use that in my daily Evernote entries (part of that morning routine I was grousing about above).

And I decided that, for now, I was happy with MLO and was going to continue on with it subject to those tweaks.

I’ve become a big fan of hierarchical todo-list managers.  It’s great to go down from “All of Life” through Roles to Goals to Projects to Tasks to Next Actions.  I don’t know if it helps me be more productive, but it certainly feels good to think that everything’s connected somehow.

Except some things are not just tree-connected.  They’re graph-connected.

What’s the difference?  A graph can have several “ancestors” (maybe better to call them “predecessors”) for each node.  So a task like “send article to Joe” can belong to “cultivate relationship with Joe” and “send article to tech visionary friends.”

An example of graph structure which most GTD-oriented software supports is “contexts” vs. “projects”.  My project might be to finish the sprinkler controller, but different parts of that project will take place in different contexts: Workshop, Internet, Computer, InMyHead.  Contexts are usually implemented as labels.

One graph-structured problem I’m wrestling with now is the distinction between a project and an event.

I might have a project, say, to improve my friendships with several friends.  And I may have an event where I get together for drinks with some or all of them.

With a hierarchical PIM and contexts, I have a couple of choices about how to implement this:

1. The Event could own the Projects.  In this case, “Get together for drinks” owns all of the people I’m going to have drinks with.  Problem: it’s inelegant, and it’s transient.  Once the event is over, I have to stick the various friends someplace else.  One would think that the friendships were the more important or less transient or more durable thing and should therefore go above the event in the hierarchy, but there’s no easy way to get a number of parents in a hierarchy to own (or share ownership of) a child node.
2. The Event could be a context, a label.  Probably a better solution, in that a context is sort of like an event — it’s a physical or logical place where certain tasks can be done — but I’ve already overloaded contexts in my PIM and it’s starting to break down.
3. The PIM I use now, MLO, allows a node to own an unrelated node elsewhere in the hierarchy, but these relationships are kind of hidden in the software (maybe an afterthought for the developers) and hard to manage.  One wants the graph relationships to be first-class citizens within the software.

Any thoughts?

My to-do lists get more and more complex over time.

I’ve explained here why I like My Life Organized (or “MLO” for short).  Briefly, MLO allows you to organize your tasks into a hierarchy, so that bigger tasks can be divided into smaller tasks and tasks without an organizing principle can be grouped into higher-level “projects” or simply “folders”.

But a consequence of this for me — and I think for any PIM-head who takes this stuff seriously — is that the list of tasks invariably grows and becomes more complex.

Most PIM software has a way of ranking or sorting tasks: by “importance”, by “urgency”, by overdue-ness, by all of the above.  It would be nice to build in to the PIM software some kind of scoring for simplicity as well.  One PIM tree is simpler than another if it isn’t as deeply nested, or if there isn’t a large degree of co-dependence between the various tasks, or <pick your simplicity function here>.

You could then have the software detect and warn you if you were adding on complexity at an alarming rate, and give you some tactics (or even semi-automated processes) for simplifying your PIM tree.

Be careful what you wish for, I guess.  I used some PIM software for a while which would actually put your tasks into the calendar based on the importance sort (and available time slots: each task had to be assigned a length).  Tasks could be split up to some extent, and it was nifty for a couple of days, but then it really got like Dr. Evil’s “unattended killer machine” that was supposed to do in Austin Powers and never did.  It was a major task trying to re-jigger the tasks so they would fit into the schedule where I knew they should go anyhow.  And finally, to achieve simplicity, I threw the software overboard and moved on.

Maybe a simplicity automaton would work better than an automatic scheduler, but I suspect it too could be become a tyrant if wholly automated.  Best to make software our companion and not our master.

My friend Bob and I are teaching together the next couple of days, and I know he gets excited about PIM stuff.  Not quite a PIM-head, perhaps, but a PIM-head-in-training.

We had a not-altogether-clear preliminary conversation about what PIM use case would make Bob buy PIM software.

What excites him, like many, is making better use of his contacts.  Matt may be a doc at Hopkins with life-science research cred (complete fictional example btw) but he’s also an expert on smoking meat.    And his wife is a patent attorney.

You could imagine several ways to code up Matt as a contact (using categories or labels or the like) but two things rise up to bite you: 1) you don’t know all the uses of Matt you’re going to make downstream (you may take an interest in scuba later on, and Matt is a certified dive instructor) and 2) the collection of all the possible labels becomes unwieldy itself; you can’t remember how to code up a smoked-meats expert and end up inventing several labels and making the mess worse.  You now have to scroll down through a hairy ontology-ish beast in order to search or browse, and chances are you won’t.

This was a down payment on a further discussion.  Someday when magically there’s more time Bob and I are going to sit down for a hour or two and work through the various use cases.  It’ll be fun.

I’m still vexed by the disconnect between these three kinds of commitments, which I discussed in an earlier post.

I still use one app for to-dos (MLO) and one for habits (most recently Habitica, as suggested by Chris Bailey.  I’ve had the feeling with my to-do app that things are somehow converging: I’m getting more and more of the features I want each time I do a kaizen improvement and switch to a somewhat better app.

I don’t get the same feeling at all with the habits apps.  I want two things from a habits app which I don’t care about (as much) with a to-do app:

1. Fuzzy recurrence.  I’ve talked about that here: basically the ability to specify things like “every 2-3 day” or “at least 6 times a week”.
2. Accountability.  I want some mechanism in the app that makes me feel good when I do the habit and makes me feel bad when I leave the habit out.

These things wouldn’t be terrible in a to-do app, but they’re not as important.  With a habits app, you’re interested in showing up, in Jerry Seinfeld’s unbroken chain.

Habitica gets a C- for fuzzy recurrence.  There are “dailies”, which are things that have to be done every day and if you miss you get dinged.  And there are habits, where you get + or – (depending on the habit) if you engage in the habit, whenever.  There’s some ability to pick which days of the week the habits apply, but it’s far from a rich set of fuzzy recurrence operations.

But the daily-ness of the app (and maybe its very clunkiness) helps me with the accountability.  I have a drive to check off those daily things, because I know the system has no flexibility, and I know I’ll be punished if I don’t.

Punished how?  The gamification elements in the app help me with staying accountable.   I lose Strength and Health if I don’t do my good dailies or if I do do my bad dailies.  Ditto with the habits, although it’s less hortatory with the habits (maybe because they don’t need to be done every day).

My ultimate PIM would combine some of this stuff with the to-do functionality.  Right now I have some things I want to do every day that are in both MLO and Habitica.  And, btw, perhaps the ultimate PIM could link accountability to bank account or reputation or other stuff that some of the “do or die” apps have.

And then having that stuff project to my calendar would be the Holy Grail.

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.