Next steps for the new site

We’re now beginning work on the new version of the Science Blogging Aggregated site.

We’d like to have a working prototype of the site ready for the ScienceOnline conference in January.

Realistically, by then we’ll probably be able to implement the following features:

  • Users login and register blogs
  • Some sort of administrative check-off on registration, with anti-spam measures
  • Aggregator compiles entries from registered blogs, displays on home page
  • No tagging of individual posts, but blogs are categorized by user-specified “themes”
  • Visitors can filter posts appearing on home page by theme

We may also add a language filter allowing users to specify their preferred languages. (This may be difficult to implement because it would require having curators in each language we support) Over the long term, we would like a multi-lingual interface, so all users can experience the site fully in their native language.

We are leaning towards a dense, information-rich layout for the home page, much like the existing home page, but with additional tools for users to filter posts, login, register, and so on.

In order to maximize the site’s utility, we are thinking about pre-populating the database. This would probably be a manual process, based on the existing feeds for ScienceBlogging.org. This would require an additional feature so that users could “claim” their blog and personalize their account. However, we’re not sure that’s doable by the January deadline. If readers can suggest models for how claiming a blog could work, with a minimum of fuss, we’d appreciate suggestions.

We are also considering a a new domain name for the site—we’d like it to be a truly notable name, one that’s memorable, says something about the site, and isn’t easily confused with some of the other science sites currently out there.

So here’s our plan for the next steps. We’ll keep you up to date as we continue to work on the project:

  1. Develop a schema for a database that can handle the trimmed-down version of the site that we’re planning for January, but is flexible enough to meet our long-term goals
  2. Arrange for site hosting. We can work on our existing personal server space for now but we’ll need a permanent home, and the sooner we find it the better.
  3. Wireframe the first (limited-feature) version of the site: Create a template that developers can use to build the system, indicating what information will go on each page. Again, we may want to do this in anticipation of the higher-functionality site to come, so we don’t have to constantly reinvent the wheel.
  4. Explore the process of creating a non-profit organization. This may be a larger non-profit that also includes ScienceOnline.
  5. Create a schedule for the process of developing the site up through the conference.
  6. Recruit additional help. We’re really short on programmers and designers. Any volunteers?

An outline for version 2.0 of the site

A few weeks ago I wrote up a tentative outline for the next generation of Science Blogging Aggregated. I’ve been sharing bits and pieces of it with you over the past week, but now I’d like to share the whole thing. It’s still a work in progress, a Google Doc that reflects our current thinking on the project—but of course, something that will continue to be refined as we move forward with the project.

Click here to view the document.

I’ve already tried to incorporate as many as possible comments from readers as I’ve shared the plans with you, but of course we continue to be open to additional suggestions. I think this is enough for us to use to get started, but there’s obviously much work still to be done. If you’d like to help out, you can either email us directly at contact@scienceblogging.org, or add a comment below and we’ll get in touch with you via the (hidden) email link you provide in the comment form. Particularly useful at this stage are people with CSS / web design experience, developers, and sysadmins.

We’re hoping to present a working prototype of the site at Science Online 2011. I’ve suggested a session on the conference wiki here.

We’ll continue to keep you posted and ask for your advice and suggestions as work progresses.

Tagging strategies

Dave’s earlier posts sparked some good conversation about tagging. Here is my proposal for how tagging could work on the new version of the site. This proposal isn’t necessarily what we will do; I’m putting it out there to get feedback from the community about whether it’s the right approach.

First, an overview. There are two ways to approach tagging:

  • Folksonomy: all the users use their own tagging schemes. There are tools to let users discover tags already in use.
  • Ontology: the owners of the site describe exactly what tags people can use, and expect people to use them.

Our goals are also twofold:

  • To help  readers of science blogs more easily find the content they are looking for, and
  • To do so without imposing constraints on the authors of science blogs

I believe that folksonomies are the best solution to the above dilemma: they impose no constraints on authors; and, if things are done right, hopefully many of the tags will start to come together. My suspicion is that if we specified a strict list of tags, users would not want to use them.

But how to make the folksonomy chaos into something useful? We will maintain adatabase of tags. Each tag’s entry in the database will have (at a minimum — this can be expanded later):

  • Name of tag (e.g., “tamarin”)
  • List of synonymous tags (“Saguinus”, maybe “tamarind” if we want to support common mistakes)
  • List of children tags (“cotton top tamarind”, “cotton top”, “Saguinus oedipus”, etc — may be very long)
  • List of parent tags (“New World monkeys” — may be multiple)

Bloggers may tag with any of the synonymous tags. Let’s say we do decide to support mistakes. Someone may tag “tamarin” or “tamarind”. Those are different tags, but our system understands that they are synonymous.

Someone searches for “tamarin.” They get a list of posts tagged with either “tamarin” or any of the synonymous tags (so “tamarind” or “Saguinus”).

So what are some problems which might arise?

What if one tag is used for two entirely separate things?

A physics blogger uses “charm” to describe a kind of quark. An anthropologist uses “charm” to describe something used medicinally by a tribe of primitive people. A user searching for “charm” will get both.

I submit that this isn’t a huge problem. It isn’t going to happen all that often. When it does, in almost all cases, the user will be able to refine their search to say “I am only interested in ‘charm’ tags used on blogs with a ‘physics’ theme.” It will be annoying to the people who want to see what the parent/children tags are for “charm,” because they’ll get a weird mix of physics and anthropology subjects. But I think it is not going to happen often enough to really be annoying (and it is better than the alternative of trying too hard to control things).

Sounds like a lot of work to input parent/children/synonym relationships!

Yes. We will have to start with no relationships at all — just a big flat list of tags. Eventually, each subject area will have one or more curators who help manage it. Part of their jobs may be to input relationships for tags in their areas. We will have to make a user interface to make this very easy. Perhaps we will build a user interface to allow users to suggest the addition of new relationships, as well.

The point is that we can do this very gradually. The system will start working immediately, and then be improved with time.

What about brand new tags (“pepsi-gate” vs “pepsigate”)? How can curators possibly keep up with that?

In that case, I believe that the crowd will start to converge, if a) we provide incentives to use the same tags — “if you use the most popular tags, your post will be more discoverable and you’ll get more readers” — and b) we make it very easy for bloggers to find out what the relevant tags are.

Of course, we will provide a list of available tags, organized for readability once we have parent/child relationships. Additionally, we will need a tool to provide tagging suggestions to bloggers while they are writing blog posts. Again, that can be something to do a little ways down the road.

We can also provide a page on the site which offers lists of the currently most popular tags, maybe even the most popular new tags. If it’s clear to someone that they are about to browse “pepsigate” posts, then if they want to write a followup, they are likely to remember that that’s the tag they are responding to, and tag their post appropriately.

Won’t this list of tags become so long that any tool which auto-suggests tags to users will become too slow to use?

This problem can be at least partly alleviated by letting users specify that they are only interested in tag suggestions from particular categories. Once parent/child relationships are in place in the tag database, tag suggestions can be filtered that way. We can also learn from other tools that offer auto-complete over large spaces to see how they solve this problem.

Have folksonomies been successfully used in the past? What are good examples?

Obviously, Flickr is the best example of a site which has completely user-generated tagging. Their mission is somewhat different from ours, though! Do you have examples of folksonomies that work or that have failed?

This post is intended to start discussion, so please, weigh in! What do you think about this approach to handling the huge number and variety of tags in use on science blogs? Is it clear, and do you have questions?