Re: [Building Sakai] [CWux] Fwd: [WG: Sakai QA] high priority UI issues

[Jacqueline Mai]

Hi Charles,

Please see my response inline below to SAK-17273.

Thanks,
Jackie

---------- Forwarded message ----------
From: Charles Hedrick < hedrick@... >
Date: Thu, Oct 29, 2009 at 7:33 AM
Subject: [WG: Sakai QA] high priority UI issues
To: sakai-qa@...


Anthony Whyte suggested that I should include this list on something I've sent to the dev list.


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

I have not seen pop-ups used in Sakai, especially as a means to ask users whether or not they want to proceed with a critical action. Seems like the convention is to present a normal page - called confirmation page - that asks the user whether they want to do X (e.g., are you sure you want to remove item X?) and the user has to decide between proceeding with the action or not. If we introduce a pop-up, which is not an expected behavior, I don’t know if you would get the result you want. Would users close the window because they didn’t expect it? I don’t know the answer to this but the pop-up solution might introduce new usability issues that are undesirable. Also, how would you address popup blockers, which would prevent critical information from being shown to users at all? Finally, if the theory is that students do not pay attention to whatever shows up after they click Submit for Grading, then it does not matter if the warning shows up as a popup or just a regular page in Sakai. They would still think that they have officially submitted their responses for grading without actually doing so.

Earlier this year, Stanford made some usability improvements to the button label and positioning within Tests & Quizzes. The navigation buttons appear to the far left (Previous/Next), then the Save/Exit/Submit for Grading buttons appear to the right. The Submit for Grading button no longer has the same position as the Save and Continue button (now called Next), which in the past has facilitated accidental submissions of an assignment before ready. This improvement has not yet made its way to Sakai (at least I’m not seeing it on sakai nightly for 2.6). Once this improvement is contributed back Sakai, one option is to remove the current warning page since users are much less likely to accidentally submit with the new placement of the Submit for Grading button. Another option is to keep the warning page as a normal page but reduce the amount of text and make the buttons more prominent - right now there's too much text on the submission warning page, which makes it more likely for users to ignore. It's also looking less like the other warning pages in Sakai, which might be another reason why it's ignored. I’m more in favor of the latter option since submission is such a critical action that it would be prudent to verify that users actually want to go through with it. I am also open to other ideas that you or anyone else might have.

_______________________________________________
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]

It's hard for me to know for sure how students will react. There  
aren't a lot of times when a student will have to confirm something in  
Sakai. I agree with you that we asked for confirmation because the  
submit button was in a place where they hit it by accident. However  
it's probably a place where confirmatino does make sense.

Assignment submission does not require confirmation.

I don't see many other places where a student would get a confirmation  
screen. However deleting a file in the workspace does. It says "Are  
you sure you want to remove the following items" and has buttons  
"Remove" and "Cancel."  I can't be sure without user testig, but I  
conjecture that the current Samigo confirmation is too wordy. I  
believe if you remove most of the other text, and say "Are you sure  
you want to submit this assessment?"  with buttons "Yes, really  
submit" and "Cancel" we might get better results. Also the remove  
confirmation screen has the most visible item large bold red Remove  
confirmation" You have that title at the top where it's slightly less  
visible and it is "assessment submission warning." I think I might say  
justt "Confirmation".

There is an issue of terminology that may also be causing trouble. The  
word "confirmation" is used both for a screen where you confirm your  
action and the final confirmation screen that gives you a unique  
confirmation number. That makes it hard for me even to discuss this  
clearly, because the only term I can come up with is "confirmation  
screen", and it applies to both of them. I don't have any obvious  
wording suggestions, but I'd call the final screen something else,  
since I think "confirmation screen" normally means "are you sure?"

However I'd still  consider a popup. We're increasingly using wha I'd  
call a popup, althought it technically isn't. See e.g. the action  
button in resources. It brings up something that I'd call a popup.  
Users browsers have to be confiigued to allow that. Furthermore, a  
popup blocks won't stop a simple Javascript confirm. I checked that  
last year before doing it.

On Oct 30, 2009, at 1:17 AM, Jacqueline M. Mai wrote:

> Hi Charles,
>
> Please see my response inline below to SAK-17273.
>
> Thanks,
> Jackie
>
> ---------- Forwarded message ----------
> From: Charles Hedrick < hedrick@... >
> Date: Thu, Oct 29, 2009 at 7:33 AM
> Subject: [WG: Sakai QA] high priority UI issues
> To: sakai-qa@...
>
>
> Anthony Whyte suggested that I should include this list on something  
> I've sent to the dev list.
>
>
> 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-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 they 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.
>
> I have not seen pop-ups used in Sakai, especially as a means to ask  
> users whether or not they want to proceed with a critical action.  
> Seems like the convention is to present a normal page - called  
> confirmation page - that asks the user whether they want to do X  
> (e.g., are you sure you want to remove item X?) and the user has to  
> decide between proceeding with the action or not. If we introduce a  
> pop-up, which is not an expected behavior, I don’t know if you would  
> get the result you want. Would users close the window because they  
> didn’t expect it? I don’t know the answer to this but the pop-up  
> solution might introduce new usability issues that are undesirable.  
> Also, how would you address popup blockers, which would prevent  
> critical information from being shown to users at all? Finally, if  
> the theory is that students do not pay attention to whatever shows  
> up after they click Submit for Grading, then it does not matter if  
> the warning shows up as a popup or just a regular page in Sakai.  
> They would still think that they have officially submitted their  
> responses for grading without actually doing so.
>
> Earlier this year, Stanford made some usability improvements to the  
> button label and positioning within Tests & Quizzes. The navigation  
> buttons appear to the far left (Previous/Next), then the Save/Exit/
> Submit for Grading buttons appear to the right. The Submit for  
> Grading button no longer has the same position as the Save and  
> Continue button (now called Next), which in the past has facilitated  
> accidental submissions of an assignment before ready. This  
> improvement has not yet made its way to Sakai (at least I’m not  
> seeing it on sakai nightly for 2.6). Once this improvement is  
> contributed back Sakai, one option is to remove the current warning  
> page since users are much less likely to accidentally submit with  
> the new placement of the Submit for Grading button. Another option  
> is to keep the warning page as a normal page but reduce the amount  
> of text and make the buttons more prominent - right now there's too  
> much text on the submission warning page, which makes it more likely  
> for users to ignore. It's also looking less like the other warning  
> pages in Sakai, which might be another reason why it's ignored. I’m  
> more in favor of the latter option since submission is such a  
> critical action that it would be prudent to verify that users  
> actually want to go through with it. I am also open to other ideas  
> that you or anyone else might have.
>

_______________________________________________
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]

Actually I think I'd say "Please confirm" just to make it as clear as  
possible.

On Oct 30, 2009, at 8:28 AM, Charles Hedrick wrote:

> Also the remove confirmation screen has the most visible item large  
> bold red Remove confirmation" You have that title at the top where  
> it's slightly less visible and it is "assessment submission  
> warning." I think I might say justt "Confirmation".

_______________________________________________
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"

[Michael Korcuska-2]

I'd argue that there are certain places where a break from consistency  
is not just allowable but exactly what is required. Specifically, if  
you hope to attract a users attention to some particularly high-stakes  
action then presenting something that visually (and/or otherwise for  
those who need/prefer non-visual cues) disrupts the expected workflow  
is advantageous.  This needs to be done selectively or it won't  
attract attention (we've reached that point with warning labels in the  
US...they are so prevalent that they are meaningless). And frequent  
users of the capability will get used to it, over time, but presumably  
by then they understand the meaning of the action.

I'm not necessarily saying that this is one of those circumstances,  
but it certainly is a candidate.

Michael

On Oct 30, 2009, at 05:28, Charles Hedrick wrote:

> It's hard for me to know for sure how students will react. There
> aren't a lot of times when a student will have to confirm something in
> Sakai. I agree with you that we asked for confirmation because the
> submit button was in a place where they hit it by accident. However
> it's probably a place where confirmatino does make sense.
>
> Assignment submission does not require confirmation.
>
> I don't see many other places where a student would get a confirmation
> screen. However deleting a file in the workspace does. It says "Are
> you sure you want to remove the following items" and has buttons
> "Remove" and "Cancel."  I can't be sure without user testig, but I
> conjecture that the current Samigo confirmation is too wordy. I
> believe if you remove most of the other text, and say "Are you sure
> you want to submit this assessment?"  with buttons "Yes, really
> submit" and "Cancel" we might get better results. Also the remove
> confirmation screen has the most visible item large bold red Remove
> confirmation" You have that title at the top where it's slightly less
> visible and it is "assessment submission warning." I think I might say
> justt "Confirmation".
>
> There is an issue of terminology that may also be causing trouble. The
> word "confirmation" is used both for a screen where you confirm your
> action and the final confirmation screen that gives you a unique
> confirmation number. That makes it hard for me even to discuss this
> clearly, because the only term I can come up with is "confirmation
> screen", and it applies to both of them. I don't have any obvious
> wording suggestions, but I'd call the final screen something else,
> since I think "confirmation screen" normally means "are you sure?"
>
> However I'd still  consider a popup. We're increasingly using wha I'd
> call a popup, althought it technically isn't. See e.g. the action
> button in resources. It brings up something that I'd call a popup.
> Users browsers have to be confiigued to allow that. Furthermore, a
> popup blocks won't stop a simple Javascript confirm. I checked that
> last year before doing it.
>
> On Oct 30, 2009, at 1:17 AM, Jacqueline M. Mai wrote:
>
>> Hi Charles,
>>
>> Please see my response inline below to SAK-17273.
>>
>> Thanks,
>> Jackie
>>
>> ---------- Forwarded message ----------
>> From: Charles Hedrick < hedrick@... >
>> Date: Thu, Oct 29, 2009 at 7:33 AM
>> Subject: [WG: Sakai QA] high priority UI issues
>> To: sakai-qa@...
>>
>>
>> Anthony Whyte suggested that I should include this list on something
>> I've sent to the dev list.
>>
>>
>> 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-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 they 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.
>>
>> I have not seen pop-ups used in Sakai, especially as a means to ask
>> users whether or not they want to proceed with a critical action.
>> Seems like the convention is to present a normal page - called
>> confirmation page - that asks the user whether they want to do X
>> (e.g., are you sure you want to remove item X?) and the user has to
>> decide between proceeding with the action or not. If we introduce a
>> pop-up, which is not an expected behavior, I don’t know if you would
>> get the result you want. Would users close the window because they
>> didn’t expect it? I don’t know the answer to this but the pop-up
>> solution might introduce new usability issues that are undesirable.
>> Also, how would you address popup blockers, which would prevent
>> critical information from being shown to users at all? Finally, if
>> the theory is that students do not pay attention to whatever shows
>> up after they click Submit for Grading, then it does not matter if
>> the warning shows up as a popup or just a regular page in Sakai.
>> They would still think that they have officially submitted their
>> responses for grading without actually doing so.
>>
>> Earlier this year, Stanford made some usability improvements to the
>> button label and positioning within Tests & Quizzes. The navigation
>> buttons appear to the far left (Previous/Next), then the Save/Exit/
>> Submit for Grading buttons appear to the right. The Submit for
>> Grading button no longer has the same position as the Save and
>> Continue button (now called Next), which in the past has facilitated
>> accidental submissions of an assignment before ready. This
>> improvement has not yet made its way to Sakai (at least I’m not
>> seeing it on sakai nightly for 2.6). Once this improvement is
>> contributed back Sakai, one option is to remove the current warning
>> page since users are much less likely to accidentally submit with
>> the new placement of the Submit for Grading button. Another option
>> is to keep the warning page as a normal page but reduce the amount
>> of text and make the buttons more prominent - right now there's too
>> much text on the submission warning page, which makes it more likely
>> for users to ignore. It's also looking less like the other warning
>> pages in Sakai, which might be another reason why it's ignored. I’m
>> more in favor of the latter option since submission is such a
>> critical action that it would be prudent to verify that users
>> actually want to go through with it. I am also open to other ideas
>> that you or anyone else might have.
>>
>
> _______________________________________________
> 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"

--
Michael Korcuska
Executive Director, Sakai Foundation
mkorcuska@...
phone: [phone] (google voice)
skype: mkorcuska




_______________________________________________
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]

My preference continues to be a Javascript alert. It's easy to do, and  
it's exactly what a user would expect. No one is going to overlook or  
misinterpret it.  However a normal sakai screen might be OK if the  
wording is updated. I generally try to avoid making web code depend up  
on Javascript. But Sakai is very far down the Javascript path by now.


On Oct 30, 2009, at 11:10 AM, Michael Korcuska wrote:

> I'd argue that there are certain places where a break from  
> consistency is not just allowable but exactly what is required.  
> Specifically, if you hope to attract a users attention to some  
> particularly high-stakes action then presenting something that  
> visually (and/or otherwise for those who need/prefer non-visual  
> cues) disrupts the expected workflow is advantageous.  This needs to  
> be done selectively or it won't attract attention (we've reached  
> that point with warning labels in the US...they are so prevalent  
> that they are meaningless). And frequent users of the capability  
> will get used to it, over time, but presumably by then they  
> understand the meaning of the action.
>
> I'm not necessarily saying that this is one of those circumstances,  
> but it certainly is a candidate.
>
> Michael
>
> On Oct 30, 2009, at 05:28, Charles Hedrick wrote:
>
>> It's hard for me to know for sure how students will react. There
>> aren't a lot of times when a student will have to confirm something  
>> in
>> Sakai. I agree with you that we asked for confirmation because the
>> submit button was in a place where they hit it by accident. However
>> it's probably a place where confirmatino does make sense.
>>
>> Assignment submission does not require confirmation.
>>
>> I don't see many other places where a student would get a  
>> confirmation
>> screen. However deleting a file in the workspace does. It says "Are
>> you sure you want to remove the following items" and has buttons
>> "Remove" and "Cancel."  I can't be sure without user testig, but I
>> conjecture that the current Samigo confirmation is too wordy. I
>> believe if you remove most of the other text, and say "Are you sure
>> you want to submit this assessment?"  with buttons "Yes, really
>> submit" and "Cancel" we might get better results. Also the remove
>> confirmation screen has the most visible item large bold red Remove
>> confirmation" You have that title at the top where it's slightly less
>> visible and it is "assessment submission warning." I think I might  
>> say
>> justt "Confirmation".
>>
>> There is an issue of terminology that may also be causing trouble.  
>> The
>> word "confirmation" is used both for a screen where you confirm your
>> action and the final confirmation screen that gives you a unique
>> confirmation number. That makes it hard for me even to discuss this
>> clearly, because the only term I can come up with is "confirmation
>> screen", and it applies to both of them. I don't have any obvious
>> wording suggestions, but I'd call the final screen something else,
>> since I think "confirmation screen" normally means "are you sure?"
>>
>> However I'd still  consider a popup. We're increasingly using wha I'd
>> call a popup, althought it technically isn't. See e.g. the action
>> button in resources. It brings up something that I'd call a popup.
>> Users browsers have to be confiigued to allow that. Furthermore, a
>> popup blocks won't stop a simple Javascript confirm. I checked that
>> last year before doing it.
>>
>> On Oct 30, 2009, at 1:17 AM, Jacqueline M. Mai wrote:
>>
>>> Hi Charles,
>>>
>>> Please see my response inline below to SAK-17273.
>>>
>>> Thanks,
>>> Jackie
>>>
>>> ---------- Forwarded message ----------
>>> From: Charles Hedrick < hedrick@... >
>>> Date: Thu, Oct 29, 2009 at 7:33 AM
>>> Subject: [WG: Sakai QA] high priority UI issues
>>> To: sakai-qa@...
>>>
>>>
>>> Anthony Whyte suggested that I should include this list on something
>>> I've sent to the dev list.
>>>
>>>
>>> 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-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 they 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.
>>>
>>> I have not seen pop-ups used in Sakai, especially as a means to ask
>>> users whether or not they want to proceed with a critical action.
>>> Seems like the convention is to present a normal page - called
>>> confirmation page - that asks the user whether they want to do X
>>> (e.g., are you sure you want to remove item X?) and the user has to
>>> decide between proceeding with the action or not. If we introduce a
>>> pop-up, which is not an expected behavior, I don’t know if you would
>>> get the result you want. Would users close the window because they
>>> didn’t expect it? I don’t know the answer to this but the pop-up
>>> solution might introduce new usability issues that are undesirable.
>>> Also, how would you address popup blockers, which would prevent
>>> critical information from being shown to users at all? Finally, if
>>> the theory is that students do not pay attention to whatever shows
>>> up after they click Submit for Grading, then it does not matter if
>>> the warning shows up as a popup or just a regular page in Sakai.
>>> They would still think that they have officially submitted their
>>> responses for grading without actually doing so.
>>>
>>> Earlier this year, Stanford made some usability improvements to the
>>> button label and positioning within Tests & Quizzes. The navigation
>>> buttons appear to the far left (Previous/Next), then the Save/Exit/
>>> Submit for Grading buttons appear to the right. The Submit for
>>> Grading button no longer has the same position as the Save and
>>> Continue button (now called Next), which in the past has facilitated
>>> accidental submissions of an assignment before ready. This
>>> improvement has not yet made its way to Sakai (at least I’m not
>>> seeing it on sakai nightly for 2.6). Once this improvement is
>>> contributed back Sakai, one option is to remove the current warning
>>> page since users are much less likely to accidentally submit with
>>> the new placement of the Submit for Grading button. Another option
>>> is to keep the warning page as a normal page but reduce the amount
>>> of text and make the buttons more prominent - right now there's too
>>> much text on the submission warning page, which makes it more likely
>>> for users to ignore. It's also looking less like the other warning
>>> pages in Sakai, which might be another reason why it's ignored. I’m
>>> more in favor of the latter option since submission is such a
>>> critical action that it would be prudent to verify that users
>>> actually want to go through with it. I am also open to other ideas
>>> that you or anyone else might have.
>>>
>>
>> _______________________________________________
>> 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"
>
> --
> Michael Korcuska
> Executive Director, Sakai Foundation
> mkorcuska@...
> phone: [phone] (google voice)
> skype: mkorcuska
>
>
>
>

_______________________________________________
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"

[Steve Swinsburg-3]

You could also try a ModalWindow which will block other input, just  
like a Javascript alert, but is more visually appealing and can can be  
styled up. Profile2 uses Modal Windows for confirmation dialogs and it  
doesn't look at all out of place with the rest of the Sakai UI.

cheers,
Steve

On 31/10/2009, at 2:16 AM, Charles Hedrick wrote:

> My preference continues to be a Javascript alert. It's easy to do,  
> and it's exactly what a user would expect. No one is going to  
> overlook or misinterpret it.  However a normal sakai screen might be  
> OK if the wording is updated. I generally try to avoid making web  
> code depend up on Javascript. But Sakai is very far down the  
> Javascript path by now.
>
>
> On Oct 30, 2009, at 11:10 AM, Michael Korcuska wrote:
>
>> I'd argue that there are certain places where a break from  
>> consistency is not just allowable but exactly what is required.  
>> Specifically, if you hope to attract a users attention to some  
>> particularly high-stakes action then presenting something that  
>> visually (and/or otherwise for those who need/prefer non-visual  
>> cues) disrupts the expected workflow is advantageous.  This needs  
>> to be done selectively or it won't attract attention (we've reached  
>> that point with warning labels in the US...they are so prevalent  
>> that they are meaningless). And frequent users of the capability  
>> will get used to it, over time, but presumably by then they  
>> understand the meaning of the action.
>>
>> I'm not necessarily saying that this is one of those circumstances,  
>> but it certainly is a candidate.
>>
>> Michael
>>
>> On Oct 30, 2009, at 05:28, Charles Hedrick wrote:
>>
>>> It's hard for me to know for sure how students will react. There
>>> aren't a lot of times when a student will have to confirm  
>>> something in
>>> Sakai. I agree with you that we asked for confirmation because the
>>> submit button was in a place where they hit it by accident. However
>>> it's probably a place where confirmatino does make sense.
>>>
>>> Assignment submission does not require confirmation.
>>>
>>> I don't see many other places where a student would get a  
>>> confirmation
>>> screen. However deleting a file in the workspace does. It says "Are
>>> you sure you want to remove the following items" and has buttons
>>> "Remove" and "Cancel."  I can't be sure without user testig, but I
>>> conjecture that the current Samigo confirmation is too wordy. I
>>> believe if you remove most of the other text, and say "Are you sure
>>> you want to submit this assessment?"  with buttons "Yes, really
>>> submit" and "Cancel" we might get better results. Also the remove
>>> confirmation screen has the most visible item large bold red Remove
>>> confirmation" You have that title at the top where it's slightly  
>>> less
>>> visible and it is "assessment submission warning." I think I might  
>>> say
>>> justt "Confirmation".
>>>
>>> There is an issue of terminology that may also be causing trouble.  
>>> The
>>> word "confirmation" is used both for a screen where you confirm your
>>> action and the final confirmation screen that gives you a unique
>>> confirmation number. That makes it hard for me even to discuss this
>>> clearly, because the only term I can come up with is "confirmation
>>> screen", and it applies to both of them. I don't have any obvious
>>> wording suggestions, but I'd call the final screen something else,
>>> since I think "confirmation screen" normally means "are you sure?"
>>>
>>> However I'd still  consider a popup. We're increasingly using wha  
>>> I'd
>>> call a popup, althought it technically isn't. See e.g. the action
>>> button in resources. It brings up something that I'd call a popup.
>>> Users browsers have to be confiigued to allow that. Furthermore, a
>>> popup blocks won't stop a simple Javascript confirm. I checked that
>>> last year before doing it.
>>>
>>> On Oct 30, 2009, at 1:17 AM, Jacqueline M. Mai wrote:
>>>
>>>> Hi Charles,
>>>>
>>>> Please see my response inline below to SAK-17273.
>>>>
>>>> Thanks,
>>>> Jackie
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Charles Hedrick < hedrick@... >
>>>> Date: Thu, Oct 29, 2009 at 7:33 AM
>>>> Subject: [WG: Sakai QA] high priority UI issues
>>>> To: sakai-qa@...
>>>>
>>>>
>>>> Anthony Whyte suggested that I should include this list on  
>>>> something
>>>> I've sent to the dev list.
>>>>
>>>>
>>>> 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-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 they 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.
>>>>
>>>> I have not seen pop-ups used in Sakai, especially as a means to ask
>>>> users whether or not they want to proceed with a critical action.
>>>> Seems like the convention is to present a normal page - called
>>>> confirmation page - that asks the user whether they want to do X
>>>> (e.g., are you sure you want to remove item X?) and the user has to
>>>> decide between proceeding with the action or not. If we introduce a
>>>> pop-up, which is not an expected behavior, I don’t know if you  
>>>> would
>>>> get the result you want. Would users close the window because they
>>>> didn’t expect it? I don’t know the answer to this but the pop-up
>>>> solution might introduce new usability issues that are undesirable.
>>>> Also, how would you address popup blockers, which would prevent
>>>> critical information from being shown to users at all? Finally, if
>>>> the theory is that students do not pay attention to whatever shows
>>>> up after they click Submit for Grading, then it does not matter if
>>>> the warning shows up as a popup or just a regular page in Sakai.
>>>> They would still think that they have officially submitted their
>>>> responses for grading without actually doing so.
>>>>
>>>> Earlier this year, Stanford made some usability improvements to the
>>>> button label and positioning within Tests & Quizzes. The navigation
>>>> buttons appear to the far left (Previous/Next), then the Save/Exit/
>>>> Submit for Grading buttons appear to the right. The Submit for
>>>> Grading button no longer has the same position as the Save and
>>>> Continue button (now called Next), which in the past has  
>>>> facilitated
>>>> accidental submissions of an assignment before ready. This
>>>> improvement has not yet made its way to Sakai (at least I’m not
>>>> seeing it on sakai nightly for 2.6). Once this improvement is
>>>> contributed back Sakai, one option is to remove the current warning
>>>> page since users are much less likely to accidentally submit with
>>>> the new placement of the Submit for Grading button. Another option
>>>> is to keep the warning page as a normal page but reduce the amount
>>>> of text and make the buttons more prominent - right now there's too
>>>> much text on the submission warning page, which makes it more  
>>>> likely
>>>> for users to ignore. It's also looking less like the other warning
>>>> pages in Sakai, which might be another reason why it's ignored. I’m
>>>> more in favor of the latter option since submission is such a
>>>> critical action that it would be prudent to verify that users
>>>> actually want to go through with it. I am also open to other ideas
>>>> that you or anyone else might have.
>>>>
>>>
>>> _______________________________________________
>>> 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"
>>
>> --
>> Michael Korcuska
>> Executive Director, Sakai Foundation
>> mkorcuska@...
>> phone: [phone] (google voice)
>> skype: mkorcuska
>>
>>
>>
>>
>
> _______________________________________________
> 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"

[Jacqueline Mai]

Hi Charles,

Sorry about my delay in responding. I've been tied up with conducting  
end user interviews for what the SAMigo user experience might look  
like in a Sakai 3.0 environment.

Is there a test/demo site or instance where I could see your  
implementation of the Javascript popup?

Thanks,
Jackie


On Oct 30, 2009, at 5:28 AM, Charles Hedrick wrote:

> It's hard for me to know for sure how students will react. There  
> aren't a lot of times when a student will have to confirm something  
> in Sakai. I agree with you that we asked for confirmation because  
> the submit button was in a place where they hit it by accident.  
> However it's probably a place where confirmatino does make sense.
>
> Assignment submission does not require confirmation.
>
> I don't see many other places where a student would get a  
> confirmation screen. However deleting a file in the workspace does.  
> It says "Are you sure you want to remove the following items" and  
> has buttons "Remove" and "Cancel."  I can't be sure without user  
> testig, but I conjecture that the current Samigo confirmation is too  
> wordy. I believe if you remove most of the other text, and say "Are  
> you sure you want to submit this assessment?"  with buttons "Yes,  
> really submit" and "Cancel" we might get better results. Also the  
> remove confirmation screen has the most visible item large bold red  
> Remove confirmation" You have that title at the top where it's  
> slightly less visible and it is "assessment submission warning." I  
> think I might say justt "Confirmation".
>
> There is an issue of terminology that may also be causing trouble.  
> The word "confirmation" is used both for a screen where you confirm  
> your action and the final confirmation screen that gives you a  
> unique confirmation number. That makes it hard for me even to  
> discuss this clearly, because the only term I can come up with is  
> "confirmation screen", and it applies to both of them. I don't have  
> any obvious wording suggestions, but I'd call the final screen  
> something else, since I think "confirmation screen" normally means  
> "are you sure?"
>
> However I'd still  consider a popup. We're increasingly using wha  
> I'd call a popup, althought it technically isn't. See e.g. the  
> action button in resources. It brings up something that I'd call a  
> popup. Users browsers have to be confiigued to allow that.  
> Furthermore, a popup blocks won't stop a simple Javascript confirm.  
> I checked that last year before doing it.
>
> On Oct 30, 2009, at 1:17 AM, Jacqueline M. Mai wrote:
>
>> Hi Charles,
>>
>> Please see my response inline below to SAK-17273.
>>
>> Thanks,
>> Jackie
>>
>> ---------- Forwarded message ----------
>> From: Charles Hedrick < hedrick@... >
>> Date: Thu, Oct 29, 2009 at 7:33 AM
>> Subject: [WG: Sakai QA] high priority UI issues
>> To: sakai-qa@...
>>
>>
>> Anthony Whyte suggested that I should include this list on  
>> something I've sent to the dev list.
>>
>>
>> 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-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 they 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.
>>
>> I have not seen pop-ups used in Sakai, especially as a means to ask  
>> users whether or not they want to proceed with a critical action.  
>> Seems like the convention is to present a normal page - called  
>> confirmation page - that asks the user whether they want to do X  
>> (e.g., are you sure you want to remove item X?) and the user has to  
>> decide between proceeding with the action or not. If we introduce a  
>> pop-up, which is not an expected behavior, I don’t know if you  
>> would get the result you want. Would users close the window because  
>> they didn’t expect it? I don’t know the answer to this but the pop-
>> up solution might introduce new usability issues that are  
>> undesirable. Also, how would you address popup blockers, which  
>> would prevent critical information from being shown to users at  
>> all? Finally, if the theory is that students do not pay attention  
>> to whatever shows up after they click Submit for Grading, then it  
>> does not matter if the warning shows up as a popup or just a  
>> regular page in Sakai. They would still think that they have  
>> officially submitted their responses for grading without actually  
>> doing so.
>>
>> Earlier this year, Stanford made some usability improvements to the  
>> button label and positioning within Tests & Quizzes. The navigation  
>> buttons appear to the far left (Previous/Next), then the Save/Exit/
>> Submit for Grading buttons appear to the right. The Submit for  
>> Grading button no longer has the same position as the Save and  
>> Continue button (now called Next), which in the past has  
>> facilitated accidental submissions of an assignment before ready.  
>> This improvement has not yet made its way to Sakai (at least I’m  
>> not seeing it on sakai nightly for 2.6). Once this improvement is  
>> contributed back Sakai, one option is to remove the current warning  
>> page since users are much less likely to accidentally submit with  
>> the new placement of the Submit for Grading button. Another option  
>> is to keep the warning page as a normal page but reduce the amount  
>> of text and make the buttons more prominent - right now there's too  
>> much text on the submission warning page, which makes it more  
>> likely for users to ignore. It's also looking less like the other  
>> warning pages in Sakai, which might be another reason why it's  
>> ignored. I’m more in favor of the latter option since submission is  
>> such a critical action that it would be prudent to verify that  
>> users actually want to go through with it. I am also open to other  
>> ideas that you or anyone else might have.
>>
>

Jacqueline Mai
User Experience Specialist
CourseWork Team, Stanford University
jamai@...



_______________________________________________
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"