APR: Use Case Briefs

briefcase

Each of the use cases defined as part of our use case names post is described at a high level of detail here. The goal is to get a broad view of the domain for our project so that we can focus on the most important elements. This is a key step in using use cases in an agile project. We need to understand enough of the big picture in order to determine what is actually the most important. Then we will work on the more important use cases.

Pre-emptive Filtering

After reviewing the use case names, we can pre-emptively filter out several of the use cases for this stage of the analysis. If you feel that any of these should be included in the initial release, please comment in the discussion area of this article, and we will revisit.

  • The “Promote An Article” use case – where a blogger promotes their own work for review or publicity will be deferred until after the general sharing of articles has been implemented. The first version of “Suggest An Article” will serve as a means for the blogger to achieve his goals – it will just happen to be suggesting an article that the blogger has written himself. Brian won’t mind, as long as any functionality is retro-active (and that would make sense anyway, if he were to discover that someone else had promoted one of his articles before he did).
  • The “Article Mashup” use cases will also be deferred from the inital release. While we think this functionality may provide a differentiating hook and significant value, it make sense to wait. Each mashup will be a mashup of articles that have already been suggested. So we need to have articles being suggested before we can start collecting them into mashups. As of right now, this will probably be the most valuable feature to follow “article scoring” features. We’ll revisit of course – that’s just a hunch.

Use Case Briefs

Excluding those use cases that are filtered per the above. We’re using the use case brief format explained in this sample use case article. The actors are being identified in terms of the personas we identified.

Use Case Name: Browse An Area

Actors: Jill (Primary), Paul & Ellen (Secondary)

The user is exploring an area to see if there is an article that “jumps out” as being interesting. This could be an exploration of a new area – trying to get the lay of the land. It could also be simply browsing an area that the user knows well, to see if something new or interesting has been written lately. The need to “only read something really good” is reduced a little here – the mode of searching is semi-directed, idle investigation. This is the usage mode that is most likely to have people “stumble upon” an article and score it.

Question: Should the “what’s hot right now” mode of browsing be included in this use case? Think about the “watch the front page of digg.com” model – the area is our entire niche, not a section of it – but the idea is the same.

Use Case Name: Search For A Topic

Actors: Jill (Primary), Paul & Ellen (Secondary)

The user is looking for articles on a specific topic, and wants to read the best articles first (or only!). This type of searching would not neccesarily be constrained by topic area – the user may want to actively find cross-posted articles (for example an “agile” article on use cases). They key element is that the user wants to research a specific topic.

Use Case Name: Rate An Article

Actors: Jill (Primary), All (Secondary)

The user has just read an article found by browsing or searching. The user will provide a “recommendation” – should people make sure that they read this or skip it. The user will also optionally identify if they think this article is targetted at beginners or experts (is it an explanation of how parallel activities work in BPMN, or is it a discussion of how you can create deadlock conditions in a BPMN diagram?).

Question: Should rating an article require users to be logged in? Mainstream sites use this approach, which probably prevents the worst gaming of the system, in exchange for the potentially tedious step of logging in.

Question: Should users be able to “recategorize” articles if they feel like something was overlooked, or the article were incorrectly classified (e.g. had nothing to do with use cases, but was tagged “use case”)?

Use Case Name: Broadcast An Article

Actors: Paul (Primary)

The user will want to share a particular article with people who are not part of the community on the site. After optionally rating an article, the user will identify some people to email the article to. Those people are probably coworkers or former colleagues who the user believes will benefit from reading the article.
Email was suggested as the communication method, and we’ll use the term ’email’ as a proxy for “tell non-users about an article” for now. This will be less cumbersome than jumping through hoops to avoid saying ’email.’

Thought: This capability may also be used for other “check this out” goals – we should prioritize the “you should read this” goal when defining requirements / designing this functionality. Other goals may be identified in the future.

Use Case Name: Comment On An Article

Actors: Paul (Primary), All (Secondary)

The user will optionally add a comment or notation to an article after rating it. Comments are great qualitative feedback to help other users decide between articles that they find as part of searching or browsing – but it is “second order” feedback that helps someone refine their search. The “first order” feedback is created via the “Rate An Article” use case.

Thought: A secondary use of this capability could be to ask questions or develop a conversation around an article (eg “This Worked for Us” or “Had anyone actually done this?” Not all articles are published such that their authors encourage on-site conversations like this. Having this facility will help users, and possibly authors.

Thought: Requiring someone to have rated an article prior to commenting will help with spam.

Use Case Name: Suggest An Article

Actors: Paul (Primary), All (Secondary)

Thought: Brian is almost a primary user of this use case, given the filtering of Brian’s use case from the initial release. He would be treated as a supplementary persona for this use case – using functionality designed for Paul without modification.

The user has discovered a great article for our niche and wants to include it in the site for others to read and review. The user will add the article to the site and optionally rate it. The user may also specify the tags/categories for which the article applies, and may classify the article as being for beginners or experts.
Version 1: The first version of this use case will require the user to be logged into the site, and enter the URL of the article directly into a form on the page.

Version 2: The second version of this use case may allow users to use a widget (like stumbleupon, or other widgets created for other sites like digg and delicious) to suggest an article with less interruption to their other browsing.

Version 3: A third version of this use case may allow users to unobtrusively leverage other external activities to automate all or part of the submission process. For example, automatically submitting any del.icio.us articles with a specific tag, or allowing a blogger to “trackback” to the site and initiate a suggestion.

Question: Should users be forced to rate an article when submitting it?

Summary

This overview paints the domain of our project (as defined in the scope and vision article) with a broad brush. It allows us to take the next step of prioritizing the use cases.

9 thoughts on “APR: Use Case Briefs

  1. Some thoughts on commenting & rating of articles:

    I’m not sure it is in your best interest to require a person to rate an article before commenting. For some people, there is a level of stress associating with ‘grading’ an article. They may feel more comfortable leaving a qualitative comment rather than a rating. If you require someone rate an article first, they may not bother with the commenting, and the site looses a potentially valuable contribution. Alternatively – you could look at some softer kinds of rating systems like ability to flag an article as ‘tried this and it worked’ or ‘tried this and it didn’t work’ or something like that.

    To ensure you still have a way to figure out which are the ‘best’ articles if you don’t require rating, you could use a combination of statistics.
    For example – how many times the article was read, how many comments, how many ratings (good or bad). I probably would want to read an article that had alot of comments associated with it – even if the comments were negative or mixed, because obviously there is something to be learned (an idea to stay away from for example) if alot of people felt inspired to comment on it.

    Finally (sorry for the long ramble) are users rating the article .. or the topic of the Article ? If the article is on some agile development technique, are users rating the article poorly because the article is poorly written and doesn’t help you to understand how to use the technique or because they think the technique itself is a bad idea. Perhaps it doesn’t matter – but maybe something to think about.

  2. Hey Chloe, thanks again for helping with the evolution of the ideas for the project!

    Great point about not requiring people to rate before commenting. You’ve convinced me :). Also – some great suggestions about ways to rate the articles with metrics other than explicit ratings.

    I’ve also been thinking about some way to “weight” the ratings people give based on the credibility of the person making the statement about the article – for example, if people tend to make similar ratings as you, your opinion is more credible. Not sure how to do this so that it doesn’t become a group-think exercise. Will be a fun math problem. Or maybe just a presentation challenge – putting stars next to keep contributors or “thought leaders” (whatever that means).

  3. Also – I think requiring someone to be logged in to comment should take care of the spam problem. And down the road, there may even be a way to incorporate Akismet (the spam blocker for comments on this blog) into the site.

  4. Browse an Area:
    Answer: I don’t think our niche is so dynamic or focused that I need to know about things just after they happened. I can live without a “what’s hot?” feature. I suggest that an 1-click way for individual users to use links to what they need most frequently (“favorites”).

    Search for a Topic:
    This also concerns the “kind” of article, like “overview”, “10 most helpful hints” or “impact of A on B”. If I was new to a topic, I’d probably start with some overviewish articles.

    Rate an Article:
    On recategorization: Maybe we have another persona here, Eddy the Editor. He corrects spelling errors, merges synonym categories, and cares about under-categorized articles.
    Thought: what happens with changed links or delete articles?

    Comment on an Article:
    Thought: “Was this comment useful?” helps with sorting the comments for display.

    Suggest An Article:
    On forcing the users to rate: maybe yes, in order reach a critical mass of idicators for relevance, what would support finding useful articles.

  5. Sorry if this comment appears several times, I have problems posting it.

    Browse an Area:
    Answer: I don’t think our niche is so dynamic or focused that I need to know about things just after they happened. I can live without a “what’s hot?” feature. I suggest that an 1-click way for individual users to use links to what they need most frequently (“favorites”).

    Search for a Topic:
    This also concerns the “kind” of article, like “overview”, “10 most helpful hints” or “impact of A on B”. If I was new to a topic, I’d probably start with some overviewish articles.

    Rate an Article:
    On recategorization: Maybe we have another persona here, Eddy the Editor. He corrects spelling errors, merges synonym categories, and cares about under-categorized articles.
    Thought: what happens with changed links or delete articles?

    Comment on an Article:
    Thought: “Was this comment useful?” helps with sorting the comments for display.

    Suggest An Article:
    On forcing the users to rate: maybe yes, in order reach a critical mass of idicators for relevance, what would support finding useful articles.

  6. Sorry about the posting problems, Rolf! Our spam-filter caught you. I “de-spammed” both of your comments so that it will learn, and not happen in the future.

    For anyone else who sees a comment “dissappear” after submitting it – PLEASE send me an email when this happens. Your comment may have gone into the moderation queue (might be spam), which I will definitely find. Or it may have gone into Akismet’s spam-bucket, along with a couple hundred spam-comments per day. I WILL NOT FIND IT in that mess if you don’t let me know.

  7. In reply to Rolf’s suggestions…

    On favorites – very cool. I imagine a “my rated articles” page for users. This will serve as the first “favorites” page, and will encourage people to rate articles. Will evolve as it grows (and as people’s lists grow).

    Good points about searching. I think that is the mandatory first thing to implement, and the mashups will improve the “learn something new” use case.

    I like Eddie The Editor. Basically the guy who gets a per-article feed from wikipedia on his topic of expertise and polices the article for errors. He’s definitely a guy we want here! The question is, is he a guy we will actually have here? I don’t know if we should include him as “wishful thinking.”

    Also – great point about “dead links.” I think that will be an nth-order problem to resolve relative to other functionality, but thanks for putting it on the stack.

    Rating the reviews/comments does seem to have a lot of support :) It will definitely happen – maybe not in the first release

  8. I think Eddy the Editor will come to life as a reincarnation of you, Scott :-D
    Seriously maybe there have to be a couple of blokes who do clean-up. Time will tell, I wouldn’t include Eddy as of now.

Leave a Reply

Your email address will not be published. Required fields are marked *