Inline Edit Family Members -- teasing out the differences

Paul Zablosky Paul.Zablosky at ubc.ca
Wed Sep 17 21:37:14 UTC 2008


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:

   1. Edit simple text inline: just click on it and away you go. This
      works for most text.
   2. 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.
   3. 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.
   4. 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. 

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./

 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.

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: 
>>> http://wiki.fluidproject.org/display/fluid/Overlay+Expanded+Inline+Edit+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)
>>>>>>> http://wiki.fluidproject.org/display/fluid/Inline+Edit+Storyboard+-+Edit+link+or+multiple+pieces+of+data+at+once+(edit+mode+required) 
>>>>>>>
>>>>>>> 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: 
>>>>>> http://wiki.fluidproject.org/display/fluid/Inline+Edit+Storycards)
>>>>>>
>>>>>> 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)
>>>>>>> http://wiki.fluidproject.org/display/fluid/Inline+Edit+Storyboard+-+Edit+link+or+multiple+pieces+of+data+at+once+(edit+mode+required) 
>>>>>>>
>>>>>>> 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 fluidproject.org
>>>>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>   
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org <mailto: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 <mailto:daphne at media.berkeley.edu>
> cell (510)847-0308
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080917/b973068d/attachment.html>


More information about the fluid-work mailing list