Great Browser Expectations
:: Development
April 19, 2006 - over 3 years ago
Platform: We like Rails
Tested Browsers: All of them!
Tag As: Ajax, CSS, XHTML, common sense
Editor: Stephanie Lyons
Refactoring is a term that has its roots in mathematics. If you take the romantic view and choose to see math as a set of patterns designed to bring order to chaos around us, then to refactor becomes a radical concept. It implies that you are imposing a new perspective; that by shuffling entrenched structures and simplifying data to its most basic essence, you can make things 'better'. 'Better', meaning faster, more logical, and easier to understand.
Refactoring is more than just another buzz term. It is more about intuition than a skill. Knowledge develops after we learn how to do something (a skill) and we find ways to adapt and improve that skill by using it in our applications. Of course, like all good things, too much refactoring can be harmful to a healthy project. The endless pursuit of the best code possible is an intellectual challenge, but it can negatively impact deadlines, not to mention your social life!
Arrogant, yet humble
The status quo for dealing with old browsers today is to redirect them to a page that explains how their Netscape 2.0 is out of date, as well as an upgrade path that will get them using the site. I advocate that we change our ways and start building our sites so that content and functionality is spread across multiple Controllers which accommodate different levels of accessibility. This lessens the feeling of punishment and makes the end result much more desirable.
We have to resist the urge to use Ajax for every interaction, just because it's cool.
If you take a long hard look at your projects, the sections that truly require scripting are less numerous than you think. Why is it bad to refresh the page when you log in? Do you really have to be logged in when you read the FAQ?
Sugar - it will get you further, unless it's in your gas tank
Many popular web sites have a 'sweet spot' - their reason for being. This would be an auction listing on eBay, or a profile on mySpace. These pages should be the most accessible part of your site, because it's very likely that they will be bookmarked and forwarded to people who might use that page as a primary entry point.
Popular destinations are not in demand because of their clever scripting. They put most of their resources into removing possible barriers to entry into their core business - and so should you! Give the sweet spot its own Controller and make sure that every browser on the planet can see it perfectly.
Encourage 'hacking'
URLs should make sense semantically, and be easily guessable. Database record identity information has no place in the end-user experience. By committing to replace database crud with tokens or a meaningful name, we create good will with people who will appreciate that the site is easy to hack - in the good way!
http://example.com/scripts/faq.asp?id=13
becomes:
http://example.com/help/why/my_credit_card_doesnt_work/
If the user runs a customized search, why not give their search results page a unique URL? Users can bookmark it to retrieve updated results later. Work hard so your clients don't have to! Bonus points if each custom search automatically generates an RSS feed.
Give feedback early and often
If a user has entered bad data on a field, don't wait for them to submit the form to tell them that they have made a mistake or omission. If possible, try to validate as soon as they leave a field. During registration, if a user attempts to enter an email address that's already in the database, you will save them time and frustration if you use Ajax to perform a lookup and display a helpful tip immediately below the field. Your server side validations are there to prevent corrupt data; you should be confident that all data is complete and well formed when it is submitted.
Don't go overboard! It should be okay to tab off a field that you have not entered data into without getting an error. If they attempt to submit a form that is missing required fields, then you can display helpful tips below each field that is in error.
In many cases, is makes sense to disable your Save buttons when they are clicked, and to re-enable them if the validation comes back with problems. This is especially important in situations such as processing a credit card; if they click twice, they will be charged twice. Some people double-click everything! It might be unnecessary, but why punish them for it?
If you change the appearance of your Save and Cancel buttons using CSS classes, you should make sure each button has an enabled and disabled state. Rails' new RJS templates let you make short work of this vital user experience glue.
You're hurting my brain!
Web developers have always had it rough when it comes to standards. No two browsers will render a page exactly the same way. It is impossible to be 100% confident that all of your CSS and scripting will have their desired impact - or even be processed in the first place. At the very least, some people will turn scripting or cookies off, which will wreak havoc with maintaining session state.
Its time that we start to right some of these wrongs. With a manageable amount of foresight and planning, you should be able to take much of the pain out of using the web. This will translate into real value for you and your clients.