The folks at BlinkList are doing a survey with 2 easy questions. 1) What bookmarks managers do you use and 2) What's the most important feature missing, that would make your Social Bookmarking Engine a lot more useful for You?

Go take the survey and if you give your email address, they'll forward you the results.

For the past several months in my group at Lucent we've been testing out a system developed to be a simple self-service publishing application. You might recognize the interface. It follows the model other social bookmarking services have made common.

Identifying the needs

The idea to take the concept of social bookmarking and turn it into more than just a bookmark saving service came as the result of several different types of requests we've gotten in the past. One type of request was for a way to clip or save articles found on our site digital library site. We aggregate a wide variety of diverse sources. The most relevant databases include vendor news (e.g. feeds from Factiva for newspapaers and journals) and internal databases (e.g. internal news publications, technical documents repository).

A second and more urgent request we got was to provide a way for users to save articles found on our site and publish them on portlets within the corporate portal. Portlets are small windows of html content that act like little building blocks or modules in a portal page.

Several things we had done in the past helped us to add on to or evolve our existing database system and develop a new and separate system that would handle these specific bookmarking needs. We had already RSS-ified our databases, providing very complete feeds of our data as XML and partial feeds (bibliographic data) of our data as RSS. Prior to that, the primary method for doing something with database results was to set up an email or web-based alert. But the new set of requirements dealt with two issues:

• Tagging of individual records
• Re-use of records off site

Social bookmarking to the rescue

So I began developing the concept for using the social bookmarking model we've been seeing on sites like del.icio.us and furl. The first requirement was to provide a means for flagging records. The second was to provide a way to re-use that data elsewhere.

Our first releases did pretty much everything that del.icio.us does. We provided a bookmarklet/favelet for saving, tagging and commenting on a web page. The default view for bookmarks showed all users tagged bookmark entries, and you could navigate to view all bookmarks under a single tag, the bookmarks of one user, etc.

The screenshots below show the bookmarks main page and the pop-up window for saving/modifying a bookmark.

The application was shaping up to be pretty decent, utilizing all of the commonplace features on social bookmarking sites. We integrated the XML and RSS feed feature that we already used on our other databases. Feeds are available for any view the application can generate, e.g. Michael's bookmarks, Michael's bookmarks on tag "searchengines", All users bookmarks, All users bookmarks on "searchengines".

Self service publishing

Now the reason I thought we could try to use this model for self-service portal publishing is the free-tagging model. The idea was to allow individuals or groups to start bookmarking articles from our News databases, e.g. any of the Factiva sources such as newspaper and magazine articles. They could use a common tag, e.g. Mobility-Portal-Hot-News, for instance. Then they could get an aggregation of all of the articles saved with that tag and somehow display them in a portlet. Of course, controlled vocabularies would have worked as well, but the free-tagging model allows them to define the use. The portlet idea is just one applicable use. There are others we could thinkg of including ad-hoc reporting.

Feeds and exporting

This was shaping up to be a pretty decent way to do self-service publishing, but the obstacle of knowing what to do with RSS stood in the way. The concept of a feed is still pretty foreign to most business users. Savvy users can install RSS readers, but re-using that content on web sites would be time consuming. The next step was to provide a means for doing this more simply.

We first provided an HTML output along with RSS, thinking that portlets could display this content as HTML, but that necessitated using iframes. The second idea I came up with was to use JavaScript to put the bookmark entries in a JS feed with the latest entries stored in an array. Then portal owners could insert a JavaScript in a portlet that referenced the JS feed and the recent entries would be displayed on the site as HTML. If you're familiar with how Google Adsense ads work, you know how simple this is.

The screenshots below show the process of preparing scripts for display on a portlet:

As always with the type of evolutionary design we do where I work, these proofs of concept helped drive the design of other functionalities we could think of. One of the nice things about working in-house somewhere is that you can continue to improve applications over time.

A common request we've gotten in the past was to provide a way to create reports for things. We commonly do output of some data for Excel, for instance. For this tool, it made sense to provide a way to generate bibliographies of bookmarks. So I began creating a tool to tranform the data into APA-style bibliographies at first, with plans to also provide RTF export of bookmark lists.

Controlling the sprawl

The set of steps we took up until now took each function and divided them into atoms or pieces of functionality that we added to our existing systems. I'm very interested in the organic approach to solving the problems. The programmer I tend to work with likes to work this way. I document the needs and the concept for the application, he makes the prototype and we evolve it together. It's actually a pretty nice approach, and we have the freedom and flexibility to do things this way.

All of these features make the system servicable, but as we conceived of different functionalities to add, it became clear that this system was becoming more and more complex from a user perspective and could do with some simplification. I liken this to getting control of a garden that has become overgrown. At some point all of those aggresive plants start dominating and stifle the smaller ones. What do we do so we can see the parts more clearly again?

At this point, I'm trying to get some traction behind removing all those little XML, RSS, HTML, and JS buttons and replacing them with one button for viewing "Export options". I'm presently trying to design the interaction and interface for this clean up.

It's been an interesting several months testing out this application. It's nice to work on such a small application that suits very narrowly defined needs. Smaller, well defined scenarios are much easier to design for than broader scenarios and rules. In the end, these small scenarios fit into the larger business rules we've established for the site and if done right, will feed back into the way we design other aspects of the site. In this instance, the self-service functionalities created for the bookmark application will be added to our other databases so that people can, for instance, create a search on a news database and generate a JavaScript to display the feed from that source on a portlet. The common example is to do a search Factiva News, for instance, on a topic like 802.11 and automatically display the links to the news items on your portal site.

This application still has a bit further to go. We're still talking about issues such as making some bookmarks private. That is possibly the last system feature we'll add. The remaining work is just refining the interface for exporting. I'm interested in seeing how other library systems are approaching the need to re-use data. Clearly enterprise information systems should be thinking about these types of issues. I'm constantly thinking of how aspects of our system can be made more useful to people throughout the company.