Inline Edit: Single line/multi-line?

Eli Cochran eli at media.berkeley.edu
Thu Jul 10 22:26:31 UTC 2008


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





More information about the fluid-work mailing list