[Building Sakai] priority UI changes

[John Leasia]

Comments below...
You also might want to look at the 'single file upload' assignment type 
- a new choice that was added (doesn't look like it made 2.6.1, so check 
trunk) that has a simplified attachment workflow when the assignment is 
for a single file upload only.

John

Charles Hedrick 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.
>
Maybe you are saying the Add Attachments should cause a popup rather 
than going to a new page, and the Continue button is superfluous, and 
after the upload you are just back to the main page. The original 
requirement however was that people wanted the ability to upload 
multiple items, possibly from different places (local system, 
resources,my other sites).

Zhen and Gonzalo are looking at some options, but in general I think 
there are some institutions whose users do know about and make use of 
their my workspaces, so if a change is  made it needs to accommodate 
various use cases. Perhaps some configuration can be built in so 
institutions can configure it to work in various ways.

> 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. 
>
Just to point out that the attachment workflow was a result of UI 
designers way back when, but  it does  seem to be the case that 
different UI designers certainly come up with different designs that 
don't always suit everyone.

>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"
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20091023/db791e91/attachment.html