[Building Sakai] priority UI changes

[Charles Hedrick]

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.
>