Designers: Re: Inline Edit - clearing the field
Eli Cochran
eli at media.berkeley.edu
Wed Jun 25 17:59:55 UTC 2008
Clay's discussion reminds me of one of my favorite inline editing
patterns...
The pattern we see most often for creating a _new_ thing is to click a
"New" or "Add" button. But I've seen cases where, when viewing a list
of items, at the bottom of the list there is an empty field just
waiting to be typed in. Click in the empty field, type, press Enter,
your new entry is added to the list, and your cursor stays in the
empty field at the bottom so that you can add another item to the list.
This also works just as well for grids, although in that case there
might be a number of cells in a row that need to be filled out before
you can move on to create another row. But still, always a row
available for entry.
- Eli
On Jun 25, 2008, at 10:25 AM, Clay Fenlason wrote:
> Most of this is for me just thinking out loud (or as loud as keyboard
> clacking gets), but I think it's at least worth noting that a 'create
> a new object' level should (when it exists) bear a resemblance (though
> not identically so, they are however related) to the look and behavior
> of the in-line editing, for reasons of proximity and consonance of
> function. This may have an implementation bearing for the CSS and JS,
> for example.
>
> A full-featured grid UI component would include inline editing,
> authoring, sorting, paging, search, etc., and so that even while we
> focus on the pieces it's useful for me to keep composite structures at
> the edge of one's thinking.
>
> I like the note about "empty being information." It's also true that
> there are many such contexts (a to-do list is another good example
> here) where the first thing you may want to do is run through and
> create a bunch of objects with their labels, and worry about going
> back and filling in the details later. In the same way that in-line
> editing makes revisions less of a burden, so also in-line authoring
> takes the edge off of generating your stuff in the first place.
>
> I imagine someone, say, at the beginning of a semester, tabbing
> through a column and typing in assignment titles for each week, just
> to get them out there as placeholders. Never mind the attached files,
> dates, and other miscellanea for now, let's just tack up these titles
> so that I can get myself organized at a basic level. I can go back
> and color in between the lines (with in-line editing) later.
>
> Which makes me also wonder about "required" fields. Are they really
> required absolutely, or is it only important that they be required at
> a later stage, when some further activity depends upon them? I think
> we're often enforcing requirements too quickly during the authoring
> stages, when they are really needed only much later (e.g. when an
> assignment is posted for students to start submitting against). We
> need greater tolerance for partial activities, for fits and starts and
> not forcing people to immediately close the full loop on everything
> they initiate, which in my mind is part of the philosophy behind
> in-line editing. While that's largely a problem for the business logic
> of the context, and not a component issue, I think there is an oblique
> design bearing: where and how validation alerts surface, for example.
>
> Of course, it must also be admitted that my desk is a mess and I've
> got post-its scattered around, so maybe I really just want things to
> be designed for my pathologies. Here's a persona with a goal of
> sorts: Let me make a mess! Let me toss up stray thoughts and then
> twiddle and tweak and tailor until something sensible starts to emerge
> from the murk. That's the only way I know how to make sense of things
> - these wizards and sequenced taskflows frustrate and humble.
>
> ~Clay
>
> On Wed, Jun 25, 2008 at 12:19 PM, Daphne Ogle <daphne at media.berkeley.edu
> > wrote:
>> It seems like a couple of main distinctions between in-line editing
>> and
>> in-line authoring is the existence of the item/object and the level
>> of
>> change/authoring. With editing, the object already exists and the
>> edit is
>> happening on information about the object. That information might
>> have been
>> empty previously but even empty is information. The assignments 2
>> storyboard Allison points to shows the group field empty for an
>> assignment
>> which is information in itself (no group assigned).
>>
>> In-line authoring -- which would be a very cool component -- seems
>> like it
>> would be at the 'create a new object' level.
>>
>> Good discussion! The boundaries for components are very tricky.
>> I'm sure
>> we'll continue to have discussions like this and probably continue
>> to evolve
>> our ideas about those boundaries.
>>
>> -Daphne
>>
>> On Jun 24, 2008, at 5:00 PM, Allison Bloodworth wrote:
>>
>>> Hi Clay,
>>>
>>> I couldn't find the situation you were talking about with JIRA sub-
>>> tasks, but did play with NetVibe's ToDo list. Generally, I think
>>> that
>>> adding a new item *is* different from in-line edit because the
>>> content
>>> item (a to do) doesn't exist yet. It's sort of an "Add New" item
>>> situation, which I don't think falls under the in-line edit
>>> component
>>> (but would certainly be interested in hearing other views).
>>> Creating a
>>> new item as you suggest I think could be called inline authoring,
>>> and
>>> it probably has many wide-ranging use cases. In the use cases I
>>> worked
>>> on for in-line edit, there was already a (parent) item/object
>>> (e.g. an
>>> Assignment), but some of it's values weren't yet filled in (e.g.
>>> Groups). (see
>>> http://wiki.fluidproject.org/display/fluid/Inline+Edit+Storyboard+-+Edit+information+with+constrained+choices+and+dates)
>>>
>>> In terms of having an affordance to delete text (I'm guessing you're
>>> suggesting an icon), again I'm wondering if that's more appropriate
>>> where you're deleting an entire item (e.g. a to do) and not some
>>> text
>>> within an item (e.g. a group within an assignment). We'd also have
>>> to
>>> balance adding an icon with space and keeping the interface
>>> simple. In
>>> the Assignments example I don't think this would work as space is
>>> at a
>>> premium, and it was hard even to find a place for the "Undo" button.
>>> Perhaps it might be helpful in situations where users are often
>>> completely deleting many in-line editable items, but I haven't heard
>>> about a use case for that yet--I think it's most often the reverse
>>> (if
>>> anyone knows of one, though, do let us know).
>>>
>>> We also talked about the potential of highlighting all the text in
>>> an
>>> in-line edit item when the user clicked on it (for easy deletion),
>>> but
>>> wanted to balance that with protecting the user from inadvertently
>>> deleting something, and also make it as easy as possible for the
>>> user
>>> to do what they normally do. (e.g. are they normally entering an
>>> entirely new value, or are they more often adding text at the end of
>>> the current value?) Perhaps we can make this configurable and give
>>> advice on when to use each method in the design pattern.
>>>
>>> Cheers,
>>> Allison
>>>
>>> On Jun 24, 2008, at 6:59 AM, Clay Fenlason wrote:
>>>
>>>> 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
>>>
>>> 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
>>
>> Daphne Ogle
>> Senior Interaction Designer
>> University of California, Berkeley
>> Educational Technology Services
>> daphne at media.berkeley.edu
>> cell (510)847-0308
>>
>>
>>
>>
>>
>
>
>
> --
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> (404) 385-6644
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
. . . . . . . . . . . . . . . . . . .
Eli Cochran
user interaction developer
ETS, UC Berkeley
More information about the fluid-work
mailing list