Inline Edit: Blanks -- initial, embedded, and trailing
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
A couple responses below.
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.
> 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
>>> • 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.
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work