Inline Edit: changing focus cancels edit?

Jonathan Hung jonathan.hung at utoronto.ca
Tue Jul 8 18:59:03 UTC 2008


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
University of Toronto - ATRC
Tel: (416) 946-3002

2008/7/4 Eli Cochran <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>:
>
>> 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 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>:
>> >>
>> >>> 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
>> >> 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
>>
>>
>>
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>>
>
>
>  . . . . . . . . . . .  .  .   .    .      .         .              .
>                 .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080708/6754c131/attachment.html>


More information about the fluid-work mailing list