Designers: Re: Inline Edit - clearing the field

Tue Jun 24 13:59:10 UTC 2008

If the aim is to allow for tasks that clear fields, does that mean
there should be some sort of "delete" affordance built in?  I haven't
looked at recent mockups, but I don't recall if something like that
was there.  Going in and erasing-by-editing seems to involve an extra
step of cleverness that could be a nuisance if all you want to do is
wipe something away

Also, creating a new value where one didn't exist previously seems to
me a task rather different - I might call it "inline authoring"
instead.  The vast majority of cases, I would think, involve some
correction or revision of a value when there has either been a mistake
or a change of circumstances.

Which reminds me of some other examples where inline editing and
inline authoring are both related but distinct.  Take a look at the
creation of subtasks in JIRA, for example, or the To-Do widget in
NetVibes.  In both cases you can create a new row in a listing with a
kind of "add" mechanism which also looks and feels very similarly to
the inline editing.

Does that mean inline authoring should be part of this component, or
something different?

~Clay

On Tue, Jun 24, 2008 at 1:55 AM, Allison Bloodworth
<abloodworth at berkeley.edu> wrote:
> Hi Anastasia,
>
> As Daphne mentioned, we a bit talked about this issue in the design
> review on Friday. I'm going to put together some mock-ups with a
> message in the empty fields (in a manner similar to what Eli suggests)
> for the contexts where this makes sense (e.g. where there aren't going
> to be a ton of blank fields on a page--something we'll give advice
> about in the design pattern), but assume whether or not this text
> appears will be configurable by the designer/developer.
>
> I agree with you (and Eli) that there should be a min-width on empty
> fields so that the yellow background shows up on rollover. I'll
> specify this in the story cards.
>
> One other point we were discussing was the fact that when someone
> tries to clear a field that did have a value but *cannot* be empty,
> the user should receive some sort of error message (and the original
> data should probably be saved if the user doesn't enter anything new).
> This (Error Handling) is something that we plan to create storyboards
> for in a future iteration. If it's something you need soon, let us
> know and we'll move that task up in priority.
>
> Cheers,
> Allison
>
> On Jun 23, 2008, at 10:59 AM, Eli Cochran wrote:
>
>> I have two suggestions, the first is to have a minimum width. The
>> second is to put in default text into the space, such as "Click here
>> to edit", which gives the visual clue to the user that the space is
>> editable and also helps enforce the min width for browsers that don't
>> support min width very well.
>>
>> Usually when this is done, the default text is displayed in a dimmed
>> and/or alternate font.
>>
>> - Eli
>>
>> On Jun 23, 2008, at 10:50 AM, Anastasia Cheetham wrote:
>>
>>>
>>>> You'll see that even though the group field is empty the inline edit
>>>> discovery interaction of highlight and hover message apply.  For
>>>> now, the interaction you describe should probably work the same
>>>> way.  One of the challenges here is the varying contexts.  Sometimes
>>>> it is really important for an empty field to be empty (in a
>>>> particularly busy interface for instance or when there are lots of
>>>> empty values so textually describing the emptiness is huge clutter
>>>> and noise).  Other times it might not be bad to have a textual
>>>> indication that the field is empty.  In Friday's design review we
>>>> decided this was likely something controlled by the integrating
>>>> app.  Does that make sense?
>>>
>>>
>>> Daphne, thanks for your feedback.
>>>
>>> Currently, the highlight and hover behaviour is the same, regardless
>>> of whether or not the field is empty. The issue is that when the
>>> field
>>> is empty, it is very small, so that when you hover over it, for
>>> example, the yellow highlight is a very small area, and easy to miss
>>> (and probably hard to target).
>>>
>>> I notice that when you do click on it, the editable field defaults to
>>> a minimum width that is larger than the empty field - if the hover
>>> highlight were styled to also have this minimum width, might that
>>> address the usability issue?
>>>
>>>
>>> --
>>> Anastasia Cheetham                   a.cheetham at utoronto.ca
>>> Software Designer, Fluid Project    http://fluidproject.org
>>> Adaptive Technology Resource Centre / University of Toronto
>>>
>>> _______________________________________________
>>> fluid-work mailing list
>>> 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
>
> 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
>

-- 
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644