Introduction to Web Applications

May 13, 2010
Discover, The Web
Scroll to comments

Web applications are still some distant dream. The world is finally waking up from it's "Web 2.0" hangover disaster. Perhaps now we can focus on doing real impressive things with the web.

The word "application" isn't something that specifically applies to the web or information technology (such as a computer.) The word application stands for the act of applying, implementation, progress.

There is a solution for every situation. There are no problems. Problems are merely situations that are in need of a solution. By the time you explain your situation, I'll have a solution. That's the way it should work. Nothing hypothetical, not spending money on conferences, seminars, people telling you how you could do it, how you should do it, but don't make it happen.

Why on the web?

You may notice that I use words along the lines of "web applications are the future" a few times. This is because I really believe that. Naive as I may be, I am convinced that web applications have the potential to become more dominant.

Every desktop computer has an Internet browser. Even PDAs and most modern mobile phones are equipped with one. Thanks to the web, we can reach out to millions of people all around the globe. A web application is no different from your average website. It's a website with functionality. Think of a message board system like phpBB and vBulletin Board, a weblog or news system like Movable Type, an online store. With the use of simple server-side scripting language a web application can display a fully functional application in your browser.

Every desktop computer in the world can access a web application. Thanks to modern browsers web applications can do everything desktop applications can do, with four times more compatibility. There are no separate versions written for Windows or MacOS. You don't need tons of memory in your computer or disk space to store it.

Interface is everything

The classic webdeveloper will create an application based on what he knows it should do. If there is no specific lay-out that comes with the assignment he'll throw together a crappy lay-out that only he understands and works from there. A webdeveloper should actually be more involved in the visual development of the application as well. This requires more work but, in the end you have a much better result as the front of the application has been well thought out at that point as well.

The first step of creating a good application is thinking out all the features and functionality. Then you create the interface. Believe it or not, the interface is the most important part of the whole application. It doesn't matter if the application works, if the interface sucks and is hard to work with, the application will fail at it's task. People won't like working with it and productivity drops, to put it in business terms.

Think about today's operating systems; Windows XP, Mac OS and even more recent Linux distributions. All of them come with a well thought out graphical interface. One that everyone understands. Back in the time when command line systems were all there is (think of Microsoft DOS and Unix/Linux) only geeks and nerds knew how to use the computer. Today everyone can use the computer. Kids are learning faster and better thanks to the graphical environment that allows them to do the things they want with ease. There's no typing commands and using secret button combinations that only the people who created the software know. Everything you want to do, everything you need is laid out on your screen, at your convenience to access it at any time with as little effort as possible.

The same thing goes for web applications. It's easy to use all the standard elements and throw together a form that takes an hour to fill out, just to place a news item on your homepage or tell people that they should just let the webmaster do it, because he knows how to do it. Create a system that everyone can use. Think about the lay-out of the page. Use a logical way of navigation through the application. Group your content and functionality, make sure no one gets lost. Take the work away from the users. Don't give them a book on HTML, give them a WYSIWYG editor.

Create at the convenience of the user

"Would the user benefit from this functionality?" is a question that often roams the programming floor. Simply things like being able to click table headings to sort a list or a quick search functionality in a list of a hundred items. Things that will require several minutes extra work and might never be used but, they could be. Even Just Like Ed has sorting and filter options on the index pages of all sections. Not because there are so many items that it has to be there but simply because it's convenient. It's easy to say that a feature will not be worth the time spend on building it.

What developers forget is that you were asked to create an application that people can actually use. Creating one that works is easy, creating one that everybody can work with is different. More importantly, it has to be an application that people want to use. Let's use a Content Management System as point of reference. I've seen many of them and all of them use a different approach when delivering the management features to the end user. I've seen systems that simply display a list of existing pages with edit, add and delete availability but also systems that show you the website's pages in a tree structure that we all know from Windows Explorer. In the latter example, people with basic Windows knowledge knew exactly how to open a page and change it's content.

n this example you see how a mere list of pages is displayed. Logical to a developer, maybe. But an end user, the webmaster who has to upkeep the website has no order over the pages. It's very hard to find a single page in a list of 1,000 pages.

You may notice that the path of the files is noted behind the title of the page. The same path could have been used to create a tree structure and yet, it wasn't. Instead it's been dumped behind the title and now serves absolutely no purpose other than confusing any layman who would be working with this system.

Click on the image to view the full version.

In this second example you can see there is much more logic to the list of pages. The list has been replaced by a logical tree structure that indicates exactly which pages are located where in the website. These are the same pages as the first example. Not only does this structure provide better overview, it's also much more efficient to work with. The tree structure allows a user to only display the section he or she is working with in a side frame, such as you have in Windows Explorer and not have to go back to the whole list of pages every time a different page has to be opened.

Why would you bother presenting something like the first example when someone would be much happier with the second? Because it's more cost efficient? It took you less time to build? Good for you. The end user has what they asked for but, not in a way they can work with. This proves again that interface is everything.


Okay, so it's common knowledge what 404 means, right? Wrong. People that work with web applications for may years will learn that it means someone screwed up. But why? Did you know that a nifty feature in Internet Explorer called Friendly HTTP error messages? It shows a default "This page cannot be displayed" when ever something goes wrong. It doesn't matter what... programming error or really non existing page, the only difference is that little number at the bottom. Prevent people from ever getting default errors. Catch all possibilities.

When someone tries to enter a letter into an Integer field in a database an error is returned. And Integer field only allows numbers, no letters, punctuation or special characters. A white page with "Invalid use of datatype on line 210" is fun for developers but, not for end users. Replace the default error with something like "Please only enter numbers in this field." But, make it nice. Not a white page with just that line. Catch the error beforehand. When someone submits a form, validate it, check the fields with Javascript. A second option is to let the server-side language check all fiends and return to the form when something's wrong instead of processing it anyway. Here's an example of Just Like Ed's error page. You'll see that the page describes the details of the error and the probable cause. It also states who you should contact about the problem.