[13-May-2007]The last week was rather quiet and while I'm still working on a major project about Rich Internet Technologies comparison, I didn't stumble over a particularly interesting part that would be worth mentioning here. Over the next days, I might release some of the documents that I wrote about RIA, such as the actual comparison methods, the result evaluation and the data types and storage methods used.

Since the launch of this site, one of the most popular resources is the Advanced Encryption Standard tutorial. While it might not be the most interesting subject and might not attract the broadest audience, I think that the quality of the tutorial is among the best you'll find on the Internet about AES. I am particularly pleased that Josh Davis used my tutorial as a starting point to implement JavaScript AES. He kindly contacted me and asked permission to use my tutorial and since everything on this page is released under the GNU Public License, he was free to use and modify the code as he pleased.

Finally, if you keep yourself updated in Rich Internet Technologies, you might be interested in hearing that SUN announced JavaFX. Especially JavaFX Script might become popular among the Java community, since Java is still a little too heavy to use for small web applications.

[04-May-2007]Over the last few weeks, my research on Rich Internet Applications was particularly focused on the increased accessibility that is provided through the use of expressive GUI widgets and how these widgets can be implemented in the different technologies, and more specifically Ajax. Before elaborating on that particular problem, it is important to first explain the basic concepts of what exactly is a widget and why it is useful in Computer Science.

According to the Wikipedia definition,

This means that widgets are the interactive elements of a computer program, that serve as an interaction medium, a link, between the user and the program. The user is limited in his actions and intentions by the possible widgets that are at his disposal, restricting his expressiveness to the different values the widgets may have.

The standard HTML widgets

Since our particular interest lies within the domain of Internet applications, let's analyze what widgets are at our disposal, using the latest HTML 4.01 specifications provided by the W3C. There are basically three different categories of elements that can be used as widgets, which are the INPUT, the SELECT and the TEXTAREA elements. The INPUT element has an attribute called type that specifies the type of control to create, which can take the following values: text, password, checkbox, radio, submit, image, reset, button, hidden and file. While this list, dating back to December 1999, provides, from a Human Computer Interaction perspective, enough means of interaction within a web application for every basic operation, it is by no means impressive and definitely not worthy of being called Web 2.0. If we compare this list to the widget list on Wikipedia, which has over thirty different types of widgets, we immediately notice the need for better widgets, that provide additional interactive possibilities and better customization.

Accessibility guidelines

Unfortunately, creating new widgets isn't as easy as it might sound. Simply throwing together graphical elements with several event listener might be functional, but doesn't correspond to the modern accessibility criteria, explained in the Web Content Accessibility Guidelines 1.0. These guidelines explain how to make web content accessible to people with disabilities but also more available to all users, whatever user agent they are using. In the HTML techniques for Web Content Accessibility Guidelines 1.0, the most important sections concerning self-made widgets are the Forms and the Scripts section, which are directly applicable to our intention to code our own widgets. The Forms section basically describes all the features that an interactive widget should have to make it as accessible as possible, ranging from keyboard access to labeling form controls and providing a text equivalent for every non-text element. The most important section in the scripts section is that one should ensure that dynamic content is accessible or provide an alternative presentation. This is commonly referred to as graceful degradation, or the ensuring that pages are accessible with scripts turned off or in browsers that don't support scripts. One might argue that these guidelines date back to November 2000, when Rich Internet Applications were less common and that nowadays most users have scripting support turned on. Imagine what would happen to the whole Flash world if these guidelines had to respected à la lettre. I'm not saying that we should change the whole widget concept because of these guidelines but we shouldn't completely forget about them either. I think that Accessibility is a very important subject and that we should try to make the web as accessible as possible. A good example for widget design principles can be found in the dojo toolkit, in the Dojo Book chapter Dojo Widget Design principles. I strongly recommend everyone to read those principles and at least intent to adapt them as closely as possible.

Widgets 1.0 Draft

The Rich Web Clients Activity Working Group is currently working on the Widgets 1.0 Draft, that covers the packaging format, the manifest file and the scripting interfaces for working with widgets. They refer to widgets as "small client-side applications for displaying and updating remote data, packaged in a way to allow a single download and installation on a client machine. The describes widget object is based on Apple's Dashboard and is intended to provide a standardized interface to self-made widgets in the future.

Unfortunately, the Widgets 1.0 format is only a draft, a work in progress, and if you are familiar with the working speed of the W3C, it is safe to assume that this won't be applied in the near future, which means we are on our own. In the next chapter, I will cover the general concept of creating widgets in Ajax, based on my experience over the last few weeks, where I spend the major portion of my time with this particular problem. Before you even consider coding your own widgets, I ask you to please carefully consider if you're doing so to increase the functionality of your interface or only for the sake of the technological aspect. Design should always primarily focus on the user experience and never be guided by the implementation challenges or the technical aspects. If the interface doesn't gain any additional functionality, your web applications will get worse if you implement your own widget. Not only aren't you using any of the standardized widgets which are fully compliant to the accessibility guidelines, you're probably also reducing the number of potential users by keeping them from interacting with your widget in non-browser user agents.

Widgets in JavaScript

I'm not going to focus on JavaScript frameworks, that already provide widgets. If you are looking for working implementations where you only have to add some lines of code to your page, then I recommend that you use the framework of your choice, but if you want to truly understand the design and implementation challenge and maybe implement your very own widget, then please continue reading. As I explained in great detail in my tutorial about creating an Ajax rating widget, the starting point for a widget is a standard DOM element, that is modified in JavaScript. Any element can be used, but if we respect the Accessibility guidelines, we have to make sure that our web application is still functional if scripting support is disabled. If we use a div container and the user has JavaScript disabled, then he won't have any interaction possibility since he'll only be presented by an empty container. As long as you ensure that there is any of the standard interaction widgets, you can use whatever you like. A good choice would be to use one of the standard widgets that is as close to what you want to achieve with your own widget as possible. If your widget is intended to only provide two different options, don't use a text field as the fail-safe replacement, since the user will likely enter a non-conform value; rather use a select menu with two options or radio buttons. You can also wrap the standard widget with a div container and remove all the child nodes of the container before inserting your own. That way, you have a good starting point to insert your widget into and you can work in a very specific subtree of the HTML DOM tree without the risk to delete something that wasn't intended to be deleted.

I won't enter into the details on how to create your own widget, the rating widget tutorial should have covered that section enough. What I want to focus on is a more delicate subject, that wasn't much of a problem during the design of the rating widget. In fact, the rating widget is designed to be used as a stand-alone widget, that issues a request upon interaction and never has to interface with other parts of the web application. While this is the generally accepted behavior of a rating widget, most widgets are user to communicate a value from the user to the application. They provide several interactive features which are translated into a value that can be used by the program to determine what the user has entered. This can be a state as in the case of a checkbox, that can be check or not, or a numerical value, as in the case of a slider. The value of the standard widgets are used during form submission, where each successful control generates a (control name, current value) pair that is transmitted in the form data set. This is a serious problem that requires additional methods to make our widget functional. Even though are widget by itself is able to handle user interaction and store its value somewhere, it isn't recognized by the user agent as a form element and thus that value isn't transmitted to the processing agent.

Implementation methods

To deal with this situation, several methods exist, of which I want to explain two. The first one uses the default form submission process to transmit the values of our widget by hooking onto the form submit button and modifying the form DOM tree before submitting the form. For this to work, it is necessary to create for every self-made widget an hidden input field, that has the correct control name and whose value is the value we want to transmit. In this case, our widget is nothing but an interface to the underlying hidden input field and every interaction with the widget is automatically applied to the corresponding hidden element. With a little caution and imagination in the element naming process, it is even possible to apply the standard methods, such as document.getElementById('widgetId').value to our self-made widget, if we take care that the hidden element is called widgetId and not the widget we created (which could be called widgetId_interface). This was the first method I used when I was tasked to create a dynamically generated interface with custom widgets and although it took some time to get used to, the result was very convincing and I had no major problems getting it to work exactly the way I wanted. I have to admit that this method strongly might be a little unusual but it gets the job done. A more elaborate method, with a lot more options, is probably the second one.

I assume that a lot of people that recently started with JavaScript, make the mistake and compare it to something like PHP, that resides in a different layer than the HTML markup and where the interaction only goes in one direction. They might think that a JavaScript function, upon invocation, generates something which is then displayed on the web site. While this is correct, JavaScript offers a lot more possibilities and contrary to PHP, objects you create aren't deleted when the JavaScript code has ended but it is possible to access them again at a later stage. Additionally, JavaScript is a very powerful object-based language, which is explained in great detail in a tutorial on sitepoint. One of the problems you have to face when you dynamically generate JavaScript objects is to actually find them again at a later stage, based on a numerical or string value that you received as argument. To solve this problem, a common solution is to create an object, a factory, that is able to store all the created objects in an associative array, or a map, as some might call it. As soon as you create an object that you want to keep for later usage, you stick it into the map, using its identifier as key for the map. This allows us to structure the entire code in a perfect object-oriented approach. First, we define a common interface that every widget we'll create has to respect. It should contain simple functions like getter/setter for the id, the name or the value and functions that define its behavior and visual appearance. This time, when the user submits the form, we don't have to rely on hidden elements to transmit our values but we can iterate over the map of created elements and generate the correct (name, value) pair for every widget we created. As each widget is internally represented by its object, the widget this time serves as visual interface to its underlying object and not to an hidden input field. For those of you that are familiar with dojo, might recognize the difference between dojo.byId, which is nothing else than a short version of document.getElementById and dojo.widget.byId, which is a lookup in the object map and returns the widget object, not the DOM element. This method is far superior to the first one, but also a little more complex to implement. The object-oriented approach has clear benefits and allow for a more modular approach, that is scalable and robust.

Conclusion

Writing and designing self-made widgets is a lot of work and requires careful thinking. More than once, you feel like you just reinvented the wheel and that you should better rely on available frameworks and widget engines. Of course, there are also reasons for writing a custom widget engine oneself, like dissatisfaction of the large overhead of some frameworks or the complexity and missing ease of use. Finally, it should be noted that several groups are currently trying to provide better widget frameworks, such as the the dojo dijit project.

[02-May-2007]I would like to inform you that I added a new RSS feed to this website, that contains the 10 latest news and tutorials. Even though RSS is a very common way to distribute news around the Internet, I never got around to integrate it into my site, since I don't use any finished CMS but like to program everything myself.
For those of you interested, I followed a guide that I found on devshed, it was easy enough to go through it very fast but unfortunately contained several mistakes in the code. If you think about added an RSS feed to your site as well, have a look at that tutorial and you'll end up with one in no time.