Inline Edit: Single line/multi-line?
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.
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
>> edit. The size of the input indicates the "expectation" of the
>> application. I'll put it another way, in good form design the
>> 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
>>> 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
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
More information about the fluid-work