Inline Edit: changing focus cancels edit?

Michael S Elledge elledge at msu.edu
Tue Jul 8 19:22:51 UTC 2008


We can do some here, as well.

Mike

Jonathan Hung wrote:
> I can foresee a instance where a user, in mid-edit, would want to read 
> back the contents of an entire inline edit field.
>  
> For example, in writing this email in gmail, I had Window Eyes repeat 
> back to me what I have written so far. Hitting ESC doesn't cancel my 
> email, instead it stops Window Eyes in mid-read.
>  
> I don't know how common this scenario is for users of AT. I think this 
> is something we should investigate during our user testing as it 
> affects both the component's accessibility and design.
>  
> What are the plans for evaluating accessibility in this iteration's 
> User Testing? We can ask Laurie McArthur here at the ATRC for some 
> help in getting testers to examine accessibility.
>  
> - Jonathan.
> ---
> Jonathan Hung / jonathan.hung at utoronto.ca 
> <mailto:jonathan.hung at utoronto.ca>
> University of Toronto - ATRC
> Tel: (416) 946-3002
>
> 2008/7/4 Eli Cochran <eli at media.berkeley.edu 
> <mailto:eli at media.berkeley.edu>>:
>
>     Since Esc would only be used in this instance when someone is
>     typing in the field it doesn't seem that it would conflict with
>     any screen reading. 
>
>     - Eli 
>
>     On Jul 4, 2008, at 4:39 PM, Jonathan Hung wrote:
>
>>     Thanks Allison for bumping this thread back up. I lost it during
>>     last week's emails. :)
>>      
>>     Mapping functionality to ESC will conflicts with many ATs out
>>     there. ESC is used in both JAWS and WindowEyes to stop the screen
>>     reader in mid-operation (like reading back a block of text).
>>      
>>     I don't recommend using ESC for the above reason.
>>     -1
>>      
>>     Is there another way of accomplishing this?
>>      
>>     - Jonathan.
>>      
>>
>>      
>>     2008/7/3 Allison Bloodworth <abloodworth at berkeley.edu
>>     <mailto:abloodworth at berkeley.edu>>:
>>
>>         Sorry about the delayed response, but I agree with Daphne. :)
>>
>>         Re: Antranig's suggestion, we may want to do some more
>>         thinking (and
>>         perhaps storyboarding) about what happens when there are explicit
>>         "Save" and "Canel" buttons and a user clicks outside the
>>         field. I will
>>         add that to our design questions for Inline edit. My initial
>>         thought
>>         is that if explicit save is there, they should have to press
>>         it to
>>         save a change. The reason the save button is there is to make
>>         sure the
>>         user indicates they definitely want the changes they have
>>         made before
>>         saving.
>>
>>         If anyone can think of a context where it would help for the
>>         action
>>         (save or cancel) which occurs when the user clicks out of the
>>         field to
>>         be configurable, definitely let us know. (Again my initial
>>         thought is
>>         that if there wasn't a need to press the button to save, they
>>         would
>>         just the use regular inline edit with no buttons.)
>>
>>         Also, I agree with Eli, +1 for <Esc> for cancel. It's sort of
>>         progressive enhancement if someone happens to know about it,
>>         and the
>>         likelihood of it hurting someone who doesn't is very low
>>         (e.g. how
>>         often do you press 'esc' when editing?).
>>
>>         Cheers,
>>         Allison
>>
>>         On Jun 25, 2008, at 11:17 AM, Eli Cochran wrote:
>>
>>         > +1 for supporting <Esc> for Cancel. It's a bit nerdy and a
>>         lot users
>>         > won't know to do it. But there is some precedent for it.
>>         >
>>         > - Eli
>>         >
>>         > On Jun 25, 2008, at 10:07 AM, antranig at caret.cam.ac.uk
>>         <mailto:antranig at caret.cam.ac.uk> wrote:
>>         >
>>         >>
>>         >> Here is my view -
>>         >>
>>         >> If there are no visible explicit controls for Save/Cancel
>>         for the
>>         >> individual
>>         >> field, focusing away from the field should commit the edit
>>         and not
>>         >> cancel it.
>>         >> If there are visible controls, it should be configurable
>>         whether
>>         >> focusing
>>         >> away leaves the field editable, or commits the edit.
>>         >>
>>         >> I think the important consideration is to not easily lose the
>>         >> user's work,
>>         >> which would be very irritating - and to support the
>>         primary and
>>         >> natural
>>         >> use of the widget which is to actually edit the text :)
>>         >>
>>         >> Hitting <enter> in a field is actually already an overloaded
>>         >> operation - users
>>         >> used to Web 1.0 expect this to cause a form submission
>>         rather than
>>         >> just a local
>>         >> commitment. Perhaps we should support <Esc> as a
>>         keyboard-driven
>>         >> cancel
>>         >> operation, or else provide a dedicated button, rather than
>>         have
>>         >> cancellation
>>         >> to be the "default function"?
>>         >>
>>         >> Cheers,
>>         >> A.
>>         >>
>>         >>
>>         >> Quoting Michelle D'Souza <michelle.dsouza at utoronto.ca
>>         <mailto:michelle.dsouza at utoronto.ca>>:
>>         >>
>>         >>> To add to the question, when should a 'cancel' happen and
>>         when
>>         >>> should
>>         >>> a 'save' happen.
>>         >>>
>>         >>> On 25-Jun-08, at 11:40 AM, Anastasia Cheetham wrote:
>>         >>>
>>         >>>>
>>         >>>> Hi, Allison and Daphne,
>>         >>>>
>>         >>>> I wanted to double-check one of the interactions on the
>>         inline
>>         >>>> editor,
>>         >>>> to make sure we've got it right.
>>         >>>>
>>         >>>> The current interaction in question is this:
>>         >>>>  The only way to save an edit is to press Enter.
>>         >>>>
>>         >>>> i.e. if you're editing a field and you move focus away
>>         from the
>>         >>>> field
>>         >>>> by pressing Tab of clicking on something else, any
>>         changes to the
>>         >>>> field are lost.
>>         >>>>
>>         >>>> You can experiment with this on
>>         >>>>
>>         >>>
>>         >>
>>         http://build.fluidproject.org/fluid/sample-code/inline-edit/announcements/announcements.html
>>         >>>> or
>>         >>>>
>>         >>>
>>         >>
>>         http://build.fluidproject.org/fluid/tests/fluid-tests/manual/inline-edit/InlineEdit.html
>>         >>>>
>>         >>>> So the question is: Is it correct that tabbing away or
>>         clicking
>>         >>>> elsewhere causes changes to be lost?
>>         >>
>>         >>
>>         >>
>>         ----------------------------------------------------------------
>>         >> This message was sent using IMP, the Internet Messaging
>>         Program.
>>         >>
>>         >> _______________________________________________
>>         >> fluid-work mailing list
>>         >> fluid-work at fluidproject.org
>>         <mailto:fluid-work at fluidproject.org>
>>         >> http://fluidproject.org/mailman/listinfo/fluid-work
>>         >
>>         > . . . . . . . . . . .  .  .   .    .      .         .      
>>                .                     .
>>         >
>>         > Eli Cochran
>>         > user interaction developer
>>         > ETS, UC Berkeley
>>         >
>>         >
>>
>>         Allison Bloodworth
>>         Senior User Interaction Designer
>>         Educational Technology Services
>>         University of California, Berkeley
>>         (415) 377-8243
>>         abloodworth at berkeley.edu <mailto:abloodworth at berkeley.edu>
>>
>>
>>
>>
>>         _______________________________________________
>>         fluid-work mailing list
>>         fluid-work at fluidproject.org <mailto:fluid-work at fluidproject.org>
>>         http://fluidproject.org/mailman/listinfo/fluid-work
>>
>>
>
>     . . . . . . . . . . .  .  .   .    .      .         .            
>      .                     .
>
>     Eli Cochran
>     user interaction developer
>     ETS, UC Berkeley
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080708/5769907d/attachment.vcf>


More information about the fluid-work mailing list