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.
- Embed an “article search” screen within the “bundle creation” screen.
- Embed some “add to bundle” widget(s) within the existing article navigation screens.
- 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.
