This is a draft in progress.

Discussion about feedback and what components might emerge.

Feedback Definition

Feedback is information that tells a user the result of an action taken. To be meaningful and effective, it must be immediate, readily visible, and comprehensible to the user.


When a user takes an action, she needs immediate and clear evidence of its result. Sakai in particular often fails to provide this feedback. For example, a user in the Resources Tool may click on a folder low on a page and expect to see its contents. The contents are displayed, but not necessarily shown to the user, since the page reloads from the top, hiding anything "below the fold." Many actions do not provide "success" messages.

A slow process, such as a large file upload, should let the user know that something is happening and if possible should let her know how much longer it will take. When an error occurs, the user should see a message that tells her what is happening and what she can do about it.

This shades into situations where the issue is not feedback in the strictest sense but a matter of poor orientation and multiple design issues of workflow, layout, language, etc., that leave the user unclear as to the meaning of an possible action or where to begin/what to do next. This was the "WTF?" sheet at the summit and is grouped here under feedback.


Sarah Windsor - Primary Persona
Scenarios to come.

Ed McClellan, Undergraduate
Scenarios to come.

Blue Sky Vision

Possible Components

Procedural/contextual help

Messaging and status indication in workflow:

Where is leaving tool/losing work an issue?

Best practices:

Design patterns

Summit Post-it Page

At the Fluid Summit, pain points represented on post-it notes were grouped into problem spaces (such as Feedback), then into (usually very high level) potential components such as the ones below. Each problem area was then rated as to whether it affected 1, 2, or 3/All of the Fluid applications (Sakai, uPortal, Moodle). Each potential component was then rated on the following matrix, which indicated how severe the pain point it helped solve was for users, as well as how frequently the pain point was encountered. It helped us determine how high a priority it was, with 1 being the highest priority and 3 being the lowest. Some of the components and pain points below also have indicators as to whether they related to (S)akai, (U)portal, or (M)oodle.

high severity



low severity




high frequency

low frequency

Procedural Guidance

1 / All
Also known as a "Wizard". Guiding a user through a multi-step series of interfaces to complete a task.

Empty State Orientation Helper

2A / All
Properly orient the user to a tool when it has no data (empty state). An example would be an inbox with no email.

Progress Indicator

2B / All
A status indicator for time to completion (for things like file upload).


1 / All
Display of messages to the user.

Contextual Help

1 / All
Help within the user's context.

Info Sharer

2B / All
The ability to share information entered through one tool with other tools.

RSS Aggregator

2B / All
Multiple RSS feeds displayed on a page.


1 / All
Sent notifications and the ability to manage and set preferences.

Print Preview

2B / All