Wednesday, February 22, 2012

Avoid using modal windows on websites

An inevitable part of each sign up form is its username or e-mail address field. The rest is optional (even the password field). Hence, it is necessary to inform the user somehow that they are required to provide the username or e-mail address. What's more, you should notify them when they leave the required field empty. How to do it? As always, there is a good and bad way.

I just encountered the ugly one.

EduBrite signup form displays a JavaScript alert which is a modal window that prevents user to interact with the rest of a website. It shows up when the username field lacks focus. As a result user has to click OK button and is forced to fill in the missing value before submitting the form. Sounds innocent?

The problem is that the modal message pops up also when the user tries to click a menu button (e.g. Features, Pricing), select some text or start filling in the form from the other field. Not annoying enough? Let's imagine it shows up even when trying to click the browser's address field! A total disaster...

The problem is that forms on websites are not the only part of the user interface inside the browser window. In desktop applications a form is usually a part of some workflow which, since started, has to be finished or canceled. In this context leaving required value empty means an error indeed. The user can either fill in the missing field or cancel the workflow (i.e. form filling). On a website, however, there are much more possible interactions and filling in the form is only one of them. The user may want e.g. just to browse the site and may be not interested in the form at all. The form shouldn't interfere with the navigation, especially out of the website context (i.e. prevent the user from typing in web browser's address bar or clicking web browser's buttons).

So, how to do it better?

Advice: Well, just avoid showing up modal windows on websites. Instead, show the information next to (i.e. to the right of or below) the problematic field in form of noticeable text, optionally put inside the box. You can use colors and formatting to draw the user's attention.

Observed at: EduBrite signup form

Thursday, January 12, 2012

Leave login forms unscripted

Password managers have become an integral part of today's web browsers. They are able to determine whether the form is a login form and fill it out accordingly. However, some ugly JavaScript can confuse them and interfere with their functionality, thus breaking it.


In fact, I found two sites where I was unable to use password manager built in my Opera web browser because it was not recognizing login or password field properly due to underlying JS hocus-pocus. Firefox and Google Chrome did not even propose password saving at all. What is more, such complication may also make it impossible to submit the form using the enter key and hence require user to explicitly click on the submit button.


Advice: Do not try to be smarter than the already existing solutions by reinventing functionality of the login forms. Or at least if you have a very good reason to do this make sure that you don't break those solutions (including password managers).


Observed at: Parallels Plesk Control Panel at netarteria.pl and website of my company's business partner.

Friday, October 14, 2011

Use only common fonts (or embed non-standard ones)

My insurance company asked me to fill out an application for account activation due to the recent functionality expansion. All I had to do was download the generated PDF document, print it out, sign it and send to them. Seemed a piece of cake. Not this time. When I tried to open the document I encountered an error saying that Arial Unicode MS font could not be found in the system. I thought that I would find it on Windows (I use Linux). Unfortunately, it quickly turned out that the font is added to your system when you install MS Office suite (versions >= 2007)! I worked around the problem but then the next error informed me about absence of Microsoft Sans Serif font in my system...

Two things I have to complain about. First, assuming that every customer uses Windows and, what's more, every customer has MS Office installed is ridiculous.

Second, if the document I'm trying to open requires some fonts not present in my system I would like to be informed about all of them at once. I don't like installing one font and then checking again whether the document opens at last, repeating the process several times - it's irritating.

Advice: When creating a content that is meant to be read by the customers use only common fonts or, better, generic font families. If you still want to use a non-standard font you have to embed it in the document (both PDF and CSS3 support font embedding).

Observed at: mojacompensa.pl

UPDATE:

Today I received an e-mail from mojacompensa.pl (translated from Polish):
Dear Sir,
Thank you for your observation, we are investigating the problem and we will contact when it is resolved.
Meanwhile I am sending you an application for your account activation attached.
After signing please send it back to the Insurance Company.
Yours faithfully,
B.S.

As you could expect, the attached document suffers from the same problem of unavailable fonts. I wonder if those people feel that they have really helped...

Saturday, August 20, 2011

Do not limit password length

I tried to fill the registration form with my login and password. After five attempts, each refused with message password too short or too long my frustration hit a limit.

First, I would like to know whether you claim my password as too short or too long.

Second, what's the point in limiting password length if it's hash has a fixed size, independent on password length? Or maybe you don't hash the passwords? Ekhm...

Advice:  Do not put unreasonable constraints on user password. Simplifying password reduces safety and, hence, your credibility.

Observed at: www.rockserwis.pl

Do not send passwords via e-mail

Sometimes after successful registration I receive an unencrypted e-mail that contain my login and my password in plain text. What's the point in securing the registration form if, a moment later, the credentials are being exposed badly, potentially giving access to the account?

What's more, if someone unluckily broke into my e-mail account he would get an extra gift - passwords to my other accounts.

As a result, my level of trust drops significantly. How do I know that they don't store my password in plain text? Hashing of passwords is such a basic thing...

Advice: Do not send passwords via (unencrypted) e-mail. Account activation link is enough.

Observed at: www.mojwzrok.pl and many other places...

Encrypt customer's personal data

I entered an online bookstore. The registration form asked me for my name, postal address, e-mail, phone number and, of course, my login and password.

However, it was not encrypted with HTTPS. I gave up right away.

That's a perfect example how to lose customers.

Advice: Always encrypt customer's personal data. HTTPS is your friend.

Observed at: www.dobreksiazki.pl

Friday, August 19, 2011

Välkomna

I started this blog because I continuously encounter amazing examples of ignorance and foolish attitude to customers. Those anti-patterns appear everywhere, both in the web and traditional stores.

I decided to write my observations in one place to prevent designers and sellers from making such mistakes.

I hope one day it will save some life from frustration and resignation of a customer.