Inline Edit: Single line/multi-line?

Paul Zablosky Paul.Zablosky at
Fri Jul 18 17:00:55 UTC 2008

My experience with this has been that the removal of carriage returns is 
closer to what I want to happen.  As Eli suggests, if you clip a 
multi-line street address from somewhere and drop it into Google maps, 
you want all the text, but don't care about the loss of the line breaks.

It really comes down to context of use, but my inclination would be to 
keep all possible text, and only lose the forbidden characters.  The 
assumption is that the user is trying to avoid typing everything, and 
wants to keep the text as intact as possible, subject to the filtering 
rules of the target field. We have to decide if the rule reads "I only 
want one line and you gave me several so I'm only going to accept the 
first one" or "Line breaks are forbidden in this field, so I'm removing 
them from your input".   I prefer the latter interpretation, since the 
line breaks in the input may not be meaningful, as in the case of text 
clipped from a paragraph in an email message.


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
>>> Software Designer, Fluid Project
>>> Adaptive Technology Resource Centre / University of Toronto
>>> _______________________________________________
>>> fluid-work mailing list
>>> fluid-work at
>> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>> Eli Cochran
>> user interaction developer
>> ETS, UC Berkeley
>> _______________________________________________
>> 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

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

More information about the fluid-work mailing list