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

Daphne Ogle daphne at media.berkeley.edu
Thu Jul 24 17:40:02 UTC 2008


On Jul 24, 2008, at 5:28 AM, 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.
Do you mean that if I edit a field and include some extra spaces at  
the beginning that they display while you are editing, do not display  
once you've saved and the field is back in edit mode but then display  
again if you go back into edit mode?  My understanding is that a big  
reason to trim is for data normalization in the DB.  If that's the  
case it seems like a trim should be trim all the way through the system.

 From the users perspective we want edit and display to match so if we  
decide to trim then we should trim everywhere.   Users want and expect  
wysiwyg behavior.

-Daphne

>
> 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
>

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/7be10230/attachment.html>


More information about the fluid-work mailing list