Inline Edit: Single line/multi-line?

Daphne Ogle daphne at media.berkeley.edu
Fri Jul 18 16:22:40 UTC 2008


So much of this kind of interaction really depends on the context.   
Allison and I have been wondering if there is a good default for this  
or if it would be better not to have a default at all and force the  
integrator to set these parameters.  I don't even know if that's  
really possible :)

Our new iteration starts Tuesday so we'll make the task of fleshing  
this out a high priority.   Anastasia mentioned wireframes could be  
helpful.  We can storyboard out a couple different cases and see that  
adds any clarification.

- Daphne

On Jul 17, 2008, at 5:25 PM, Allison Bloodworth wrote:

> I generally think the removal of carriage returns would be more
> jarring, as it is substantively altering the content (though I'm sure
> you could find use cases where this would be helpful).
>
> Removing the carriage returns along with any text following them I
> think better conveys the message that they aren't allowed without
> forcing the user to process all their text in order to even realize
> they are gone, and then think about why that may have happened.
>
> On Jul 10, 2008, at 3:26 PM, Eli Cochran wrote:
>
>> Different contexts have different requirements and the inline editor
>> should be configurable to handle those different requirements. Some
>> fields may disallow certain characters or be limited to X number of
>> characters, be limited to a single line or allow for expansion.
>>
>> There is also an important "design" issue in how you present an  
>> inline
>> edit. The size of the input indicates the "expectation" of the
>> application. I'll put it another way, in good form design the  
>> designer
>> sizes the field so that the user knows what is expected or allowed.
>>
>> If multiple lines are acceptable or expected then multiple lines
>> should be presented from the start. If not, then not.
>>
>> Which brings up an interesting question. In the single line instance,
>> what is more jarring or difficult for the user to deal with: when
>> pasting multiple lines to only accept the first line of text, or to
>> accept all the text but remove the carriage returns. (I thought that
>> Google maps used to do that latter but when I just looked, I saw the
>> former.) I don't know the answer.
>>
>> - Eli
>>
>>
>>
>> On Jul 10, 2008, at 4:59 PM, Anastasia Cheetham wrote:
>>
>>>
>>> Hey, folks,
>>>
>>> The Inline Edit functional requirements distinguish between editing
>>> simple text and editing large amounts of text. Technically we've  
>>> been
>>> interpreting this distinction to be single-line vs. multi-line. So
>>> far, we've only implemented single-line editing.
>>>
>>> Is this a reasonable interpretation? Or should the notion of 'simple
>>> text' include support for multiple lines of text? If someone pastes
>>> text that includes a carriage return into a simple inline edit,
>>> should
>>> it resize to be multiple lines?
>>>
>>> -- 
>>> 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

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






More information about the fluid-work mailing list