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

[Daphne Ogle]

Yes, good point Paul.  Because those 2 cases are very different we've  
decided not include the text editor context in the scope of the inline  
editor -- for now.

-Daphne

On Jul 24, 2008, at 11:20 AM, Paul Zablosky wrote:

> 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
>>>>> 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> fluid-work mailing list
>>> 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
>>
>
> _______________________________________________
> 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



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