SPAWS Use Case: “Paradata for Widgets should be shared across Widget Stores”

JISC asked for use cases before funding the recent round of rapid innovation projects – here’s the one I created for “Sharing Paradata Across Widget Stores”:

Context and Rationale: A Widget Store is a site that allows users to search for widgets ( aka “apps”, “widgets” and “gadgets”) to embed in an application such as a VLE or portal, install on a mobile device, or download and run on the desktop. Several Widget Stores are currently being developed tailored towards education. These include a UK HE Widget store at the Open University, the ROLE Widget Store managed by IMC, and the ITEC Widget Store operated by European Schoolnet. While each of these stores is being developed using common standards and a common codebase, they are operated independently by different organisations, and customized for a particular audience. One limitation of this approach is that paradata – reviews by users, ratings and ‘likes’, and aggregate download statistics – is collected separately by each store. Sharing this paradata between stores will add value for users of all the stores.

User Stories:

“As a widget store user, when I browse a widget store, I want to be able to read reviews by other users, irrespective of which store they downloaded it from”

“As a widget store owner, I want to be able to rank widget popularity based on downloads from other sites”

“As a widget developer, I want all the reviews and download stats to be available to users, irrespective of which widget store they are using”

Changes Required: As well as maintaining an internal model for reviews, ratings and aggregate download statistics, each widget store must also periodically synchronize this information with other stores. Stores also need to make it clear to users that their feedback will be shared with other stores, for example in the store Terms and Conditions, and/or as part of the submission of a new review. This requires a standard model for expressing the paradata used by the widget stores.

Success Criteria: If successfully implemented, the case can be tested using the following test scripts.

Test A: Reviews

  1. Browse a widget store
  2. Download a widget
  3. Submit a review of the widget in the widget store
  4. Search for the same widget on a different widget store
  5. The description page for the widget should contain the review submitted to the other widget store

Test B: Popularity

  1.  Identify a widget with a reasonable number of downloads (i.e. scoring highly on popularity rankings) on one store, but which has not been submitted to another.
  2. Submit the widget to another store.
  3.  Once the widget has been accepted, browse its category by popularity
  4. The widget should have a popularity ranking based on aggregate downloads from the other store, rather than set to zero.
About these ads
This entry was posted in usecase, widgets and tagged , . Bookmark the permalink.

2 Responses to SPAWS Use Case: “Paradata for Widgets should be shared across Widget Stores”

  1. Pingback: SPAWS: Sharing a comment between stores | Scott's Workblog

  2. Pingback: SPAWS: What have we made? | Scott's Workblog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s