The second release of nexus went live today (build 127). It included the top features from our prioritized list published yesterday. This enabled the next use case from our first prioritized list of use cases – searching the articles. We also took this opportunity to refactor part of the user interface – adding pagination of articles and search results, and reworking the presentation of the article content based on user feedback.
In this article we look at the content of the third alpha release of nexus.
Alpha Beta
Alpha and Beta have become part of the web 2.0 lexicon for releases. The way many sites use the terms, it seems that alpha means “incomplete” while beta means “complete but needs work.” We’re taking a similar approach here. We know we are releasing incrementally increasing functionality. The early releases are driving usage and feedback. The insights we gain as we’re building also allow us to prioritize what people want as we go. When we think the functionality is sufficiently complete, we’ll move to beta status. I don’t expect to be in beta for long. With a website, I believe it is completely reasonable to continue adding functionality after a site goes live (post-beta). I think beta is a good label for “improve performance, enhance experience, validate existing value” activities. Since we’ll be doing that all along during the alpha releases, that should be a short cycle.
This begs the question – why not just call it a beta now? Because we don’t want to set the expectation that things are remotely complete at this point. There’s a lot of things people will be able to do with nexus that aren’t implemented yet.
De-prioritizing Support for a Use Case
In our initial prioritization of use cases listed broadcasting of nexus content as a high priority for the second release. This is an important behavior for Paul the Product Manager, one of our personas. We still believe broadcasting is important to Paul. However, we believe the cost of making it easier for him is not justified.
Paul can easily send an email, instant message, twitter tweat, jaiku update, cocktail napkin, blog post, or other message to people about an article at nexus. All he has to do is cut and paste the URL for that article. Ideally, he will cut and paste the nexus URL, encouraging people to rate the article and join our community. Or he may just find the article on nexus, and send the link to the original article. That won’t directly help us, but it will still help him achieve his goals.
Anything we do to facilitate this communication for Paul will at best take the same amount of effort for him, and most likely take more effort (and constrain his means of communication). And for marginal gain on our part. And there’s no way to assure that Paul will use our embedded implementation – he may still just cut and paste. Based on the non-zero cost of implementing, and the near-zero benefit (to Paul) of implementing support for his broadcasting, we won’t be implementing that within nexus. Hopefully Paul will tell people about nexus when he tells them about the article that they should read.
Thoughts About Capabilities
With the current functionality, nexus can become what it needs to become – a repository of validated content. With the ability to submit, rate, and review articles, we can collect the needed resources. With the ability to search, browse, and filter, people can use the site to find the content they are interested in. We can refactor the interface to make this easier – but the base functionality and presentation are in place.
One very powerful idea that came up during the evolution of use cases and design approaches was the notion of creating collections of articles that can be used together to achieve a learning objective (or a teaching objective). We think this may very well be the killer feature that makes nexus the place people go to understand a topic in our niche. Many companies succeed by combining available components and bundling them together for sale – the whole is greater than the sum of the parts. This is true of ideas as well.
In effect, each bundle of articles can be the equivalent of a multi-author book, or multi-instructor training curriculum. There are some other interesting unintended uses that could arise – bundles of articles where the goal is a shoot-out between several similar treatments of the same topic. People might create bundles of articles by their favorite authors. Training curricula could be formed in a general way (Learn to do Use Cases) or for very specific circumstances (Learn how to manage risks and schedules for projects at company X).
Prioritized Goals
Based on the above, and other similar analysis, here are the goals for the third release of nexus.
- High Priority. Support for creation, editing, scoring and reviewing of bundles of articles. (Must have)
- Medium Priority. Publish an RSS feed of newly created articles to which people can subscribe. (More is better)
There are also some low-priority goals, basically tweaking the presentation layer. These will be (possibly) addressed as targets of opportunity during implementation of other goals.
Next Steps
The two things we need to do next are develop the use case(s) for bundle interactions, and work on some design ideas. If you think we should be taking a different prioritization approach, please join the discussion on this article.
