Monthly Archives: June 2009

First mockups and todosOverlay

The first two iterations of the management interface have been uploaded to the project homepage:

This is the page that users will be facing once they are logged in: their most recent presentations are displayed and a search-box allows to search for other documents just like in gmail. It will be possible to filter the documents by tag, date or title. For example the query

date last month

will display all documents that have been created during the previous month. I’m going to try to leverage Ubiquity‘s fantastic natural language parser in this project and I hope to make this omnipotent search-box a first class citizen of the interface of the whole application.

When selecting a presentation, different icons appear for different actions that are yet to be determined (I was thinking about play, share, tag and use as a starting point for a new document).

I’ve also started to use the css framework oocss from stubbornella. This is a really easy way to make a first step into the world of css frameworks and the focus on performance of this project doesn’t let you any reason not to try it.

Finally, facing the lack of an elegant and light-weight image overlay solution (commonly known as lightbox), I’ve started my own which is really simple but not yet really flexible: todosOverlay. It’s simplicity is a direct consequence of the exclusion of IE6. I’m pretty sure we could enter into a virtuous cycle with this browser:

The less support we provide, the more users are facing broken Web sites, the more likely they are to figure out that their is something wrong, and they’ll be in turn more eager to switch to a better browser, the less we’ll need to care about providing support!

So, what is great about this “yet another overlay plugin”?

  1. it requires only four files:
  2. which have altogether a really small file size
  3. it looks beautiful in the latest versions of Firefox, Safari and Chrome thanks to the border-radius and box-shadow CSS3 properties, it looks Ok in Opera, IE7 and IE8.
  4. just like the rest of this project, it is Free Software and all the SVG sources are included. Therefore you can really adapt it to suit your needs and desires (changing the color of the close image for example).

What might not please you in its current state:

  1. the overlay doesn’t scroll with the page,
  2. the overlay has a fixed size and the inner image is scaled,
  3. you cannot add text to the overlay,
  4. you cannot switch to the next/previous directly from the overlay like you can do with jQuery lightBox
  5. there can be only one overlay at a time on the page

How does that work?

[code lang="js"]
// The plugins has to be set on thumbnail container

It is currently possible to change the size of the overlay (its width, the height is calculated according to the thumbnail dimensions) and to change the regex used to find the full size image based on the thumbnail’s url. If the thumbnail is:

and the full size image is:

you can use the following options:

[code lang="js"]
width: 500,
regex: /_200px/,
replace: "_500px"

By default the plugin will search for any “_thumbnail”, “thumbnail_” or “_thumbnail_” string in the url and remove it.

By the way, I tried to use picasa as a CDN for the pictures on this site, and it turns out that it is not possible. For some reasons, the pictures sometime refuse to load: the address is correct, the thumbnail even appears in firebug but the load event never triggers… I just gave up. If you want to give it a try, the options for picasa are:

[code lang="js"]
regex: //sd+//,
replace: "/"

Announcing ToDoSo

This project has officialy a new name and a Web page: (I know, it’s a shame not to use @font-face, SVG and other wonderful modern Web technologies).

You can expect to see the first mockups of the user interface on this page in the next few days. I’m going to post about it of course.

Next Wednesday (1st of July) I’m going back to France for one week of holiday, I hope to find a nicer weather over there. Otherwise I’ll go to Spain!

Specification of the project

Finally, here they are! The .pdf version of the specification is already available while a link to the .lyx source will be provided soon.

It took longer than I thought but I’m proud of the result. This is a rather long document (3300 words) so I’m only going to reproduce the conclusion on this blog and hope it will pique your curiosity:

The previous state of the art allows to pinpoint three characteristics of existing presentation software:

  1. they are now very rich applications, allowing for the production of highly customizable and visually appealing documents in which multimedia assets can be embedded. The Web enabled a further leap in feature richness, offering a better availability of documents, new possibilities of collaboration and distribution.
  2. if most of them have significant original features that differentiates them from their competitors, there are only slight variations in their GUI that has evolved only minimally over a ten year period.
  3. there are no presentations on the Web that are able to both reproduce their information as a whole through assistive technologies and allow the navigation of slides with a keyboard.

From these observations it it possible to infer three directions for an innovative and valuable presentation software as a Web application:

  1. Trying to compete in term of feature richness with existing solutions is not a reasonable aim for a single developer. In fact, this project could not be completed without the help of external contributors. The first aim of this project will be to encourage individuals to participate in this project and mainly in its implementation phase.
  2. All presentation software use a GUI that is described as an Overview+Detail interface by Andy Cockburn. But other concepts of GUI such as Zooming and Focus+Context are to be found on the Web (Cockburn 2008). The second aim of this project is to assess alternative concepts of interface for presentation software. The ideal would be to build an interface that would give a strong identity to the application and be more intuitive than the traditional one.
  3. It appears that there is a large space for improvement in the accessibility of presentations on the Web. The third objective of this project will be to allow authors to produce accessible presentations with an application that has a graphical user interface.

There is also an interesting part about the nature of information in presentations illustrated by the following document:

A special thank goes to Sébastien Delorme from [fr] for his precious help on the accessibility evaluation of current solutions.

The next steps are the analysis and design of the application. I’ve already posted about solutions for vector graphics in the browser but I should post about the rationals behind my technological choice (Open Web of course) and about my first ideas for the Graphical User Interface. The next weeks are definitely going to be busy!

The state of cross-browser vector graphics

Vector graphics have for long been the preserve of Flash on the Web as browser vendors never agreed on “one standard to rule them all”. But intrepid newcomers relying on browsers’ native features might well change this situation…

A bit of History

Microsoft first proposed their own standard to the w3c, VML, which was later merged with Adobe’s PGML to give birth to the SVG recommendation.

However, Microsoft chose to support vector graphics in their browser before the corresponding working group of the w3c had a chance to publish their first recommendation: VML was implemented in IE5, released in March 1999 while SVG1.0 was only published as a recommendation two years and a half later in September 2001. On the other hand, partial support of SVG was not to be found before Firefox1.5, released in 2005.

Even though VML was the first technology of its kind to be natively supported in a browser and although this browser could have taken pride of its monopolistic usage share for several years (above 90% between 2001 and 2005 according to different sources), it remains unclear why this technology never really took off… On the contrary, the fate of SVG, never supported by the dominant browser is much easier to understand.

A bit of Technic

From a Web developer perspective, it is arguable that the main advantage of VML lies in its deep integration in HTML:  it is possible to nest HTML elements in VML ones and vice versa. SVG was meant to be an independent specification, the result is that it has to be used in a specific namespace in HTML documents, and HTML can only be used in SVG when nested in a <foreignObject>, an element poorly supported in the earliest implementations.

However, SVG reveal all its power when it comes to transformations: rotations, translations, skewing and other scaling can be nested in any ways where different attributes, filters and computations have to be used in VML.

A bit of hope…

Meanwhile, Adobe’s claim of a 99% browser penetration of its proprietary but nonetheless fully vector based Flash technology obviously succeed to seduce a significantly larger number of developers. Nevertheless, two projects saw the light of day with the promise of providing a cross-browser vector graphic API relying on an abstraction layer above VML and SVG:

  • Dojox.gfx, an integral part of the dojo toolkit specialized in 2d graphics. Its main advantage is that it does provide “one API to rule them all“: its set of shapes, paths and transformations can be rendered either to VML, SVG, canvas (the scriptable raster graphic element of HTML5) or Silverlight (details follow). It is shipped with helpers to make elements movable and to render vector fonts, although its supposed negative impact on performance makes it only suitable for a limited amount of text (see the Caveats section of the page).
  • Raphael, a library agnostic (i.e. autonomous) library which offers a clean API mimicking jQuery’s one. It provides the same basic features as dojox.gfx together with animation, color manipulation, event handling, and vector fonts (as of version 0.8) right out of the box (animation and color manipulation are integrated in other parts of the dojo toolkit).

Both libraries can be used in a similar way: first, the area where the drawing will be possible is defined. In Raphael it is called the paper, in dojo.gfx it is the surface. The function that build this area returns a reference not on the physical DOM element that has just been created but on a more abstract JavaScript object that offers methods independent of the browser. The following kind of code is always to be found at the beginning of a script using on of those library:

[code lang="js"]
var area = createArea( positionOrParentElement, dimensions);

Using this reference, any shape or path can be created, once again those functions return an abstract reference on the created shape:

[code lang="js"]
var rectangle = area.createRect( position, dimensions);

And this reference can in turn be used to dynamically modify the attributes of the element, to animate it or to delete it:

[code lang="js"]
rectangle.setAttribute("fill", "red");

This kind of code should look familiar for any developer used to JavaScript libraries such as jQuery, prototype and of course dojo. There is however an important difference: in the latter libraries, it is possible to find an existing element in the DOM and use it to build an abstract object:

[code lang="js"]
var existingElement = library.domQuery("#myDiv");
existingElement.animate({'opacity': 0.5});

Using vector graphics, this abstract object is only created when the associated physical element is inserted in the DOM. The reference that is returned must be conserved as long as the element needs to be modified. This fact turns out to be important when doing event delegation. With a traditional library, modifying the opacity of all list-items of a list on mouse click could be achieved with the following code.

[code lang="js"]
// A function will be executed every time the user clicks on the list
library.domQuery("#myList").onClick(function(event) {

// The event object references the physical element that has been clicked
var physicalListItem =;

// The library can build an abstract object from this existing element
var abstractListItem = library.abstract(physicalListItem);

// This object can then be used to modify the properties of this element no matter the browser
abstractListItem.animate({'opacity': 0.5});

Unfortunately there is no such thing as

[code lang="js"]

But this can be easily circumnavigated by keeping a record of all abstract object associated in hash table with the id of the element:

[code lang="js"]
var abstractRect = area.createRect( position, dimension );
// Make sure the shape has an id
abstractRect.setAttribute(id, "myId");
// Store this reference associated with the id
var hash = { "myId": abstractRect };

area.onClick(function(event) {

// Event gives access to the id of the clicked shape
var shapeId =;

// Which can in turn be used to recover the abstract shape
var abstractShape = hash[shapeId];

The impact of such hash map on memory footprint is discussed in the paragraph about performances.

… and delusion

With the release of the 8th version of its Internet Explorer, Microsoft dealt VML a severe blow: several features appear to be broken, the most serious one being the possibility to use percentage units… What are vector graphics when the drawing cannot scale? It remains unclear whether those issues have been introduced unintentionally, what is certain is that it will help Microsoft to impose its new technology with vector graphics possibilities: Silverlight, a concurrent to Adobe’s Flash/Flex/Air Framwork also relying on a multi-browser plugin.

This inexplicable coincidence  leaves unfortunately only few hope for an happy ending to the epic battle of native vector graphics.

State of the art

Nevertheless, the baby should not be thrown out when Microsoft siphon off the bath water. It remains possible to use vector graphics in the browser as IE8 can be turned in compatibility mode to act just like the good ol’ IE7 used to. The two aforementioned vector graphic libraries still have to be compared… So be it:


In terms of feature richness, the advantage seems to be for dojox.gfx: As far as as shapes, paths and transformations are concerned, the two APIs are equivalent. Both libraries offer animations, color manipulations and event handling, although this is lies in a lower level part of dojo. However, the alternative technologies that dojo can use to render the graphics might give it a real benefit: Silverlight makes it a more future proof solution and canvas even allows a server-side rendering into raster graphics. Moreover, Raphael does not allow to use other units than pixels, this one being hard coded in the library.

File size

In term of file size however, analyzing the loading process of the two solutions with Firebug yields a size of approximately 22kB for Raphael (once minified and Gziped) and a cumulative 40kB for dojo (when loaded from AOL’s CDN). In one single file, Raphael ships all its utilities and both SVG and VML rendering code, whereas the utilities of dojox.gfx adopt a lazy loading approach with its utilities spread throughout inter-dependent files and a single rendering code being loaded according to the browser capabilities. Even with lazy loading, dojo is almost twice as big… This can be an important criteria for developers who do not intend to use the full capabilities of dojo or who have chosen another JavaScript toolkit. In the latter case, it can be noted that even Raphael will be duplicating some features commonly found in JavaScript libraries: animations, color manipulation and event handling.


In order to evaluate the impact of storing all references on abstract shapes, two tests were built: a thousand rectangles were created in a page and then in one case all the references were kept in a table to change the color of the rectangles, whereas in the other case no references were kept. It appears that storing the references has a negligible impact on memory footprint in Firefox3. However, in Internet Explorer 8, it turned out that Raphael systematically caused the browser to freeze. The test would complete only when it was limited to 500 shapes, but after 30 seconds of delay. The profiler shipped with IE8 revealed that the lag was mostly caused by the internal setBox method of Raphael that is specific to the VML code.

It should also be noted that Raphael does not offer event handling at the paper level. Event delegation is thus impossible when the library is used in standalone despite the benefit of this method on performances (even listeners are set only once on a container instead of being set for each elements).


Last but not least, the quality of the documentation can in many cases tip the scales.

Raphael offers a documentation of its API which includes useful code snippets, however some utilities for color manipulation such as Raphael.hsb2rgb(), Raphael.rgb2hsb() or Raphael.getRGB() are not yet documented. On the projects’ home page, numerous visually appealing and inspiring examples can be found such as a dynamic graph, a start point for a mind map and a demo of the vector fonts. It can be argued that an example with detailed code comments is lacking.

Dojo offers a complete and up to date reference of its API where the documentation of dojox.gfx can be found. However, developer not familiar with the dojo toolkit should read Dojo, Now With Drawing Tools to get started. This article also provide more advanced examples with appropriate comments.

Choice is yours

Dojox.gfx is a natural choice for any developers working with dojo while Raphael is more suitable as a standalone library thanks to its smaller file size. When a large number of shapes have to be created at once, the performances of Raphael should however be evaluated in Internet Explorer. The ability of dojox.gfx to render graphics using Silverlight or canvas can prove to be useful in some case.

For developers already using a JavaScript library other than dojo, it should be noted that in both cases, there will be some code redundancy. Moreover, if performances are critical, the file size of dojo and the problem of Raphael might even prevent to choose any of those…

Project Renaissance: about and usability

I’m still working on formal specification for my project but I can post about interesting things I’ve discovered along the way: Project Renaissance.

In brief, project Renaissance aims at improving the user experience with products, which is well summarized by the project’s motto:

“Create a User Interface so that becomes the users’ choice not only out of need, but also out of desire”

From my point of view it seems like a good start! Even though the project’s homepage show already some flows, such as the Project Charter being spread across different pages when one would have been much more effective… Let’s not be picky and see what is going on:

The first phases of the project consist of surveys to better understand the needs and desires of the users and involving the community with a call for mockups for the future Impress (which is an application that appears to be important for users and where there is obviously a lot of space for improvements). Those mockups can be reviewed in slides 21 to 34 of this presentation. I don’t really like any of them : / But remember that they are only ideas of interested contributors, they are just personal contributions to a greater goal: making Impress better for everyone.

There is also a Blog for this project that gives a better idea of the progress being made. It is just a shame that it gets so little visibility… or is it just an impression? Anyway, the first benefits of renaissance are expected to make their way into’s products for the version 3.2 which is expected… when it is ready probably. I’ll be happy to see what this great project come up with, I’m sure that my application will be very different but only the future will tell which approach is the best.

At the same time I discovered about another interesting and Open project: and particularily its encyclopaedia available under a Creative Commons ShareAlike license. The quality of the content seems satisfying, I’m sure everybody could learn something. In the article about Mockups, I really liked the following idea:

“Mock-ups incite criticism from users because they are low-cost (can be made of cardboard) and low-fidelity. If a user is presented with an early version of a system that has required substantial work, he/she is likely to be more reluctant (as well as able) to criticize it.”

I’m personnaly always trying to create visually appealing mockups because I am afraid that the very first impression might have a bad influence on the user’s general opinion. My perfectionism is once again playing a trick on me…