Inline Edit Family Members -- teasing out the differences

Daphne Ogle daphne at
Tue Sep 23 19:50:45 UTC 2008

Hi all,

As always Paul, very thought provoking.  Thank you!

Your case 2 below:  Inline Edit Clickable Content
Your case 3 below:  Inline Edit Hidden Content

Your case 4 below:  If I understand you correctly, this should be  
handled by either 2 or 3.  I assume if there is a URL there is a also  
usually an opportunity to have a different title (like the option in  
confluence when you include a link on a page).  In that situation, the  
user would click o the edit control (could be a link, icon, button...)  
and be able to edit the title and the URL, which is case 3.  They may  
choose to keep them the same.   If there is not an option to edit a  
title and the user chooses the edit control then if would be handled  
by case 2 (where it's likely the URL just becomes editible).

So that means our inline edit family includes:

- Simple Text Inline Edit
- Clickable Content Inline Edit
- Hidden Content Inline Edit
- Dropdown Inline Edit
- Date Inline Edit
- Rich Text Inline Edit

Additional comments inline...


On Sep 17, 2008, at 2:37 PM, Paul Zablosky wrote:

> I agree with your opinion, Daphne -- we are talking about two  
> different kinds of components.  And your boldface descriptions are  
> spot on.
> I confess that I always liked the word "hidden" in the "Hidden  
> Content Inline Edit" name.  It was immediately clear to me what was  
> meant: there's some content you can't see, but will be exposed for  
> editing when you select it for editing.   I don't really have strong  
> feelings about the name, however.   To get back to the cases, I  
> actually see an intermediate case that we'll have to think about:
> There are:
> Edit simple text inline: just click on it and away you go. This  
> works for most text.
> Edit a thing where clicking does something else. So select it some  
> other way (an edit icon? a different keystroke?) and away you go.  
> This works for link text, tab title text, drop-down titles, etc.
> Edit some hidden information, such as the URL behind a link.  Select  
> with an "Expose hidden content for editing" action (a different edit  
> icon perhaps), and proceed to modify the exposed/revealed fields.  
> This works for URLs and other hidden content/structure.
> Edit the link text where it's the same as the URL!!
> Case 4 is a bit tricky.  If the user wants to edit the link text,  
> they need to invoke a case 2 edit.  If they want to change the  
> underlying URL, they need to invoke case 3.  How can we make the  
> distinction clear to them? It's hard to do without a lot of  
> explanation, and the tools we have -- hover text, icons, selection  
> keystrokes, and clicks -- are all a bit terse and cryptic.  Any  
> designer who can offer a really simple and clear solution to this  
> will have my deepest admiration.
If you have a link, don't you almost always have the option to create  
a title?  So I think it is handled by 3.  The user clicks the edit  
icon and because we know there is hidden content attached to it (the  
URL) the user gets the ability to  edit both the title and URL, likely  
in an overlay.
> Getting back to case 3: In my own mind the name for case 3 is Select  
> and reveal hidden structure for editing -- Inline edit -- that's how  
> I think of it.  Somehow we need to get across the idea that "there's  
> some hidden structure here" (the concept is not really that obscure  
> -- Excel has hidden columns for example)  -- "and you can select and  
> expose that hidden content for editing".  That's the understanding  
> we have to put into the user's mind. The key words are hidden,  
> expose or reveal, select, and edit.
There are 2 main use cases for this:

- Editing clickable content which has a URL setting, which we suggest  
calling Clickable Content Inline Edit.  In this case we would  
automatically give the user the opportunity to edit both the text and  
URL.   An outstanding question is whether the user will realize this  
capability or will they be looking for some function that says "edit  

-  Editing information that is on another, likely deeper page, but not  
displayed on the current page (which we suggest calling Hidden Content  
Inline Edit).  An example of this is announcements in Sakai (screen  
shot attached).  On the landing page, the user sees a table of all  
announcements.  The announcements content isn't viewable here, only  
the title.  Clicking on the title open the full announcement on a new  
page.  Inline edit could give users the ability to edit the title and  
the content (without going to another page) since the content is  
something they would likely want to easily edit.  Here I think there  
is a challenge with discoverability.  However, the user could still  
edit the announcement content the traditional route of going into edit  
mode so maybe it's okay for them not to get it until they run across it.
>  I think the way Thunderbird handles cases 3 and 4 is informative.   
> If you have a link in your compose window, you can just type and  
> alter the text with the rest of your composition, although it  
> sometimes gets confused about whether or not you're in the link  
> text.  If you want to edit it, you have to select it with the mouse,  
> and the expose the hidden structure for editing with Ctrl-L.  It's  
> not wonderfully clear or intuitive, but it does cover all the cases.
Does this fit more with the rich text case (that we aren't actively  
working on now)?
> I think cases 1, 2, and 3 are all distinct, and case 4 is just a  
> special case of ambiguity.  Rich text is in a class of it's own so I  
> won't discuss it here.
> But let's consider this: a date picker is a special case that is  
> eerily similar to case 3 -- but also has constrained choices  
> associated with it.  I have the feeling that date picking/editing is  
> something that deserves its own analysis without trying to form an  
> association in the user's mind with our case 3 solutions.  But we  
> can gain insight by acknowledging the similarity in our designs.
> Just my thoughts on a beautiful Wednesday afternoon on the west  
> coast...
> Paul
> Daphne Ogle wrote:
>> Hi all,
>> My opinion is that we are still talking about 2 different kinds of  
>> inline components.  One that allows the user to quickly edit hidden  
>> information (info not on the screen you are looking at like a URL  
>> or content of announcement if you only see the title on the  
>> dashboard).  The second is editing a thing where clicking it  
>> already does something else (usually taking you someplace else like  
>> to a URL or to the complete version of something that you might  
>> only be seeing the title for).  I'm not sure I have solutions to  
>> the naming but I've made some comments below...
>> -Daphne
>> On Sep 17, 2008, at 9:57 AM, Paul Zablosky wrote:
>>> Hi Allison,
>>>     It sounds like the case you have identified with link title  
>>> editing is (as you say)  very much like simple inline text  
>>> editing.  The only difference is that you can't select the text  
>>> string for editing in the usual ways (left-click or Enter).  Hence  
>>> the need for some other selection activator, such as an "Edit"  
>>> icon.  This leads me to wonder if the case is more general than  
>>> just links.  Are there not other simple text strings that we might  
>>> want to edit that can't be selected for editing with a left- 
>>> click?  Suppose we wanted to edit the title of a drop-down box or  
>>> a tab label?  Aren't these  similar cases that we could cover in  
>>> the design?  I'm wondering if we couldn't extend this to "any text  
>>> you want to select for simple editing but can't because the usual  
>>> selection action action is already taken".  I can't think of a  
>>> good short name for this just now, but if we agree to the  
>>> description, I'm sure we can come up with something.
>> Makes sense Paul.  Can we be even more specific and say it's  
>> "inline editing an item where clicking on that item takes another  
>> action (hence it must work different that simple text edit which on  
>> click becomes editable)"?  Also not a good title but working toward  
>> a description :).  The original title for this kind of interaction  
>> was Edit Mode Inline Edit which I don't think really describes what  
>> we are getting at either.  Perhaps it's the term "link" that is  
>> misleading here.  As Allison mentions below for links, the goal is  
>> to change the URL of a link -- that seems to nicely fit into the  
>> case of editing hidden content.  There must be a term for the kind  
>> of thing we are talking about -- "actionable item"?
>>> Thoughts?
>>> Paul
>>> Allison Bloodworth wrote:
>>>> Hey all,
>>>> Erin and I talked a bit about this tonight. We came up with  
>>>> "Overlay Expanded Inline Edit" (as opposed to "Expanded Overlay"  
>>>> since that may just sound like an overlay has been "expanded") to  
>>>> replace "Hidden Content Inline Edit" because it describes the two  
>>>> parts of what it does: show additional content as well as open up  
>>>> an overlay. This overlay I think is a big distinction for this  
>>>> component because it sort of gets you outside the world of truly  
>>>> editing text inline, without going anywhere else at all (e.g. not  
>>>> even to an overlay). Other suggestions are most welcome if this  
>>>> doesn't make sense!
>> Hmmm...Definitely better but I'm not sure this really gets the  
>> point across.  It still made me think of an overlay being  
>> expanded.   Again, to me in this case the overlay is just a  
>> particular implementation.  The fact that this component is good  
>> for editing hidden information inline is what is really  
>> important.   Since we are in such early stages of design for this  
>> user problem, I don't think we've finalized what the implementation  
>> will be.
>> Erin is working on separating each of the family members in to  
>> their own design overview page now which gives us an opportunity to  
>> describe the problem being solved by each one (that's one of the  
>> sections of the page).  I think that will also help quickly  
>> describe what we are talking about.
>>>> We also talked a bit about whether "Link Inline Edit" and "Hidden  
>>>> Content/Overlay Expanded Inline Edit" were similar. To me it  
>>>> seems that "Link Inline Edit" is usually a sub-case of expanded  
>>>> overlay: you probably need an edit button or icon next to the  
>>>> link, and you need to open up an overlay that allows you to edit  
>>>> (usually) the Link Title and the (usually hidden) Link URL.
>>>> Sometimes, though, as in the case in Sakai or other applications,  
>>>> you may just be editing the Link Title because the URL may be  
>>>> hardcoded into the application. In that case, though, you may  
>>>> uncover some new information in the overlay as is done in the  
>>>> Announcements tool in the Overlay Expanded storyboard: 
>>>> .
>> There are many cases where Sakai is the COU that the user just  
>> wants to edit the link (resource title, assignment title,  
>> discussion topic...).  If we think of this from the users problem  
>> they need to solve.  I see inline editing of an actionable thing as  
>> very different than inline editing of hidden content.
>>>> If we had a component which only allowed editing of the link  
>>>> title, it could behave more like simple text inline edit and upon  
>>>> clicking an edit icon or edit link next to it, the text in the  
>>>> field (e.g. representing the Announcement name, for example)  
>>>> could become editable. If we were to build something like this  
>>>> (though I don't think it's currently on the radar), it could  
>>>> either be in the "Simple Text Inline Edit" family or perhaps be  
>>>> something like "Simple Link" or "Link Title" Inline Edit.
>>>> Cheers,
>>>> Allison
>>>> On Sep 16, 2008, at 9:23 AM, Erin Yu wrote:
>>>>> Great, thanks for your comments.
>>>>> I'd like to let everyone know that I am now editing a lot of the  
>>>>> Inline Edit pages using the consistent names (below) and placing  
>>>>> them in the tree-structure.
>>>>>>>> 1. Simple Text Inline Edit
>>>>>>>> 2. Link Inline Edit (different than simple text in that you  
>>>>>>>> can't click on the text itself because it will go to the  
>>>>>>>> actual link)
>>>>>>>> 3. Hidden Content Inline Edit (editing content tied to the  
>>>>>>>> subject.. please see the announcement example)
>>>>>>>> 4. Rich Text Inline Edit (editing a large amount of text)
>>>>>>>> 5. Date Picker Inline Edit
>>>>>>>> 6. Dropdown Inline Edit (rather than Constrained Choices  
>>>>>>>> Inline Edit)
>>>>> Please note I've changed #4 to Rich Text from Document, because  
>>>>> Document can include spreadsheets, etc. which we do not handle.  
>>>>> I think it would be clear if we named it Rich Text and placed it  
>>>>> below the Simple Text.
>>>>> Erin
>>>>> On 15-Sep-08, at 7:07 PM, Daphne Ogle wrote:
>>>>>> Hi there,
>>>>>> +1 Erin!
>>>>>> Some comments below...
>>>>>> -Daphne
>>>>>> On Sep 15, 2008, at 12:07 PM, Justin wrote:
>>>>>>> Hello,
>>>>>>> Here are some thoughts about the name of Constrained Choice  
>>>>>>> Inline Edit
>>>>>>> The Constrained Choices inline edit is linked to from story  
>>>>>>> card 8 which talked about editable fields such as radio  
>>>>>>> buttons and checkboxes
>>>>>>> This is the same page that is linked to from story card 5, for  
>>>>>>> dropdown.
>>>>>>> (Link to story cards:
>>>>>>> That being said, is dropdown another type of inline edit? Is a  
>>>>>>> dropdown a form of constrained choice?
>>>>>> Yea, the constrained choice is a leftover.  We originally  
>>>>>> thought there would be a type of inline edit component that  
>>>>>> covered cases where the user was making edits from a  
>>>>>> constrained list of choices.  So it's different from simple  
>>>>>> text in that it is a dropdown or radio buttons or checkbox or  
>>>>>> other.  Chatting with Erin and Allison this morning we decided  
>>>>>> that each of those types of interactions should probably be  
>>>>>> looked at individually and each would be child in the inline  
>>>>>> edit component family.  So far we've only worked on the  
>>>>>> dropdown case so that's all you see in the storyboard.  Until  
>>>>>> we uncover a specific implementation of checkboxes or radio  
>>>>>> buttons we probably won't flesh out that design.
>>>>>>> I'm not actually sure what "Allow editable field to be radio  
>>>>>>> buttons or checkbox" actually means. Radio buttons and  
>>>>>>> checkboxes are naturally editable. I'm assuming it is  
>>>>>>> referring to the fields these items represent, but that could  
>>>>>>> be edited using Link mode or simple text.
>>>>>> Yea, not very well written :).  Sorry about that.  I think what  
>>>>>> I meant here was that jumping off the simple text edit case.   
>>>>>> Now we want to work through what it means for the inline edit  
>>>>>> field to have these different kinds of controls.  I'll take a  
>>>>>> looks and try to clean the text up.
>>>>>>> Thanks
>>>>>>> Justin
>>>>>>> On 15-Sep-08, at 2:45 PM, erin yu wrote:
>>>>>>>> I was working on the Inline Edit landing pages and found some  
>>>>>>>> inconsistencies and lack of clarity in the family members'  
>>>>>>>> names. I would like us to agree on a set of simple names and  
>>>>>>>> refer to them from various wiki pages.
>>>>>>>> As far as I understand, there are 6 members in the Inline  
>>>>>>>> Edit family.
>>>>>>>> 1. Simple Text Inline Edit
>>>>>>>> 2. Link Inline Edit (different than simple text in that you  
>>>>>>>> can't click on the text itself because it will go to the  
>>>>>>>> actual link)
>>>>>>>> 3. Hidden Content Inline Edit (editing content tied to the  
>>>>>>>> subject.. please see the announcement example)
>>>>>>>> 4. Document Inline Edit (editing rich text)
>>>>>>>> 5. Date Picker Inline Edit
>>>>>>>> 6. Dropdown Inline Edit (rather than Constrained Choices  
>>>>>>>> Inline Edit)
>>>>>>>> Let me know if this seems inaccurate or if you have any other  
>>>>>>>> suggestions.
>>>>>>>> If this looks good, I'll update the wiki with these names.
>>>>>>>> Thanks,
>>>>>>>> Erin
>>>>>>>> _______________________________________________
>>>>>>>> fluid-work mailing list
>>>>>>>> fluid-work at
>>>>>>> _______________________________________________
>>>>>>> fluid-work mailing list
>>>>>>> fluid-work at
>>>>>> Daphne Ogle
>>>>>> Senior Interaction Designer
>>>>>> University of California, Berkeley
>>>>>> Educational Technology Services
>>>>>> daphne at
>>>>>> cell (510)847-0308
>>>>> _______________________________________________
>>>>> fluid-work mailing list
>>>>> fluid-work at
>>>> Allison Bloodworth
>>>> Senior User Interaction Designer
>>>> Educational Technology Services
>>>> University of California, Berkeley
>>>> (415) 377-8243
>>>> abloodworth at
>>>> _______________________________________________
>>>> fluid-work mailing list
>>>> fluid-work at
>>> _______________________________________________
>>> fluid-work mailing list
>>> fluid-work at
>> Daphne Ogle
>> Senior Interaction Designer
>> University of California, Berkeley
>> Educational Technology Services
>> daphne at
>> cell (510)847-0308

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at
cell (510)847-0308

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list