I agree with Daphne's proposal for the default, and think that these
behaviors--trimming spaces a) at the beginning and end of a field and
b) trimming extra spaces within a field--should be configurable. I
think the big difference in when you would want to do one or the other
is when inline edit is being used like Word/a text editor vs. when
it's being used to enter a (single) value into a database. Advice on
choosing the proper configuration could be part of the design pattern.
I wouldn't think we'd want to trim multiple tabs or multiple carriage
returns by default, as I'm guessing this would only be allowed in the
situation where inline edit is being used more like a text editor when
users may be using this for formatting. But is it necessary to have
configuration options like this for tabs and carriage returns, too?
On Jul 23, 2008, at 9:34 AM, Daphne Ogle wrote:
Anastasia Cheetham wrote:
On 21-Jul-08, at 8:05 PM, Paul Zablosky wrote:
A couple of questions:
• Is the trimming and compressing of blanks part of the
intended behaviour of the component?
The compression of blanks is a side effect of the way HTML works
- if you put a string of spaces into HTML markup, they are
displayed as a single space. If you want what is called a 'non-
breaking space,' you have to use the special character ' '
instead of a regular space character.
It's a question for the designers as to what would be the ideal
behaviour when a user enters a string of spaces into the edit
field.
In this case, without know the context, I think we have to take the
users actions as intentional. Can people think of scenarios where
a user likely enters more spaces than they meant to? We could make
this configurable.
Eli and I were just discussing this since we had fairly different
answers to this question (he thought there were rarely times when
you wouldn't want to trim the spaces). I keep thinking about Word
and that we hear quite often from users that they just want this
stuff to work like if they were working in Word. Although to
folks who know HTML markup it seems silly to use spaces to adjust
presentation but this is how many non-markup folks are left to
deal. If there are spaces in the middle of a text string I think
we need to assume the user is intentionally adding the extra
spaces. User intentions become unclear if there is an extra space
at the beginning or end of their text because those are hard (or
impossible) to see. And apparently extra spaces can be evil with
data normalization so minimizing those mistakes is important. So,
my proposal is keep extra spaces mid text (like Paul's original
example) and trim extra spaces at the beginning and end.
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED]
cell (510)847-0308
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED]
cell (510)847-0308
Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
[EMAIL PROTECTED]
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
