Inline Edit: Single line/multi-line?
Paul.Zablosky at ubc.ca
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,
>>> 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
>> . . . . . . . . . . . . . . . . . . .
>> Eli Cochran
>> user interaction developer
>> ETS, UC Berkeley
>> fluid-work mailing list
>> fluid-work at fluidproject.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work