There is another question here. If you trim the spaces within a field,
should those spaces be permanently removed or just displayed removed.
Currently it removes it in the display but it persists in edit mode.
This may be more confusing to the user, but it isn't destructive.
Which would be the correct approach?
- Justin
On 23-Jul-08, at 8:19 PM, Allison Bloodworth wrote:
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
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
