Inline Edit: Blanks -- initial, embedded, and trailing

Allison Bloodworth ABLOODWORTH at berkeley.edu
Thu Jul 24 00:19:41 UTC 2008


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
>> daphne at media.berkeley.edu
>> cell (510)847-0308
>>
>>
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> Daphne Ogle
> Senior Interaction Designer
> University of California, Berkeley
> Educational Technology Services
> daphne at media.berkeley.edu
> cell (510)847-0308
>
>
>

Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
abloodworth at berkeley.edu




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080723/5382b610/attachment.html>


More information about the fluid-work mailing list