Forums 2.7 UMich Scorecard
Intro
With the impending mothballing of the core Discussion tool, UM took a look at the Forums tool. After a fairly exhaustive review and several pilot uses the UM design/user support team found that the tool itself met the requirements in an online discussion tool, but that several surface changes to the interface would benefit the users and drew a set of recommended changes.
All of these changes involved editing the interface layer files only (jsp, jsf, js, css). In a few instances the underlying java code was affected, but always in the service of an UI change.
The work was carried out in a branch (SAK-13736) and now we are asking that this be merged back into trunk. This is an anomalous situation in that it is not new functionality (sensu strictu), a new tool, etc. Several of the scorecard lines are unchanged from what one will find in the trunk (or 2.6) version of Forums, for example. The scope of this scorecard is restricted to the changes done under SAK-13736.
UM decided to do without the point system in the scorecard, adopting a +, - , ? scale where ? represents a doubt about the scorecard item or that the item value is still under discussion.
Scorecard
See also Scorecard Item Definitions
No. |
Scorecard Item |
Score |
Comments |
|
---|---|---|---|---|
1.0 |
User Experience |
|
|
|
1.1 |
Consistency / Best practices |
+ |
All Sakai standards have been followed for the UI work (which was 100% of the work). There is some deviance where needed, as the functionality demanded it. |
|
1.2 |
Usability |
+ |
The changes were actually intended to address the usability of the tool. See both FORUMS:changes requested by Michigan, the changes FORUMS:requested by Indiana and the detailed issue list. A FORUMS:second round of changes were requested after team become more familiar with the use conditions. |
|
1.3 |
Accessibility |
+ |
The accessibility checklist was applied to the tool and the necessary modifications were made. The only remaining issues are related to the JSF limitations, primarily as they relate to the use of tables for layout and establishing a relationship between components (inputs and labels for example). These are unchanged from what you will see in trunk. |
|
1.4 |
Internationalization |
+ |
N/A - Internationalization/localization were not affected by the work. Any new strings or edits to old strings are being served from the language bundle as expected. Equivalents for these new or edited items in other languages are not supplied. This is traditionally done by a separate language specific team before string freeze. |
|
1.5 |
Ease of use |
+ |
There has been no radical changes to the UI - that is, the workflows have not been altered. The work addressed only the rough edges of the tool, making the interface clearer and more presentable. |
|
1.6 |
User testing |
? |
There has not been any formal user testing. The design changes proposed by UM (and amended by IU and UCT) were discussed with user support and design team members beforehand , there was two design critique iterations, one involving IU, and the tool has been running at Michigan for a year with minimal number of requests for help from users or bug reports. TODO: Formal user testing. |
|
2.0 |
Technical |
|
|
|
2.1 |
Browser support |
+ |
Supports all browsers in the Sakai recommended browser list. |
|
2.2 |
Code review |
? |
The only changes that would remorely qualify as "code" would be the increased use of javascript to provide functionality. TODO: These will be reviewed. |
|
2.3 |
Unit testing |
+ |
No change from trunk in this respect |
|
2.4 |
Functional regression testing |
+ |
The SAK-13736 branch was exhaustively tested at Michigan |
|
2.5 |
Integration testing |
? |
|
|
2.6 |
Performance testing |
+ |
There has been no change to anything that would affect server performance. |
|
2.7 |
Internationalization |
+ |
See above |
|
2.8 |
Licensing |
+ |
The only new elements that are licensed are one javascript library that has Sakai-compatible licensing. |
|
2.9 |
Outstanding JIRA bugs |
+ |
See SAK-13736 |
|
2.10 |
Packaging (code structure) |
+ |
No change from trunk |
|
2.11 |
Static code review |
? |
TODO: run PMD, findbugs on changed code. |
|
2.12 |
Validation/spec conformance |
? |
TODO: Javascript can be validated with jLint |
|
2.13 |
DB support |
+ |
No change from trunk |
|
2.14 |
DB best practices |
+ |
No change from trunk |
|
2.15 |
Security review |
+ |
No change from trunk |
|
2.16 |
Technical |
+ |
No change from trunk |
|
2.17 |
Event tracking |
+ |
No change from trunk |
|
3.0 |
Descriptive |
|
|
|
3.1 |
Bundled Help |
? |
No change from trunk. TODO: check if bundled help strings are at variance with new strings used in the branch version of Forums. UM commits to update bundled help if this is necessary |
|
3.2 |
Test plan |
+ |
See Test plan grid for main work and for second iteration |
|
3.3 |
Javadocs |
+ |
No change from trunk |
|
3.4 |
Design Documentation |
+ |
||
3.5 |
Wiki/website |
- |
TODO |
|
3.6 |
Deployment doc |
+ |
No change from trunk |
|
3.7 |
End user external docs. |
? |
No change from trunk. TODO: check if bundled help strings or are at variance with new strings used in the branch version of Forums. If existing user documentation has screens that are at variance with new screens UM commits to update user docs if this is necessary |
|
3.8 |
Issue Tracking (Jira) |
+ |
||
3.9 |
Events documented |
+ |
No change from trunk |
|
3.10 |
Licensing Documented |
? |
TODO: how? where? |
|
3.11 |
Configuration |
+ |
No change from trunk |
|
4.0 |
Community Support |
|
|
|
4.1 |
Team size |
+ |
The entire UM Sakai team. |
|
4.2 |
Team diversity |
+ |
One developer, one UI mechanic, one project manager, one user experience person, one technical writer specifically involved. |
|
4.3 |
Responsiveness |
|
The team has responded rapidly to partners (UCT and IU). UMich is committed to fixing bugs in these changes for the next 2 years. |
|
4.4 |
Production experience |
+ |
Yes. General production experience good, Forums branch has been running for a year at UMich. [FORUMS:Where has it be running?] |
|
4.5 |
Communications and openness. |
+ |
The team involved has tried to be very communicative and forthcoming. |