The Problem With Many Web Applications Is The Front-End
October 03, 2003 | 
11 Comments
Dear “average Joe” Web Application Developer,
Your Web application is very hard to use, oh and it’s ugly too. Yes, I know the back-end code is wonderfully functional, and I understand that you feel that is the important part, but does it really matter if nobody can use the damn thing?
You say you spent countless hours getting this application to function correctly? Why then, did I get an error I didn’t understand when submitting your sign up form. Oh, it’s because there was a mandatory field I missed! Oh, ok, well next time can you tell me before I hit submit, lose all my carefully entered info and have to start again? A human readable error message would have been nice as well.
Oh, so you spent hours and hours getting your end to function! I can see why you’re upset, but let me come back to that.
So let’s get down to what is wrong, since I seem to have piqued your interest. Well, to begin with I have to use my Windows machine, with IE, at work to use your application, and also have to disable my pop-up blocker. That’s a bit of a pain.
Your forms are too long, they’re hard to read (the small red links are illegible) and they aren’t logically organized — at least from my end. And, like I said, the error messages don’t make sense to me. I actually thought my browser was broken for a minute.
It takes forever to load, probably all of those funky 3D, gradiated graphics you are using. I still don’t see what purpose they serve, they’re ugly and actually just get in the way. I want to use this thing, not look at it and an artist you are not.
In a word your application is — unusable. Oh, you say it works just fine? All I need is to understand what, exactly? Hmm, well, see, the thing is I’m not an application developer, and even if I was, I didn’t develop this one so what you just said is meaningless to me. Did you test this out with people who actually have to use it?
Hmm, ok, well no, Bob from IT doesn’t really count, although I guess it’s better than no one at all. What did he say? Oh, he did have problems! I’m not surprised. Why didn’t those get worked on? No time or money, that’s a common problem.
Let me ask you — what is the purpose of this application? To save the company time and money? Good. How exactly? Ok, now explain how this application is going to accomplish this if nobody uses it? That’s right, it won’t. Doesn’t it seem to make sense now to have it thoroughly tested by people who will be actually using it? Good, now we’re getting somewhere.
Another good idea would be to put some time, effort and money into the front-end. This is hardly ever done, and most Web applications are in sore need of some front-end attention. So you think front-end design and development are all about “making something pretty” do you? Figures.
No, friend, front-end design is crucial to the long-term success of your application. A designer will not only “make it pretty”, they’ll help insure it’s usable, that it’s layout is clear and logical and if they know what their doing, that the front-end is built with Standards, thus assuring a quick loading, logically structured, forward thinking and long living face to your important application.
No, I don’t think you can do that yourself. I looked at the code, I saw your nested tables, your inline styles and your deprecated tags. You’d not have this kind of code bloat on the back-end, why have it on the front?
Look man, I’ll break it down for you.
The success of any Web application hinges on whether or not it’s usable. To insure that success, you need to make sure you have resources allocated to usability. Time and effort also need to be spent, by a professional, on the design of the application. User interface and front-end design are key. These applications not only save time and money, they represent the company or organization that built them and should be treated like any other public (or internal) facing communication.
It seems like a disproportionate amount of time is spent engineering Web applications, and not enough designing and developing the presentation layer. There are very few Web applications out there coded with Web standards, let alone designed and laid out by professional Web designer. The result is ugly, unusable applications that have a tendency to break (or at least not function as intended) under less than their developer’s “ideal” circumstances (you notice this on a Mac all the time) and who’s life span is ultimately limited.
I imagine countless funds have been spent on Web applications that have failed for these very reasons. If you are going to take the time to do something, you should do it right, the first time. It’s high time people building applications for the Web begin to take notice of things like usability and Web standards. It’s in their best interest as in the end will save even more time and money and insure the most potential for success.
Hope that sheds some light on the subject. Good luck, and feel free to drop me a line, should you need any help!
Filed under: Web General
Comments
1. Gabe said:
I’m a programmer and a designer. My web applications work great for their users because I meet with them and discuss exactly how they will be used. It’s hard for me to imagine building a web application without beginning and ending with usability. That said, I haven’t found the ‘average’ web application to be that horrible. Have any specific ones in mind?
Posted on October 3, 2003 10:52 AM | #
2. Craig said:
Hear hear, Keith.
Posted on October 3, 2003 10:59 AM | #
3. Keith said:
Gabe, I don’t have any specific aps in mind, the vast majority of those I come in contact with, both as a user and a designer, are pretty bad.
I’m not talking just form based applications. I’ll give you an example - there is a CMS system I used to work with quite a bit. It’s got problems on the admin side as well as with the code it generates.
I had to spend hours learning it and it still had all kinds of problems. Display problems, cross browser problems, access problems, usability problems. All of which could have been avoided.
In any case, I’m trying to think of a well designed application (and don’t get me wrong – I’m sure there are plenty) and all that comes to mind is Movable Type and even it has problems.
Posted on October 3, 2003 11:05 AM | #
4. Ethan said:
Well put, Keith. Very well put.
Posted on October 3, 2003 11:21 AM | #
5. Scrivs said:
Instant classic. The reason I included you for this entry http://www.9rules.com/whitespace/design/elements_of_web_design_content.php
Posted on October 3, 2003 11:48 AM | #
6. Justin said:
You know, the concept is quite right. Unfortunately in my experience this is not the result of web application developers. This is the result of general programmers working on web applications projects without first learning or being taught about the web.
I work as a web application developer and have for many years. I’d say most web application developers actually care a lot about the web portion and that their [x]html and css is far better than 95% of those who create web pages.
Yes, there is a portion of those who have not yet learned the web, and there’s another portion who don’t really care to. They don’t make up the majority, however. (Unless maybe you’re in a corporation where “programmers” are being phased out and forced to become “web application developers” instead, since much of the actual programming remains consistent between the two fields.)
I agree wholeheartedly on the whole form layout/organization issue, and the fact that the applications don’t look too great, etc. We (web application developers) often don’t have the greatest skills in this area. I’m fortunate enough to work somewhere that encourages me to work with web designers on projects. Makes a huge difference.
As for the rest, though, do you understand how painfully tedious and difficult it is to make every form keep it’s information when users make mistakes, or even to deal with data from the forms in the first place? Personally I’ve developed a set of libraries that takes most of the work out of it, but obviously introduces some limitations and inefficiencies in the process. It’s worth it, though.
Please understand that creating web applications is not nearly as easy as it might seem (or as it should be.) The way html forms work, having stateless systems, lacking persistent data handling capabilities by default, unreliable browsers/scripts/networks, and all the other stuff thrown in makes it amazingly difficult to create a smooth-flowing and well-working web application.
Instead of scolding, how about coming along-side and helping us figure it out? The job is hard enough already, thanks.
Posted on October 3, 2003 07:11 PM | #
7. Gabe said:
I guess I haven’t used any full-blown web applications then. The stuff that I’ve done involves moderately complex databases and form semantics, but beyond a certain point I think things are better left off the web, for the very reasons that Justin states.
There are two big hurdles to maximizing usability of a web application. One is the whole state issue: the best solution is cookies because you can make it persist arbitrarily, but it is the most insecure and prone to failure with cookies off. So in practice, everything must be done in sessions. Only problem is that they only last for some predetermined amount of time (30 minutes usually). Beyond this, you have to go the easy route and just force the user to start over or else serialize the state somehow and store it. Of course that gets complex when you realize that you have to force a login every time the session expires or face a totally insecure system (think public kiosks or dynamic IPs). The final hurdle of state processing is that you have no way to know when the user is done without an explicit final-page-loading scenario which is virtually impossible to enforce in any kind of multi-function application.
Then you have the whole dynamic processing dilemmas. You can only reliably do anything on the server side, yet often it is simply unacceptable to force a page load. So you must resort to Javascript which in my mind is always an inaccessible solution because 10% of people have it turned off (according to W3schools stats) to begin with. If you don’t do JS then you are in a tough position where you must choose between requiring multiple reloads or encumbering the form with non-specific data somehow (think two select fields, where the second list is determined by the first choice).
Combine that with the need to support all browsers and you quickly paint yourself into a corner. That’s not to say that web application design can’t improve. It will take a lot of dedication to learning good HTML and CSS, but it CAN improve. The only thing is that it will never be anywhere near as good as a platform specific application. Now if you use the DOM and ECMAscript and say: okay I am going to test the javascript enhancements in Mozilla and IE 6 then maybe you can build a web app with usability that approaches a native app, but you still have unstateliness of HTTP to contend with.
So basically I have two points: While simple functionality maybe cheap to attain on the web (essentially you get your network communication and interface design cheaper than building it from scratch), complex functionality starts costing exponential amounts especially when you start rubbing up against the limits of the protocol and the interface elements (HTTP and HTML are not robust). Web developers are frequently on a very tight budget (why is it a web app anyway?), so it may not be an option to engineer things properly using standards when the whole point is to get something usable right away.
I think the issues you raise can be addressed successfully by having web developers better versed in HTML, CSS, and browser bugs, but that is a cultural change that can only happen when web app development gets more respect in its own right instead of having so many crossover developers who barely know HTML.
At any rate, I’m not seeing all these public web applications that you seem to be referring to. It may be that management has forced a lot of things onto the web that really have no business being there.
That’s my $0.03, not meant to be antagonistic, just pointing out the limitations of the medium.
Posted on October 4, 2003 02:42 PM | #
8. Egor Kloos said:
I think it’s all been said before, but if a form breaks once that is once too many. You can lose your user and everything that goes with it. Like a sales opportunity for instance.
You often get just one shot of getting it right. One mistake and it all goes to hell in a handbasket. That is why it important to have good people working in their respective disciplines to get thing right. Like Justin said, it pretty tricky.
Webdesigners complain about poor webdevelopers being inflexible and webdevelopers complain about poor webdesigners messing thing up. Any gap in ability between the disciplines always causes pain and aggravation. Companies who build websites also make it difficult for themselves by having the need to focus on a core competency: Programming or designing. Budgets are effected by cutting the costs in area’s where competency is weakest. How many times have I seen a designer go all out on aesthetics and style leaving the programmers to pull of a miracle for less than peanuts. Or that programmers have a webapplication with seriously difficult requirements and then ask the designers pull a stylesheet out of their hat at the eleventh hour. I’ve seen it all, and it ain’t pretty.
The truth is often that both would really really like to work more closely with each other to create a site that makes sense in every way you look at it. But the reality is that such sites cost truckloads of cash and in the allocation of funds something has to give.
I’ve been very lucky to have worked closely with programmers and interaction specialists in big projects. The combined effort and creativity from all sides is something to behold. And you know what, the end result can still stink. Building websites is like tempting Murphy’s law. Something can always go wrong and it always does.
Posted on October 4, 2003 05:35 PM | #
9. Keith said:
First off I want to apologize to Justin, and any other Web application developer that might have taken my post personally. I guess my little rant was a bit “scolding” by design, but really it’s not meant to chastise, rather to get people to think about how Web applications are done.
In hindsight I guess I wanted to target the average Web application not the average Web developer. It’s just easier to write to a person I guess.
Justin also brings up a good point – that Web applications aren’t easy – and of course I know this. Gabe adds to that point, talking about how the problem with many applications is that they shouldn’t be on the Web at all.
I can’t agree more. There are many business processes, application or otherwise that are “Webified” that have no business (pardon the pun) being on the Web at all. I see this everyday, and the cost of these fruitless effort is amazing, and sad, really. Maybe that is the root of the problem, I’m not sure.
I do know I’ve seen more failure here than success, and I also know that there are many applications out there that would have a better chance at succeeding if they’re had been more thought put into the front-end, usability and everything that goes along with that.
As you can probably tell I’m a bit frustrated, that is because I’ve come across far to many applications as a user that I’ve had problems with and as a designer and user advocate I’ve been left out of the application development process many times as well, for many reasons that I just don’t understand.
Again, I feel like if you are going to do something, you should do your best to do it right. In the case of Web applications I guess the first thing to decide is whether or not to do it at all.
Posted on October 6, 2003 09:54 AM | #
10. Justin said:
Well, I should apologize a bit for immediately starting on the defensive. It’s just hard to come off a long day dealing with bugs in browsers, bugs in scripting languages, quirky databases, limited protocols, and then see a post from a guy you respect that seems to bash the result of your work.
I completely see your side too, though. I couldn’t count the number of times I get mad at whoever made a form that doesn’t save my info when it gives me errors, or just plain doesn’t work in Mozilla – the most complete and standards-supporting browser out there. (Doesn’t always mean the most usable, but basically any page *should* work in it.)
I’m guessing I notice it even more than you do, Keith, since it’s my job to ensure all the little things get straightened out in web forms and applications.
However, now you’ve seen from a few of us that we have about 50 things to deal with to ensure an application actually works correctly before (in priority, not time) we can even think about making it more usable. That’s probably a really good starting point for figuring out how to attack the problem, though.
So you’ve got a list up there of all the things we “do wrong” at the moment. Or at least that some of us – and I like to think those with less training or experience ;) – do wrong. If we take that and start explaining how they affect users and what’s going to stop people from using the form vs. what’s going to inconvenience them, then the web developers can make some better decisions.
If we’re sitting here on a budget that couldn’t buy a candy bar, and a negative time schedule, we have to make tradeoffs. No other way around it. But when do we decide to limit functionality (and provide a “stop, go back” type error) so we can focus on making parts more usable, and when do we spend the time to make sure necessary functionality gets in place at the expense of a more usable form? Which things affect the users more?
I think for beginning developers we need to mainly focus on education about all the things an application needs to be basically usable – never lose its information, provide error messages that’ll at least get the user back in the right direction, etc. On the other hand, for more experienced developers (especially those doing it as a career) we need to focus more on the question above – what tradeoffs should we make?
If you delve into the realm of web development more, though, you’ll find out that where we need far more education for the beginners is not necessarily in usability. I work in PHP for most of the stuff I do at my job, and it’s amazing to see the ignorance of the general PHP culture toward safety and security in web programming. Input that goes right into sql queries without being escaped, assumptions that hidden fields and select lists in a web form can’t be altered by users, etc. I find it very easy to “break” nearly every web application I play with that hasn’t been put through its paces by a good developer or the open source community in general. Honestly, that’s my first focus. Accessibility comes next (depending on the target audience). Then comes usability.
That doesn’t mean I don’t value usability. It does mean it’s not my specialty, and not my first priority. But I still know that a web application cannot be complete (read “good”) unless it’s had some usability, workflow, layout, and graphic design work done on it.
Anyway, those were just some more thoughts. I’d love to see a write-up based on the list of “things web developers do wrong or simply don’t do” where instead it discusses how to do them and why they’re important. Would really be a useful piece of work for those who don’t get to work directly with designers.
Posted on October 6, 2003 11:32 PM | #
11. Simon Minister said:
Dear all,
I am currently in the final year of my degree at university and have to finish a project of my choice. My project is mainly surrounding databases and the web as I wish to move from my comfort zone and learn new things. I have done the research for my project with the potential customer and written my own project specification which the customer agrees with. I am currently on a first going into this year and want to produce a Grade A project to graduate with honours. I’d appreciate any adivce or suggestions you have on how best to implement my project, languages to use, which DBMS is most appropraite and the like. Please find below my spec.
Project Specification
1 Project Title
A Complaints and Suggestions system for Wortons Estate Agency
2 Aim of the Project
The aim of the project is to design and build a web-based complaints and suggestions system for a local chain of estate agents. This will have an interface for customers, accessible through web browsers and terminals at the agents⦡mp;#x20AC;™ premises, for the input of complaints, compliments and suggestions (notifications) and an interface for management to produce reports and to respond to the notifications
3 Background Information
The local agent, Wortons, has shops in Hatfield, Potters Bar, Brookmans Park, Welwyn Garden City and St. Albans. They advertise properties for sale and rent and specialise in the letting of properties to students. They provide the following services:
Survey and valuation of properties
Sale of properties, advertised in the shops, in newspapers and on the web
Management of rental properties on behalf of clients
Location of properties for clients to buy or rent
A special service to local students and to clients offering properties for student rental
Customers may be people looking to buy or rent a property, people with a property to sell or people with properties to let. When things go wrong they are not usually slow in complaining. Currently complaints are dealt with by staff at the individual agencies who write them onto a slip of paper and pass them on to the management team. There is a suggestions box at each agency (which people also use for complaints, but rarely compliments) but the box next to it containing the empty suggestions slips is often empty so customers have nothing to write on.
Management are keen to improve their customer services and would now like to implement a complaints and suggestions scheme on their web site which customers can access from a terminal in the reception area or from home. They propose to acknowledge all notifications within one working day ⦡mp;#x20AC;“either by email or post, with follow-up letters for complaints once they have been investigated and dealt with. Management would like to be able to report on the types of notification received and also the speed with which complaints are dealt with.
The system should have access to a database containing all the customers⦡mp;#x20AC;™ details and all notifications should be recorded in this database referenced by a client number assigned to the author.
4 User Requirements
4.1 The Customer Interface
Customers should have an easy way of accessing their details by entering their surname and postcode. There should be a facility for them to enter their details if they do not appear, as new customers may not yet be on the system.
Customers should have a free-text area to type in details of their notification. They should be encouraged to select from a list of types and sub-types the main description which applies to the notification.
If there is no recorded email address for the customer on file they will be asked if they want to input one.
Once the notification has been submitted the customer should be thanked for taking the trouble to communicate and told that an acknowledgement will be sent within one working day by email or post (if they don⦡mp;#x20AC;™t have an email address)
4.2 The Customer Service Interface
Submitted complaints are automatically entered into the database. Every day, the customer services manager (CSM) will analyse all notifications received. A list of the complaints should show on her system at login.
The CSM will select the notifications one at a time and may adjust the types allocated by the customer. She will decide if the notification is a complaint, compliment or suggestion and allocate the appropriate category. She will then choose an acknowledgement letter from a pre-defined list of Word documents ⦡mp;#x20AC;“ the letter will be generated in Word with the customer⦡mp;#x20AC;™s name and address automatically entered. The acknowledgement will either be printed for posting or sent by email if the customer has an email address.
If the notification needs no further action, the CSM will mark it as resolved. If it needs further action she will allocate it to one of the team of Resolvers (i.e. people working at the different agencies), she will give it a turn-round date (a default has been agreed at 5 working days but this can be over-ridden) All notifications allocated to a Resolver will show on a list when s/he logs in. For each notification s/he should either:
Deal with it and contact the customer saying what has been done ⦡mp;#x20AC;“ stored standard letters may be used for communications with members
Pass it on to another Resolver with a note of what action is required
If the Resolver considers the notification has been dealt with s/he should mark it as resolved.
Every action taken relating to a notification should be recorded in an Actions list in the database.
4.3 The Reporting Interface
Management would like access to a number of standard reports:
All notifications by category and type
Outstanding notifications by category and type
Outstanding notifications by Resolver
A summary table showing numbers of complaints by type and sub type over a given period
5 Project Tasks
In order to be considered for a pass at Third Class Honours standard on this project, I must give evidence of having adequately attempted to:
Design and implement a database to store details of customers and notifications they have posted.
Design and partially implement a prototype web-based front-end for the Worton Estate Agency Complaints and Suggestions system
Enable notifications to be input via the web and stored in the database against the client number of the author (all new customers will be automatically allocated a client number)
Design and partially implement an interface for the customer services manager to view notifications, and record actions against them. The operator should be able to select the name of a standard letter from a pull-down list, but links to Word and email are not required for 3rd Class Hons. Standard and the letter templates do not need to be created.
Implement at least two of the required reports
In order to be considered for a pass at Second Class Honours standard in addition to the above, I must give evidence of having adequately attempted to:
Provide automated links to Word and email from the customer services manager interface. A few template letters should be created to show how the customer⦡mp;#x20AC;™s details can be transferred into a Word document, however the content of the letters is not important and you do not need to create the full text of the replies.
Implement all of the required reports
Have produced interfaces which not only work but have robust error trapping and show due consideration of usability issues.
In order to be considered for a pass at First Class Honours standard on this project, I must, in addition to the above, must also give evidence of having adequately attempted to:
Identify usability criteria for all aspects of the system and show how the design of the system meets these criteria
Evaluate the system with a number of users and comment critically (based on the evaluation) on the extent to which these criteria have been met.
6 Project Deliverables
As appendices to the project report I am expected to provide
An entity relationship diagram and data dictionary for the final system
Documented program code
A full set of annotated screen shots
Useful References
Recommended reference on evaluating the usability of software
http://www.useit.com
Other references on web design and usability
www.usableweb.com
www.usability.gov
http://www.usability.gov/guidelines/index.html
http://webtango.ischool.washington.edu/
www.otal.umd.edu/uupractice
General Human Computer Interaction Texts:
Human Computer Interaction Dix, AJ. et al. Prentice-Hall 1998
Designing the User Interface, Shniederman, B. Addision Wesley 1998
Human Computer Interaction, Preece, J. et al Addision Wesley 1994
Usabiltity Inspection methods Nielsen, John Wiley & Sons 1994
Handbook on Usabiltiy Testing, Rubin J. John Wiley & Sons Ltd 1994
Interaction Design beyond human-computer interaction, Preece, J. et al John Wiley & Sons 2002
Posted on October 10, 2004 05:37 AM | #
Comments are now closed