Inline Edit -- a few basic issues

[Paul Zablosky]

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









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