What I Want From “Bookmarks”
I mentioned last week that I wanted to work on “better bookmarking” as my next coding project, basing my approach off of my own thoughts and recent Mozilla research. Now I want to examine what that project might be like.
Mozilla’s Categories
Mozilla, or at least their researcher Brian Groudan, came up with six categories, and I’ll go through each, using the same nomenclature.
I am assuming that all resources under consideration can either be saved to storage or retrieved by a URL, or both. My system is slightly broader in that it will need to deal with the mechanics of “saving for later” as well as the following different things that people do with saved items.
Consume
Something you don’t need to keep after reading/watching/hearing it. Two wrinkles here: are you going to be right about your never wanting to visit it again, and what if you’re more broadly interested in tracking your online experiences? In either case, the “consume and discard” approach is less viable, so here I would want a “consume and file away” option. This immediately makes apparent that organized storage of these resources is necessary, and any such storage needs to be searchable and sortable in ways easy for the user. In other words, this is a problem of structuring information, with additional problems of user interface/interaction design.
The system I really want may be close to a combination of improved bookmarks and browser history—track everything I don’t explicitly tell it not to, and make it easy to promote certain resources to a level of easier access; the things that aren’t promoted are in the class that dubbed “consume”.
This class of resources seems to me like a trail, and the resources I promote to an easier-access class are trail highlights. Any geographic metaphor will have problems, but tracking the trail of my passage across the web seems like an apt description of the basics of what I want this to do.
Reuse
Content you check regularly, which may be dynamic.
If it is dynamic, this is really about storing URLs and making it very easy to go back to them. I used to use bookmark keywords for this, but now mostly leave these pinned open in Firefox. My Facebook and Twitter feeds, for example, fall into this category.
I would want my system to track these also, in a way that marks them out from the rest of the trail. In practical terms, I would like this system to be able to define the pinned tabs in Firefox, with the understanding that “pinned tabs” are merely how I access them at the moment and that this will presumably change over time—but that they will still essentially be URL-based resources. For the reusable resources that I don’t want to check all the time but do want to check frequently, I want some easy keyboard-based way to get there, and this way to get there needs to be faster/easier than a Google search. There are a variety of ways to do this, but again the system must allow some set of resources to be handled in arbitrarily different ways, and track those changes across different devices.
I’m assuming that a version control system, presumably Git, will be used to handle tracking, although whether this will be integral to the system or something the system is designed to make easy I’m not sure.
Nothing
Groudan explains this as “You save it because you think it may be useful later or for archival purposes”, which doesn’t seem like “nothing” to me; I would call this one either “archive” or “unknown purposes”. It’s clearly not the same as “consume”, since you’re marking it as something to revisit, but it’s not a dynamic resource you’ll check regularly. This is more or less the “trail highlight” class.
Apart from things like tagging and categorizing, as well as tracking when they were added, I would like to have some kind of reminder or culling feature here, where I could set a time for a resource and have the system remind me (or tell me when I ask) that I haven’t done anything with them after some period. This is one of the major problems with bookmarks currently: there’s no easy way either to promote or demote them, so they just expand over time, making the set as a whole far less useful.
Organize
This entire system is based on organizing all of the resources in one way or another, so it’s not really a separate thing, but we can look at this as the explicit tagging/categorizing step that occurs post-consumption, and the system will have to make that step very easy.
Tagging is well-understood at this point. There might need to be categories as well as tags, and in addition the system should handle other metadata (especially when you saved/consumed something).
Clean Up
This apparently means “delete without consuming”, as otherwise I don’t see a difference between it and Groudan’s “consume” step. This would need to be part of organization, essentially, and the main options seem to be “highlight by tagging/categorizing”, “leave unmarked on the trail”, and “remove all trace from the trail”.
States
Those are the six categories Groudan’s research produced. What states would my system need to track? This system should handle both saving things for later and later retrieving them.
The last three, “highlight by tagging/categorizing”, “leave unmarked on the trail”, and “remove all trace from the trail”, are roughly analogous to “bookmarked”, “in browser history”, and “not bookmarked or in browser history”. They’re not exactly the same because this system wouldn’t necessarily mirror browser history, but it’s close. I don’t think those are enough states, because browser history doesn’t distinguish between the unremarkable article you read and the two or three pages you went through on your way to it. You might not want to call out the article as a highlight, but it’s more noteworthy than those pages you went through on your way to it.
That suggests sets ascending in prominence in the system:
- Explicitly deleted resources. No trace of your visit to these should be kept by the system (at least in its current state; there may be problems with version control here).
- Unremarkable “resources”. The intermediate pages I referred to. Not deleted because it’s always possible you might want to either retrace your steps or repeat the search, but pages like these should not clog up searches for other, more important, resources.
- Minor resources. Not quite highlights, but you want to note that you did stop at them and experience them.
- Highlights. The equivalent of current bookmarks, but with better/easier categorization.
Anything beyond those is slightly different given that past this point the user can prioritize based on their own organizational system. At least the following four further sets seem important:
- Shared. If you’ve shared it once, you might well share it again, and making the system easily handle sharing means it can also track this.
- Pending. You’re likely to want to view the “saved for later” items you haven’t yet gotten to.
- Action. While the system should not attempt to be a to-do list, it’s likely that you’ll often have resources that you want to do something with, and flagging these as such would be useful.
- Frequent. If you visit them regularly, you’ll want them to be prominent. This matches the “reuse” category.
As mentioned, just about everything in the system would need to support being tagged and/or categorized in user-defined ways in addition to the above states.
Implementation Thoughts
Storing the data doesn’t seem like that difficult a problem. The difficulties lie in four main areas: integration, user interaction at the entry stage, user interaction at the consumption stage, and user interaction at the organization stage.
Integration would ideally access to system functions from within the browser, access to the browser history, and synchronization across platforms. The first is probably easiest; using JavaScript bookmarklets would likely suffice. The latter two are rather more significant problems. This would be done using JavaScript and/or browser plugin technologies.
User interaction at the entry stage refers to the problem of getting you to actually enter something into the system, which is primarily about making it really easy to do so; and to the problem of differentiating between the “unremarkable” and “minor” resource states I mentioned above. I can’t think of a way right now to do that without requiring the user to make some kind of note every time they access any resource beyond “unremarkable”, but that seems far too onerous a requirement. This would again be JavaScript and/or browser plugins, talking to a web server backend.
User interaction at the consumption stage mostly comes down to searchability and letting the user tailor the system to whatever retrieval patterns suit them, neither of which are trivial problems. The first way to approach a consumption interface to the system would be as a web application, but obviously mobile apps would be desirable here also.
The same goes for the organization stage, but they’re distinct enough that, even if they end up being the same application, it should be considered differently. The first implementation I would try would again be a web application.
First Pass
In order to make this at all realistic as a project, the first version needs to be very simple. I suspect it would be inferior to existing approach to this problem through many iterations, but my hope would be that it would have more room to grow in a way that matches what I want from it. Features for the first version:
- A JavaScript bookmarklet that’s easy to invoke and that can either bring up a tagging interface or simply pass the URL to the backend.
- A backend that’s capable of receiving the data from the bookmarklet, with or without tags.
- A web application that can be queried for the data.
- A web application that can be used to organize the data.
It should be possible to build this with a reasonable API.
10 Dec 2012 at 08:42
Did you just jinx yourself by invoking a “reasonable API”? ;)
10 Dec 2012 at 11:57
I used to bookmark based on frequency. Sections named something like Frequently, Daily, Weekly, Randomly, Rarely. Inside each one was probably less organised, but I found it split it up in a way that I could quickly navigate.
Now Frequently and Daily have been replaced by Google Reader and various interfaces to it. If I check things that often it seems easier for them to tell me rather than the other way around. Weekly, Randomly and Rarely then seem pointless.
I’ve not really bothered with very good organisation since then but I do love the fact that Chrome syncs it all making it available anywhere I have Chrome.
In other news – as you use recaptcha – press the “Get an audio challenge” button sometime – it’s hilarious.
11 Dec 2012 at 22:22
I’m very interested in this topic, as I’ve tried and abandoned a number of bookmarking systems without much satisfaction. My bookmarking is currently a dogs dinner of Evernote. Instapaper, Google+ and Firefox Live Bookmarks, but altogether it’s an illogical and non-intuitive mess. A single bookmarklet solution with a small menu of options such as you describe would be very useful. Please let me know how I can help this project.
11 Dec 2012 at 22:23
I should add that Google+ meets the first three of your four criteria.