Honey is a co-curation tool with aspirations

I’ve been using a new co-curation tool (social intranet) tool called Honey, and so far I like what they have implemented. The product is intended for people to share links, files, and notes with others in their company. Honey is attractively designed and based on the idea of aggregating content — as captured in files, links, and notes — into topics as opposed to the traditional collaborative model of groups or projects.
Honey is similar to other tools I’ve reviewed like Mightybell (see Mightybell builds community through co-curation), Dispatch.io (see Dispatch.io is now at the center of my work flow), Refinder, and others.
Topics can be either private — meaning that they are only accessible to those invited to them — or public. And topics can be followed, meaning that a user can opt to be notified whenever new information is placed into a followed topic.
Here’s my topics:
h topics
As a soloist my patterns of using such tools is unusual: I am mostly saving things for myself. And the current design of Honey makes it difficult to share aside from the standard company model, where everyone is supposed to have symmetric access to a bunch of shared topics and related content. What I need is something quite different, about which I will write more in the Futures section, below.
Because I am using this as soloist all the posts in the landing page are from me:
h landing 2
As you can see along the top (just barely) various topics are trending, and these posts are the most popular which has little meaning with me using it alone.
Clicking on a topics leads to this view:
h topic
In this case I added an avatar for the topic, but that is not required.
I set up this account for the stoweboyd.com company, which required me to have an email in that domain. But I was subsequently able to invite others with different domains. However, these people are all treated as members of the stoweboyd.com organization, which makes sharing across companies difficult at present. For example, if someone wanted to share information with me from their Honey account, they’d have to invite me with a different email than the one I am currently using at the stoweboyd.com account.
There are three kinds of posts: links, files, and notes. Links are most simply created by using the Honey provided bookmarklet while browsing a web page. Selected text is copied into the description area, and the URL is automatically captured. The bottom two in the topic above were created in that fashion. Here’s what a link looks like:
h comments 2
The text with the gray bar is a quote: the descriptions and notes have a limited editing palette, but sufficient for general use.
Embedded files are rendered in sensible ways. Here’s a PDF:
h file pdf
This is ok for limited purposes, but I think a more sophisticated annotation capability along the lines of what Red Pen has implemented for images would be enormously helpful for PDFs (see Red Pen is the simplest and smallest design review tool I’ve seen). Word docs and other file types are rendered in a similar fashion (might be Crocodoc under there). Images can also be uploaded.
Notes are basically text posts with limited formatting, but completely usable.
h edit note
Posts can be in one of more topics, so topics are like tags in this way.
One other note about my usage. I find myself creating posts in Honey of news stories that I want to write about, and I then create a task in Asana pointing to the post in Honey:
honey asana
I can then capture the URL of the task — the Asana bookmarklet cleverly displays it — and store it in a comment on the Honey post, effectively cross-linking them. So, even those the two tools have no knowledge of each other and no formal integration, I am able to use them in sync quite easily.
There are a few problems with the model of sharing in Honey, but I had a conversation with Dan Hou, Honey’s CEO, and it seems like they are making some fairly significant changes that will solve at least some of them in the relative near term.
The biggest problem is that Honey is intended for use in a very closed company context. However, Dan told me that many Honey users are agencies or groups using freelancers, and that model has been a hindrance. They are rapidly moving to a model where I could share a topic with people in one or more other companies, where each may already have their own people, topics, and posts. This federation of work across companies is essential today.
Dan was a little less certain about the other problem I have with Honey, but he is thinking about it. Basically, I want the ability to say that some topics are totally open: they should be accessible to anyone online, just like my tweets and blog posts are. My suggestion was that he change his current two access control settings so that what they now call ‘private’ would be ‘secret’ (hidden from all but those company members invited to see it), and what they call ‘public’ would be ‘private’ (accessible to all company members). Then the term ‘public’ would be used to represent the truly public: visible to anyone on the web that  knows the URL. In essence, this third mode would be publishing a public version viewable even by people who do not have a Honey account. Perhaps they would have to sign up for a free account to make comments or to start following the topic, but otherwise it would be wide open.
I am happy to hear that the Honey team is moving to quickly enhance the sharing model of the product, because I find it a great tool for me as a soloist, and I would like to be able to share topics and posts with others without the overhead of inviting them to my account, and without the headaches involved with that generalized access. The second issue — publishing fully open topics — is more of a nice-to-have, but one that would dramatically increase the viral adoption of Honey, I think, as well as support use of the tool in a thought leadership use case.
Honey is a solid co-curation tool, moving fast to be perhaps the best by targeting today’s fast-and-loose world of work.