WYMeditor concepts
Here are some tips, thoughts, suggestions, and observations based on our experience of using WYMeditor for several professionnal projects for 1 year.
I write this doc to share these infos with everyone involved in WYMeditor 0.3 development, so everybody can benefit from our past experience. I hope it will contribute to make version 0.3 the more friendly possible for an everyday usage. Please share your thoughts !
Flexible editor width
I noticed some clients are confused when WYMeditor's width is fixed.
Because the width of the editor doesn't necessary match the width of their website. An example: the end-user inserts several images side-by side using the editor. Obviously, the images will flow in multiple lines if their width is too large to make them all fit in one line. But the final result may not be the same on the website (a different width for contents can change the way elements flow).
I had to explain this behaviour to some clients, but it was really difficult for them to undestand.
Fortunately there is a simple "fix" to avoid this kind of misunderstanding:
When the editor's width is flexible (it adjusts to the browser window width), you can simply resize the window to make content flow adjust immediately. This helps clients understand the concept instantly and not be confused anymore.
Containers visibility / general visual feedback
One of the key-features of WYMeditor, although very simple, is to apply a visible background color for the block elements + "labels" to clearly reveal the nature od each block element (paragraph, title, ...).
It makes it very easy to spot problems in the document's structure. It also "visually suggests" good practices to end-users.
For example, clients find it "not pretty" to have empty containers ("white blocks with no content") in the editor, so they tend to remove them naturally. It's easy to explain to them that it's nonsense to have empty paragraphs.
Whithout this visual feedback, it would be very difficult to make them produce clean documents as they would think it's only whitespace they can "play with".
The labels (not implemented yet in version 0.3 see the WYMeditor 0.2 demo) allow to reveal the structure of the document, it reveals instantly eventual problems in structure, hierarchy ...
So it becomes easy to make end-users produce clean documents, as they find it "prettier" to make things right.
NOTE: I found it almost impossible and very time-consuming to make clients fully understand concepts and benefits of accessibility, standards compliance, ... But I found it very easy to make them do things right when doing another way would be "less pretty" in the editor.
NOTE: The label system in version 0.2 uses background images, which is far from an ideal solution. We should try to find another way to implement labels in verison 0.3.
Javascript-generated "pseudo content" would be preferable. It should be displayed only inside WYMeditor, during edition time (not saved with the content).
!!Suggested generic classes
I have a set of "default" generic classes which are enabled for all projects. It's a very simple set but very powerful as these simple classes give lots of possibilities. (For simple projects, you rarely need to provide more classes). Plus their usage can be explained to end-users in a short time (though some users find it difficult to use the float-left/float/right/force-new-line classes correctly).
Here they are:
- Para: align center (.content-center)
(for paragraphs only)
centers the content of the paragraph
- Para: align right (.content-right)
(for paragraphs only)
aligns the content of the paragraph to the right
- Para: float left (.float-left)
(for paragraphs only)
floats the paragraph to the left
- Para: float righ (.float-right)
(for paragraphs only)
floats the paragraph to the right
- Force new line (.force-new-line)
(for any element)
makes any element clear all floated paragraphs and appear on a new line
- Image: border (.border) (for images only)
adds a border to an image
You may notice that I don't allow images to be floated, but paragraphs. It's a more powerful approach, because you can achieve the same results plus a lot more:
- put several images into a paragraph then float it left or right. If you use line breaks between images, you can produce "columns" of images or "mosaics" which are nicely displayed on the side of the content.
- It is often interesting to replace the image with another element (using xsl, javascript, ...) only on the final web page. It works better when the replaced image is not floated but it's parent paragraph instead.
Don't think WYMeditor can't insert flash anims, videos, mp3s…
We don't need these features in WYMeditor, simply because there are more elegant ways to insert anything you want.
For example here is the method we use to insert videos, various other approaches are possible:
- Videos are put in a specific folder, for example "/files/videos/myvideo.flv",
- For each video, there is a preview image with the same name, for example "/files/videos/myvideo.png"
- WYMeditor is used to insert the image to te content of the website.
- Then Jquery is on the final website to automatically replace all images from the directory "/files/videos/" by the corresponding videos and the code needed.
This approaches applies the concept of progressive refinement, and is more elegant than if the code was directly embedded in the html source.
With a little work ,you can apply this concept to any kind of media files.
These content-manipulation techniques are very powerful and make specific assistants for inserting these types of multimedia content obsolete (although you will find them advertised as key-features in traditionnal WYSIWYG editors).
- maximise wymeditor possibilities: suggested default classes + explanation transformations that work (using xsl, jquery, or other languages to "enhance" the code)
- strong basic features rather than lots of features
- suggested future improvements wymeditor plugins for * correct whitespace management with visual feedback (nbsps, linebreaks...) * dictionnary * interface improvements (iframe resizing ... -> should be a skin feature) * ability to access and manipulated content while editing to "improve" visual feedback or execute macros ... * ... ?
