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

Steve Swinsburg steve.swinsburg at gmail.com
Fri Oct 30 17:28:16 PDT 2009


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 at rutgers.edu >
>>>> Date: Thu, Oct 29, 2009 at 7:33 AM
>>>> Subject: [WG: Sakai QA] high priority UI issues
>>>> To: sakai-qa at collab.sakaiproject.org
>>>>
>>>>
>>>> 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 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"
>>
>> -- 
>> Michael Korcuska
>> Executive Director, Sakai Foundation
>> mkorcuska at sakaifoundation.org
>> phone: +1 510-859-4247 (google voice)
>> skype: mkorcuska
>>
>>
>>
>>
>
> _______________________________________________
> 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"



More information about the sakai-dev mailing list