Inline Edit: changing focus cancels edit?

Jonathan Hung jonathan.hung at utoronto.ca
Fri Jul 4 14:39:56 UTC 2008


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080704/ed0a5dac/attachment.html>


More information about the fluid-work mailing list