During recent projects, integrating fonts for the right look and feel has shown to be troublesome for Internet Explorer. After implementing a font file into a CSS file, Internet Explorer 9 would provide the following error and not show the embedded font:

CSS3114
@font-face failed OpenType embedding permission check. Permission must be Installable.

This error is listed on MSDN and states that:

 The font-face does not have permissions to install with the current webpage.

And to fix:

Obtain the correct permission or licenses for embedding the font.

The only help this really provided was narrowing my search results.  Luckily, I found a nifty program that can be run from the command prompt to correct this error in IE9.  Be aware however, as stated on the publishers download page:

Changing the embedding value does not give you license to distribute the fonts. You should only change this setting if you are the font creator, or something like that. Use at your own risk.

Download embed.exe

Program Useage:

1. Download the executable and move to the desktop with a copy of the font file.
   (Alternatively, you can drop this in your Windows/system32 directory)
2. Pull up a command prompt window.
3. Navigate to the desktop within the prompt
4. Execute by typing: embed.exe fontfilename.ttf
5. Viola, your font should be ready to use in IE9.

More on Font Embedding from MSDN »

Every usability expert, designer or developer could give you different opinions about what makes forms more usable, less confusing and less daunting. I sought out to research all the experiments and form a general list of things that developers, designers, and gurus should and should not do. The rest, as usual, always depends on the context of the project.

After combining this research with fellow co-workers and everyone’s combined knowledge, I generated a short list of common things you can do to improve your forms, but I want to discuss what types of forms I’m talking about first.

One type of form is the generic one: I’m talking about the generic “contact” form on the web, the one with fields that aren’t even new to my grandmother anymore. Fields are empty areas for you to fill in data, usually personal data. Fields like “Name”, “E-Mail Address” and “Comments” are very well known. Also, forms like “Request for Quote”, “Search” or “Sweepstakes” have much in common with the “Contact” form: they are generic, no task required, “enter in that information yet again”, forms.

The other type of form is one that requires more thought on the user. Forms like these include insurance quotes, submitting payment, government forms, loan requests, etc. These are the types of forms you receive in the mail in a booklet and have an instruction book accompanying it. These forms are quite different from the “generic” forms I mentioned above. The more data and thought necessary required from the user, the more division and instruction is needed in the form itself. In general, I think each form in this division should be designed in each instance, so I don’t think general tips apply all the time, but most of the ones I will list can apply.

So we will only be discussing the generic form, which is a good base for any working professional in this area I think. This form shares a commonality with many others, your contact form will be at least 50% identical the next guy’s contact form, and this means that already your user base is experienced with your form. Which brings me to the first tip:

#1 Don’t break convention just because it looks neat or you think it’s better
Break convention only if it works better. Your forms should be putting your user first. They are active participants ready to endure your form gauntlet – do not change their minds! Making your forms work should be the number one priority. What’s the only way to know if it’s working better? Field testing.

#2 Do field testing
I can’t agree with the usability experts more: field testing always shows you what went wrong or right with your forms. I understand that many companies lack the resources to hold usability tests, but they are a necessity. My favorite thing to do is actually allow the client to field test by bringing them in and watching them use your form. Make your coworker do it. Make your mom do it. Don’t tell them you’re testing the usability, make something up. If you are able to watch them use it, you did not guide them through it and you learned something from the experience, congratulations, you just did usability testing. Now take notes and correct what went wrong. This won’t be as accurate as some measurement tools the experts have, but it’s just as helpful and it was free. Have to say, nothing is more embarrassing then to watch that client months later use it and complain because it makes them frustrated or simply does not work. Field test before it’s too late.

#3 “Use the right field for the right task”¹⁸
Crescimanno and Nielsen argue that every field type should be appropriated correctly with the label. For example, if your label said “First Name” you should not use a radiobox for your field because then the user cannot correctly fill in their first name. A more complex example would be if your label said “Expiration Date” and you gave the user 3 drop down menus, 1 for month, 1 for day and 1 for year. The month and day fields have an absolute beginning and end, 01-12 for month and 10-31 for day. The year field, on the other hand, is a bit arbitrary since we are concerned with when said subject expires. Do you list the years until 2012? 2050? Should the user have to endure a very, very long drop down menu or should the user face having their year not even listed? If you put into too many years or not list enough, respectively, this could happen. Why not just make all 3 fields free entry? Or why not require just month and year in the same format and make it easier not only for the user, but also your developer? Usually there is a good solution to every type of data you need. And like Crescimanno suggests, stay away from multiple-selection boxes that are confusing (and may not even work in all browsers).

#4 Don’t let your clients pick your form structure for you
Unless your client is a certified master in creating usable forms, don’t allow them to pick what type of data they “think” they need. Have a good sit down with them and ask considerate questions about why they think they need this form, what do they expect from the user, what data are they looking for, how do they intend on using the data, and so on. I guarantee that your company (full of qualified, wonderful people) can create not only a more usable form, but also a form that integrates better with the database, integrates better with the graphical design of the website it is in, does not deter the user away, that takes the least amount of time to fill in, etc. Clients are blind-sighted by the bigger picture, take control of this crucial analysis process.

#5 Use informative error messages¹
Don’t tell me the form encountered a critical error after I hit “submit”. Don’t tell me my e-mail address is invalid when I only have not registered with it yet. Don’t tell me my password is not strong enough, tell me why. Please.

#6 Use better placed labels¹²³
Do not make them bold, do not place them far away, make them consistent with other labels, right-align if you won’t place the label above the field and don’t use illegible fonts.

#7 Quit putting in a reset button⁴
Reset buttons are accidentally hit instead of the “submit” button when the user submits a form, so what purpose does it serve?

References:
1 A List Apart: Sensible Forms: A Form Usability Checklist
2 UX Matters: Evaluating the Usability of Search Forms Using Eyetracking: A Practical Approach
3 UX Matters: Label Placement in Forms
4 Creating Good Websites: Usability
5 Sitepoint: 7 Steps to Usable Forms
6 Krug, Steve. “Don’t Make Me Think: A Common Sense Approach to Web Usability”, 2000, New Riders Press.
7 Nielsen, Jakob. “Designing Web Usability”, 1999, Peachpit Press.