Let’s get some rest.

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:

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:

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:

Section = ActiveRecord.create('sections', {
	article_id: ''
});

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

section1 = Section.create({ });
section1.createArticle({
	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.

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 div.red to .yellow, the following code would be used:

$("div.grey").find("div.red").live("click", function( event ) {
// event.currentTarget is the clicked red.div
$(event.currentTarget).removeClass("red").addClass("yellow");
});

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 div.red inside the div.grey
   2. a function loops through all the retrieved div.red to check if the event target is one of them, and fails.
2. the ancestor of the event target (the top left div.black) needs to be checked in the same way
   1. the DOM is accessed to retrieve all div.red
   2. a function loops through them, searching for the parent div.black, without success
3. finally, the ancestor of the div.black (the top left div.red)  is checked
   1. once again the DOM is accessed to retrieve all div.red
   2. a function loops through them and the top left div.red is one of them
4. as of jQuery 1.3.3, the currentTarget property of the event object is set to the found div.red

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, “div.red” in this case.

However, it appears that, in the case of a delegation selector of the form “div”, “.red” or “div.red”, 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:

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 navigation in ToDoSo will occur on three different levels:

• The folder level allows the user to view all the presentations that he/she has created in the application. Although there are no folders in ToDoSo, this term is used in analogy with the file system explorer that is to be found on the desktop.
• The presentation level allows the user to navigate within a presentation, through the slides that it is composed of.
• The slide level is the one at which the player and the editor of the presentation operate: the slide is displayed in full-screen.

Those levels are detailed in a different order to clarify the rational behind their design.

Presentation level

In current presentation software, navigating in a set of slides generally requires to scroll through the thumbnail view. In desktop applications, additional ways of navigation might be provided but they are neither the default choice nor obvious alternatives.

This way of navigation is obviously convenient to navigate to the previous and next slides, however, this could also be achieved by providing two buttons labelled as “previous” and “next”. What is the real value of the thumbnails for those two slides when they could be accessed in full screen by a simple click? The visual consistency of the presentation should be guaranteed by the “theme” and “layout” features of the application, it does not require for the user to remember (or see) how the other slides look like. Likewise, the thumbnail is generally too small to have a readable content. A slide has to be in the main view for its content to be readable.

The usefulness of the thumbnail view resides in the possibility for the user to quickly search for a particular slide, which is likely to be easily identified visually. It requires, that the user points at the thumbnail view with its mouse, then scroll until he/she finds the slide and finally click on it. If it is a long presentation, this can be a rather long process with those slides stacked on top of the others in a single dimension.

The solution that will be explored in ToDoSo is to remove the thumbnail view from the interface and to create a zoomable bi-dimensional map of the slides.

When a presentation is opened, this map is displayed to the user who can simply double-click on a slide or point at it ans use the mouse’s wheel to zoom in. Once a slide is zoomed in, controls appear to let the user access directly the next and previous slides, and to zoom out to search for a particular slide in the map.

This way of navigation can be compared to the one used in Google Maps and which is generaly referred to as Zooming interface (Cockburn et al., 2008) or Zooming Interface Paradigm (ZIP) (Raskin, 2000).

Folder level

It would be tempting to apply the Zooming Interface concept to the folder level to provide a coherent way of navigation throughout the application. However, this would require to display all the slides of all presentations at this level which in turn requires to have very tiny thumbnails to be able to fit multiple presentations on the same view. Instead, it has been decided to present only the first slide of a presentation at this level.

A visual clue should be provided to differentiate this level from the presentation level in addition to the different menus and toolbars, such as a a different background colour.

To switch to the presentation level, the user would simply double click on a presentation to reveal its full content while other presentations are hidden.

Slide level – the player

The player is designed to let the user access to the next and previous slides as well as playing the possible animations of the slide and switch back to the presentation level.

In this mockup of the player, the buttons have been given the look of keys. This emphasise the possibility to use the keyboard as an alternative to control the display of the presentation. Indeed, when the presentation is played during a lecture, the buttons should be hidden and a keyboard or a remote control could be used instead of the mouse. Those buttons actually fade out when the pointer of the mouse is moved away from the slides.

The button with the bigger arrow corresponds to the “play” button: the main control that either triggers an animation or the display of the following slide if all the animations have been played.

Slide level – the editor

This part requires further research before a valuable design could be produced.

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.

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.

$("#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

// 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:

<p>
	<b>Louis</b> is a <em>male</em>.
	His/Her friend is <b>Remi</b>.
	His/Her enemy is <b>Eugene</b>.
</p>

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:

// Insert a Person in the database and returns its assigned id
function insertPerson( name, gender, friendId ) {
	DB.execute(
		"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.name, remi.gender );
// Then build Louis
louis = new Person({ name: "Louis", gender: 1 });
// Save Louis while making him friend with Remi
idLouis = insertPerson( louis.name, 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: data.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.

// Build and save Remi
remi = new Person({ name: "Remi", gender: 1 });
remi.save();
// Build Louis, make Remi his friend and save him
louis = new Person({ name: "Louis", gender: 1 });
louis.make("friend", remi);
id = louis.save();
// 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.

// Build Louis
louis = new Person({ name: "Louis", gender: 1 });
// memorise Louis <=> Create
id = louis.save();
// Turn Louis into a female
louis.set("gender", 0);
// Make sure this change is memorised <=> Update
louis.update();
// Get rid of Louis <=> Delete
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 http://myapp.com/person/1, an Web page with the details of the person that has the id 1 should be displayed to the Internet user.

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:

<p>
	<b><? data.name ?></b> is a <em><? data.gender ?></em>.
	His/Her friend is <b><? data.friend ?></b>.
	His/Her enemy is <b><? data.enemy ?></b>.
</p>

The related controller being:

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 = {
		name: person.name,
		gender: person.gender,
		friend: friend.name,
		enemy: enemy.name
	}
	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.

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…

… could be written as follows in HTML4 …

<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> <!-- ...as List Items  -->
		<li>Be careful, some are laready suspicious:</li>
	</ul>
	<!-- The following tag is rather self-explanatory -->
	<blockquote>
		In ancient times, cats were worshiped as gods.
		They have never forgotten this.
		― Terry Pratchett
	<!-- this tag indicates the end of the quote -->
	</blockquote>
<!-- note the / at the begining of the closing tags -->
</div>

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.

Conclusion

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.

Important notice: the following post is likely to be largely modified in the next days due to the importance of this topic in the scope of my Master project.

An obvious criteria of usability for an application in general is its performances. This criteria encompasses the initial load time of the application and the potential transitions time between the different states of the application (e.g. the different screens of a desktop applications or the different pages of a Website). There are two complementary ways to tackle it:

• identifying the technical parameters involved in the length of those load times and taking actions to make the application faster,
• identifying the psychological factors of perceived performance by the user and taking actions to make the application feel faster.

Making the application faster

Over the past decade, performance on the Web is an area that gained an increased attention as Websites moved from static text-based content to dynamic and multimedia Web applications. The literature is an important source of information about back-end performances, informing about the different servers (e.g. Hu et al 2007), architectures (e.g. Barroso et al 2003) and patterns (e.g. Pyarali et al 1999).

Lately, majors actors of the Internet including Yahoo and Google started to advocate front-end optimisation as an easy and effective way to achieve performances on the Web. Yahoo published guidelines for “High-performance web sites” (Souders 2008 and its online and more up-to-date conterpart: Best Practices for Speeding Up Your Web Site) along with a browser plugin which measures the performances of a Web page against those guidelines: YSlow.

The approach adopted in ToDoSo was to delegate the responsibility of back-end optimisation by using a cloud computing service and an existing Web application framework, while concentrating on front-end optimisations using Yahoo’s resources.

Back-end performances – the infrastructure

One of the fastest growing trends about Web infrastructure during the past two years seems to be the cloud computing.

Cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet. Users need not have knowledge of, expertise in, or control over the technology infrastructure in the “cloud” that supports them.
‒ Wikipedia, the Free Encyclopedia

In the case of Web applications such as ToDoSo, it allows project managers to rely on a third’s expertise in building, refining and maintaining an efficient infrastructure which will run the application in optimal conditions.

In addition to the enterprise-oriented cloud computing offers (see DELL, Sun Microsystems, Microsoft, IBM, Joyent and Vmware services), there are now more affordable solutions aimed at developing projects such as Amazon EC2, Google App Engine, Engine Yard and Aptana Cloud.

The latter has been chosen in ToDoSo…

• because it is based on Joyent services, which is a guaranty that the infrastructure will be able to scale with the application until it becomes the next Facebook,
• because of its low starting price ($0.027/hour, second only to Google’s free plan),
• because of its large variety of preconfigured environments (PHP, Java, Jaxer, Rails, Python) which makes it possible to switch easily if the first choice proves to be a bad one,
• and because of its tight integration within the Integrated Development Environment used throughout this project ‒ Aptana Studio ‒, effectively reducing the complexity of the deployment.

Back-end performances – the development Framework

Performances were not a key factor when it came to choose the development framework for ToDoSo. There is a vast choice of existing frameworks for Web applications; producing an objective comparison of their respective performances would have therefore required a tremendous amount of work that this project could not obviously afford. The choice was limited to the Open Source frameworks available on the chosen infrastructure and was actually based on the gentleness of their learning curve. Additional details are provided in the section related to “Developer Friendly technologies”.

Being Open Source software, it would be possible to fine-tune the application on different levels later in the development process, if required. It should also be noted that the less expensive cloud computing service for the Microsoft .Net platform appeared to be Amazon EC2, starting at $0.125/hour, i.e. 460% the price of the first plan in Aptana Cloud.

Front-end performances – Yahoo guidelines

Yahoo’s “Best Practices for Speeding Up Your Web Site” is a set of 34 best practices which can significantly improve the speed and responsiveness of a Web site. The following part describes which have been applied to ToDoSo and how.

• Some instructions are straightforward and have been carefully applied along the development of the application:
  • Put Stylesheets at the Top
  • Put Scripts at the Bottom
  • Make JavaScript and CSS External
  • Use GET for AJAX Requests
  • Reduce the Number of DOM Elements
  • Choose <link> over @import
  • Don’t Scale Images in HTML

• Some best practices leave much more freedom to the developer when it comes to their technical implementation:
  • Minimize HTTP Requests
  • Minify JavaScript and CSS
  • Gzip Components

These rules can be summarized into “reduce the amount of external resources to download”.

For that purpose, RockstarApps provides the JsLex plugin for Aptana Studio. Once installed, <link> or <script> tags can simply be selected from the source of a Web page; a dedicated options in the right-click menu can then be used to concatenate, minify using YUI Compressor and archive in gzip the source files all at once, while the selected tags are replaced by a single one pointing at the new optimised resource.

• • Use a Content Delivery Network (CDN)
  • Split Components Across Domains
  • Add an Expires or a Cache-Control Header

These rules can be summarized in “improve the external resources download speed”.

A [CDN] is a system of computers networked together across the Internet that cooperate transparently to distribute content for the purposes of improving performance and scalability.
‒ Wikipedia, the Free Encyclopedia

Just as for cloud computing, there are enterprise-sized CDN, the most famous one being Akamai as well as solutions adapted to smaller projects. Amazon offers two services, Simple Storage Service (Amazon S3) and CloudFront, which, once combined, constitute a CDN with no minimal fees and a competitive pricing: according to Bob Buffone, the monthly cost for a Website receiving more than 200 visitors a day is around $0.15¹.

There is another Eclipse plugin for Amazon Web Services by RockstarApps which allows Web developers to upload static resources to Amazon S3. The gzip compression must be applied before uploading the resources on S3 since, being a passive server, it does not archive files on the fly. Appropriate headers must therefore be set on the files (”content-type: text/css” and “content-encoding: gzip” for a CSS, “content-type: text/javascript” and “content-encoding: gzip” for a JavaScript), which is automatically done for files with the extension “.css.gz” or “.js.gz” by the plugin. In Safari and Google Chrome however, the extension takes precedent on the headers; the .gz suffix has therefore to be removed, which is not possible in the current version of the plugin.

• • Optimize Images
  • Optimize CSS Sprites

Yahoo developed its own image optimisation tool in accordance to this guideline, smush.it, which can be used directly from within the YSlow plugin. As of July 2009, Gracepointafterfive developed their own tool, punypng, claiming for their state of the art solution to be second to none. Although no benchmarks have been produced by independent testers, the early results exposed by the creator of the tool seemed encouraging enough to justify its use for ToDoSo.

• Some instructions are related to the use of script within the Web pages
  • Develop Smart Event Handlers
  • Minimize DOM Access

During the development of the different prototypes of this project, JavaScript already proved to be of a major importance in the operation of the Graphical User Interface. The library of choice for this project was jQuery, a lightweight piece of JavaScript (about 19KB once minified and archived) with a clean and easy to learn API making DOM traversing and manipulation, event handling, effects and ajax implementation a breeze. An important documentation and optimisation work has been undertaken to use the library in compliance with those guidelines.

• Finally, some instructions have been ignored because either because they were not relevant to the chosen development framework (e.g. Flush the Buffer Early) or because the problem they were dealing with did not appeared in ToDoSo (e.g. instructions related to the use of cookies or iframes)

Conclusion

By getting familiar with simple rules that have then been applied during the development of the application, choosing affordable cloud computing and CDN solutions and using few simple tools aimed at front-end performances improvements, the load time of the project’s home-page is now inferior to 2 seconds despite the dozen images displayed on it.

It should however be noted that some of those strategies have not yet been applied to the two online prototypes, since they are early previews that will be vastly modified before being usable in real conditions.

Since I’m producing rather long posts these days (and there are more to come), I figured out that some adjustment in the the layout of the pages would be more than welcome.

Nothing has changed on the home page, but when clicking on the title of a post (or following the links in a feed reader), the new width, line-height and font-size should prevent the “there’s-no-way-I’m-reading-that!” effect.

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.