In reply to Dan Whaley.

Given how I would suspect that most people use Hypothesis, having a more explicit bookmarking functionality may help to make that a simpler entryway into the rest of its functionality. If Hypothesis could collect traditional bookmarks with tags of things readers are interested in researching, revisiting, reading, and potentially marking up, then it could be a more self-contained product rather than needing to use other services for this. Each part could build upon the next and ultimately allow researchers to use the product as a defacto online commonplace book for their research work.

Naturally, knowing that this is a potential pathway or use case is half the battle for users who might want to use Hypothesis for bookmarking and later revisiting. Page notes with tags could be used for simple quick notes about referent sources or reasons one may wish to log for why they want to revisit certain pages. I wish I had kept it, but I remember a few years back seeing some year end data from the Pocket service that readers who bookmarked more articles generally read more and used the app more even if their percentage of read articles stayed relatively low.

Within the hypothesis UI, in addition to the "eye" and "page" mini-icons for annotations and page notes respectively, one could explicitly add a bookmark icon and allow users to create a bookmark with notes and tags and save things either publicly or privately. In some sense this may really be no different than the functionality of creating page notes which amounts to the same thing, but from a usability perspective, many users are more likely to respond more aptly to a bookmark functionality versus a page note functionality, which requires some additional explanation. Perhaps changing "page note" to "bookmark" (with the ability to still create page notes in the text box) may make more sense to a broader audience? Looking at the number of page notes with a bookmark flavor versus traditional highlights/annotations may give some idea of how useful this may be.

From within the user data view (example: at https://hypothes.is/users/chrisaldrich) the page is primarily about lists of annotations (by time) with links by tag in the sidebar. The main part of the page could be split with two tabs at the top that differentiate between traditional annotations and then bookmarks. At some point it may be useful to have a read/unread data toggle to allow users to differentiate between the two to give themselves a dashboard of unread documents with similar views by tag. UI cues can easily be had by looking at extant platform examples like Pocket, Instapaper, and Pinboard, though simple and clean UIs may be more valuable to Hypothesis versus the more visual UIs of these others, particularly given that the academic market that Hypothesis services isn't as visual-oriented.

Some of this is reminiscent to me of services like Zotero or Mendeley, though these tend to have the reference data at their heart with some of these additional functionalities of bookmarking, read/unread, and notes/annotations bolted on as also-ran ideas. The piece that really draws me back to Hypothesis over these others, is that it has the reading, annotating, and interacting at its heart and doesn't worry about the reference portion which is really the add-on or after-the-fact functionality that is easy enough when it comes to ultimately publishing much further down the line. In some sense, these customized products are starting at the end and building to the beginning of the workflow while Hypothesis covers the majority of the middle incredibly well.

Within this general framework, being able to bookmark documents that I'd like to read becomes the start of the journey for the research, writing, interacting, and thinking which Hypothesis already has at its core. The real missing piece is making the social bookmarking a bit more explicit and providing some simple views for users to see what they've bookmarked (as well as views by date and tag) so they can determine what they need to read and work on next.