Browser Support

Choosing your Browser Support Level

Choosing which browsers and which versions to support for your Web Application is a serious consideration.

For every browser you need to support you will need to do testing to ensure that your application works properly and if there are issues you will need to spend time debugging and fixing the issues.

In addition to each browser there is the issue of Operating Systems. Do you support browsers on all Operating Systems? Have you considered how you plan to test this?

Finally the most important question is: "Does it make smart & financial business sense for me to support browser X?"

So how do you determine what browsers to support?

Step 1: Operating Systems

Are there any Operating Systems that you can not justify supporting? e.g. If you are making an application for the Enterprise market do you need to support Apple or Linux? I'm not saying to drop support, but rather to consider what percentage of your users will be using these Operating Systems.

Step 2: Browsers

• Firefox
• Internet Explorer
• Safari
• Chrome
• Opera
• Camino
• Konqueror

The good news is that Netscape is no longer a browser you need to support - the bad news is that you will need to support several if not all of the above browsers. If you don't need to support Linux you can remove Konqueror from your support list. If you don't need to support Mac's you can drop support for Camino...... but the top 5: Firefox, Internet Explorer, Safari, Chrome & Opera... are likely going to be on your support list.

The even better news is that Firefox, Chrome, Safari and Opera all do an excellent job of supporting web standards... which means if you make your application work in one of them it will likely work just fine in the other 3.

Step 3: Internet Explorer

The bad news is Internet Explorer. With a staggering dominance of the browser market, especially in the corporate enterprise world you will almost guarantee-ably have to support IE.

So in my opinion which browsers should you support?

• Internet Explorer 7, 8 (if you have to support IE6 I really pity you, but the good news is that even Microsoft isn't supporting it after 2014)
• Firefox 3, 3.5
• Safari 3, 4
• Chrome 1, 2
• Opera 9+
• Camino 1.6
• Konqueror 3.5

Feel free to support other browsers like Pogo, Maxthon, Arora, LunaScape as well if you like ;-) they are growing in popularity every day esp. as IE6's market share slides.

Once you've got all of these covered you'll need to consider mobile browsers... but we'll leave that for another post.

Step 4: Money talks

At the end of the day it will be your customers that determine which browsers you will support. I just hope for your stress levels that IE6 isn't in your supported browser list. ;-)

Forgot Password

The Forgot Password feature is something you will definitely need. Your users will have umpteen dozen username/password combos to remember (from other applications) and most users will forget their password at least once, if not many times.

However this feature needs to be implemented very well or you run the very real risk of opening up a security hole that begs hackers to walk on in.

Step 1.) Send the user a password reset email

Since the user has forgotten their password, you will need to set up a new one (securely).

• Why? - Because you hashed the password - right? So you can't just tell them their password

You will want to ask for the email address of the user. This does 2 things for you.

1. It lets you verify that there actually is a user in your system with this email address.
2. It ensures that the password reset email you send is opened up by the "true" owner of the account. e.g. it isn't just the next user in line at the Internet Cafe that is trying to mess with a user's account.

The email should clearly indicate:

• What site the request came from (e.g. Example.com)
• What action is being requested (e.g. password reset vs. address change)
• What the user should do if they believe they received this email in error (e.g. a bogus request)
  
• What will happen if the email is ignored (e.g. Nothing will change)
  

If the email is ignored, nothing happens to the account. This step is also important to make sure that a hacker isn't just sending in reset requests to "disable" existing accounts.

Within the email you will need to include a "key" typically a short hash, that the user needs to enter to "confirm" the password reset request... and/or a link in the email (that includes the key) so the user can return to the site confirming the reset request. Make sure you provide both - there are some users out there with old email clients that won't auto create the hyperlink and there are also users out there that for security reasons want to type in the site address them selves (e.g. for banking sites - to avoid phishing emails)

Step 2.) User confirmation of password reset action

By arriving at your site on the password reset page (with the key in the url) or at a page where they can manually enter it the user can thereby confirm they requested this action.


Step 3.) Enter new password (and verify)

Once confirmed, the user must supply a new password (optionally meeting your password strength requirements) and enter it twice to ensure they haven't done a silly typo.

Depending on the security level of your site, you might have another step. (e.g. what if the email account itself was compromised? For financial applications typically you want the user to also enter in some key piece of information to ensure they really are the person they claim to be. If this is the case, this step should come before setting the new password.

e.g. Security Question/Response:

Q.) "What was your first pet's name?"

A.) "Sticky Paws"

Step 4.) Inform the user

Once the new password is set, inform the user that it has been set and remind them they'll need to remember this... but not write it down for security reasons.

Step 5.) What next?

Again, depending on the security level of your site... once the password has been reset you can either "automatically" log the user in, or explicitly log them out. Forcing the user to be logged out is actually considered a good thing in some cases since a.) The user could be "done" all they planned to do at that point or b.) Making the user log in with the new credentials ensures that they at least remember the password for 2 minutes ;-) and re-type it in will help enforce the new password to memory.

Signup Forms

Signup Forms are one of the first interactions a user will have with your site therefore you'd better get it right.

"You never get a second chance to make a good first impression."

So what makes a good vs. bad signup form?

Good:

• Clear indication of where to go to signup
• Simple signup form

Examples

Facebook has a simple signup form...


Bad:

• Too many fields!
• Unclear instructions
• Losing user data if they fail to complete all details
• Pre-checking any option to send spam to the user
• Forcing a user to check a "Terms of use" checkbox without providing a link to said terms
• Not providing a privacy link
  

For example this signup form is way to long... 90% of these questions can be asked after the user has created an account.




On the other hand, this site needs to work on ensuring that CAPATCHA tests are actually usable... can you read those 6 letters?


I'll link in some more specifics in a bit.

Why create a Web Application?

So you've decided that you want to create a software application. There is a ton of things that you'll need to decide, but one of the most important, is where your application is going to live.

Today's choice is:

• Create an online Web Based Application?

or

• Create a typical Distributable Application?

Both have specific advantages and disadvantages we'll consider.

One of the biggest things to consider is the target audience for your application. If they all run Mac, building a Windows application isn't going to cut it.

Platform Independence:

One of the biggest advantages to building a web based application is that you are not limited to any single OS (Operating System), and in fact, you are pretty much unlimited in terms of the OS's that you can support! (Windows, Mac, Linux, BSD, BlackBerry, iPhone, Other?)

On the other hand building an application for the OS world means picking a single OS, or using a technology that is OS independent like Java.

Software Piracy:

This is an often overlooked aspect of software development. If you build a cool Windows based application, sooner or later someone will hack it and place the cracked version on the Internet to share with everyone. On the other hand, if you build a web based application, there is no CD/DVD or download that the user gets and thus they can't hack your code to create their own cracked version. In order to "copy" your application, they would need to get a hold of your source code (not easy), then host their own version on the public Internet (which costs money) at which point the legal battle to stop them is much easier than trying to track down thousands of copied CD's.

Device Independence:

If you build a web application you can extend the client "reach" by being able to target more than one device. Sure, all of your clients will have a computer, but they may also have a smartphone (e.g. BlackBerry, iPhone, etc.) Being able to support multiple devices is a huge bonus for any application that you can build.

Remote Access:

If you are out of your office, away from home, on vacation and want to access your application being able to access it online is the ultimate in flexibility.

Application Interaction:

As a final note, having your application online makes the possibility of interacting with other online applications and sites an instant option in fact, the whole Internet is just waiting there to be tapped into.


The choice is all yours of course, however since this Blog is focused on Web Applications, lets presume that you've weighed the options and chosen to create a web based application that is accessible to all OS's, multiple browsers & many other devices.

Smart Move!

Welcome to Web App Usability!

This blog is dedicated to the design and maintenance of Web Applications. Each week or so we'll look in another aspect of web app usability highlighting the best and worse techniques that are out there today.

With a focus on usability (that applies to web sites & thick client apps just as much as web apps) this blog will hopefully become a great resource for information, tips & tricks.

We can't promise a post every day or even every week (we have our own 9-5 jobs) but we'll try our best to keep this site updated on a regular basis.

Finally, this site is a "sister' site to a Browser Bug Tracking site called Web Bug Track. Since every great design either accidentally encounters a bug, or needs to be designed around known existing bugs we'll link into the bug tracking site when important info can be better described outside our feature post.

Glad you checked us out,
Enjoy!