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

Daphne Ogle daphne at media.berkeley.edu
Wed Jul 23 00:43:07 UTC 2008


Right, and we can assume that most of our users won't be used to  
working with markup language.  One thing we've talked about for future  
iterations of inline edit is allowing the user to use a mini-wysisyg  
editor when using inline edit (like a mini-tool bar).  We haven't  
thought it completely through and it wouldn't be something we'd work  
in soon but is an interesting idea.  It could help with understanding  
the users intentions since they can clearly create the presentation  
they want in that mode.  Many of the design challenges that have come  
up are based on this guessing and the answer changes depending on the  
context more than with any component we've worked on yet.  Interesting  
work...

A couple responses below.

-Daphne

On Jul 22, 2008, at 10:27 AM, Paul Zablosky wrote:

> It's interesting that a lot of the tricky issues with Inline Edit  
> are associated with "whitespace" -- blanks, tabs, newlines, and  
> "emptiness".  Here it's a case of the user having to deal with the  
> internal value of the string (which may contain repeated spaces)  
> while editing, and later seeing the display value which has been  
> filtered through HTML.  If the user is used to doing markup-language  
> text editing, they probably understand what is going on. If they're  
> used to WYSIWYG, they probably don't.
>
>
> Paul
>
> 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.
>>
>>
>>>     • Shouldn't the width of the edit box be the same as the  
>>> editable text width?
>>
>> This is a good question - another one for the designers, I  
>> suspect :-)

Yes, one of the worst interactions is for a user not to be able to see  
all the text they are entering.    But again, context is so  
important.  What if the page is just poorly designed so the space for  
the text to be displayed is just too small.  Do we want the edit field  
to show the user what part won't display by giving them a realistic  
view of how it will be presented while they are in the edit or is it  
more important to allow them to see the text in it's entirety while  
they are editing (so we could overlay on top of the interface for  
instance)?  Context matters so I think we need to make some good  
default decisions based on the likely contexts we've identified.  I'll  
create a task to think through a few of these in rough wireframes.

>>
>>
>

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/20080722/6bf9c376/attachment.html>


More information about the fluid-work mailing list