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

[Paul Zablosky]

Allison's two cases -- a text editor context and a data entry context -- 
are revealing.  In either case the final value of the stored field will 
depend on what input-edit rules are applied, and these are likely to be 
different for the two cases.  I think the key to resolving this is to 
focus on the input validation step.

Paul

Justin wrote:
> 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
>>>> daphne at media.berkeley.edu <mailto:daphne at media.berkeley.edu>
>>>> cell (510)847-0308
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> fluid-work mailing list
>>>> fluid-work at fluidproject.org <mailto: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 <mailto: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 <mailto:abloodworth at berkeley.edu>
>>
>>
>>
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org <mailto:fluid-work at fluidproject.org>
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>   

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