“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” Sir Tim Berners-Lee
In Part 1 and 2, I reasoned why and how an Ajax enabled web application performs better than an application built the traditional way. So should we Ajax enable all our web applications? The answer is no.
A serious issue with Ajax enabled web applications is that of accessibility by persons with disabilities.
Most of the discussion center on visually impaired users who have embraced “the power of the web” through assistive technologies such as screen magnifiers and screen readers. The problem arises from the inability of Ajax enabled web applications to effectively communicate to assistive technology, especially screen readers, that a part of the page has been updated, and allow users to easily investigate those changes.
These articles detail the problem:
AJAX Accessibility Overview
AJAX and Screen Readers - Content Access Issues
James Edwards, presenting his findings on how screen readers dealt with Ajax enabled web applications [http://www.sitepoint.com/article/ajax-screenreaders-work], remarks: “I’m forced to conclude that, unless a way can be found to notify screen readers of updated content, Ajax techniques cannot be considered accessible, and should not be used on a production site without a truly equivalent nonscript alternative being offered to users up-front.”
In 2006, Freedom Scientific, the developers of JAWS, a widely used screen reader indicated that version 7.1 of the software would be designed to work with Ajax based applications:
Developers Working to Overcome AJAX Accessibility Issues
This 2007 article indicates that, though some improvements have been made, the current level of support for Ajax in screen readers leaves a lot to be desired:
Improving Ajax applications for JAWS users
With Ajax pushing the boundaries of technology on the Web, and screen readers still stuck on outdated technology, it is very frustrating for the innovative developer.
However, there are other areas of accessibility where the developer can be more attentive to his users: think of people with learning/cognitive disabilities, for example, people who can’t use a mouse: did you provide them with an alternative to that cool drag and drop feature? Do you really require that drag and drop feature?
Some initiatives are underway: Charles L. Chen and T.V Raman has come up with a JavaScript framework - AxsJAX - for enhancing the accessibility of AJAX applications. “The AxsJAX framework helps inject accessibility features into these applications so that users of adaptive technologies such as screen readers and self-voicing browsers experience the same level of interactivity that is now taken for granted by users of Web 2.0 applications.”
The W3C has begun working on a standard that “defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.” This standard is currently a working draft. It will be a while before this is a recommendation, and developers and manufacturers of assistive technology understand and implement it.
Till then, if we have to develop a web application where accessibility is mandated, it is best to go the traditional route.
Further reading:
Accessibility Links
IBM Human Ability and Accessibility Center
Microsoft
Firefox extensions:
Fire Vox: a cross-platform self-voicing extension that includes early support for most of the leading edge features of W3C ARIA
Fangs: a screen reader emulator
Monday, November 24, 2008
A for Ajax, Part 3: Accessibility
Monday, November 10, 2008
A for Ajax, PART 2: Some data to substantiate claims made in Part 1
In Part 1 we discussed that an Ajax enabled application will perform better than a traditional web application. In this post we substantiate this claim with some data.
We compare a web application built the traditional way, in ASP.NET 3.0, with the same application built the AJAX way. Both application fetch data from the Northwind database using the same stored procedures. All the stored procedures have a wait period of 1 second to simulate delay.
We use Fiddler and Firebug to monitor the HTTP traffic, and the Web Application Stress Tool to load the sites with concurrent requests, and examine some of the data generated.
You can read the entire document here [http://docs.google.com/Doc?id=dcggqmtv_36c2tjrqg4].
The source code of the example applications, the Fiddler data used in this post, can be found here. The code is in C#, targets the .NET 3.5 Framework and developed using VS2008 SP1. The Northwind database is included in the download, you can either copy it to the App_Data folder of the applications, or attach them to SQL Server 2005. Rememeber to change to the appropriate connection string in the web.config.
We compare a web application built the traditional way, in ASP.NET 3.0, with the same application built the AJAX way. Both application fetch data from the Northwind database using the same stored procedures. All the stored procedures have a wait period of 1 second to simulate delay.
We use Fiddler and Firebug to monitor the HTTP traffic, and the Web Application Stress Tool to load the sites with concurrent requests, and examine some of the data generated.
You can read the entire document here [http://docs.google.com/Doc?id=dcggqmtv_36c2tjrqg4].
The source code of the example applications, the Fiddler data used in this post, can be found here. The code is in C#, targets the .NET 3.5 Framework and developed using VS2008 SP1. The Northwind database is included in the download, you can either copy it to the App_Data folder of the applications, or attach them to SQL Server 2005. Rememeber to change to the appropriate connection string in the web.config.
Posted by
santanu
at
12:09 AM
A for Ajax, PART 2: Some data to substantiate claims made in Part 1
2008-11-10T00:09:00+05:30
santanu
Ajax|Fiddler|Web Application Stress Tool|
Comments
Labels:
Ajax,
Fiddler,
Web Application Stress Tool
Thursday, October 16, 2008
A for Ajax, Part 1: Expectations from Ajax enabled web applications
Many of today’s web applications are Ajax enabled. What are our expectations from an Ajax enabled web application vis-à-vis traditional web applications?
Traditional page-based web applications process every request entirely on the server and sends across a HTML response that is rendered on the browser of the client machine. The HTML will contain the content [the HTML markup] and data. Refer Figure 1.
Figure 1: The traditional request-response web application architecture [please click the image for a larger view]
This request-response strategy is characterized by:
• high end server hardware.
• a browser on the client machine acting as a dumb terminal.
• complicated state management.
• the user waiting for a response after every request because of the synchronous nature of the request-response operation.
Considering that client machines are quite powerful nowadays, it makes sense to move part of the processing from the server to the client. This is the strategy followed in Ajax enabled web applications. The immediate gain is that this frees server resources, allowing the same server hardware to service more client requests concurrently. Ajax enabled web applications scale better than the traditional applications.
In an Ajax enabled web application, the only time the server processes a request entirely on the server is when the page is loaded the first time. This is the only time that the server serves content and maybe some data. For subsequent requests it serves only raw data, encoded in a given format. The client receives data feeds and updates only the parts of the Web page that have changed using JavaScript. In Ajax enabled web applications, UI updates take effect without postback. Refer Figure 2.
Figure 2: The Ajax enabled web application architecture [please click the image for a larger view]
Since only raw data is served, the size of the data is much smaller than what would be served by a traditional web application. This speeds up individual request and response, resulting in reduced network traffic and bandwidth requirements. Ajax enabled web applications are faster than the traditional applications.
By default the request-response strategy of an Ajax enabled web application is asynchronous in nature. This means that the user can continue to use the application while the client requests information from the server in the background and updates the UI [think Google Map]. Ajax enabled web applications are more responsive than the traditional applications.
In Ajax enabled web applications UI processing happens at the client. This makes it possible to achieve rich functionalities such as drag and drop, auto-completion, smooth animation, client side calculation, validation, etc. JavaScript libraries, such as ExtJS, bring in more sophistication to the UI. Ajax enabled web applications result in a rich user experience.
In summary, Ajax enabled web applications [with respect to traditional web applications] can be expected to:
1. scale better
2. have better overall performance
3. result in a richer user experience
Traditional page-based web applications process every request entirely on the server and sends across a HTML response that is rendered on the browser of the client machine. The HTML will contain the content [the HTML markup] and data. Refer Figure 1.
Figure 1: The traditional request-response web application architecture [please click the image for a larger view]
This request-response strategy is characterized by:
• high end server hardware.
• a browser on the client machine acting as a dumb terminal.
• complicated state management.
• the user waiting for a response after every request because of the synchronous nature of the request-response operation.
Considering that client machines are quite powerful nowadays, it makes sense to move part of the processing from the server to the client. This is the strategy followed in Ajax enabled web applications. The immediate gain is that this frees server resources, allowing the same server hardware to service more client requests concurrently. Ajax enabled web applications scale better than the traditional applications.
In an Ajax enabled web application, the only time the server processes a request entirely on the server is when the page is loaded the first time. This is the only time that the server serves content and maybe some data. For subsequent requests it serves only raw data, encoded in a given format. The client receives data feeds and updates only the parts of the Web page that have changed using JavaScript. In Ajax enabled web applications, UI updates take effect without postback. Refer Figure 2.
Figure 2: The Ajax enabled web application architecture [please click the image for a larger view]
Since only raw data is served, the size of the data is much smaller than what would be served by a traditional web application. This speeds up individual request and response, resulting in reduced network traffic and bandwidth requirements. Ajax enabled web applications are faster than the traditional applications.
By default the request-response strategy of an Ajax enabled web application is asynchronous in nature. This means that the user can continue to use the application while the client requests information from the server in the background and updates the UI [think Google Map]. Ajax enabled web applications are more responsive than the traditional applications.
In Ajax enabled web applications UI processing happens at the client. This makes it possible to achieve rich functionalities such as drag and drop, auto-completion, smooth animation, client side calculation, validation, etc. JavaScript libraries, such as ExtJS, bring in more sophistication to the UI. Ajax enabled web applications result in a rich user experience.
In summary, Ajax enabled web applications [with respect to traditional web applications] can be expected to:
1. scale better
2. have better overall performance
3. result in a richer user experience
Friday, July 18, 2008
Copy database diagrams in SQL Server 2005/2008/2012
To copy database diagrams from database dbA to database dbB, run the following in the Query Analyser:
INSERT INTO dbB.dbo.sysdiagrams
SELECT[name],[principal_id],[version],[definition]
FROM dbA.dbo.sysdiagrams
--SELECT * FROM dbB.dbo.sysdiagrams
[Thanks to Pankaj Saha, a colleague at work, for this code snippet.]
Edit: This also works for SQL Server 2008.
Edit: This also works for SQL Server 2012, Service Pack 4.
Edit: Some other links that could be useful:
http://stackoverflow.com/questions/3310137/sql-server-2005-how-to-copy-a-database-diagram-to-another-server
If you get an error "Cannot insert the value null into column "diagram_id"", check this out: http://social.msdn.microsoft.com/Forums/en-US/sqldocumentation/thread/767de035-5509-4150-af21-8b6752653f05
INSERT INTO dbB.dbo.sysdiagrams
SELECT[name],[principal_id],[version],[definition]
FROM dbA.dbo.sysdiagrams
--SELECT * FROM dbB.dbo.sysdiagrams
[Thanks to Pankaj Saha, a colleague at work, for this code snippet.]
Edit: This also works for SQL Server 2008.
Edit: This also works for SQL Server 2012, Service Pack 4.
Edit: Some other links that could be useful:
http://stackoverflow.com/questions/3310137/sql-server-2005-how-to-copy-a-database-diagram-to-another-server
If you get an error "Cannot insert the value null into column "diagram_id"", check this out: http://social.msdn.microsoft.com/Forums/en-US/sqldocumentation/thread/767de035-5509-4150-af21-8b6752653f05
Thursday, July 3, 2008
Hierarchical Data
A lot of real life data is hierarchical. Some are naturally hierarchical, like a family; others are classifications, like the folders in windows explorer. Either way, this data can be quite complex. Hierarchical data is best represented as a tree because of its ability to present the complexity in an easy to understand manner.
In data driven software, hierarchical data is often stored in a database, and presented in a tree control. Most tree controls will accept XML as data. You can retrieve hierarchical data from most databases in XML format. However the shape of this XML is hardly ever compatible with that required by the tree control, requiring transformation of the data XML to a shape acceptable by the tree control. One approach is to use XSLT to effect this transformation.
This requires the developer to develop an XSLT file. However, many developers find it hard to develop in a declarative language such as XSLT.
In this article, we discuss how to:
1. retrieve hierarchical data from the SQL Server 2005 database as XML data, using Common Table Expressions or CTE.
2. develop an XSLT to transform this XML into a shape acceptable to the tree controls. We will develop XLSTs for the ASP.NET 3.5 tree control and a custom tree based on the article Advanced UI Design Using XML and XSL. The code download also has an example of an ExtJs tree.
Download the article and the code here. [Click on the file name and click the Save As button.]
Or, download the article [http://www.mediafire.com/?jmhcjz9bygm].
Download the code [http://www.mediafire.com/?xmm2xjzmxjv].
In data driven software, hierarchical data is often stored in a database, and presented in a tree control. Most tree controls will accept XML as data. You can retrieve hierarchical data from most databases in XML format. However the shape of this XML is hardly ever compatible with that required by the tree control, requiring transformation of the data XML to a shape acceptable by the tree control. One approach is to use XSLT to effect this transformation.
This requires the developer to develop an XSLT file. However, many developers find it hard to develop in a declarative language such as XSLT.
In this article, we discuss how to:
1. retrieve hierarchical data from the SQL Server 2005 database as XML data, using Common Table Expressions or CTE.
2. develop an XSLT to transform this XML into a shape acceptable to the tree controls. We will develop XLSTs for the ASP.NET 3.5 tree control and a custom tree based on the article Advanced UI Design Using XML and XSL. The code download also has an example of an ExtJs tree.
Download the article and the code here. [Click on the file name and click the Save As button.]
Or, download the article [http://www.mediafire.com/?jmhcjz9bygm].
Download the code [http://www.mediafire.com/?xmm2xjzmxjv].
Labels:
CTE,
Hierarchical Data,
SQL Server,
SQLServer 2005,
XML,
XSLT
Saturday, June 21, 2008
The Singleton and the .NET framework
Taking advantage of the .NET framework, a singleton can be implemented as
follows:
// .NET Singleton
sealed class Singleton
{
private Singleton() {}
public static readonly Singleton Instance = new Singleton();
}
Read the article at http://msdn.microsoft.com/en-us/library/ms954629.aspx
Labels:
design patterns,
singleton
Wednesday, February 6, 2008
Exploring the .NET Configuration Files
It is a headache trying to post code to Blogger. After trying for most of the evening, I gave up.
I have uploaded the article and the code to Mediafire, a free file hosting site. Download the pdf file here [http://www.mediafire.com/?66ek99twzj1] and the code here [http://www.mediafire.com/?70c0h5fddtp].
If you have difficulty downloading these, leave your mail address as a comment and I'll mail them to you.
The article explores:
- the classes that represent the structure of configuration files
- the configuration hierarchy and the Configuration class
- classes used to read from/ write to the configuration file
- how to create custom sections
The code explores the concepts discussed in the article.
Your comments and opinion on the article will be greatly appreciated.
I have uploaded the article and the code to Mediafire, a free file hosting site. Download the pdf file here [http://www.mediafire.com/?66ek99twzj1] and the code here [http://www.mediafire.com/?70c0h5fddtp].
If you have difficulty downloading these, leave your mail address as a comment and I'll mail them to you.
The article explores:
- the classes that represent the structure of configuration files
- the configuration hierarchy and the Configuration class
- classes used to read from/ write to the configuration file
- how to create custom sections
The code explores the concepts discussed in the article.
Your comments and opinion on the article will be greatly appreciated.
Labels:
.NET 2.0+,
Configuration files
Thursday, January 24, 2008
Keeping up the net presence
Maintaining a presence on the net has not been easy.
I am on Orkut since June 2007. Till recently I lived with 7 scraps. My son discovered me and scrapped "hey dad....just seven scraps ...thats pretty poor...". Since then - due to greetings for the new year - I crossed 10 scraps..whew...feels like an achievement.
A sister invited me to join Shelfari. Seemed like a good idea - books are something I like. Since then I have been bombarded with mails about how inactive a member I am. A Shelfari member, Dr.M, sent across a 'lets be friends' request. Not knowing any Dr.M's, I rejected his/her hand of friendship, only to find out later that he was a one time customer.
I have been around on Blogger since October 2006. Signing up was easy.
But I have decided to make amends. Blog I shall - sounds like a new year resolution.
I am on Orkut since June 2007. Till recently I lived with 7 scraps. My son discovered me and scrapped "hey dad....just seven scraps ...thats pretty poor...". Since then - due to greetings for the new year - I crossed 10 scraps..whew...feels like an achievement.
A sister invited me to join Shelfari. Seemed like a good idea - books are something I like. Since then I have been bombarded with mails about how inactive a member I am. A Shelfari member, Dr.M, sent across a 'lets be friends' request. Not knowing any Dr.M's, I rejected his/her hand of friendship, only to find out later that he was a one time customer.
I have been around on Blogger since October 2006. Signing up was easy.
But I have decided to make amends. Blog I shall - sounds like a new year resolution.
Labels:
ramblings
Subscribe to:
Posts (Atom)