Implementation continues on nexus, and we’ve re-factored the way that items in a bundle are ordered, as mentioned in our earlier post. We talk a little about affordance, and show a couple screen shots.

Drag and Drop Affordances

An affordance, to oversimplify, is an appearance of an object that causes users to intuitively know how to interact with it. We found a couple good articles on this challenge and posted them to nexus.

Drag and drop user interface elements are becoming more common on the web. The challenge is that many implementations do not make it obvious to users that the elements can be dragged and dropped. In the best case, users are missing out on powerful functionality. In the worst case, the user interface is frustratingly unusable. Here are the nexus links for the two articles we liked. Please read them, rate them, and comment on them.

• Drag and Drop Controls
• Drag ‘n Drop is Invisible to Users

Nexus Design Choices

The design decisions that we came away with from reading these articles were

1. Include a text explanation like “drag to re-order” so that people would know that it was an option.
2. Create an image that conveys the ability to drag to re-order the items.

Here are the screen shots of what we came up with for our first usable iteration on the task of re-ordering items in a bundle:

1. Two items, in order.

2. Dragging one of the items to re-order them.

3. The two items, in the new order.

The design element we created is a double-headed arrow, with some cross-bar lines that give it a tactile feel. When you drag one element past another, the second element moves into the space previously occupied by the first element. Screenshots don’t do it justice. It is really cool. Effectiveness will be determined by you – but I believe it will work.

Hope you all had a great holiday weekend (or a great weekend even if not a holiday where you are). The implementation is moving forward for the bundles. The pending release now allows me to add, delete, re-order and edit items within a given bundle. The re-ordering is not good – you have to manually change the “position” of each item. While functional, this isn’t good enough to release – so I will be refactoring this tomorrow.

Progress Update

The following items (from our previous update) have a first implementation complete:

• Each bundle is created by an individual (Paul the program manager).
• Each bundle has a subject and description (”Intro to Use Cases” and “A tutorial that is designed…”).
• Each bundle is composed of multiple items, and the items have an order (1,2,3,…).
• Each item is created by an individual.
• Bundles may allow for collaboration (multiple people submitting / editing items).
• Bundles have categories and experience levels (”Testing,…” and “Beginner”).

The following items have not yet been implemented:

• Each item can point to / represent / contain a single article, or it can be “empty”.
• Bundles can be rated and reviewed by users.
• Bundles may allow for collaboration (multiple people submitting / editing items).

How You Can Help

Bundles will demonstrate their power by providing vetted collections of articles on a single topic. You can help by starting to populate nexus with articles that you might want to combine into bundles. Or you can help by submitting articles about use cases – anything to do with use cases. The first bundle that I am going to create will be a “how to write use cases” bundle. Many of the articles that I believe I will include are articles that I’ve written over the last 18 months. I would love it if I could include other articles by other authors.

So – our team goal is to get a critical mass of articles about use cases – how to write them, how to use them, manage them, whatever. Submit some articles today. If you only submit one, that still helps a lot.

This is a quick update on the implementation progress for the third release of nexus. For this release, we are focused on the creation and consumption of bundles of articles.

Completed Work

We defined an object model for representing the bundles. Bundles can be described as follows:

• Each bundle is created by an individual (Paul the program manager).
• Each bundle has a subject and description (“Intro to Use Cases” and “A tutorial that is designed…”).
• Each bundle is composed of multiple items, and the items have an order (1,2,3,…).
• Each item is created by an individual.
• Each item has a subject and description (“Writing Use Case Names” and “Explaining how to…”).
• Each item can point to / represent / contain a single article, or it can be “empty”.
• Bundles can be rated and reviewed by users.
• Bundles may allow for collaboration (multiple people submitting / editing items).
• Bundles have categories and experience levels (“Testing,…” and “Beginner”).

Several of the implementation steps are complete:

• The database work to represent bundles and items and other relationships (ratings, etc).
• The initial bundle-creation UI elements are complete.
• Sorting and filtering of bundles is working (same as with articles).

In Design

One thing that has jumped out in each design sketch of a user interface is that people will need to search for articles to add to the bundle, while still thinking about the bundle. There are three ways we’re exploring to make this happen.

1. Embed an “article search” screen within the “bundle creation” screen.
2. Embed some “add to bundle” widget(s) within the existing article navigation screens.
3. Create a view that displays both bundle-creation and article-exploration interfaces at the same time.

I’m personally leaning towards the #2 approach. I think that cognitively, people will put the “bundle thoughts” on hold during the “where’s that article on X” sub-task. So leveraging the existing article-exploration setup will not only be fastest to implement, but possibly the most effective.

The “Items” notion above is an interesting one – it essentially exposes an implementation artifact. We need to be able to say that an article should be in position 3 for bundle A, and position 5 for bundle B. We also want to have placeholders for “missing articles” in someone’s series or concept. And within a bundle, someone may describe the articles differently (in context) than the descriptions of the articles (out of context). So the “item” is basically a wrapper and a placeholder. It will be a design challenge to hide the item objects, while exposing the capabilities (ordering of articles, contextual descriptions, placeholders).

In Progress

The implementation of the bundle creation and editing interface/forms is currently underway. The barebones “create a bundle” UI is done. And a prototype for editing “in place” has shown some promise. In-place editing allows you to change the value(s) of a given field without navigating away from your current view to an “edit form.” Rails makes this super easy for text fields. But not for the selection and multi-select fields we also use to specify experience level and categories. I’ve learned enough to know that this is possible to do, and will take (me) a lot of time to learn how to do.

Tomorrow morning, I will explore a way to achieve a similar goal (make changes without losing context) with a different approach. Tomorrow afternoon I’ll be immersed in Pirates of the Caribbean 3 with half-a-dozen mutinous middle-schoolers. And we get to see it on a DLP digital projection system at the local theater! Aarggh! So have a great weekend!

Let us know if you have any thoughts about the design approaches and decisions that have been built on the use cases.

Yesterday, we identified the high priority goal for the third release of nexus to be supporting creation of bundles of articles. In this article, we will define the use cases we need to support.

Defining The Use Cases

The first step in defining the use cases is to review the scope and vision for the product. Once we’re sure we’re operating within the scope, we review the goals of our personas, and then we define the use case names. The next iteration of the use cases is in the form of use case briefs. And finally informal use cases. This agile approach to use case definition seems like a lot of work, but the mechanics don’t take very long – most of the time is actually productive time spent thinking about the use cases. And the effort of writing a few things down introduces some implicit refactoring and editing. An analysis of the stakeholders at this stage will help identify any missing use cases – it helped us identify a missing one, as we’ll see below.

Scope and Vision Analysis

We reviewed the scope and vision yesterday as part of defining the goal for the release. The goal of bundles is to leverage the effect that the whole is greater than the sum of the parts to leverage articles from nexus to create valuable meta-artifacts that combine articles into cohesive collections, designed to achieve particular objectives. At a sound-bite level, people combine articles into bundles, and people will consume the collections of articles found in a bundle.

Persona Goals

We initially focused on Paul the product manager’s goal of sharing ideas, and started sketching out some design concepts based on how Paul might want to create his bundles. Those sketches helped keep us on target as we moved forward on use cases. From a classical requirements definition perspective, they were a bit of a segue. From an interaction design perspective, they were important embodiments of the ideas.

We actually missed a persona goal, until we did a quick stakeholder analysis. Until we reviewed the stakeholders, we completely forgot about consumption of the bundles – we had focused only on their creation.

All of our personas would be consumers of the bundles, with the possible exception of Brian the blogger, who is focused more on getting information out to others than pulling information in. Brian may be a bundle creator – he probably already creates summary-posts on his blog that collect multiple articles together. He can use bundles as a secondary means to organize his articles, or to combine his thoughts with others.

Use Case Names

The use case names we initially defined for the bundle-creators are

• Create a Bundle of Articles.
• Update a Bundle of Articles.

After reviewing the needs of other stakeholders, we added

• Study a Bundle of Articles.

Considering both the consumption and creation of bundles will definitely affect how we design the interactions and the implementation.

Use Case Briefs

Create a Bundle of Articles (Paul the product manager is the primary user, Jill the business analyst is secondary)
Paul defines the topic and a brief explanation of the goal of the bundle (to teach a new product manager how to write use cases). Paul creates an outline of the topics to cover in the bundle, organizing his thoughts and the topics. Paul then begins inserting existing nexus articles into the bundle at each point in the outline. Alternately, Paul may need to submit some articles to nexus in order to include them in the bundles.

Update a Bundle of Articles (Paul the product manager is the primary user, Jill is secondary)

Paul returns to an existing bundle, and adds new articles to it. Alternately, Jill adds an article to a bundle that she is studying to “complete” it from her perspective.
This raises an interesting question – should people collaborate on bundles? Or should it be single-author? I’m leaning towards collaboration, or an implementation that allows people to control it (e.g. make a bundle “open” for anyone to edit, or closed).

Study a Bundle of Articles (Jill and Ellen are primary, Paul is secondary)

Jill browses the available bundles in a particular topic area, and finds one that looks interesting. The bundle is a tutorial on how to write use cases for a project. She starts by reading the first articles, leaves nexus, and returns later. On each visit to the site she gradually reads the articles, occasionally rating the articles and providing feedback on them. Jill also provides feedback about ways to improve the bundle.

This use case would be greatly facilitated if there were a way to manually or automatically track which articles Jill has already read.

Stakeholder Analysis

Stakeholder analysis is important because it identifies who cares about a particular feature or functionality. It can be very effective for finding missing use cases – usually because of a focus on the indirect users of a product. For example, an accountant may generate reports with a product, which are then delivered to a regional manager. Although the regional manager does not use the software, her needs must be addressed when generating the report.

In the analysis of bundles, we initially overlooked the consumption of bundles. This was immediately obvious when we started to think through how they would be used. We went back and added the Study a Bundle use case. We also uncovered the possibility of a consumer becoming a collaborator on a bundle.

Summary

This analysis of use cases presents us with the inputs we need for designing the interactions, and defining the specifications for the bundles. The “under the hood” implementation will probably be very straightforward, while the user interface work will be more significant.

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.

1. High Priority. Support for creation, editing, scoring and reviewing of bundles of articles. (Must have)
2. 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.

The next build of nexus starts today as our agile project continues. Let us know what stuff you think is most important for this release, as part of our prioritization.

Already Scheduled Work

We already know that we’re going to focus on a couple items for this release of nexus. These items represent, as Roger put it in recent comments, areas of highest risk. Our interpretation – risk is the risk that the site won’t gain critical mass and become the valuable tool that it can be.

• Searching Articles. This is one of the previously identified use cases – also previously targeted for the second release.
• Pagination of Articles. While not a requirement per se, we are introducing this refactoring of the design as the most significant usability concern that has arisen. There are currently only 18 articles on nexus – and when you view an unfiltered list of the articles, you see all 18. When this list is 50 or 100 items strong – which should be this week – pagination will have a significant impact on usability and adoption. So this is on the top of our list for refactoring.

As an interesting aside – these are both technically challenging activities too – so they also represent two of the higher technical risks.

Other Possibilities

Here’s a quick list of other items, not in priority order, that we may work on this week. We will look at prioritization of them as early as later today – and as late as the completion of pagination and a first version of search.

• Broadcasting an Article – notifying someone who isn’t a registered nexus user about an article.
• Creating a Mashup – allowing users to create collections of articles that can be used for organizing ideas that span articles.
• Suggestion of Articles – provide article suggestions based upon the scores that you and others have given to articles on the site.
• Allowing article deletion/moderation – give moderators the ability to suppress articles that don’t contribute to the community.
• Allowing review suppression – give registered users the ability to suppress reviews that detract from the experience for people.
• Present a feedback form / suggestion box – allow users to make suggestions about how to improve the site.
• Enforce article uniqueness by URL – prevent duplicate submissions.
• Create an about-page for nexus – explaining the purpose of the site beyond the snippet in the sidebar.
• Create help documents – explaining how to accomplish goals with nexus.
• Create a subscription service – allow people to subscribe to notifications when articles are submitted to nexus.
• Allow users to edit their info – change password, email address, other data.
• Refactor the presentation of articles – time-box 2 hours for a redesign / treatment of presentation.

Your Suggestions

And any suggestions that y’all want to make at this time. Maybe some of the ideas above either inspired you to suggest new ideas. Maybe you have thoughts about the approach to implementing any of the above. Please share them in the discussion on this article. If you feel strongly about any of the above – either for inclusion or exclusion (or delay) – please share that input in the discussion below. And remember, you can subscribe to the comments for individual articles – so do that if you want to track this discussion as it unfolds. We’ll take all of the inputs into account when prioritizing these efforts for the current release.

Rolf presented a valid critique and some questions on our previous article announcing the launch of nexus. I started writing a long response, and realized it would work well as an article for analysis of our process over the last month. Here it is.

Rolf’s Critique and Questions

Here’s the critique/question part of Rolf’s comment:

However, allow me to comment on the agile project experiment (no offense intended !).
For me, in an agile project there’s no room for “Bonus Features -
a couple other things implemented early while we were there”. I’d like to see us come back to the original idea of prioritization (which can mean a change of priorities with the help of the users).

All new ideas or things we stumble upon should undergo the same persona/usecase/priorities analysis as the original ideas did. Otherwise this project leans over to hacking. (However, I respect your dictator role, Scott.) This should be done for the purpose of the experiment reader’s (and my) education and their chance of gaining insight. I know that it is easier to skip these things, but that is not what we are preaching in agile/lean product development classes/articles/books.

On the other hand, can the “change of plan” be interpreted as an experience with agile projects? Can we deduct that it is more important to have a strong product manager than to have a clear process for transforming ideas into products? (or even further, that projects should be created so, that a product manager can implement his own vision ;-)
This would be very interesting knowledge I gain from the experiment.

I’d love to know what YOU are thinking about the project’s process. Why did we deviate?

Hey Rolf, first – thanks for the help on the project, I’m looking forward to more as we go. Second – thanks for the spot-on critique of the “bonus features.”

It is definitely not agile. Can I plead temporary insanity? I cite as evidence the “ideas” section in the previous article. That is definitely the right way to do it from an agile standpoint – throw ideas into the prioritization mix. I would also add that there is an element of dictatorial product management in the mix. We can walk through each of the bonus features and see what we think…

Here’s how I would categorize the ‘bonus features’ above:

• Faceted navigation & URLs – an interaction design-driven part of the implementation approach. I would contend that this is orthogonal to the prioritization process. This is getting good ideas at a lower level, into implementation. I think this was wholly appropriate and not subverting the process. Maybe it feels clunky trying to mix it into the other discussions, but I didn’t view it as “implement and refactor without reprioritization.” I felt that the ‘out of the box’ routing (/nexus/article/show/12) was sophomoric, and the implementation of the first version of page navigation (specifically for browsing) required some form of IA implementation and solution in order to create the nav-bars. So this was the first proposed solution for browsing – just with user feedback.
• Having reviews in the first public release. I would say that this was just bad form on my part. A sign of weak project management. The product manager (me) knew it was important – it was scheduled for the second release. The developer (me) knew it was relatively easy – what I had just learned as part of implementing article-submission made it easy to extend to reviews. The project manager (me) was still busy freaking out about the risk of XSS attacks and was distracted by the demands from the President (me) that the site not go live until acceptable security measures were in place. The developer (me again) and product manager (me) snuck it into the first release. We occasionally show disdain for me in this way.
• Rating a Review – I put this in the dictatorial product manager bucket. I felt that it was important (as part of allowing comment/reviews) to the notion of credibility and trust, that we have this feature. Especially since to make it happen required 30 minutes of learning/refactoring the existing rating implementation to apply it to reviews as well as articles.
• User Page – hmm. Don’t really know if I can sneak this in as design or dictatorship. Just seemed like the right thing to do. Wasn’t in any of the mockups either – just appeared during development.
• Calculating a User Score – OK, so this one is definitely a violation of prioritization. And it probably took a couple hours to figure out and implement. I did get some feedback offline on the design and approach, but will it demonstrate value – maybe. No way to describe this one as anything other than “not following process.” Slapping myself on the wrist now.

Drawing Conclusions

Getting back to Rolf’s question – “Can we deduct that it is more important to have a strong product manager than to have a clear process for transforming ideas into products?”

I think people trump process any day. But a good process makes people better. So process is worth pursuing. I have a struggle on this project, wearing dev/design/product&project management hats. Plus I have the dictator-card. And blogging about the project as we go, while really useful info for learning, is also a form of inappropriate, low level marketing announcements. We’re essentially broadcasting very prematurely, about every move we make and when we’ll make it. So this study is a bit polluted. By watching the process, we modify the process. Good thing this isn’t a quantum mechanics experiment.

I think design inputs are valid elements of the implementation (faceted navigation as an implementation choice for browsing). I think a process that prevents convenient low-hanging fruit (rating the quality of reviews) is a bad process.

Also, I think we made a mistake in including reviews in the first release without re-prioritizing first. In my defense, the security-thing threw me for a bit of a loop, and reviews were not part of the very-first release (which was shared with the Austin on Rails developers). I probably should have just addressed security and released without reviews. As a developer, I needed some occasional breaks and accomplishments to make the days of reading about XSS and SQL-injection solutions more fun. And that’s what I ended up doing. Probably shouldn’t have.

We did get some good user feedback about reviews being more important than numerical ratings for some people. So it was easy to “cheat.” I think the dictator philosophy is actually a good one – listen to your customers – absolutely. But that doesn’t mean you do exactly what they say. You do what they need, to the best of your ability, which is highly aligned with what they say – but not exactly the same thing.

What Do You Think?

What should we do differently next week as part of building out the next release? Our plan is to start with prioritization of pending / new ideas.

The alpha release of our site/product developed as an open agile project has just gone live!

http://tynerblain.com/nexus/ is the home page. More stats and updates below.

Time To Market

We started the project exactly one month ago today. We defined a vision and scope, target users, use cases, constraints, UI designs and implementation designs. We also created tests at a specification level (user login ID must be unique, etc). We designed a logo and worked on information architecture.

We learned Ruby on Rails (learned enough to launch, anyway – much more to learn) along the way, and had to get some help with setting up our deployment environment. Now, updates to the site can be pushed to the server with a single command-line.

We spent somewhere between 160 and 200 man-hours on this release, across all the different areas, with I believe, the following rough breakout of time:

• 1/3 requirements
• 1/6 design
• 1/2 learning
• 1/6 implementation (and most of that in writing tests)

Kevin Rose mentioned that the first version of digg was built by one guy in two weeks – after giving him a spec. I think we stayed competitive with that, especially given the time spent learning the language. Digg was built in php by someone who knew php already.

Delivered Capabilities

What can you do with nexus today? We defined the priorities for the first release on April 25th as follows:

1. Browse An Area (Jill & Paul + Ellen). First. Done
2. Suggest An Article [Version 1] (Paul & All). First. Done
3. Rate An Article (Jill & All). First. Done
4. Search For A Topic (Jill & Paul + Ellen). Second.
5. Broadcast An Article (Paul). Second.
6. Comment On An Article (Paul & All). Second. Done

After getting some great feedback, we recognized that commenting (aka reviewing) an article was also important – possibly more important than numerical ratings. When we discovered the security issues that we needed to address, that bought us some time – it delayed the initial release while we learned and implemented protection. During that time, we added in the ability to do reviews.

Some Bonus Features

We also implemented a couple other things “early” while we were there.

• The ability to rate a review – is it fair, accurate, misleading?
• The ability to view “my articles” – all of the articles you submitted are available on the “Your Page” page.
• Friendly URLs – part of this came out of our IA exploration.
• A first attempt at “scoring” the quality and content that each user contributes. The scores reflect how many articles you submit and reviews you write. More importantly, they are driven primarily by the ratings that your articles and reviews receive.
• Faceted navigation is in place too – allowing people to use different browsing approaches.

What’s Next for Nexus?

I’m about to leave for the airport – my mom is visiting for the weekend, so we won’t really make any progress tomorrow. Once we get started again, we’ll finish up the features for the second release (searching and emailing). Emailing will be tricky – we have to prevent spammers from using the site to bombard people with emails. Searching may be easy, but we have stuff to learn first.

We also have some “catchup testing” to write – there is a tool that provides code-coverage analysis, which we need to install and apply. So next week will be primarily working on those two features, adding testing, and refactoring.

Ideas

I’ve had a couple ideas this week.

Rolf submitted an article that is in German. I want to see if there’s an easy way to leverage Google’s translation tools to automatically translate the articles (if desired) into the current user’s language of choice, when the user leaves nexus to visit those articles.

I’ve also been thinking about “books” as peers to “articles” – I want to explore that more, but I still believe it is secondary to at least the already-prioritized features.

I think it might be handy to generate an RSS feed from nexus, so that people can keep track of when new articles are submitted – both overall, and by category/experience.

I need to see how to make Ruby on Rails perform scheduled tasks (like backing up the database, tracking statistics, etc). I want to be able to monitor how the site grows over time. I think it also might be interesting to share that data publicly. For now, there are some counters in the sidebar that provide real-time data, but no history.

What Can You Do?

Sign up, and start submitting, rating, and reviewing articles. We have to collectively make a push to get enough content (and feedback on content) into the site to make it a useful, then compelling, then necessary resource for people.

Thanks to everyone who has helped so far, and especially to everyone who helps push us to get valuable content up asap.

In our previous article in the series on the development of nexus, we discussed navigation and information architecture. We identified the challenge of filtering articles by category and by level of experience (beginner / expert), while also viewing the articles along a characteristic (most-viewed, highest-rated, etc). Between both url-creation and visible site-navigation, the challenge we explored was how to present one facet or dimension as primary and others as secondary.

One of our readers presented a third alternative – faceted navigation.

Scott Weisbrod commented:

Have you considered using faceted navigation? Faceted navigation means that level of expertise, category of article, and chosen approach can all live at the same level.

Therefore, as a user, I can pick the facet by which I want to begin navigating the site. For some, level of expertise is the most sensible place to start. Others will want to begin their search by category or even chosen approach.

Why not surface all of them and let your users pick the most appropriate starting place?

He also suggested looking at The Guardian’s search page. You get the idea by interacting with the controls in the sidebar – we’ll try and explain here with a static image, but go check it out.

The left sidebar shows a list of “active filters” (initially empty), and as you click to “add search filters” you narrow down the choices. Amazon.com also uses this approach, for narrowing by product category, price range, supplier, etc. While it may encourage an element of precedence, it allows users to filter choices in whatever sequence they desire. This is very cool presentation (in the two-dimensional sense).

When we started exploring our approaches, we were also concerned about how the URL looks, both for providing context to users and for sharing with others. Unlike the Guardian, this is the main navigation for our site – not just an admittedly cool way to do browse/search. If we look at a URL from their site, with facets selected, we see http://browse.guardian.co.uk/search/all/Politics/Labour+party? month=07&lDim=N%3D4294962719%2B4294962540%2B4294963588%2B3098 &year=2002&N=4294962719+4294962540. Not a very pretty picture [ed: spaces added to line-wrap the URL].  It exposes the implementation (looks like an OLAP cube database to me).  More importantly, it would confuse anyone trying to read it, and might even dissuade them from clicking on the link if it were shared in an email.

Nexus Implementation

Luckily for us, we did three things today. First, we decided that we agreed with Bob, at least enough to include the experience level dimension in our initial implementation (it added less than an hour of work). Second, we took an implementation approach that would actually support this faceted navigation presentation. Third, while we implemented it with a hierarchical presentation, we stuck to the Ruby on Rails convention of separating the presentation from the implementation.

This affords us the opportunity to refactor the presentation to look more “faceted” and less hierarchical.

Here’s what the navigation elements in the latest version in source control look like:

The top bar is clearly a hierarchical parent. It establishes context (articles or users, or your own page, etc). It also shows a “categories first” navigation bar. However, that navigation doesn’t “reset” the other choices.

If you’re looking at beginner product management articles, organized by their ratings, and you click on “Business Analysis” – you will see business analysis articles, for beginners, organized by highest rating. In effect, we have a faceted navigation implementation under the hood. We just presented it hierarchically. Note that we also agreed with Bob, and put experience level filtering “above” the organizational sorting (most read, etc) of the articles.

We critiqued The Guardian‘s URL structure. We should look at ours. The URL for an example above would be http://tynerblain.com/nexus/business_analysis/beginner/highest_rated/. Incredibly easy to know exactly what to expect before clicking on that link. We can also extend this approach in a couple ways – we can add more skill levels or categories, we can add more sorting options (highest rated reviews, etc), and we can add subcategories (like testing:test-automation). We won’t add any subcategories until we have enough articles to warrant it. I think we can even add sub-categories selectively (have them for testing, but not business analysis, for example).

Design Conclusion

I am happy with the under-the-hood design, for both being extensible enough for likely future needs, and being adaptable enough to work with either a hierarchical or faceted presentation.

In order to get the alpha release launched as soon as possible, we will keep the “hierarchical-looking, faceted navigation” in place for the first limited release.

How You Can Help

In order to really get a feel for the effectiveness of the navigation, we have to have some critical mass of articles on the site – I would think at least 100. Please spend a few minutes to queue up some great articles to be reviewed – and when we release the alpha, submit those articles. Every page will include an “article count” in the sidebar – and when we get to 100, start evaluating the navigation and let us know how it works for you.

Thanks in advance!

We have an interesting information architecture challenge as part of our agile project. We have talked about browsing and searching articles organized both by category (product management, business analysis, etc) and by level of expertise (beginner, expert). We’re also rating and reviewing the articles, which introduces the ideas of “latest”, “most reviewed”, “highest rated”, etc.

This presents us with a three-dimensional way to approach structuring the information and navigation of the site.

Two Areas of Focus

There are two things we need to address as part of helping people find the articles that they are interested. Searching, which can bypass this structure, is not in scope for the next release of nexus – as we are focusing first on the browsing use case.

The most important element to focus on is the site navigation. A lesser, but also important element is URL structure. There are benefits to having consistent and clean URLs that represent the different pages of nexus. Site navigation is a two-dimensional problem (we have two dimensions within the screen real-estate). URL-creation is a one-dimensional problem – each URL (web-page address) is linear, or even serial. Since URL structure is more constraining, we are tackling this first.

What Does Browsing Look Like?

We’re focusing on URL structure, as it relates to browsing. How does that perspective apply?

A “good” URL will tell us something about the page. For example: http://tynerblain.com/nexus/testing/highest_rated/beginner/ could represent the list of the highest rated articles about testing, written for beginners. This approach to URL structure has benefits in that it provides context for users (who can look at a URL and see where they are), makes it easier to share or save a page, and does a good job of setting expectations.
http://tynerblain.com/nexus/?topic=testing&view=highest_rated&expertise=beginner would provide the same benefits – but it is clunky for people to read, harder to share, and far less memorable. It also forces the implementation on the users. Users should not care if “highest rated” is a view, or a sort, or whatever. There are also search-engine benefits to using the clean URL structure. And luckily, it is actually easy to use the clean structure when working with Ruby on Rails.

When browsing, we have three dimensions:

• Level of expertise (beginner, expert, both/either/neither)
• Category of article (Product Management, Business Analysis, Project Management, Testing, Agile Development, Interaction Design)
• A Chosen approach (view the highest rated, most recent, most rated, most reviewed, or most viewed articles)

Good design approaches will survive changes to this as well (new categories, etc).

Which Comes First?

We can ignore the URL-formatting for a minute, and just think about which sequence makes the most sense. Here are some examples:

• beginner -> testing -> most_reviewed
• testing -> beginner -> most_reviewed
• most_reviewed -> testing -> beginner
• most_reviewed -> beginner -> testing
• beginner -> most_reviewed -> testing
• testing -> most_reviewed -> beginner

I believe that the beginner/expert dimension is the least important of the three. I also think that the category “filter” is the dominant element when users are browsing, and the “let me slice it this way” dimension of ‘chosen approach’ is subordinate. I would expect a person researching testing articles, for example, to look at both the “highest rated” and the “most reviewed” views within a single browsing session. I think it is less common that someone would be viewing “highest rated” articles and change category to category as part of the same exercise.

So, we’re going to start out with category->approach->expertise as the winning information structure for URLs.

Consistency Matters

Once we establish a hierarchy of category->approach->expertise in our URL structure, we need to make sure that our site navigation reflects something consistent with this. Therefore, navigation elements should present category information/filtering in a dominant position, and the chosen approach (most rated, etc) as a subordinate. The expertise level should be below both of these.

In truly agile fashion, we’re implementing category->approach first, without mixing in the expertise element into either the URL structure or site navigation. We are showing it as information. When this matters more (more than whatever else is being prioritized), we will re-address it.

Thoughts?

What do you think?

We’ve come up with a name for the site we’re creating as part of our agile project. Read on to see our rationale.

nexus

The dictionary has several definitions of the word nexus. Two of which are “a connected group or series” and “center, focus.”

Vision

In our vision document, we defined the following:

Create a site that allows people in our niche to help each other find great articles, regardless of who wrote them. People will identify and evaluate (rate/review/score) articles on their merits. People will also categorize (taxonomy/folksonomy) the articles to make it easier for others to find documents that they are looking for at that time. When a person is searching in our space for an article, it is either as a beginner or an expert (on that subtopic). This site should help people filter to look for articles appropriate for the type of search they are doing at that time.

We want to focus on sharing and reputation, while incorporating elements of identity, conversations, and relationships. We do not want to focus features on groups or presence.

Nexus is a great name for realizing that vision.

Naming

Naming is a tricky thing. Roger Cauvin writes about it regularly (and recently). There’s an interesting dichotomy that descriptive names are apparently good for business to business products, yet non-descriptive names have been successful in business to consumer products. His article links back to others he’s written on the topic, and they link back to more still. Check em out.

David Meerman Scott, of Web Ink Now, has also influenced our feelings about naming and branding, from too many articles to link to. You should just read his stuff. And go buy his new book, The New Rules of Marketing & PR. I’m looking forward to reading an advance copy next week. Thanks again David!
Nexus is a business to business consumer product. While our customers will be acquired and retained as consumers, they will be using nexus to help with their business. As non-experts in branding, we had no idea how to tackle this. We’re excited to have a name that is descriptive, while still sharing the single-word, two-syllable, unique/easy-to-remember elements of many non-descriptive names. I think we dodged a bullet with this name.

The Logo

Our logo for nexus

tries to demonstrate the characteristics of the vision:

• We (the users of the site) are the focus of the site. This is demonstrated both with the color of and the placement of the “us” inside the central hexagon.
• Nexus is intended to be the hub into which great content feeds and connects. The smaller elements represent the individuals who contribute by sharing, reviewing, rating, and writing content.
• Nexus will have a compounding effect that helps people follow threads of knowledge and explore and discover new content and new contributors. This drives the “second order” connections to the node on the bottom right.
• And the logo is cool.

Feedback Welcome

Would love any feedback that folks would like to share!

Earlier this week we iterated on our agile project to assure that we have sufficient application security to meet our user’s implicit requrements.
Read on for updates on our implementation of the security constraints, and progress on the next feature to be implemented.

Security Implementation

In our previous article defining constraints, we fundamentally established a user goal of trust. Trust that their work would not be misrepresented, and trust that their privacy would not be compromised. We’ve implemented the functionality to address these goals – at least enough for the first public releases.

Ruby on Rails promotes a model-view-controller design approach. What this means is that different parts of the code do different jobs. Views present an interface for the users. Views display information, and allow users to interact. Controllers are responsible for managing the user interaction requests. Controllers send users from one view to another, and reject or satisfy requests from users. Models encapsulate the business rules and functionality of the software. They do all the real work.

You can imagine the flow of an interaction with a Rails application as follows:

1. User browses to a URL and views a page (View).
2. The application selectively presents data, and selectively exposes ways for users to interact (View).
3. User requests an action such as ‘write a review of an article’ or ‘login’ or ‘show me all the articles that I’ve rated’ (View).
4. The application rejects or attempts to satisfy the user’s request (Model).
5. The application (Model) will provide the service/data/etc to satisfy the user’s request to the controller (Controller).
6. The application (Controller) will forward the response from the model to the appropriate view for display (View).
7. The application (View) will render the results of the user request for the user (User).

I mention this flow because this architecture encourages a deep security security model.

All interactions with models (by convention) happen either from controllers, or from other models (classes). Controllers, in theory, handle requests from views. Views are the gateway to our application. Consider the requirement that a user can only view her own email address. We could satisfy that requirement just by checking to see if the current user (the person at the keyboard) is the user who’s information is being displayed. This constraint is necessary but not sufficient.

We can’t truly validate that all external interactions with controllers come through views. Software can be written to impersonate an actual user, in order to interact with a website in undesired ways. So if we only implemented view-level security, we would still have a bug.

Controllers can also be protected, so that they always reject unauthorized requests. This way, even requests that don’t come in from one of our views will be protected. This is essentially protection against unanticipated (but reasonable to expect) interactions with the outside world.

We can’t add a constraint that a model only “do the work” if the current_user is authorized. Models don’t know anything about views, so they have to rely on the controllers to only ask for something when it is appropriate. If there is a better way to approach this in Rails, please let me know.

Deep Security Example

We have a requirement that anonymous users can not submit articles.

• In the view, we can determine if the user is logged in, and if so, present a link to the action that creates a new article. If the user anonymous, the link to the action is never rendered.
• In the controller, we can determine if the user is logged in, and if not, prevent the controller from creating a new article.

We’ve made several updates to the application to support this type of security around our constraints.

Next Feature for our Project

After reviewing the feedback again, we have identified the ability to write reviews of articles to be the next feature to implement.

Last night I got some great feedback from the Austin on Rails guys who helped with the deployment technology for our project. I also got a bit of an education about website security. Based on that conversation, I’m adding a new constraint to our project – that it be secure.

Security Vision And Requirements

In line with our project scope and vision, and corporate goals, we are adding a security constraint for the product. We believe that having an un-hacked site is important to meeting these goals.

Further, I believe that users impicitly require that there be a level of confidence about the information that they find on the site – even with entirely user-generated content. Here’s a list of what I believe those expectations of trust might be – would love to know any others that people feel are important.

• Users expect that their profile information can not be modified by other users.
• Users expect that anything they create (an article, review, etc) should not be modifiable by others (at least without attribution and visibility into the changes).
• Users expect that article “scores” are reflective of the individual scores. Further, I think users expect to have an understanding of how scores are computed, if not complete transparency (the score might not be a simple average).
• Users expect that their private information be secure (e.g. encrypted password if present in database, application logs, etc)

Writing Security Requirements

Honestly, I’m not really certain how you would do this in a more significant site. Perhaps writing requirements around the terms of a service level agreement (SLA) or contract. We’ll talk about that more in a second. For this project, and certainly at this stage, I believe the requirement is “be prudent to the best of your knowledge about security.” That’s not a good requirement. But it is good enough for now.

How would you make a security requirement measurable and testable? Hackers just won a $10,000 prize for hacking into a macbook pro a couple weeks ago. We have no practical way to measure the effectiveness of a security requirement. “99% of all hacking attacks must fail” makes no sense – there’s a premise of a predefined amount of hacking activity.

Writing a security specification is the only thing we really can do – we can only intentionally prevent the types of exploits we know about. And for me right now, that’s not very much. And we can take a design approach / philosophy of deep security in building the product. But “Use design approach X” is not a requirement, it is a constraint.

Addressing Implicit Requirements

We can however, address the implicit requirements listed above. And we can address them with a series of specifications and design constraints:

1. A user shall only be able to view their own private information.
2. All content attributed to a user shall be created by that user.
3. User passwords shall be encrypted whenever they are stored.

We can also address cross-site scripting (XSS), SQL-injection, and session-fixation attacks with the following:

1. External content must be scrubbed for SQL injection attacks before using it in a database query.
2. External content must be scrubbed for XSS attacks before displaying it to users.
3. New sessions must be created whenever a user logs in.

These are the attacks that I know about and know how to prevent. If anyone knows of other attacks (and defenses) that we should incorporate, please let me know via email.

What About The Prototype?

I was able to get feedback on the initial prototype from the folks last night without exposing it to attack. I’ll be incorporating the above security measures before sharing the prototype with the public at large. I hope to get that done this week.  Part of the challenge is designing tests that adequately validate the above.

Thanks very much to the rock stars who helped us out tonight. Some of these rockstars are former coworkers of mine, and I believe are all active in austinonrails.org. – next meeting is Tuesday (see the website for more details).

In alphabetical order – everyone chimed in to fix, coach and teach at one point or another.Thanks very much to…

• Damon
• David
• Mars
• Ryan
• Shad
• Steve

I hope the links send some visitors your way, and thanks again!