Analyzing a web application for its user experience quality

So you did believe after all that it might be worthwhile to meander to my lair on the net and check out whats on my mind. Thanks for the confidence and I shall try to keep your grey matter engaged. 
I intend to use this blogging medium for primarily 2 reasons:

1. Sharing my learnings across the different consultancy assignments that I undertake so that I might attract some intelligent folks who could add to my understanding of the topic. I firmly believe that the collective wisdom of the public will any day be superior compared to my incisive analysis of any topic that I might fancy. It might also help someone else with a similar task and/or it might just serve the purpose of making aware some hapless soul browsing for some info to avoid possible usability pitfalls in his/her web application.
2. As a means of consolidating some of my observations. I've noticed that when I write, my brain does does extra processing to sort out the pieces of the jumble better and look at the essential picture thats at the crux of the model. Basically I am consolidating my knowledge and in the process doing myself a favor :-) 

OK that should suffice for a pre-introduction ;-)

Being a software consultant one of my recent assignments was to assess the usability for a suite of web applications related to the health care domain. There were a secondary goal that was related to performance for some pages in some apps of this suite. These apps were meant to be used by the drug manufacturers to publish their drug details which could be used by the physicians as their electronic and/or paper reference. 
I had never before cared to observe with a keen eye for usability issues in the software that I work with and I was quite surprised at the quantum of issues that struck me as I went about my analysis. Listing all of those will make this post unwieldy. So in the interest of brevity (guys I value and respect your time, hence the strategy towards terseness) I am going to list only those deficiencies in the suite which I perceive as the bigger demons that need to be exorcised.

Each of these small apps were developed as silos. You might wonder why? Umm, thats quite normal in our software development industry after all, where work gets outsourced to multiple vendors. Each vendor/team gets to work on a part of the solution. Now thats reasonable and normally should not be a cause for concern. The problem crops up when the product development services vendor ends up treating the requirements spec as the bible and does not try to understand what problem is being solved. And therein lies the biggest reason for a solution to fail. Not asking 'What problem is being solved?' is probably the biggest mistake that was made in this case. Some vendors probably have the notion that going back to the client is likely to be perceived as a general lack of smartness by the client (blame it on cultural influences if you want to be diplomatic) and hence desist asking too many questions. And to add to that, some clients (their Business Analysts or Product/Solution Manager) do not like to be bothered once the requirements specs are handed out. 
The reasoning for my conclusion is simple: When I counted the number of apps in the suite and it exceeded half a dozen,and thought about the problem that these apps were trying to fix, I was like 'WTF are some many apps needed in the first place'? All it needed was some internet facing functionalities (for manufacturers to add their new products to the compendium of drugs that is being maintained by the system) that triggered the data input to the system and which gets augmented with more metadata and data on the intranet side to support some basic workflow before it is persisted in the designed format for final consumption. Its not so difficult to visualize redundancies in multiple areas of the domain model, like manufacturers, drugs, co-ordinators, etc. which were being duplicated across these apps. User-management, logging, styling and such cross-cutting functions were all over the place due to the lack of a plan to handle such components of the system in a centralized fashion across the applications of the suite.

The next important observation I had was the needless screen complexity on some of the apps. Clutter on the screen is never welcome and in these cases there was an overload of info on the screen. One particular screen epitomized the violation of some very common UI guidelines that are recommended for better usability. 

• Presence of multiple horizontal and vertical scroll bars in a single screen. Forget talking in the singular here though that itself needs to be shunned.
• Profusion of drop-downs that enable the-revenge-of-the-mice. Thanks to the innocent looking mouse scroll wheel!
• Visited links would not be remembered
• Pagination elements that were getting hidden due to the horizontal scroll as these elements were in the bottom right corner area of the grid
• Performance issues due to the huge amount of data being pulled in (~1.3MB in production)
• The notion of a grid view for multiple instances was taken to its extreme where all the columns for the row were being shown at once (irrespective of the user role) and a single data grid was showing up more than 300 records per page before pagination kicks in and there were about 20 odd columns in one of the grids. I wonder what justified such a huge page size. There were 3 such different grids on the screen! 
• The table column headers would not scroll horizontally, but the data would. So it would lead to a mangled UI where it was painful to see what value of the row was for which column.
• There was no link presented on the records of the grids to open their detail pages! wait the irony was, such a details page existed already! Only that the linking between the 2 pages was not done and I shudder at what motivation could have lead to such a design :-(
• And yet another irritant was the support to perform some actions on this grid table record directly. Icons were shown for all records irrespective of whether that action was valid for that record. Oh yes thank God, error handling was there to save the day. 
• The craziest part is that some actions on the record could alter its state thereby making it incorrect to show the record anymore in that grid. So to overcome that, all of these actions were posting data back to the server and the entire page with the multiple grids was getting reloaded for every such action on the record. No points for guessing the severe performance degradation. The server was sending more than a MB of data every time the page reloaded and this meant several tens of MBs per user very easily per typical session. Consequently some users reported that the page never rendered completely even after a few minutes and they finally got a time-out error. 
• And here is the final punch, this page happens to be the landing page for the app. 

There probably were some more such bloopers but I am not able to recount them all now. Yes, the couple of weeks that the assignment spanned would probably be the time when I sighed the most in my life, having to deal with the UI-cum-performance-cum-design-mess that the most important screen in that app was in. Unfortunately, answers could not be found for questions I wanted to ask to understand if there was any method behind this madness (the product had gotten sold to another company and thats how the current owners possessed these apps). 

My conclusion was this - Don't just implement feature requests from "user representatives" or "business analysts". I am pretty sure nobody bothered to see how the apps were being used at all as the apps were being built. My hunch is: end-users tell what they want, but they probably do things differently from how they think they'll use the features. Now combine this with a scenario where the IT services vendor company does not question the requirements and believes that the requirements are frozen. Voila! isn't that a catastrophe in the making?

IMHO it is only by observing how the end-users navigate around the app, can the application screen's UI elements be re-factored for better ease of use. It is really really hard to visualize how the features will be used and thereby plan and build the most optimal usability in the first go. No wonder we developers are proponents of the Agile development methodology aren't we?


Honey I've a brainwave. As I worked my way through the different apps in the suite, my laziness inspired me with an idea. And I am going to state it here and request your feedback. Listening to your opinions might sharpen the idea and give it further form and direction after all. The idea is to come up with an application which will be able to do some primary usability analysis automatically based on some set of static usability rules and maybe metrics too. It can act as a first level usability check before further resources get committed towards usability aspects of the project. It could also serve in identifying possible problem areas that warrant focus.


A word of caution. The bane of IE 6's snail-like Javascript engine was so obvious in one screen which was excruciatingly slow in getting loaded. IE 6 just could not stand up to the task of heavy DOM handling via Javascript. (If you know of tweaks and tricks to kick up IE 6 to perform better, I'd be glad for the education!). This particular page would take more than 5 mins to render in IE 6 whereas in Firefox/Chrome would take less than 20secs. And you know what? the app was designed with IE 6 as the target browser. 


Thats as much for my first post. I intend to show up regularly here, so look ahead for the next post folks.