How To Make Your Web Apps Suck Less
Posted at November 14, 2005 11:22 AM - Category: Coding
It's been a while since I've written a decent post in this blog, so here's my attempt to make up for lost time.
Frankly, I'm more than a little bit shocked at how bad some web applications are. I don't know if these people are blind, retarded, or both, but there are some truely awful apps being passed off as stable, final versions. Of course, that's how it goes with most anything. There are always those low quality products that make you wonder if there was an open can of paint in the room while they were being designed.
But that doesn't mean you have to.
So, here are some notes on how you can improve you applications significantly. This isn't a complete list, nor is it guaranteed to be accurate. But I think at least following some of the bare minimum guidelines can make a big impact on your app.
Make It Easy To Install
Installers are the biggest gripe I have with just about every web app out there. The majority of them either rely on some separate file you have to edit or are just a form to enter in database details and run some SQL statements. They are generally either the last thing to be set up or are quickly created so the developer can get their script tested and out the door faster. However, that's missing one big thing: Installers are the first thing your users see! You've got to give them as much attention as your application itself. If you don't do that, you start people off with a sour taste in their mouth, and that just sets you up for disaster.
One of the biggest things is making sure there is clear documentation on what's going on. Most people with problems installing scripts don't fully understand the fields they're expected to enter. "What the hell is a 'Database Server Address'?" would be a prime example of a question they may ask themselves. Instead, use lots of descriptive text all over the place. Even if your installer is nothing more than a glorified set of SQL statements, giving a user a better idea of what's going on will ensure less errors and make them feel more in control of the whole process.
Less Bloat
The bloat I'm referring to isn't just large page sizes, it's also in the number of listed features and available options for users. Take a look at a demo of Modernbill to see what I'm talking about. On the main dashboard page, there are 48 images, CSS, and JavaScript files that need to be loaded. In addition, there's a horrid rollover menu at the top, that hides sub-sections until you rollover them, and there are dozens of possible links to click depending on where you need to go in the application. So, what we have here is information overload both in terms of what your computer and network have to handle, and what your brain has to handle.
Now, cutting down on bloat doesn't have to mean cutting down on what your app is capable of. Less features do not mean less capabilities. The point is to make the features you have more flexible and usable so that your users can do more with less. Going back to ModernBill for an example, there's the ability to do an upgrade or downgrade of a user's accounts via a separate wizard interface linked from the client's information screen. This automatically does all the pro-rated billing and sets up things to be upgraded on the server. Instead, why not use the existing screen to edit an account's details. Have it prompt you to pro-rate the cost when you save changes (if the plan has been switched). No new screen needs to be added, you're just using the existing functionality. Hell, if you want to use AJAX, just have the listings of accounts include clickable items that drop down to a selection of possible new plans. Then just pop up a message with any feedback or information that's needed and you don't even need a separate editor screen.
Flickr is a great example of how bloat can be reduced in an app. On the same page you view a photo on, as an owner you can edit the title, description, tags, notes, and sets the photo belongs to. This is all done without an additional screen or interface. So, there are less places to go, but the same capabilities. The AJAX used in this case isn't about reducing reloads, it's about reducing the places you need to go to get things done.
Do The Thinking For Your User
Let's face it: Users can act really dumb sometimes. However, this often isn't because the user is actually stupid, but because they are put into a confusing situation. So, it's up to our apps to fill in that gap and be smart on the user's behalf.
There are two ways to make actions in the system go more smoothly: 1) Instruct the user carefully or 2) Do it for them. The first involves either writing a good manual or providing sufficient contextual help throughout your application. To be honest, it should be both. Many people, myself included, don't like help text all over the place after we've used the application for a while and end up turning it off. So, for those of us like that, you should have a well-written manual available to reference. Seriously, writing a manual should be as important as writing code. The manual should even be longer than your code (unless you're really verbose with your code...).
As for doing things for the user, I don't necessarily mean full automation, just little nudges where the user needs it. One thing that most coders don't think about is the default value for form inputs. Often time it's left blank and the user figures out what to enter based on the title next to that field. Instead, if we pre-fill that field with information we can do one of two things: show the user how to format input into that field or fill in data they were going to enter anyways. In either case, you boost productivity because you're either avoiding errors in the form or just filling it out for them. For instance, say you have an admin section to enter in items into an inventory app. You could fill a date with "mm/dd/yyyy" (which disappears when you click on the field) to give the correct format and help new users. Over time, your application can determine the best pre-filled value for that field and enter it in each time (most likely it would be the current date).
The End
That's all I've been able to think of off the top of my head. If you have any other suggestions for areas I should comment on, feel free to leave them in the comments. Again, I'm not any form of expert, I just play one on TV. I'm sure I've made errors (both logical and grammatical), so feel free to point them out. If there's enough interest, I'll post up a followup on this to clarify anything that needs it.
Anyways, get to it! Let's see some killer apps!
