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