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>