Ask and it shall be given

Well one breakneck week later, a new visual interface to the user interaction aspect of Rapidsite is taking place.

As I mentioned earlier, my boss, Stuart, was unhappy with the previous user interface of the Rapidsite editor. This was a completely realistic assessment of the needs of the typical Rapidsite customer. I had created n interface that would look great in a medium complexity Content Management System, but unfortunately was way too complex for the simple updates and edits that Rapidsite customers were looking for.

One quick rethink later…

So we decided to make it more of a simple editor rather than your standard WYSIWYG editor (What you see is what you get, in case you were wondering). To this end we decided to make individual elements editable, rather than editing the content as a whole. By taking the page in smaller bites we hoped to make it less ’scary’.

We had to make some decisions over what is ‘editable’, that is which elements will we give the client access to. The final list came down to essentially the content tags, that is headings below the page heading level (below H1 for those in the know), list items and paragraphs and their contents. This gave the client plenty of scope to add their own copy, and to structure that copy in a logical and semantic way, but at the same time limited their ability to ‘break’ the page or it’s design.

Point and change.

If the original user interface was too complex, then how could we make things simpler? Taking the fact that the user will be expecting to be able to change page elements, we must indicat which elements are available for them to change. To do this we assigned all the editable elements a specific CSS class, this then allows us to assign changes in design to all of the editable elements as a group and allowed us for instance to give all of them a background color which would change as the mouse moved over them. This effect it was felt would indicate to the user that they were available to edit.

Once the user understands what is available for them to edit, how do we let them edit it? The most natural method it was felt was that once we had demonstrated that this was an active, and therefore editable, element, accessing the editor should simply be by clicking on the element itself. Once clicked a new window opens which is pre-filled with the elements current contents, and editing and adding to those contents can commence.

At first we tried opening a window the size of the element, and in the same place as the element, in an effort to look as though editing was occuring actualy within the element itself. But it was felt that this was both clunky, and did not feel ‘natural’. Web page elements are not generally editable, and to have one suddenly become one was both strange and easily missed or mis-understood.

Instead we opted for a lightbox effect where the editor appears in the center of the viewing area while the rest of the page dims into the background. This does two things, one it makes it obvious that an event and draws the users attention to the editor, and secondly it shows that this is not a normal web page and that an activity, namely page editing, is now available. The editor is still pre-filled with the existing content, but does not try to reproduce the size or appearance of the element that is being edited. If anything we are trying to make the editor appear as little like the edited element as possible. Appropriate option buttons accompany the editor depending upon which element has been selected for editing. So for a heading element only the save option is shown, but for a paragraph, buttons for bold, italic and underline styles as well as a save option are shown.

The editor used is still xStandard, this allows us to use xStandards excellent code quality controls which will operate silently behind the scenes. Interestingly enough, the full version of xStandard is actualy still there, just tucked away, so a possible option for the future would be an expert mode, which would enable the full version and turn off the per element editing.

Once editing is complete the lightbox effect is removed, the changes are applied to the selected element and the editor is deleted. At this point we will implement an ajax call to update the stored page on the server, making the changes permanent.

On the other hand…

Although we like this technique, and it certainly seems to work as intended, we are also interested in exploring the possibility of implementing the same technique, but using an Adobe Flex application with a Flash 9 front end. This gives us the reliability of removing many of the cross browser issues inherent in javascript applications. Once we have succesfully built both we will be in a position to judge which works best.