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 <[EMAIL PROTECTED]>: > 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, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>: > >> > >>> 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 > >> [email protected] > >> 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 > [EMAIL PROTECTED] > > > > > _______________________________________________ > fluid-work mailing list > [email protected] > http://fluidproject.org/mailman/listinfo/fluid-work >
_______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
