Part 1: Functional Description

---

Forums Interface Enhancement

Summary

 This enhancement involves providing some final polish to the user interface of the Forums tool. It does not involve changing the workflows substantially. This entails bringing the interface closer to the Sakai norm, adding new UI idioms where the application needs them. It will also involve validating the produced markup and doing an accessibility check. Some minor UI-only functionality will be added to address some identified pain points.

Rationale

The Forums tool will be a good candidate for some schools to replace the old Discussions tool that is being phased out. The feature list is fairly complete and it has been tested repeatedly and used extensively - all that remained was some UI TLC.

Origin

A team at UMich reviewed the tool during Fall 08 and made a set of recommended changes. There were a few iterations of these recomendations as we became more familiar with the tool. Review was conducted by Sean Demonner, Diana Perpich. The later also brought to bear her experiences as a trainer working to familiarize users with the tool. Others from user support such as Jeff Ziegler provided input based on their knowledge of the common pain points experienced by users.

User Stories

(Aside: there is little "functional" change in this enhancement. The user was able to do all the things detailed below in the version in trunk and in 2.6. The enhancement targets making these tasks easier/more natural/pleasant). 

A user will better understand the hierarchical nature of the information in the tool (Forums/Topics/Theads/Messages/Replies)

A user will be better able to tell at a glance what the attributes of each part of the hierarchy are.  Are specific Forums or Topics moderated, locked, is there any recent activity, is there an instructor edit to a response that was denied, etc.

A user will be better able to tell at a glance what has changed in the context since the last visit - what new messages have been posted, approved, denied, graded, need approval or denial, and do so in the context not via some external (to the context) view.

A user will be better able to take an action with full awareness  of the context - for example, to delete a Forum or a Topic, click on a "Delete" link next to it, instead of having to edit it and then selecting "Delete" as one of the possible form actions in the edit screen.

 A user will be better able to  scan lists and find specific information based on any of the attributes of the searched for item (title, date, read/unread, pending status, author, etc.)

 A user will be able to navigate a long list by jumping from one message of a type (pending, denied, new) to the next message of the same type as a way of performing a given task (catching up, moderating) with full awareness of context.

Diagrams and Mockups

See the suggested new screensand a comparison between the stock and the new UI

Community Acceptance

These set of changes have been discussed by members of University of Capetown, Indiana University, Stanford and the University of Michigan. The discussion has taken place via email and as comments to the umbrella JIRA ticket. Enhancements have been adopted in three of these institutions.

Quality Metrics

Given that this was not a new feature or a total rewrite of an old one, and that there was little "functional" change this is going to be a bit hard to provide.  UM is committed to provide some metrics on the benefits of this work.

Assumptions

The main assumption was that the work carried out in the branch would be merged into trunk for Sakai 2.6.x or failing that Sakai 2.7 - Indiana, the owner of this specific tool gave assent to this. UMich and partners believe it to be of considerable benefit. UMich is very interested in not having a branch to maintain, and happy to stand by the work and contribute to the maintenance for these changes for 2 years.