Editable fields WAS Date widget

[Andrew Petro]

Daphne,

 > Thoughts?

Nice wireframe.

In general I like the behavior of fields visually changing on rollover  
(here, white box) and a tool tip indicating click-to-edit.

So long as one can tab from one such field, editing, to another,  
jumping into edit in it, I suspect the edit pencil is extraneous  
interface noise -- certainly once I get the idiom of click-to-edit, I  
no longer enjoy that additional control to switch into a whole 'nother  
visual mode.  I wonder if it would be better to put a help widget in  
place of that pencil, and then the help popup would explain the click- 
to-edit idiom, as well as be an opportunity for richer domain specific  
help, and thereby get more goodness out of the screen real estate  
involved.

If there is to be that edit icon, then it needs to be more modal to  
indicate when one has clicked it and entered edit mode, and probably  
the way to get out of edit mode is to click it again to un-mode it.   
Possibly there should be more submit controls in edit mode --  
particularly a "Submit" and a "Cancel".  A possible advantage of a  
full edit mode is this richer edit experience of being able to abandon  
my changes.  In click-to-edit, the typical idiom is that once you  
start editing the field, you're editing it, and when you click out of  
it, those edits commit.  Often a behavior that's acceptable given the  
elegance and economy of expression of click-to-edit, but a liability  
and not always appropriate when changes are better understood as  
changesets rather than as field edits.

I've sometimes seen a "done" control appear on editing a field in  
click-to-edit, making it clearer how to make the change "commit".   
Going further with that concept, there's the "checkmark to commit or X  
to abandon" spreadsheet field editing idiom.  What if each of these  
fields, on click-to-edit, sprouted such controls, a little green  
checkmark to commit the change and a red X to abandon the change?   
More clutter, but nice to get out of a field without mangling it end  
it is clicked-to-edit accidentally.

Much of these comments go beyond the scope of the wireframes, that is,  
what happens when I do click-to-edit, beyond the rollover.  Out of  
scope.  Nonetheless, my thoughts.

Andrew

Andrew Petro
Senior Software Engineer
Unicon, Inc.


On Jan 4, 2008, at 12:23 PM, Daphne Ogle wrote:

> I sent this wireframe out yesterday but when I got it back from the  
> list the message wasn't there so let me try again.
>
> <editible fields.jpg>
> The first 3 show rollover for different types of editable fields.   
> The last is an explicit click on the edit icon.  I didn't user  
> highlighting because of the confusion it might cause with the other  
> ways we use highlighting in Sakai.
>
> Thoughts?
>
> -Daphne
>
> On Jan 4, 2008, at 2:29 AM, Raad Al-Rawi wrote:
>
>> On Jan 3, 2008, at 6:31 AM, John Norman wrote:
>>>
>>> Google Calendar works well for this situation (once you work out
>>> how it works :-) ). It displays brief date information - apparently
>>> as normal html - but when you click on the date info it becomes
>>> fully editable year, day and time. The usability challenge for me
>>> was that at first I didn't realise the date was editable. After
>>> thinking "how could Google write something so badly" for a while, I
>>> clicked on the date out of frustration and behold, the editable
>>> interface was revealed unto me. With the help of an edit icon
>>> (pencil) I would probably have got there sooner, but now I know how
>>> it works I like it.
>>
>> On 03 January 2008 at 19:10, Daphne Ogle wrote:
>>
>>> My favorite approach right now is to highlight on rollover.   This
>>> interaction could be quickly learned.  However, we currently use
>>> highlighting in other ways:  1) to show what's new, 2) row stripping
>>> to separate information.   Is rollover highlighting different enough
>>> from these other visual indicators to not confuse users?
>>
>> Does Google listen in on the sakai-dg-ui list?!?
>> I had a go with Google Calendar and I noticed that rollover  
>> highlighting is
>> implemented for event metadata that is editable (What, When, and
>> Description). It might give better indication of "editability" if  
>> it used a
>> title tooltip or displayed some text somewhere when rolling over  
>> (say,
>> "click to edit").
>> I noticed that Google don't use any alt text or title text, so they  
>> are
>> missing out on this type of UI/usability feature (not to mention  
>> better
>> accessibility).
>>
>>
>> Raad