Adding images in an easy and accessible way is a vital part of a modern WYSIWYG editor, and one of the things the almost all of the implementations I’ve come across get wrong. There are several levels of implementation, from adding images using a URL, to creating and choosing from a library.
The simple interface
It might be considered beyond the scope of an editor to cover image libraries, if so, the simple case should be just that: simple.
From the allowed HTML, we know that most of these fields should not be there:
The three things required at a minimum are:
- Location (i.e. URL)
- Text alternative
- Style
The interface for adding an image should not include depricated attributes such as border, hspace and align. Other attributes that might be allowed, but probably behind another tab are in the custom attributes list (id and longdesc come to mind).
As we saw from dynamic styles, it is best to only show what is relevant in style selections. The editor could either detect styles such as img.alignleft, or allow the developer to configure the styles available. This style would be applied as a class to the image.
When the user has to type or paste in a URL, it would be best to show a preview of the image, or at least some indication that the image is valid.
I am inclined to recommend that editors do not allow authors to re-size images. Using the mouse to grab a corner and re-size makes many people think that the image is being shunk, when it just appears to be have been shrunk. Also, browser do not render re-sized images well.
Image Libraries
Having to cut and paste in a URL to add an image is a pain, and is not nearly as usable as choosing one.
Having a choice of images requires more integration than just slapping in an editor, it requires reading from and writing to the file system of the server. It is also this that is the worst aspect of many editors, either because it adds such a complicated interface, or because it is not flexible in how it integrates with the server.
Browsing an image library
There is one exception I have come across that is (relatively) simple to set up, has a simple interface, and is fairly flexible in where it can browse. This exception is a (now defunct) WordPress pluggin called Iimage browser. Unfortunately it doesn’t work with the WYSIWYG editor, just the code view.
The UK Windsurfing Association site has thousands of pictures which are of several types. It has ‘graphics’ that include logos (100s), event maps (10s), flags (10s), and sailor profile pictures (100s). It also has several years worth of ‘galleries’, consisting of an average of 30 pictures per event, with 10-20 events per year. That’s a lot of pictures, and they need categorising:
This pluggin shows the images from the file system within a reasonably standard web page (requiring JavaScript, but hey, you need JavaScript to have gotten here). The links at the top are your navigation through the folders. It even understands thumbnails, and any image with a matching version preceded by _thb_ is treated as having a thumbnail.
Although the galleries images are held quite separately, I created a symbolic link (like a short-cut) in the file system so that it could read the images, and adjusted the script to use the real location of the gallery images when chosen.
The interface to add an image revolves around adding the code, but is still a good example of what should be there:
If you removed the code panel (as we are aiming at WYSIWYG editors), and added a style drop-down this would be ideal. I haven’t found anything that allows you to add thumbnails with links to the large image as easily.
Uploading to an image library
The ability to add images is a strong requirement as well, as asking non-technical people to use FTP is something of a non-starter, I have tried repeatedly!
The current WordPress functionality works well, you don’t have to leave the editing interface to upload a picture:
The upload interface includes a field for ‘title’, which becomes the default alternative text. I’ve tried to think of a reason why people would apply different alternative text in different situations, but it seems unlikely and I don’t see a problem with centralised alternative text (assuming that you can edit the alternative text after upload).
There should be some guidance on what makes good alternative text, preferably in context, when the user is uploading the picture. A help symbol next to ‘title’, which expands to show concise guidance, such as “imagine you were describing the picture to someone over the phone”. Since editors in this context are only adding images to the content, it is unlikely that a null alt would be suitable, so file names and null alts should result in a warning.
The uploading process should process the image. How many times have you come across non-technical authors uploading a 3MB, 99% quality picture straight from a camera? The picture should be reduced to a size configured by the developer, for example, constrained to 550px square at 75% quality. It would also be useful to automatically create a thumbnail as well.
Another useful feature would be the ability to upload a folder, or set, of images all at once. You’d have to set it off and leave it, but it would be invaluable for galleries. Another option would be to integrate with a popular gallery, making sure that you have access to those pictures as well as the option to upload your own.
Conclusions
Although I am now leaving the analysis of the editors to the end of this series, I know from experience that this is one of the most frustration aspects of trying to integrate a WYSIWYG editor with a real web site (as opposed to just testing).
I will have to scour the internet for plugins for each of the editors to test this fully.
Technorati Tags: