[Building Sakai] priority UI changes

[Silverio, Gonzalo]

Charles, all.

Please take a look at Option 2 in the pdf proposal attached to

  http://jira.sakaiproject.org/browse/SAK-17273

It may address the issue. Feedback very welcome.

Thanks.

    -Gonzalo


On 10/23/09 10:08 AM, "Charles Hedrick" <hedrick at rutgers.edu> wrote:

> Incidentally you'll see a common theme: Sakai has a tendency to use
> one level too much of dialog when dealing with attachments-like
> thiings, whether files or portfolio forms. What you'd like to see is
> on the main test or assignment or wizard a list of the current
> attachments, with an upload button that uploads new ones. The result
> would show as one more thing on the list. In contrast, Sakai tends to
> have a button "add attachment" that brings up another screen. In the
> best case that screen has a view of your resources and a button saying
> "upload." After some head-scratching most users can probably find the
> upload button, although they wonder why we made them click upload
> twice. The problem is that once having done the upload, it isn't clear
> to them that they're now one level down in menus, and need to get back
> to the main one. The worst case is where the extra screen doesn't have
> an upload button. It just shows you Resources, and you have to know to
> click "Add" in a folder, upload there, and select the uploaded item.
> By that time the user forgets what they were trying to do in the first
> place.
> 
> This is caused by a common problem: Developers think users are going
> to want to attach existing objects: files from resources or forms
> already filled out. I very much doubt that most of our users even
> realize they have a worksite. You don't want to add another level to
> all the UIs to allow use of existing files. My suggestion is to use a
> widget like the "Action" pulldown in Resources, You'd have a button
> "attach" that pulled down to "Upload file" and "Use existing file from
> Worksite." I'd like to see a common approach throughout Sakai, since
> this issue occurs all over the place. I've flagged the ones that I
> think are worst.
> 
> 
> 
> On Oct 23, 2009, at 9:45 AM, Charles Hedrick wrote:
> 
>> I realize it's late for 2.7, but there are a few areas causing us so
>> much trouble with users that I'd like to find a way to prioritize
>> them. I'm sure others might have different priorities, but mine are
>> 
>> http://jira.sakaiproject.org/browse/SAK-17273  - assignment tool
>> losing assignments; because of the way uploads are done, there's an
>> extra level of interaction that confuses users. They think they've
>> finished when they haven't. The result is faculty telling us that a
>> student reports they've submitted an assignment but Sakai has lost
>> it. We ended up building a screen that finds all attachments
>> submitted for an assignment, even if the assignment wasn't
>> submitted. This allows faculty to find the missing assignments.
>> However they would clearly prefer not to have them missing in the
>> first place.
>> 
>> http://jira.sakaiproject.org/browse/SAK-17270 - tests and quizes
>> losing submissions. This one just became clear to me yesterday,
>> after processing the Nth report from a student claiming he had
>> submitted an assessment when he hadn't. The final confirmation
>> screen is probably the wrong design. We actually asked for this.
>> Students had been doing "submit for grading" without intending it.
>> As a local patch we added a Javascript confirmation box "are you
>> sure". Stanford agreed, but turned it into a normal screen. The
>> problem is that if students don't read the screen carefully (and
>> many don't) they think the extra screen is the final submit
>> confirmation. So we have otherwise good students telling faculty
>> that the submitted something they didn't, and faculty believing that
>> Sakai is losing submissions. We have a workaround for this as well:
>> we have a way to recover all the data for assessments that weren't
>> submitted. I think the best approach is to go back to the Javascript
>> confirmation box. Students are used to confirmation boxes, and are
>> unlikely to confuse an "are you sure" popup with having finished.
>> 
>> http://jira.sakaiproject.org/browse/SAK-17271 and
>> http://jira.sakaiproject.org/browse/SAK-17270
>> .  Together these deal with the continuing complaints we get that
>> OSP is too complex to use. In 2.6 work was done on the generation of
>> portfolios to help that end. We need similar work on the data entry
>> side.
>> 
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"