Requirements (v2.0)

nmontoza edited this page May 18, 2012 · 17 revisions

Requirements (v2.0 initial release)

Requirements define the functionality we expect to appear in this release of the software. They are written as user stories in the following format: "I want to [an explanation of the functionality that is to be provided] so that [an explanation of the value created by this functionality]." This format keeps us focused on the value that each requirement provides to the end user.

Each list of stories starts with the most basic requirements for that part of Concerto 2 and then moves into more specific requirements.

Structuring Content into Feeds

  • I want to map each piece of content into one or more feeds so that I can associate messages of similar context and type together as collections.
  • I want to be able to change the title of a feed so that I can change it to better reflect its contents without having to delete and recreate the same feed.
  • I want to create private feeds that can only accept submissions of my own and from other members of my group so that I can have exclusive access to these feeds and keep them hidden from basic users within Concerto 2.
  • I want to create a feed as a child of another feed so that I can define a hierarchy of Concerto 2 feeds that gradually hold more specific subjects of content (e.g. Entertainment > Music > Concerts).

TLDR: Content mapped to one or more feeds; Field titles editable; Private feeds; Nested feeds

Adding Content

  • I want to have the capability to batch upload multiple images at a time so that I don't have to manually (and tediously) upload large collections of photos and other graphics one at a time.

Browsing Content

  • I want to be able to browse content without having to log into Concerto 2 so that I can view content without even having to create an account (i.e. as a "visitor").
  • I want to be able to view Concerto 2 content in a tabular view by default that shows a thumbnail (if applicable) and other details so that I can quickly peruse content in a manner that combines a visual element with essential CMS details.
  • I want to be able to click on any Concerto 2 content in a table view to enter an enlarged view that takes up most of the screen and also includes controls applicable to the part of the application I am viewing so that I can concentrate exclusively on this single piece of content and look at a whole string of content without ever leaving the zoomed-in view.
  • I want to be able to see any sub-feeds that are children of the current feed in the user interface so that I can quickly navigate to them from the parent feed.
  • I want to see a breadcrumb view of all feeds that are ancestors of the current feed so that I can understand how this feed fits into the overall hierarchy AND quickly jump from this feed to any other within the breadcrumb bar.

TLDR: Non-authenticated content browsing; tabular view of content plus a zoomed-in view; Breadcrumb view of feed hierarchy

Moderating Content

  • I want to approve a piece of content submitted to one of my feeds so that I can act as the gatekeeper for whether or not that content should appear within feeds for which I have moderation privileges.
  • Approve All
  • Trusted Sources
  • I want to have a grid view and table view for all content that is in my moderation queue so that I can flip between a more visual presentation and one that presents more overt details for each submission.

Viewing and Changing Screens

Modifying Screen Subscriptions

  • I want my field subscriptions to be saved to a particular template so that the same subscriptions are recalled when I switch back to a template I have previously set up.
  • In cases where I change from one screen template to another screen template with equivalent fields (i.e. fields that accept the same type of content, such as graphics), I want Concerto 2 to carry over my field settings for those equivalent fields and automatically populate my new template with the same subscription settings so that I do not have to tediously recreate the same subscriptions myself.

These previous two stories might create conflicts, so we may want to just pick one to use as our strategy when changing from one template to another and remove the other story. /brz

Users and Groups

  • I want to add one or more other existing users in my Concerto 2 instance to my group so that these other people can gain access privileges as part of the group.

Concerto Player

  • I want to be able to see content my screen has subscribed to by opening a web browser on a computer (whose MAC address I've entered in the web application) so that I can display Concerto content on any platform that supports web access.
  • I want to have an easy-to-install Linux distribution that's customized to include an easy setup wizard, screen control, and support for private feeds so that I have a simple way of deploying Concerto to many screens easily while accessing some more advanced features.
  • I want an easy setup wizard for newly deployed screens that allows me to configure them (locally via mouse/keyboard or via HTTP over my network) to connect to my Concerto installation so that I don't need to spend time taking down locations and MAC addresses for each screen I deploy.

TLDR: Basic web browser access to screen content; customized Concerto Linux distro; setup wizard for new screens

We need to establish/reaffirm the distinct roles that the client and server play with respect to displaying content. My current feeling is that it makes sense for the server to figure out the ordering of content that must be displayed by the client within a certain window of time in the future by applying the shuffle algorithm and incorporating specific overrides that need to be taken into account. Then the client can just be responsible for figuring out how to display that content correctly. But I won't claim to understand the specifics here - we should discuss together. /brz

Plugins

Plugins have the ability to augment core system functionality (such as adding new content types) and also replace core system functionality.