[Building Sakai] priority UI changes

[Charles Hedrick]

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@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

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

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Sean Keesler-2]

I agree.

It is a very rare case that a piece of work done for one class is
"reusable" for another. In fact, I can imagine some instructors being
rather disappointed when they learn that their assignments are SO
similar to another class' assignment that the student didn't have to
do ANYTHING NEW. No new learning may mean bad curriculum/program
design! It seems like selecting something from resources would be at
best an edge case under an "advanced" group of choices.

Not to say that students wouldn't build on past work to create
derivative works, but that speaks to content authoring, versioning and
features that are not at all part of Sakai 2. If students are creating
derivative works, it is going to happen outside of Sakai.



Sean Keesler
130 Academy Street
Manlius, New York 13104 USA
315-663-7756
sean.keesler@...



On Fri, Oct 23, 2009 at 10:08 AM, Charles Hedrick <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. 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@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"
>

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[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@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"
  

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[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@...> 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@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
> with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"