I have been trying to get a feeling for some of the basic issues
associated with an Inline Edit capability. Gary and I talked this
morning about this and I decided to put down some of the things we
discussed.
1. Simple text: The idea is to give the user the ability to do
in-place edits of simple text. But it's difficult to decide just
what simple text is. It's probably something more than the
character set of the inner keyboard, and something less than the
Unicode character set. We need to decide what's in and what's out.
2. Special characters: We need to specify what happens when the user
inputs special characters, such as control characters, escapes,
nulls, octal, hex, and whitespace (newlines, tabs, blanks,
carriage returns).
3. Visual formatting: In the simple text case, do we give the user
any capability for visual formatting, such as line breaks,
centring, right-justification, typeface, size, and stress?
4. Input validation filters: If the application needs to run an input
validation filter to verify that a field is all numeric, a postal
code, a SIN, or of some other standard format, what interactions
are there between the filter and the component? Should the
component include some standard filters? What about templates
(e.g. for postal codes). What is the flow of acceptance/rejection
as the user types into the field?
5. Structured fields: How do we handle fields that have some
structure such as hyperlinks? These fields have at least two
components -- the URL and the display text.-- and may have more.
These are outside the simple text case.
6. Stored versus display: If the string is to be interpreted as HTML,
is the user editing the internal form or the display form? What
happens if the user types in an HTML tag?
7. Length: How do we indicate to the user the length allowed for the
text? Is the display length the only one that matters? What limit
does the component place on how much text can be typed or pasted
into the field?
8. Do we need concern ourselves with a user typing in (or pasting in)
malicious code (HTML or SQL)? Do we need to guard against code
injection attacks? Input validation is the solution to this, of
course. Let's not forget that Little Bobby Tables
<http://xkcd.com/327/> is lurking out there.
Resolution of these issues is -- as we keep reminding ourselves --
context dependent. In many cases we can punt to the integrator and have
them make the best context-framing decision they can, perhaps through
the setting of optional parameters. If we do that, we should make it
clear which options are the best choices for which contexts. This could
be expressed through the accompanying /design pattern/, which can
describe the reasoning behind each option value and why it best serves a
particular context of use.
Beyond the simple text case, is the enhanced text case, where text
elements can have appearance attributes such as positioning, font size,
and typeface, as well as semantic attributes such as hyperlinking. With
this sort of content, an advanced edit view is required, allowing the
user many more options. With the enhanced text case we may choose an
entirely different set of resolutions to the issues listed above.
I understand that Gary is going to explore some existing solutions and
put together some storyboards.
Paul
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
