Web Applications are Still Web Sites

Friday, March 19 2010 - user-experience, web-applications

I was recently working with another developer that admittedly did not have a lot of web development experience. But he really wanted to use Ajax on the business web application we were working on. He wanted to use it so much, that he literally wanted to have the entire site reside in a single .aspx page, and every action, from logging in to processing data to running reports, would take place without a single new page being requested. How did I find this out? He wanted to use jQuery tabs for the navigation. When I built a navigation bar with HTML and CSS, he actually got mad that it wasn’t using jQuery. I asked him why he wanted to use jQuery for the navigation, and he said that he needed to be able to hook into the events when the tabs changed, so he could change the content accordingly. I just kind of stood there, not knowing what to say. I was absolutely flabbergasted, thinking that he could actually want an entire web application to run as one page. This couldn’t be right, could it? Even someone with only minimal web development experience would know that this is a bad idea, right? So, very carefully, I asked him if his intent was to have the entire site run as a single page. He said yes. Again, totally speechless.

Luckily, in this situation, I had an out – another developer, and the first developer’s superior at that. He heard part of this conversation and after he got the full details from me, his response was an immediate “no”. So, that was the end of the single-page, incredibly complex, enterprise-level web application, and is now going to be a standard MVC web application, with multiple pages and everything. But this whole episode got me thinking – do people really understand that web applications are still web sites, and not the same as desktop applications? I had thought so previously, but now I’m not so sure.

Just because you use the word “application” instead of “site” to describe what you are working on (on the web), you can’t forget the same rules still apply (in the random order that they popped into my head):

• By default, state is not maintained from request to request, so you need to manage that manually, and you need to be extra careful when you do, because every single item you put in memory has to go back and forth across the users (and your server’s) internet connection, increasing load times and bandwidth usage.
• People want to bookmark pages so they can get back to where they need to go as quickly as possible.
• You have a much larger range of platforms that you will need to account for and people get much more upset when you limit their choices to a single platform. Most of the time, if you tell a user base that your business application is Windows (or Mac) only, they will be fine with it, since you likely built the application based on the user base to begin with, so you should know what they are using. However, if you tell a user that they must use IE or FireFox for your application, the results are not nearly as kind.
• A little pizzazz is okay, but overdoing it is never a good idea.
• People do not go to your application because they like it. They go there to get something done. As such, you need to make it as simple to use as possible.
• The more you try to do on a single page, the bigger it gets. The bigger it gets, the longer it takes to download. The longer it takes to download, the more irritated your users will get with the application. Do this on many (or most) pages in your site, and the results won’t be pretty. You can do this in a desktop application (to an extent) because all vital things can be loaded at launch of the application, and you can preload less vital things in the background once the main application has started up. Everything is kept in memory on the user’s computer at that point, so it is easy to access again and again.
• As a corollary to the previous point – the web application must do (almost) everything quickly. Users seem to be used to something of a delay when loading a desktop application (especially users of Adobe products – I could go eat a full meal in the time it takes Photoshop to load), but web applications need to come up right away.

These are just a few of the many things that you need to consider when building a web application. If you find yourself designing/building a web application, just remember that it really is just a website, and if you follow the same rules that you do for sites, you should be just fine.