One of my software projects is Slidy, a web-based slide presentation application that has proven popular amongst the W3C Team and elsewhere. It uses CSS to render HTML div elements as slides, and JavaScript to move from one slide to the next in response to user input. Another similar application is Eric Meyer’s S5. When writing Slidy I had to work hard to ensure that it worked across a wide range of web browsers. The variations in the scripting interfaces is a big challenge.

The next goal was to create a cross-browser slide editor. I would like to make it really easy for people to create slides and to avoid the need for them to deal directly with the markup. Internet Explorer introduced a rich text editing feature some years back, which has now been duplicated in most modern desktop browsers. Unfortunately each browser has its own quirks in how it approaches this, but there are work arounds. A much bigger problem for me was that simple rich text editors don’t provide the kind of user interface needed for slides. PowerPoint offers a very different UI for authoring compared to Word.

It rapidly became clear that to approach the ease of use of Power Point, I would have to try something different. After quite a lot of work, I found that I could emulate basic text editing support by using an HTML span element for the editing caret and JavaScript to define the desired behavior in response to different keyboard events. This revealed big variations in how browsers support the keystroke events. For example on Opera, the keys for period and delete produce the same key code. Nonetheless, a bit of hacking sufficed to find a rough work around. I am very much hoping that browsers will add support for the DOM3 text events which provide a well thought out solution for text entry.

Slides without graphics tend to be rather dull. Unfortunately whilst you can get browsers to scale images, this tends to introduce nasty side effects, particularly for line art. The solution is to use vector graphics. W3C has been working on SVG for many years now, and browser support is slowly coming up to speed. Perhaps SVG would be a good basis for presenting and editing slides? SVG 1.2 looks really promising with a well defined DOM (the micro DOM) that includes DOM3 text events. SVG 1.2 supports text wrapping and a means to indicate which fields can be edited when viewing the SVG file. This sounded wonderful after the trials and tribulations with HTML browsers.

To ensure everyone could use the slide editor, I have to work with what the desktop browsers support. Firefox and Opera are still slowly progressing towards full compliance to SVG 1.1, but full support for SVG 1.2 is a long way off. Unfortunately, these browsers offer the HTML DOM and not the SVG microDOM. Luckily, the work arounds for HTML proved to also work for SVG. I now have basic editing support working using a tspan element in place of the span element I used in HTML. There are two versions, one using SVG 1.1 that works in Firefox and Opera, and another using SVG 1.2 that works in the BitFlash SVG viewer.

Given the problems with browser SVG support, it seemed like a good idea to take a look at the potential of the very widely deployed Flash player plugin. This is something that I had been meaning to do for a long while. In addition to the official Flash authoring tools, there are a range of open source tools such as gnash,  swfmill, swftools, and mtasc, that have the advantage for me of running on Linux. I was able to get the Macromedia Flash8 authoring suite trial to run under Wine, but Adobe is no longer selling licenses for Flash8. I haven’t tried CS3 but couldn’t afford it anyway for personal use. The Flash file format (swf) supports rich graphics, event-driven scripts and rich text editing. You can also easily download and parse XML and post the updates back to the server. In principle, Flash looks very attractive as a basis for authoring applications of XML. Some of the drawbacks include the fact that Flash SWF isn’t an open standard e.g. compared to SVG, and concerns about the accessibility of Flash-based applications.

Accessibility features in Flash have improved considerably since earlier versions and Flash content can now be used with screen readers such as JAWS. In some cases it is a mainly a matter of providing text alternatives to graphics. In other cases, an audio narrative can provide an effective alternative to screen readers, but this won’t be adequate for people with visual and hearing impairments, and some form of timed text may be needed. Macromedia published best practices for accessible flash design (PDF) back in 2005. However, there remain problems with tab order and access keys when Flash is used as part of an HTML page. Hopefully future browsers will provide better integration of accessibility information across HTML and Flash.

In the longer term, I am hoping to explore the use of XML for easier ways to author Web applications without having to be concerned over the details of particular delivery environments. Such end-to-end models can be compiled to a range of delivery environments including, HTML, SVG, Flash, Java and .NET. This promises to reduce the cost of developing and maintaining applications, as well as making it easier to attend to security and accessibility concerns. I will give more details in a future blog.

In closing, I am now focusing on using SVG as the basis for the slide editor and there is still a great deal of work to do before I have a slide editor ready for people to try out, but I hope to get there by Summer 2008.