#9 User capability to edit static text on pages

[mark]

THE VISION

One of the fundamental visions of our web application is that any user with a certain level of permissions should be able to edit and modify ANY static text on ANY page within the entire web site. The vision is so pretty revolutionary. We are giving the users (who have appropriate permissions) the capability to become web site editors. Essentially, what I am proposing is that every single page, the entire content within our web domain becomes effectively, sort-of a wiki wiki application. The challenge is to make it happen, to design a clean software, and to make it very user-friendly to the end-user. Below, I am describing the issue in slightly more details. We should further discuss the details to make sure that we have a good thing going on...

CURRENT DESIGN -- BACKGROUND
Currently, in our web application, all the static text content of all web pages resides in Struts MessageResources.properties file. This is a pretty good approach for internationalization and for centralizing all the text content in one location (simple to find). But this solution does not completely satisfy our vision. Editing text in message resources requires some knowledge of certain basic syntax. This approach (through Message Resources) is not user-friendly enough to be made accessible to the general public. It is too easy to make mistakes and screw something up. Some very basic awareness of programming concepts is required (a task more complex than setting the clock on a VCR). So that's not so good for us.

Recently, we have moved message resources editing capability to XWiki. In this way, the MessageResources.properties file does not physically exist any more. It is parsed and constructed on-the-fly when the application deployment script is executed. This recently introduced approach made editing a little bit easier for me, but it is still not up to snuff to satisfy our vision user-friendly editing capability. Below, I propose new set of requirements:

HIGH-LEVEL INITIAL FUNCTIONAL REQUIREMENTS (PROPOSED)

1) Each "unit of content" (we need to define this term better) should have a tiny link at the bottom right corner. The label on the link should be short and sweet, for example: "Edit".

2) When the link is clicked, and assuming that the user is logged-in and has sufficient level of permission, then a text area should open showing "pre-formatted" (we need to define pre-formatting better) text which the user wants to modify.

3) Ideally, we would prefer the "Edit" link action to execute the user request "in-place": that is, the text area should appear without refreshing the page, and without re-directing to a new URI location. This implies using JavaScript/AJAX technology (probably GWT?).

4) The system should recognize line-breaks as a valid formatting operation. In other words, a carriage return should be equivalent to the BR tag. This is probably one of the "pre-formatting" attributes: showing line breaks in text area.

5) The system should recognize and support only a very limited set of HTML formatting tags: BR, B, STRONG, I, EM. (I believe that should be enough, we do not want to create a style editor, only content editor).

6) The system should disallow (or ignore) any HTML tags other than the ones shown above.

7) If any unsupported HTML tags are included in the submitted content, then the system should throw them out (do not save unsupported tags) but store all the other valid text string.

8) In the operation above, there is no need to stop the submit action. The data should be saved and the edit should be redisplayed. However, a warning message should be presented to the user saying, for example: "The HTML tags that you have submitted are not supported and have been discarded".

9) The error messages themselves are static content and reside in MessageResources, therefore, they also should be editable in-line.

OPEN ISSUES (TO BE DISCUSSED)

Internationalization remains something of a question mark to me right now. We do need to preserve the capability recognize the locale and serve internationalized content if any. The default language should be English. However, if there is a different language content for example Chinese, and if the locale is recognized as China, then the Chinese language content should be served... This may be simple to do, or not -- I simply do not know the capabilities presented by the underlying mechanisms that we use.

Validation of data is to be determined. Some characters might be invalid. Some minimum, maximum limits should be established.

PERCEIVED LEVEL OF DIFFICULTY

This is a relatively challenging, and non-trivial feature. Requires good knowledge of Struts, software and database design skills, J2EE and many other interesting things.

[mark]

Logged In: YES
user_id=1691791
Originator: YES

There is another functional requirement that I forgot, which is necessary for this functionality to exist without undue vandalism to occur:

10) A permanent record should be kept and publicly displayed showing what is the screen name of the user who performed the particular change and on what date. It would be nice to have a capability to reverse any particular change, but initially, perhaps it is not a necessary requirement.

[Anonymous]

Logged In: YES
user_id=1717523
Originator: NO

Do you want to be able edit every static text on every page?
I can imagine how to do it with relativly large paragraphs of text, but for example label on the form, probably there is already submit button and other input fields so where to put 'Edit' link or button?
Hmm...

however may be we could edit the whole page in one time?
I mean when user clicks 'Edit' link (somewhere at the top) all static text is replaced with input fields (with this text inside) and submit and cancel buttons appear at the bottom (and may be at the top if page is long).

[mark]

Logged In: YES
user_id=1691791
Originator: YES

You are asking about the point that I wrote above: We need to define the "unit of content" to be edited. Yes, every unit of content (ever static text on every page) should be editable.

It is not a user-friendly approach (bad usability) to treat the entire page as a single unit of content. Also, it simply would not work the way users expect: On one hand, we do not want a header on one page to have a different label than a header on a different page. On the other hand, users would not understand that changing a header or footer labels would become a global change.

So the unit of content needs to be very clearly defined for each case, every button, everything. Maybe a unit of content is a table with all its text content. Usually a table is a cohesive visual structure. Clicking on such an edit button would enable editable fields (in place) in the entire content (expose them to editing).

Maybe we need to implement this task in stages. There will be some units of content which are hard to define. But I would not worry for now about where we put a submit button. There is always a place for it. It is a matter of web design and graphics.

[mark]

Logged In: YES
user_id=1691791
Originator: YES

Hi Maria... Thanks for volunteering to do this feature. That is super! Feel free to ask any questions you may have. As I wrote in my initial description, this is not a simple feature... certainly a perfectly do-able task. But I do not think anything like this has ever been accomplished before, so we are pioneering some very new concepts and ideas here (from both technical and social aspect). Also, there are going to be quite a few tricky and interesting issues, requirements, design and implementation decisions involved with this task; but Adam and I will help you out -- so you will not be left hanging there alone. I can help hash out the functional requirements in detail... Adam can provide you with an detailed background regarding the current software design, architecture and implementation.

Because this feature is so large, we should probably divide this task into stages. I will think about it some more tomorrow. I will also work on some sketches of what I imagine the high-level user interface screens should look like.

I have one request: Let's communicate any discussions, Q&A, requirements and specifications in this tracker. It is important to preserve the records of our written conversation as future documentation. Thanks again,

Cheers,
Mark

[mariaT.]

Logged In: YES
user_id=1722575
Originator: NO

Hi mark,

Yes it is not a simple feature. But i like challenges. First i will provide a concept. That needs a little time. I think, that i need your helps and ideas.
I understand, that i must create a form of Web-Editor for the user. If i have ideas or questions, i will post here.
maria

[mark]

Logged In: YES
user_id=1691791
Originator: YES

After some thinking lately, I am beginning to have some doubts myself about this feature. Maybe I have jumped the gun a little here... The functionality is very good and useful. However, maybe we should first look at some existing content management systems (programs). (If the wheel has been invented already, maybe we should not reinvent it.)

One of the existing CMS is Apache Lenya http://lenya.apache.org/ , but I believe there are many others. What do you think?

[mariaT.]

Logged In: YES
user_id=1722575
Originator: NO

I have regarded CMS lenya. It is more complexity. And it is not to use so intuitive. But the Content Editor has all functionality, what you want. I think also, we should first look at some existing content management systems. There are many CE.