I’ve never been able to find address book software that functions quite the way I would like it to.  As a result, I’ve often considered writing my own.  But I never quite get there, because I end up generalising my ideas to the point where I have something that isn’t even an address book any more—even though that thing is still kinda cool.  And I do wonder whether that thing already exists in some online form.

So what’s my biggest gripe with software-based address books as we know them?  Redundancy.  With paper-based address books this is an inadequacy inherent to the medium; we just work around it because we have no choice, and we’re okay with that.

Software-based address books, however, mimic paper-based ones so closely that they too have those now-avoidable drawbacks.  Perhaps this is because people are more likely to adopt something with which they’re already familiar, or perhaps it’s because the programmers of these things just lack the interest in improving on the idea that’s already there.  In any case I’m somewhat dissatisfied.

An address book consists of a number of contact entries.  Typically, a contact has a name, an address and a phone number associated with it.  Sometimes the address book caters for people with multiple phone numbers; this might be done by labelling them as home, work, fax and mobile for instance.

Most address books only offer one address per contact entry.  After all, people don’t live in two separate locations; that’s just silly.  Or is it?  Perhaps.  I know someone who spends equal time living with his divorced parents in two separate houses, but admittedly this is a rare scenario.  People don’t frequently have two home addresses.  People do however frequently have secondary locations: work addresses.

With address books as we know them (and assuming space for one address per entry), what’s the best way to handle storage of work addresses?  We can’t store them as part of a person’s contact entry, because we probably use that for their home address.  Unless we know we’ll never care about their home address, we simply have to create a whole new “contact” for this information.

But what do we call it?  We could put “Jim’s work” as the name, but then Jim’s details are spread across multiple records; we don’t know by looking at Jim’s entry whether we need to look at others to find out more about him.  We could put the business name as the name, but then we have no link between Jim and where he works at all.  If each contact entry can have free-form notes then we can use that to our advantage, but then we’d be using a free-form field for information that isn’t arbitrary, and should be deemed a proper part of the record itself.

If that seems too far-fetched, consider how we currently deal with home addresses.  If you want to store complete information in your address book for a family of five, you need to create five separate entries.  This in itself is reasonable, but because each entry has its own address and home phone information, you are repeating a large amount of common data across all five entries.

What happens when, for one reason or another, their home phone number changes?  That’s five records out of date; five records needing correction.  If you then fail to correct all five, you introduce inconsistencies.

You could avoid this by regarding one of the five people as the “head” of the house, and using only their record to hold all of the home address details.  Then, you could leave the address details for the other four blank and attempt to keep in mind that these people live with the “head” when you need their addresses.  Or you could list their addresses as literally, “see Bob’s entry.”

But then not only do your records depend partially on information residing solely in your brain (somewhat defeating the purpose of an out-of-mind “copy” in the first place), but now they also inaccurately suggest that you don’t know the addresses of these four people.  Or you’re placing usage instructions in your data, which is inelegant.

What happens when you know people with multiple personal mobile numbers?  I’ve never seen a paper-based address book that caters for this ever more common occurrence.  Perhaps on paper you would jam all of the numbers into the one space, or cross out “pager” and write “other mobile” in its place.  After all, assuming that everyone has a pager in this day and age is probably overkill.  With most software-based address books though, we don’t have the facility to overwrite labels on a per-record basis.

These are deficiencies that can’t be avoided on paper, but can on screen.  How, though?

Recognise that people and locations are separate things, and treat them separately.

Give Jim a “person” entry containing his name and his personal mobile number.  Give his house a “location” entry, and give his work a location entry.  Then, create links between Jim and the two location entries.  The links themselves could also hold information telling you what the link signifies; one link is for “home address” and the other is for “work address.”  This information goes into the link rather than the location entry itself, because one person’s work address might indeed be another person’s home address—what if Jim is a butler?

Create five separate “person” entries for the family of five, each containing personal mobile numbers as appropriate.  Then, create a “location” entry for the address at which the five people live.  Then, create links from each of the five people to the location as a “home address.”

Where does the home phone number go?  It doesn’t belong to any one of the five people; as a fixed phone line it belongs to the location itself.  Therefore, it goes into the location entry and not the individual people entries.  Looking at the people entries and following their links to the location entry, it’s easily inferred that those people can be contacted via that number.  Because that number is stored once, when it changes it only needs to be changed once.

How about email addresses?  Many people have many email addresses for different purposes (often just for something completely unrelated to email, like MSN).  I just tried an online contact manager that allows you to store only two emails per person: a “home email” and an “office email.”  Terrible!

How is the problem of multiple mobile numbers (and emails) per person solved?  So far, it isn’t.  These would go into the people entries, but perhaps both the people and location entries would be designed such that they can accept as many numbers (and emails) as one wishes to store, and the user could assign any label they like to each one (“primary mobile,” “secondary mobile,” “line 2,” “MSN address,” “uni email address,” “fax line,” “garage door opener,” etc.).

Yes—garage door opener.  My place of employment is setting up a spare phone number to accept incoming calls from employees as a trigger to open and close the garage door to the car park, saving people from carrying around a remote control (or not being able to open the door at all when there aren’t enough clickers to go around).  Pretty neat.  How would one go about storing this in an existing address book?

So at this point, we’ve gone from a set of “contact” entries containing as much information as possible relating to one contact, to a set of “people” entries, a set of “location” entries and a set of links between them.  The people and location entries hold phone numbers specific to that person or location, with a label specific to each number.  Software that implements an address book in this way would, I think, leave me happy.

But in thinking about how I would go about implementing this, I then realise: is there any major difference between “people” and “locations?”  They both have an identifier (such as “Jim” or “107 Lygon Street”), they both have phone numbers hanging off them and they both link to other things.  So really, they’re just information holders linking bidirectionally to other information holders.

If you reason that no information is lost by turning phone numbers into separate entities and linking to them, all we’re left with is a graph (not to be confused with chart) of tidbits of information, made meaningful via the relationships between them.

And at this point, we’re no longer limited to storing just contact information.  By being able to link anything off a “person” entry we can now store dates of birth, favourite colours, shoe sizes, car registrations…the list is endless.  And of course by being able to link anything to anything, we can even link people together.  What started out as an address book can now also function as a family tree, among other things.  Anything that can somehow be linked back to a person can make an appearance.

So now, we’ve gone from sets of “people”, “locations” and relationships to just “nodes” (small bubbles with tidbits of information, like a name or an address) and “edges” (the relationships between those tidbits of information).

Given any arbitrary node (perhaps retrieved by name), we can follow its edges to other nodes.  In this way we could eventually traverse the entire knowledge base.  What if we just want to see a list of people though?  We’ve generalised away the concept of “people,” so all nodes are now equal in status.

Simple: create a node called “person” or “people,” and link all nodes representing people to this newly created node.  Do similar for “locations,” “phone numbers” and “dates” perhaps.  If you then wanted a concise reference to all the categories that you’ve defined, you could then link all of these to a new node named “categories.”

A graphical user interface could probably incorporate this in a nicer fashion: it could make “category” appear as an adjustable attribute for each node.  Perhaps the interface could then colour different nodes appropriately, according to their category.  It can be seen however that the data structure itself can hold all of this information, and it would; the user interface would simply choose to interpret it in a special way.

It can be seen that because edges (relationships) provide the meaning to the data, there will be many of them—possibly even hundreds—for some nodes.  Perhaps a user interface would want to offer the ability to somehow limit or filter the display of relationships.

For instance, perhaps I could have a view (a predefined set of filtering rules) that tells the user interface to start by showing me only “people” nodes, and when I open them, to only show me links to “location,” “phone number” and “email address” nodes.  I could call this my “address book” view.

What other views could one build?  It depends on what would be useful for the data stored.  A “family tree” view might start with display of just people nodes and limit viewing of relationships to other people nodes.  A “password manager” view might only list website URLs with links to “password” nodes.

On the topic of storing passwords in a structure like this: if you don’t use a different password for every single thing in your life requiring one, this data structure could give you interesting insights.  Relationships between nodes can be traversed in either direction, so you could discover exactly which services use a particular one of your passwords.  In a situation where this password is compromised, you would have a concise list of services that require you to go and change it to something else.

This inverse observation of things obviously applies to anything in the data structure, so you could learn all sorts of new things from information that you already know, simply because you’ve never had the inverse relationships pointed out to you.

So here’s the question: is there any software or online service already in existence that offers anything remotely like what I’ve described above?

The closest graphical equivalent I’m aware of is FreeMind.  Primarily, however, FreeMind “maps” function as trees; hierarchy is enforced whereas in the structure I’ve described above, any hierarchy is merely incidental.  Links can be made between two arbitrary nodes of a FreeMind map, but I don’t know much more about it.  And as software, your data is only accessible from your own computer; you can’t just log into an online service to retrieve something if you’re out and about.

In terms of actual functionality (though not necessarily usability), wikis might come close depending on how they are set up and used.  For instance, a wiki page would serve as both a node and its links; the page’s name/title would serve as the node’s name, and the page’s body would document its relationships with other pages.  Links would be strictly unidirectional unless the wiki software offers “backlink” functionality (a list of wiki pages that link to the currently displayed one), and depending on the quality of that functionality, one might have to visit the other page to understand its relationship.  Creation and maintenance of such small wiki pages would be tedious since wiki pages are designed for much more content.

And so for now, I remain tempted to implement my own solution to this.  I’m always hesitant to act because I don’t want to start and then discover that someone else has already done it, but then I don’t think anything would function quite the way I would like it to.

Should I embark on this development adventure, these will be my considerations:

  • Web-based. If it’s accessible from a web browser, your data can be accessed from any computer with an internet connection.
  • Simple mobile interface support. I would want to be able to use it from my phone, which has limited screen space and limited processing power.

The system would start out predominantly text-based, even though in my mind I visualise it as bubbles or boxes with lines to other ones.  Further down the line it might be possible to dynamically generate still shots of parts of the data using Graphviz.  Even further down the line, with continued lessons of wisdom from a good friend it might be possible to offer an AJAX-like Flash interface complete with traversal animation.  I would most probably write my code in Perl using the Catalyst web framework, and I’d probably use MySQL as the data store since that’s what my web host provides.

In the meantime however, I guess I’ll just continue keeping all of my tidbits of information disjointedly on sticky notes and hope that I find some other information management solution that works for me.