Category Archives: todoso

Improvements to ActiveJS

The ability to create relations between the different objects of the application (a user has many articles, a section has one HTML content) was believed to be implemented in ActiveJS as it is implemented in Ruby on Rails.

An attempt to define the relations between articles and sections was implemented as follows:

[code lang="js"]
Section = ActiveRecord.create('sections', {});

Article = ActiveRecord.create('articles', {
created_at: '',
updated_at: ''

Section.belongsTo( Article );

And when relations were to be set between instances of the User and Article class:

[code lang="js"]
article1 = Article.create({
created_at: now(),
updated_at: now()
section1 = Section.create({ });
section1.createArticle( article1 );

It appeared however that those two assumptions were false. ActiveJS in its official implementation requires the following to be written:

[code lang="js"]
Section = ActiveRecord.create('sections', {
article_id: ''

Article = ActiveRecord.create('articles', {
created_at: '',
updated_at: ''
Section.belongsTo( Article );

[code lang="js"]
section1 = Section.create({ });
created_at: now(),
updated_at: now()

The fact that it was not possible to use pre-existing objects when creating a relation between two objects penalising problem, as it was actually impossible in the application to create a presentation once all of its slides were created.

Instead of working around those two issues, it was decided to spend some time implementing the missing features. The first two snippets of code can now successfully be used with the improved version of ActiveJS and additional unit tests were added to the existing one to ensure that those change will still work with future versions of the framework.

Improvements to jQuery

As advised in Yahoo’s best practices, an extensive use of event delegation has been made in ToDoSo while access to the DOM have been reduced as much as possible.

However, upon careful inspection of jQuery’s internals, it appears that those two rules are contradictory with this library. Indeed, in the case of a document composed of nested <div>s of different colours such as illustrated in the following figures:

Structure of the document

actual document

If event delegation is to be used at the div.grey level to change a class of a to .yellow, the following code would be used:

[code lang="js"]
$("div.grey").find("").live("click", function( event ) {
// event.currentTarget is the clicked red.div

In the current implementation of jQuery, this is what happens when div.white is clicked, before the class can be changed:

  1. the event is captured at the div.grey level, but the event target is the clicked div.white
    1. the DOM is accessed to retrieve all inside the div.grey
    2. a function loops through all the retrieved to check if the event target is one of them, and fails.
  2. the ancestor of the event target (the top left needs to be checked in the same way
    1. the DOM is accessed to retrieve all
    2. a function loops through them, searching for the parent, without success
  3. finally, the ancestor of the (the top left  is checked
    1. once again the DOM is accessed to retrieve all
    2. a function loops through them and the top left is one of them
  4. as of jQuery 1.3.3, the currentTarget property of the event object is set to the found

The complexity of this algorithm is O(n * m) or 0(n²):

  • n being the number of level of elements between the initial event target and the element to which the listener is bound,
  • m being the number of elements corresponding to the delegation selector, “” in this case.

However, it appears that, in the case of a delegation selector of the form “div”, “.red” or “”, it is unnecessary to access the DOM and loop through the elements corresponding selector. Instead, it is possible to:

  1. check if the event target is a div and has a class “red”: its class is white
  2. check if the ancestor is a div and has a class “red”: its class is black
  3. check if the ancestor’s ancestor is a div and has a class “red”: the currentTarget has been found.

Although checking the class and type of an element requires an access to the DOM, it does not require to retrieve elements from the document, which is far more expensive, and effectively reduces the complexity of the algorithm to 0(n).

A new implementation of the jQuery.filter() function (used by .live()) yielded the following results for the previous document:

Action Original implementation New implementation
function calls exec. time function calls exec. time
Click in div.grey 75 2.2ms 33 0.8ms
Click in a 46 1.4ms 24 0.6ms
Click in a 78 2.3ms 34 0.8ms
Click in a div.white 94 2.7ms 39 0.9ms

Those results make the reduced complexity obvious and show a decent performance improvement. The test has been run on a simple document with a high end machine and the latest version of Firefox (3.5). The performance gain is expected to be significant when run on less powerful hardware with older browser.

Moreover, click events occur rather rarely on the document, but mouseover, mouseout and mousemove events occur much more frequently as the user moves the cursor within a page. Dealing with those event is far more efficient with the new implementation, as long as the delegation selector conforms the previously specified pattern. This limited choice of “efficient selectors” proved to be sufficient when developing ToDoSo.

An advantage of improving the jQuery.filter() function rather than the .live() function directly is that it benefits all function of jQuery using the former: .filter(), .is(), .hasClass(), .closest() and .live().

The model

The database

The model of the application has been built with the specifications of the project in mind and the will to make it future-proof. Although it was only supposed to support an application used for managing presentations, creating/editing slides and playing presentations, it seemed sensible to enable, in its design, features such as revision control, collaboration as well as the possibility to store different kind of documents in the application. The following criteria have been considered

  • in order to make the model more generic, it is designed for “multi-parts documents”, rather than “presentations composed of slides”,
  • the different parts of a document are split to make it possible to load only the parts of the document that the user needs (lazy loading),
  • the HTML terminology is used to designate those “multi-parts documents”, a document being an <article>, which is composed of an unlimited number of <section>s
  • a document has a unique creator, a user registered in the application, although it might later have multiple authors if collaboration is to be enabled,
  • there are no folders in the application, but presentations can be tagged with an unlimited number of tags and later sorted by tags,
  • the bin is just a tag which, when applied in a document, prevents it to be displayed in the main view,
  • a document can have a theme, which is stored as a style (using the CSS format) that will be applied to all of its parts
  • additionally a document can be associated with a piece of script describing its background as vector graphics for example (to be translated either to SVG or VML)
  • a section of a document has an HTML content, a style to overwrite the theme of the document and define the layout of the content, as well as a piece of script used to represent its vector graphics content in a browser agnostic way,
  • the script, the style and the html content are split to make version control easier (details follow)

This description of the model can be graphically represented as follows:

About the version control

Version control would be easy to implement with this model because it makes creating a new revision of the document inexpensive: when the content of a single section is modified, instead of duplicating the whole document, a new version of the this specific content is created, and only the representation of the document and the sections are duplicated, not their unmodified content. This mechanism is illustrated in the following figures.

Since there is no content at all directly in those representations, the database does not expense at an exponential rate. The elements coloured in red in those figures are the ones potentially heavy weight.

The way the revision control could be implemented is rather clear: to restore a previous revision, a relation between the user an the previous revision (found through the current revision) has to replace the current relation.

Developer friendly technologies

Since ToDoSo is a too important project for a single person, it appeared as important for its underlying technologies to be easily learned by external developers willing to contribute to the project.

Being a Web application, the choice is naturally limited to Web technologies and the project will likely drive the interest of developers with technical skills related to the Web.

The client-server relationship on the Web

The Web is a particular platform to work on, since it is strictly divided in two parts:

  • the server side, which refers to the part of the application hosted on a server,
  • and the client side, which refers to the part of the application that is executed directly in the Web browser of the users.

Originally, this client-server relationship was described as a thin-client: the server being the host of all the logic of the application while the client, in this case the Web browser, was a rather passive one, only able to request an URL, process the incoming HTML code into what the user knows as a Web page and sending back a request (sometime with form data) for a whole new page. Since the introduction of JavaScript in the Web browser, they evolved in smarter clients now able to dynamically and partially update the page ― known as ajax techniques (Paulson, 2005) ―, turn static Web pages into rich user interfaces ― gmail often being quoted as the pioneer of Web applications (O’Reilley 2007) ― and even use them for distributed computing (Klein and Spector 2007).

Client-side technologies

As it has already been mentioned, in addition to HTML and JavaScript, other client-side technologies are available as plugins for Web browsers, such as Flash and Silverlight. Not only have the latter ones a limited accessibility, but Web developers are also more likely to be familiar with the still prevalent Open Web technologies.

The obvious advantage of those plugins is that they provide a consistent environment across the variety of configurations that they support: a website built for Flash will be displayed exactly the same way in Internet Explorer 6 on a Windows computer as in Safari 4 on a Mac OSX computer. There are, however, numerous inconsistencies between configuration that have to be dealt with when using Open Web technologies:

  • There are different browser vendors with different implementations of HTML rendering engine and JavaScript engine. All of them are supposed to follow the w3c recommendations for HTML, CSS and the DOM interface as well as the ECMA-262 standard for JavaScript. Due to the complexity of those recommendations, the difficulty for all browser vendors to agree on them and their constant evolution ― not even mentioning the so called browser war between Microsoft and Netscape in the late 90′s (Phillips, 1998) and backward compatibility issues ―, there are unavoidable differences between the way a single Web page is interpreted in two different Web browsers, either because of an incorrect, incomplete or flawed implementation.
  • There can be different versions of a browser in use at a given time. According to Net Applications, there are currently 27% of Internet Users using IE6, 23% using IE7 and 12% using IE8. If an implementation is improved or fixed in the new version of a browser, it is therefore impossible to assume that all users will benefit from it.
  • The fonts that can be used in a Web page is still limited to the ones available in the rest of the Operating System and the displaying of the text relies on the OS capabilities. This can result in differences in the width and height of textual elements.

Dealing with JavaScript

JavaScript is the most consistent technology of this set. Although some browsers implement more recent versions of the standard, all current browsers comply with the version 1.5 of the norm, which has proven to have appropriate features for large scale Web applications.

Dealing with the DOM

In order to deal with DOM inconsistencies as well as simplifying common operations on Web pages, numerous JavaScript libraries (sometime named toolkits or frameworks) were created, the most widespread ones being Dojo, Prototype, YUI, jQuery and Mootools.

There does not appear to be any objective comparison of these different libraries in the literature. Indeed, being Open Source software, they have influenced influenced each other to a point where it is difficult, if not impossible, to pick one as the best. Their common traits are:

  • simplifying DOM traversing and manipulation, i.e. inserting, finding, moving and deleting elements of a Web page,
  • simplifying the modification of elements’ attribute such as class or style attribute to dynamically change the appearance of an element,
  • providing methods to change the style attributes of an element over time to animate it,
  • providing an unified API for ajax instead of the one implemented in w3c compliant browsers and its counterpart in Internet Explorer,
  • providing an unified API for event handling (i.e. detecting a user’s actions on a page) instead of the one implemented in w3c compliant browsers and its counterpart in Internet Explorer and providing helpers to deal with event delegation.

The library of choice for this project is jQuery, because of its clean API, its light weight and its thorough documentation. The jQuery philosophy is unofficially summarized in “Find things, do stuff“: The page is queried with a CSS selector (a mechanism that every Web developer is familiar with) and the selected elements can then be manipulated using jQuery methods.

[code lang="js"]
$("#myButton").click(function() {
$("<span>Hello World!</span>").hide().appendTo("#myParagraph").fadeIn();

The previous snippet of code illustrates the different possibilities of jQuery, its conciseness and the principle of chainability: once an element has been selected in the page, different operations can be applied at once. It reads as follows:

  1. find the element with an id “myButton”,
  2. when it is clicked executes the following…
    1. create a text wrapped in a span element (this is an HTML syntax),
    2. make sure it is hidden …
    3. … before appending it to the element with the id “myParagraph”,
    4. gradually modify its opacity from 0 to 100%.

Although there are no clear statistics of the usage of the different libraries, the growing popularity of jQuery amongst Web developers, illustrated by its inclusion in the set of tools distributed with Microsoft’s Visual Studio IDE, as well as its documentation is expected to make it easier for external developers to contribute to the implementation of the client-side part of ToDoSo.

Dealing with CSS

CSS is the languages that suffers the most inconsistencies on the Web. In their latest versions, all browsers appear to be compatible with a large subset of CSS2.1, but as outlined previously, there are still around 50% of Internet users browsing the Web with older versions of Internet Explorer.

A simple solution would be to enjoin users of old browsers to update to the latest version. However, in a recent survey lead by digg, one of the largest social news Website, it appeared that 70% of those users are using IE6 because they are not allowed to install a different browser on their computer[1. Much Ado About IE6 ]. Although this number cannot be generalised, it tends to indicate that ToDoSo should be compatible with IE6 to be accessible to most users. Since ToDoSo is not expected to be publicly available before several months, a compromise could be to ignore versions of IE prior to 8 during the development phase (developers are likely to have up to date browsers) and reconsider the compatibility with older versions of IE later. Their usage share might have decreased to a point where they could definitely be ignored.

Server Side Technologies

Unlike on the client-side, there is a large variety of languages and frameworks available on the server-side to build Web applications. If any environment can be used on the server-side to create Web applications, Ruby on Rails lately pioneered the field of agile Web frameworks which seem to seduce more and more Web application developers.

The Agile Manifesto defines four leading principles (Cockburn, 2002):

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

A framework that actually allows for working prototypes to be rapidly built and for changes to be answered quickly would be highly valuable, for ToDoSo is expected to become a project opened to external contributions. The choice of server side technologies was thus limited to frameworks that shared some of the key features which make Ruby on Rails an agile framework.

  • Model-View-Controller architecture
  • Object Relational Mapping
  • CRUD for all objects
  • Routing mechanism
  • HTML templating

A simplified explanation of this technical jargon is possible with a sample pseudo-code application: a Website that allows users to view the relationships between three people: Louis, Remi and Eugene.

MVC Architecture

This design patterns makes a clean separation of the application in three layers:

  • the model defines what a person is, what relations it can have, and how those different properties are remembered in the application
  • the view in this case is the HTML page used to display the people and their relations,
  • the controller is the logic that answers to users’ requests by recalling people and relationships from the application’s memory and invoking the appropriate view to display them.

The model

[code lang="js"]
// A person is defined by its name and its gender
Person = isDefinedBy({ name: "String", gender: "Boolean" });
// A person can have a relation of friendship with another person
Person.canHave( "friend", Person );
// A person can have an enemy
Person.canHave( "enemy", Person );

Once the memory of the application contains some person, the controller can retrieve them and pass it on the the view to produce the following output:

[code lang="html"]
<b>Louis</b> is a <em>male</em>.
His/Her friend is <b>Remi</b>.
His/Her enemy is <b>Eugene</b>.

Such a clean separation makes modifying one of those layer safer and easier.

Object-Relational Mapping

Traditionally the people and their relationships would require two different representations in an application built with an object-oriented language and a database, typically using either Classes or SQL queries. In such paradigm, making Remi a friend of Louis is a rather complicated task:

[code lang="js"]
// Insert a Person in the database and returns its assigned id
function insertPerson( name, gender, friendId ) {
"INSERT INTO 'person' ( 'name', 'gender', 'friend_id' )" +
"VALUES ( '" + name + "', '" + gender + "', '" + friendId + "' );"
return DB.lastInsertId;
// Build Remi first
remi = new Person({ name: "Remi", gender: 1 });
// Save him
idRemi = insertPerson(, remi.gender );
// Then build Louis
louis = new Person({ name: "Louis", gender: 1 });
// Save Louis while making him friend with Remi
idLouis = insertPerson(, louis.gender, idRemi );
// And later...
// Find Louis' data in the database
data = DB.execute( "SELECT ALL FROM 'person' WHERE 'id' = '" + id + "';" );
// Recreate Louis from its data
louis = new Person({ name:, gender: data.gender, data.friend_id });

Using an Object-Relational Mapping layer, the database is abstracted away and relations defined between two objects of the model can be applied directly between Louis and Remi.

[code lang="js"]
// Build and save Remi
remi = new Person({ name: "Remi", gender: 1 });;
// Build Louis, make Remi his friend and save him
louis = new Person({ name: "Louis", gender: 1 });
louis.make("friend", remi);
id =;
// And later...
// Recreate Louis from the database
louis = Person.findById( id );

CRUD for all objects

CRUD stands for Create, Read, Update and Delete which represents the basic operation required for the complete life-cycle of an object in the application. In agile frameworks, once an object is defined in the model, it is automatically possible to use “create”, “update” and “delete” methods on every person, “read” being available on the Person object.

[code lang="js"]
// Build Louis
louis = new Person({ name: "Louis", gender: 1 });
// memorise Louis <=> Create
id =;
// Turn Louis into a female
louis.set("gender", 0);
// Make sure this change is memorised <=> Update
// Get rid of Louis <=> Delete
// Try to find Louis in the memory <=> Read
Person.findById( id );

Routing mechanism

This mechanism allows for urls to be mapped to specific actions of the controller. For example, when visiting, an Web page with the details of the person that has the id 1 should be displayed to the Internet user.

[code lang="js"]
personController = new Controller(function( id ) {
// Fetch data from the memory
data = Person.findById( id );
// Pass it on to the view
personView = Views.invoke( "person.html" );
personView.pass( data );
personController.mapTo( "/person/:id" );

HTML templating

A template engine makes it possible to put place-holders for data of the model directly in an HTML document. Those place-holders are then replaced by the data fetched by the controller before being sent to the client.

The following template would be used to produce the aforementioned view output:

[code lang="html"]
<b><? ?></b> is a <em><? data.gender ?></em>.
His/Her friend is <b><? data.friend ?></b>.
His/Her enemy is <b><? data.enemy ?></b>.

The related controller being:

[code lang="js"]
personController = new Controller(function( id ) {
// Fetch a person from the memory
person = Person.findById( id );
// Find his friend
friend = person.getRelated( "friend" );
// Find his enemy
enemy = person.getRelated( "enemy" );
// Build the data to be passed to the view
data = {
gender: person.gender,
personView = Views.invoke( "person.html" );
personView.pass( data );

Choosing an agile Framework

After spending some days looking in the literature and on the Internet, the selected frameworks were Ruby on Rails, Django (Rails’ python counterpart), Symfony (for PHP), Grails (for Java) and ActiveJS (for Jaxer).

Once again, it appeared impossible to pick one as the best. ActiveJS was finally selected for ToDoSo because, despite its lack of maturity compared to other frameworks, it had numerous features that was likely to make it easier for external contributors to adopt it:

  • it is meant to be executed by Jaxer, which is basically a Web browser stripped from its rendering engine to run on the server side. Web developers can thus leverage their client-side skills on the server-side with the possibility:
    • to access and modify the DOM on the server before it is sent to the client,
    • to share code between the client and the server sides (for safe but instantaneous form validation for example),
    • to call server side function from the client side (using invisible ajax requests)
  • it offers an abstraction not only to MySQL and SQLite databases (on the server-side) but also to client-side persistence such as Google Gears
  • its has a routing component similar to the Ruby on Rails’ one but also offers deep linking on the client side (enabling the use of the browser’s “back” button in ajax based Web applications)

Any developer able to use Open Web technologies would then find a familiar and consistent environment to work both on the server and the client side.

Aiming for Accessibility in a Presentation Software

Since none of the existing on-line presentation software has been found to be accessible to keyboard navigation and screen reader users, none of the Web technologies used in this applications (HTML, Flash or Silverlight) clearly stands out as the technology of choice to achieve accessibility in a presentation software. A deeper comparison of has thus to be undertaken.

What makes an application accessible?

Accessibility is a general term used to describe the degree to which a product (e.g., device, service, environment) is accessible by as many people as possible.

Wikipedia, The Free Encyclopedia

It is important to note that accessibility concerns are not oriented only oriented toward people with disabilities in its common sense. To some extent, everybody has some disabilities when it comes to using a computer application: most elderly people don’t have heavy sight problems but they might just be reluctant to use them because of the technological barrier, children might prefer to go out and play football rather than seat in front of a screen, businessmen might be using a mobile device with a small screen without a real keyboard… The finiteness is anyway a handicap shared by all humans: there is so much to do, so little time.

To the variety of individuals corresponds a variety of expectations against which the accessibility of the application will be evaluated: the elderlies are likely to prefer simplified software, children might be more keen on the ones that are enjoyable, whereas professionals are looking for powerful applications that do not make them waste their time. Accessibility can thus encompass notions such as usability, hedonistic, usefulness. From this point of view, technologies that help produce highly visual and dynamic applications might, for a particular user target, be the most accessible ones, despite their lack of compatibility with screen readers.

What makes a presentation software accessible?

A presentation software is multiform: it consists of different interfaces to manage, display and edit presentations, as well as the documents themselves. No claim of accessibility could be made unless both the interface and the content are accessible.

User Interface Accessibility

In all studied software packages, the main purpose of the management interface as well as the player is to allow the user to navigate through a set of documents or the different parts of a document. This navigation is usually possible both by using a pointing device and clicking on navigation buttons (play this presentation, display the next slide) or by using keyboard alternatives. The three aforementioned Web technologies all offer mechanism to make those controls accessible to visually impaired users: in all cases, text alternatives can be assigned to the buttons by the developers and this text as well as other textual elements of the page can be read aloud by screen readers.

The main purpose of the authoring part of a presentation software is to allow users to compose a slide by placing different kinds of elements (titles, bullet-points, quotations, images, graphs) in a particular layout. As pointed out in the project specifications, an important part of the information in presentations is carried out visually. It might be possible to create a presentation authoring tool specially for visually impaired users. Adapting a traditional one to those users seems however almost as challenging as adapting a drawing package for blind users, the issue here being rather a matter of usability than a technical one.

To be able to provide a pleasant navigation in the application, the underlying technology should allow for smooth effects (fade transitions, position animation) to be applied to the User Interface. Flash has always been famous for its animation capabilities, which are extensively used in on-line advertisement or in-browser games. Silverlight has been conceived to have equivalent capabilities notably in term of animations and visual effects (Paries, 2008). It is now possible to animate HTML documents as well, thanks to JavaScript libraries such as Scriptaculous, jQuery and Mootools, resulting in visually attractive Websites that would have been realised with Flash yesterday.
There is a lack of comparison of the animation possibilities and performances of those three technologies in the literature. It is thus hard to guess if the effects will always be smooth and not exceed the resources of low-end hardware.

Content Accessibility – Text and Images

As pinpointed in the project specifications, the nature of information in a slide is textual and visual. If the text is accessible to visually impaired users through assistive technologies and to Web crawlers, the purely visual information is not.

Although it is possible to provide textual alternative for non-textual content using Flash or Silverlight, there is no way to preserve the distinction between titles, paragraphs, bullet-points and quotations.

In HTML however, the content is surrounded by semantic tags, i.e. indications about the nature of the text. The following slide…

A screenshot of a slide with a title, a bullet-point and a quote

… could be written as follows in HTML4 …

[code lang="html"]
<div class="slide">
<!-- The title of the slide is a heading of second level -->
<h2>A Cat's Guide to World Dominashun</h2>
<!-- bullet-points are nested in an Unordered List... -->
<ul> <!-- List Items -->
<li>Be careful, some are laready suspicious:</li>
<!-- The following tag is rather self-explanatory -->
In ancient times, cats were worshiped as gods.
They have never forgotten this.
― Terry Pratchett
<!-- this tag indicates the end of the quote -->
<!-- note the / at the begining of the closing tags -->

This added structure and semantic is used by the screen reader which will state, while reading the content, that the first line is a heading, the following is a bullet point, followed by a block-quote, etc… Using a screen reader, it is also possible to jump from heading to heading using a keyboard shortcut and to use possible internal links to access directly the navigation menu. When the query “world dominashun” is typed in Google, the first results will be pages that have those two words in their headings, because they have a higher importance than if they were used in a paragraph.

In HTML4 there are no semantic tags that could be used to represent a slide or a presentation. The HTML5 propositions introduces new ones including the section and the article tags:

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading, possibly with a footer.

The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.

The section tag seems appropriate for the slides and the article tag seems appropriate for the presentation. All current browsers but Internet Explorer are able to deal with unknown tags. In the latter, a special script has to be used before being able to style the elements. Those elements are not yet recognised by assistive technologies either and are currently ignored.

Content Accessibility – Vector Graphics

In addition to text and image elements, users should be able to use vector graphics to create chart and diagrams in a slide. This would effectively make ToDoSo useful for a large variety of professional users.

Vector Graphics are traditionally the prerogative of Flash as browser vendors never agreed on a common standard. Despite being not interoperable, all browsers have native vector graphics capabilities which integrates with HTML. Just like Flash, Silverlight provide the possibility to create and manipulate vector graphics.


Although Flash and Silverlight seem to be appropriate technologies to make ToDoSo accessible to its average target users, they fail to make the content of the document accessible to visually impaired users as well as Web crawlers. Moreover, those two technologies requires the client to have an additional plugin installed on its computer and those plugins are not available for all configurations (see project specifications). HTML5, on the other hand, would allow for the whole application but its authoring part to be accessible to people using assistive technologies and/or keyboard navigation. Thanks to JavaScript, it is now possible to apply rich visual effects on HTML content and use browser native capabilities to render vector graphics, effectively aligning the Open Web technologies with the other rich multimedia technologies of the Web.

This is Not the End

It’s actually only the beginning.

ToDoSo is slowly moving to Aptana Cloud: the website first, and… the first version of the server as well!
Be kind with it, it is still very young. There is no point in mentioning that it is a prototype that needs a lot of work.
What it needs more than anything is care.

The next week or so will see no development of the application itself but many posts on this blog, as I’m writing the final report of my Master.

Server-side JavaScript and working with ActiveJs

In my effort to make it easy to contribute to ToDoSo, I have chosen JavaScript as the server side technology for this project.

Although Ruby on Rails is the technology of choice for most Web applications that appeared lately on the Internet [1. twitter - most job offers require to be familiar with this framework -, github, uservoice, zendesk, lighthouseapp - all of them using the Ruby on Rails cloud engineyard - and getsatisfaction - created by rubyredlabs - to name a few], it requires to learn not only HTML, CSS and JavaScript for the client side development but an additional technology for the server side development (a new language and a complete Framework in the case of Ruby on Rails).

Some would argue that Ruby is a really simple and rather self explaining language, that Ruby on Rails is a mature framework and altogether they make Web development a breeze once you know how to use it. I agree, but I also know that JavaScript is a great language as well and that it would lower the technological barrier if it was possible to use it on the server side with a framework comparable to Ruby on Rails.

There are already a large number of server-side JavaScript interpreter listed on wikipedia and on the ServerJs project page of Mozilla. There is also Jaxer, developed recently by Aptana. I recommend to watch the introductory videos on to have a brief overview of what is possible with it, but in brief its main features are:

  • the possibility to access and modify the DOM on the server before it is sent to the client (you can even use the canvas API to dynamically create images)
  • the possibility to share code between the client and the server sides (you only have to write your form validation logic once)
  • the possibility to call server side function from the client side (using invisible ajax requests)

Most of those server-side interpreters are based on open-source JavaScript interpreters that are to be found in modern web browsers [2. SpiderMonkey and V8 mainly, I haven't heard about any based on SquirrelFish or TraceMonkey so far but it seems that Jaxer will switch to the latter] which means that they benefit from the same speed improvements that we saw recently in Web browsers.

There are also few JavaScript MVC frameworks similar (at least in the spirit) to Ruby on Rails built on top of this server technologies: the most advanced ones seem to be Helma NG and ActiveJS. Both projects however, still seem to be in an early stage of development. Once again it could take ages to make a deep comparison of those and it wouldn’t help to get ToDoSo real. Instead you’d rather choose one and stick with it for better or for worse.

I’ve chosen ActiveJS because it is built originally for Jaxer and thus doesn’t require any configuration to get started if you are developing with Aptana Studio. Moreover, the ORM layer of ActiveJS (ActiveRecordJS) offers an abstraction not only to MySQL and SQLite databases (on the server side) but also to client-side persistence such as Google Gears or the SQLite database that is to be found in Safari and the iPhone Web browsers. Its route component is similar to the Ruby on Rail’s one but also offers deep linking on the client side, in the Jaxer spirit.

Hacking into ActiveJS

Because ActiveJS is still young, it is really likely to miss some features that might be important for your project and the best solution will be to hack into it instead of waiting for someone else to do the job. So here is how to configure a development environment to be able to build ActiveJS from sources (as a reminder for myself):

  1. I assume you are developing with Aptana Studio and you have the Jaxer and Git plugins installed.
  2. Fork the ActiveJS repository on Github.
  3. Import it as a project in Aptana (File > Import > Git Repository, choose git+ssh as the protocol and don’t change the username)
  4. Ruby needs to be installed in its 1.8 version because the build script depends on ftools, which is deprecated in ruby1.9. With Ubuntu and probably other linux distribution, the ruby-dev package is required as well.
  5. The package rubygem is then required to install most dependencies of the build script: json, packr (beware, this might soon be replaced by YUI) and rdiscount. In any case look at the beginning of build.rb to find the dependencies of the script.
    [code lang="shell"]$ sudo gem install rdiscount [/code]
  6. Remember to configure your editor to use 4 spaces instead of tabs and try to respect the coding style.

Et voilà! You’re ready to change the files in the src folder, build active.js, test your modifications and send pull requests to the original branch.

[code lang="shell"]
$ ruby1.8 ./build.rb compress

My first tasks will be to improve the relationship features because it doesn’t behave as a proper ORM layer currently and to add support of HTML5 elements to the view component.

Getting ToDoSo Real!

I’ve finally been reading Getting Real: a great book by the guys behind Ruby on Rail, about the method to get a Web application real: online,  engaging and ready to use as soon as possible. It changed my plans for the work to come on ToDoSo without any doubt.

There are only five weeks left until the hand-in date of the project’s report, and what has been achieved so far? I’ve written quite a good specification of the project with a detailed analyze of the accessibility issues in presentations, I’ve dived deep into the mess that vector graphics are on the Web… But I’ve been creating mockups for less than one month and the first prototype is not even one week old. What exciting part of the application have I to show? Well, I’m proud of this first mobile prototype but it’s a bit far from the core of a presentation software.

I was intending to write about the rational behind the interface concepts and stuff… Yes, I could spend hours talking about why I’ve chosen the Open Web, Github, jQuery, Jaxer,  just like I wrote 2000 words to compare dojo.gfx to Raphaleljs. Eventually I would event gain enough knowledge in some of those technologies to conclude that they are not good enough and start my own project. But this is pointless, it is a waste of time, effort and creativity. This is not helping to get ToDoSo real, to let people get as excited by it as I am. Worse, it’s even undermining my enthusiasm to have to write about that when I could be creating svg mockups or coding some prototypes with my weapon of choice. Focusing on the details, thinking about all the insignificant features of v2.0 and considering performance problems early on is definitely things that I’ve done wrong.

I’m instead going to put all of my efforts into getting real, starting yesterday : ) I’m going to write stories about ToDoSo: why people would use it and which feature they could expect from it. I’ll also create the mockups of the authoring part of the application (and strip the shiny vector graphics and animation feature out) and create the most important prototypes: the player, the authoring part and the management interface (maybe in a different order). I’ve already updated the homepage of the project to add a small description and separated the content into tabs.  I’ve opened a Launchpad for the project and I’m going to twitt more regularly about it.

I’m anyway pleased to have the confirmation that there are parts of this project that I’ve been doing right: starting with the interface, epicenter design, using real words (the “Cat guide to world dominashun”)… and choosing the name of the app (definitely better than SlideMe ; )

Whoever you are, you, visitor of this blog, please do not hesitate to be the first one to file a bug in launchpad, or to ask a question there!

"I won't make you click": exploring the potential of presentation on mobile

In one of my Master’s module, I designed and developed a script to display presentations on mobile devices (typically a smart-phone with a Web browser). The presentation was a simplified HTML file with all the slides stacked one on top of the other, each one displayed in full screen. It took me quite a long time to find a way to enable users to navigate through those slides and to get it to work on one device. Basically the world of mobile browser is a horrible mess, even when trying to work with Webkit based browsers, I was still facing some strange behaviors in the way events were handled.

I did manage to have it work on Android few days before the hand-in date of the project and realized that the result was not that impressive. In a corner of my brain there was the idea of using a mobile device to control a projected presentation. That seemed cool. So in 24 hours I read through the documentation of cometD, set up a server and hacked into the code (only the client side part) to get a functional prototype. It turned out that it was not only cool as my teachers thought that this was the main purpose of my project.

Anyway, time has passed and the cometD server no longer works, so I can’t produce any video to demonstrate it. However, while watching a video of Mozilla’s design challenge, I realized that my script required to tap the screen at least twice to navigate, when using only the native scroll of the browser was far enough! So I produced the first prototype of ToDoSo. Go ahead, give it a try. It won’t bite and I won’t even make you click!

I hope that this feature is not only cool, but also useful:

A presentation-assisted talk is in most case given in front of an audience, with the presentation projected in the back of the speaker. To be able to refer to his/her presentation, the speaker can use a remote control, which allows for moving freely but requires to turn back and look at the screen. Alternatively, the speaker can stand in front of a computer, allowing him/her to face the audience while restraining his/her movements.

A mobile device could take the best of both world if it was able to display a presentation to the speaker and control the slides faced by the audience.

New mockups and keyboard navigation

I’ve added mockups demonstrating the appearance of the presentation when an embedded one is maximized. Since it is pure HTML, it is not going to be opened in a different window unlike a Flash video, it is rather going to overlay all the page.

todosOverlay, the overlay plugin used on the intro page of ToDoSo, is now an independant project since it tends to become a full featured overlay plugin. It is now possible to use the keyboard for navigation and I got rid of some graphical glitches. I’m quite proud of its look & feel. The idea of using buttons looking like keys  is likely to be used again in ToDoSo since it seems like a great way to make keyboard shortcuts discoverable.