I've been involved in a discussion of Flash's capabilities to develop a better HTML editor component for authoring hypertext content through a browser interface. This is a topic I've been openly giving some initial thought to and was consequentially asked to share my views on how this editor might be designed. While far from complete, this post is a summation of those thoughts thus far to begin what I hope is a productive dialog on this topic.
Recently I said that a simple and extensible markup editor is too integral to web applications that it has to be ubiquitous and without constraints. How this editor component is designed can be defined with three primary goals: flexibility, simplicity, and lightweight. Of course these design goals can be interrupted in varying ways and requires elaboration. The also require a certain amount of balance and compromise to achieve a broad set of requirements. Here are some specific thoughts I have had in mind.
FLEXIBILITY
The editor widget should be configurable through a separate XML file (locally or remotely) rather then modifying source code. I really enjoyed using Homesite 2.5 in its day. While it was a code (rather then WYSIWYG) editor, it was streamlined and yet powerful with its easy extensibility. (Has anyone used TopStyle by the same author?) One of favorite features was the ability to create custom editor "tags" by defining attributes such as start and end segments. One click would wrap the highlight text in those start and end tags. This was immensely helpful in pre-CSS days because I could define a tag that was composed of multiple HTML tags. For instance I could create a <scream> tag that would wrap the selected text in <b>, <i> and <font color="red"> HTML tag sets. Besides saving time it made my HTML coding more consistent. Once acquired by Allaire, HomeSite extended this capability by introducing VTML with TagTips and dialogs. Unlike HomeSite these configuration options probably shouldn't be editable directly from the widget rather the site manager or application developer. If one really wanted to allow users to customize the editor they could elsewhere and dynamically generate the configuration file.
This is just one example of why configurability is an important feature. What markup tags are available and how they are implemented (XHTML or HTML?) could also be controlled without code modification. To this point...
SIMPLICITY
The editor should "shield" the user from understanding actual markup and not be limited to producing just HTML. This editor would initially be used for HTML editing interfaces like those found in weblog tools. In considering the bigger picture, I believe it's important to allow for the configuration of task-centric editors. For instance, which is more user friendly: having a bookTitle option or selecting span and choosing class "bookTitle?"
Does not attempt to come close to the sophistication of standalone editors like Dreamweaver and Composer. The value of this editor will diminish if it tries to do too much.
Supports only simple interfaces. The editor should make minimal use of dialog boxes. The widget should only support a single editor window.
LIGHTWEIGHT
Implements "fat" features as web services. Simple helps in creating a lightweight application, but not completely. Functions such as a spell checker or markup validator should offload its processing and data to an external service
Leave a comment