myShoggoth

Foundations: Accessibility

In my experience accessibility is the most poorly understood, unappreciated, and least valued of all of the Foundations I'm talking about in this series. Fundamentally I think the reason it is not valued highly enough is that it isn't understood, and the value it creates in a product both directly and indirectly is unappreciated.

Many people know about one or two accessibility features (usually hotkeys and keyboard navigation) but not everything involved, so I want to lay out both all the things involved in getting it right and the results for both the direct and indirect users of the features.

Keyboard Accessibility

The primary audience for this feature is a person who is able to use the keyboard relatively easily but has trouble with the mouse and mouse alternatives (trackballs, touchpads, etc.). They may not have an easy time with fine muscle control, or have carpal tunnel issues, have had a stroke, arthritis, or many other issues.

Keyboard Navigation

The first level of support is to make sure all UI elements are navigable from the keyboard. In other words, can I tab between all the controls, use spacebar or enter to use them. Can I fully use your program without a mouse? If so, you've met the minimum bar. If not, please find another career because you should not be producing software, you suck far too bad. Try Starbucks, you might be able to become a barista.

I'm sorry, that was uncalled for.

I didn't mean to insult baristas, I do enough with coffee myself to have high regard for skilled baristas.

Quick and Convenient Keyboard Access

The next level is to make all the main user actions fast and efficient through keyboard access. If one of the primary tasks your user is going to do requires launching two dialogs, going to the fifth tab of a property page, and moving through 12 controls in order to accomplish it, you're not streamlining your UI to your customers' needs either way. If you can accomplish the same task with two clicks of a mouse instead, however, you're causing a more serious accessibility problem for your users who can't (or prefer not to) use one.

The burden you put upon your users is relative, of course. For the carpal tunnel victim the extra keyboard strokes may not be that big of a deal, and depending on your application's performance may be faster than the equivalent mouse actions. What about the quadriplegic who interacts with the computer via a wand they grip in their mouth and type into the keyboard? In the latter case maximization of every keystroke is critical to their efficiency and ability to use your application.

Power Users

The indirect beneficiaries of this work are your Power Users (with a high correlation between them and carpal tunnel sufferers...). Many interactions with applications can be done faster with hotkeys and keyboard navigation, and once a user is comfortable they can increase productivity by learning them. For my example above where the user had to do a bunch of strange steps instead of two mouse clicks for a primary task they will perform in your program, let's say instead you made a hotkey for the same task. Now instead of two mouse clicks it is one keyboard stroke. You've just made your program more usable and your customer more efficient, thus increase the value of your application!

High Contrast

Windows' High Contrast color schemes assist those who cannot see well, are color blind, etc. In my experience very few programs run correctly in these modes. In fact, I just switched my Windows XP Tablet Edition into High Contrast #1 with extra large fonts on a 1024x768 display and found bugs in CopyDesk where the menu bar and more than half the toolbar buttons are unreadable or unusable. Why?

The new background for the menu and toolbars is black, the correct text color would be white but in this case all the menus are still drawing their text in black. Black text on black background makes for a difficult user experience. I don't mean to pick on this application, it just happens to be the one I'm writing this article in while I do the experiment.  In reality you put most applications in this mode and they will be awful. I've know more than one tester, when faced with the need to build up their bug count, to put their computer into high contrast mode with extra large fonts on the minimum 'supported' screen resolution and let the party start. We call it a 'bug farm'.

By contrast (haha sorry) you can tell the very mature, high quality applications by the fact that they handle all of these without issue.  I launched Word in the same situation and it looked great (under the circumstances).  However, when I selected this article and pasted it in, the text from the article was black on black even when I tried pasting with destination formatting.  Guess I'll let them know they have a bug.

To try this out you can either use the Accessibility Wizard or set the color scheme to one of the High Contrast schemes in the Display control panel (your Windows and buttons setting must be Windows Classic style for Windows XP).

High DPI

High DPI displays are not an accessibility feature but rather the cause of additional accessibility problems.  Most applications are built assuming 96 DPI displays (because that's what most displays are currently).  If you make that assumption on a computer with a higher DPI display it can make it unusable, including (and why it is in this article) UI elements that are way too small and difficult to click with a mouse, etc.

I'll talk more about High DPI Displays in a later Foundations article.

Large Fonts

When a user tells the operating system that they want to use large or extra large fonts (Appearance tab of the Display control panel), all applications running for that user should respect the setting and act accordingly.  This means your GUI needs to scale, allow room for the larger strings, and in general accommodate a user who has said they want things bigger and easier to read.

Instead, what often happens is the applications use the correct font size for common controls and their own favorite font and font size for their own custom controls.  This leads to a mix-n-match UI that looks horrible, amateurish, and is more difficult to use.  Alternatively, the UI can all have font sizes the same: still small and difficult for the user to read.

Furthermore, be careful when you store font information.  Just as hardcoded font names and sizes on the web is bad (and it is), saving for instance '12pt' when you mean 'standard size' and '16pt' when you mean 'larger than standard size' means things won't work right if and when the settings are changed.

Microsoft Active Accessibility

First, the more general MSDN page on developing accessible applications.

MSAA is a set of APIs used by hardware and software developers to create assistive technologies for people who have disabilities that prevent or impair them from using computers and/or the more widely used input devices.

Examples of assistive devices and software:

• Screen readers - Software that reads the text on the screen to those who can't.
• Screen magnifiers - Acts like a magnifying glass to enlarge the active area of the screen.
• Speech recognizers - Allow the user to interact with speech instead of keyboard or mouse input.
• Braille displays - Show either the active or the entire screen in a Braille texture surface.
• Alternative pointing devices - Other approaches to indicating points on the screen besides the mouse.

And more, limited only by what creative people can design to make interaction with computers easier or even possible for some.

What developers of UI need to do is either use common UI controls (and set the accessibility properties of them correctly) or implement IAccessible on their custom controls and give complete and correct information via that interface.  That way, when the assistive technology code talks to yours and asks it what it should tell the user via a screen reader, or what it should show in a Braille display, or what your control does, what its label is, etc. it will have the correct information and user will be able to use your program painlessly.

Foundations: Multi-User Windows

Read the title to this article and think to yourself what you expect it to be about.  I believe most people will have a definite idea, and while most of them are correct they are incomplete.  Such is the nature of this problem, many applications deal with one aspect of the problem well while ignoring the others.

I'm going to talk about Windows with multiple users from three angles:

1. As of the Windows NT line of products (which includes Windows 2000 and the current version as of this writing, Windows XP) you log into the computer with an account, and different users (should) log in with different accounts.
2. Windows XP has a feature called 'Fast User Switching' which allows more than one person to be logged in at the same time.  You can switch from account to account without logging the other ones out.
3. On a Terminal Server, many users can all be logged on remotely using Remote Desktop to a single computer simultaneously.

User Accounts

DOS, Windows 95, Windows 98, etc. all were based on the single user model.  There was only one user of the computer (at a time, anyway) and they owned everything and could do pretty much whatever they wanted.  This evolved from the nature of the PC in the formative years and made sense for a while.

So why should different people using the same computer use different user accounts?

• Settings, options, and preferences: For well-behaved applications these are all stored on a per-user basis, by logging onto my account the application can load my settings rather than someone else's.  This includes the Desktop, My Documents folder, etc.
• Ownership: When I create a file my account 'owns' it, which means it is either impossible or at least more difficult for someone else (from their account) to modify or delete it on purpose or by accident.
• Privacy: Different users' private data can be made inaccessible to other users, protecting their privacy.
• Security: Each user has their own password and/or other authentication mechanisms, preventing others from impersonating them and allowing administrators to deny access to only the required people when necessary.
• Stability: By having different users access the computer with different accounts and specifying access rights for those accounts properly, the chances of users accidentally destroying data, installing bad software, corrupting the system with a virus, etc. are all substantially reduced.

Let's dig into what makes an application play nicely in this environment.

User Settings

If you store information about settings or preferences, it should almost always be done at the user level.  For the registry, this means HKCU (HKEY CURRENT USER).  HKLM (HKEY LOCAL MACHINE) should only store information that is universally true for the entire computer regardless of who is using it.  Even in those cases it is often best to use HKCU, because...

Running As a Non-Administrator

The number one thing a user on a Windows system can do to avoid getting viruses, worms, and other nasty problems is to have their user account not have Administrator rights to the computer.  There are a few issues in the OS that get in the way of this happening, but there are tons of problems with some non-Microsoft products that behave really badly in this case.

These issues get even more extreme when someone uses an application while logged on with minimum rights such as the 'Guest' account.  It is reasonable for an application to have features that don't work given non-administrator rights (although this is usually just laziness), and even more reasonable when they have only Guest rights, but the important this is to have graceful degradation of functionality based on the resources and rights available.

Run As

When you're running as a non-Administrator there will be times where you need more access in order to get something done.  That may be accessing some data, it may be installing a new program (this is the normal case in my experience), or it may be running some application that boneheadedly requires Administrator access.  No need to log out and log back in (or even use Fast User Switching which I'll cover below but can be handy in these cases from time to time), instead use the Run As command.

In Windows XP it is available as a right-click option on programs as well as being a command line utility (type 'runas /?').

Files

Another common mistake (besides HKLM instead of HKCU) is where files are kept.  If you store them based on the user account it is very unlikely there will be permissions issues.  Create your files in the right location with the correct ACLs, and never allow other users to access your customer's data unless they want them to.  If they're stored in a hard coded location (especially in Program Files) it takes elevated (read: Administrator) privileges to create files often.

I'm sure there are a number of old applications (especially games) that require the user is an Administrator for no other reason than they save information in their Program Files folder instead of the user's profile or My Documents folders.  Which leads to...

PIDLs

Hard-coded paths suck, especially when trying to get the location of special folders from the OS.  Use functions in the SDK like SHGetFolderLocation(), where you pass in value for the special folder you're looking for and it will give you back the location that is always correct.  Special folders include the Desktop, the My Documents folder, My Pictures, and so on.

Privacy and Security

For particularly sensitive information there are security and encryption APIs to help developers help their users keep it hidden and safe.  The amount of information you can store is limited, so use it wisely, but it makes a lot of sense for things like encryption keys.  If you wanted to encrypt a file with sensitive data, for instance, you don't want to just write the key for the encryption into another file right next to it.  Instead, hide that key using the OS's mechanism.

Fast User Switching

Fast User Switching (FUS) and Terminal Server (TS) are very similar, the only real difference being that with FUS only one user can be interacting with the computer at a time even though they're all logged in to the system, while TS allows the users to all be active.

The big gotcha for most programs is to realize that more than one user may be running the program at the same time, with different access rights, operating with a different set of preferences, etc.  For most programs this isn't a big deal, but if you require exclusive rights to a resource (maybe the sound card, or the DVD drive) you need to check for the conflict, avoid major problems, and thoroughly inform the user.

Terminal Server

An issue that is more important for TS than FUS is idle time processing.  Most developers think that taking up 5% of the CPU (as an example) every X many seconds is not a big deal.  It may not be in the case where only a single user is interacting with the system (although it can be very annoying even in this case), but if you're on a TS machine with 20 people logged in, every X many seconds 100% of the CPU is being used if they're all running such an application.

Foundations: Usability

Applications exist to either make something easier for an end user to do or in some limited cases make it even possible.  The UI in particular (and by this I mean either the GUI, the command line argument structure, however the users interact with the program) exists to make it possible for the user to accomplish tasks.

Despite what some applications display, the UI does not exist to show the user how the code works under the hood, what the data structures are that store the user's information, nor the graphical embodiment of the organizational structure for the team working on the project.  The User Interface exists for the benefit of the user, and should be designed around the user.  Novel concepts, huh.

Ease of Use

The summary of the entire article is that ease of use translates into user productivity.  Productivity is, for most applications anyway, the whole point and the value proposition that gives customers the reason to spend the money.

It is critical to measure usability and usage in any way that is possible.  If you don't know where you are, you can't know where to go.  If you don't know whether a change is good or bad, you can't know whether the right decision is to make it, not make it, or change it in a way that will make it better.  Of course, if you guess you're very likely to get it wrong.

Usability Data

So you need data, you need to make informed decisions.  What are your choices?

Lab

Bigger projects and companies have their own Usability Labs where they can test out different kinds of prototypes to see what works, what doesn't, and how their current versions score.  They can prioritize based on the biggest problems they have and either make changes to existing features or design new features to address them.

The ability to take prototypes to users and get feedback before spending time and resources on design, development, and testing is a big win.  The industry is awash with bad ideas that could have been either avoided or fixed if this simple and relatively inexpensive exercise had been done.

CEIP

Microsoft's Customer Experience Improvement Program is a great example of getting and using real-world product usage data to improve future versions.  It is an opt-in, anonymous feature added to many Microsoft products that allows users to send data on their usage of the product.  Opt-in and anonymous are both absolutely key to this sort of functionality, you should never collect information without consent and you should not store the information in such a way that you can tie it to other data you may have about them.

Some examples of questions this type of data is excellent at answering:

1. How often do users encounter this specific error?
2. If they select feature X, do they use sub-feature Y?
3. Do only users with Pentium IV computers or better try do to Z?  How often do they cancel it if it takes longer than 30 seconds?
4. What is the average data transfer speed user experience with B?

In other words, if you need some data based on real-world usage of your application and you can't get a good sense of it from usability testing (there's a lot of data that falls into this category), letting your customers help you help them better by collecting anonymous data from them to feed into your decision making processing can be a huge help.

Surveys

Pretty self-explanatory, you should get consultation from your friendly neighborhood statistician on the best way to design the questionnaire and choose the recipients to make the data you receive as meaningful as possible.  Got questions?  Ask your users and/or potential customers!

Feedback

If someone spends money on your product they usually are more than happy to let you know what they think about it, and are just looking for opportunities to tell you about it.  You have to listen, have well-understood ways to incorporate the feedback into your decision-making processes, and be able to turn the feedback into solid value propositions.

For most customers the problem they face (or at least feel strongly that they face) is the inability to effectively communicate to the company their feedback.  Easily discoverable ways to let you know what they like and don't like, discussion forums to talk to each other and build a community of customers and users, these are great ways to get information and strengthen your customer base.

Fit and Finish

I debated when outlining this series whether fit & finish belonged in Usability or Performance.  I ended up putting it here because these problems get in the way of the user trying to do tasks.  It may not stop them, but it interrupts their flow. Since flow is crucial to productivity and efficiency, getting all the small details right can make your application more valuable.

Scrolling

A great example of getting all the small details correct is Raymond Chen's series of blog posts on Scrollbars.  You may have to scroll down a bit for it (hahaha at hem sorry), but it is well worth it.  Getting scrolling just right is a minor, nitpicky point for most applications.  If you don't get it right your users will notice and will be affected by it.  I'm not using this as an example of something you need to get right or else, but rather an example of how to approach fit and finish in your application.

MRUs

Most Recently Used is a great example of something that is usually a usability win.  Keep track of what the user is doing and optimize their experience around it.  Make it easy for them to repeat what they usually do, so there isn't searching around or trying to find files, etc.  It is not a silver bullet, however, and in some cases MRUs can get in the way instead of help.  Usability labs help to determine which is which.

OOBE

OOBE stands for Out Of Box Experience, in other words what happens the first time the user installs and runs your application.  In most cases I believe that experience should be different than the experience they have the second time and onward they run it.

What do they need to learn to use your application?  What needs to get set up to make it work correctly?  How do you make the user feel good about the purchase?  These are all good things to think about for the first time the program runs.

However, you should not get in their way every time they run.  A few examples: splash screens, intro movies for games, wizards, tips and tricks, anything that gets in the user's way when they want to launch and get going.

One problem I think most products have is the company considers them an island and an experience unto themselves.  Most are just part of an overall workflow the users are in the midst of to get their work done, the more you can do to get out of their way and make their lives easier the more valuable your product will be.

Interaction Models

A good portion of usability is tailoring the UI interaction model with the type of work to be done.  Creating a tree view of data because the programmer really understands how to use the tree view control doesn't make it the right way to have the user interact with the program (although it very well may be).  Starting with what the users want to do rather than how you want to store it is a good start, but next is to figure out ways to taking advantage of different mediums (like GUI did with the mouse) to make things easier for the user.

A few newer items to think about and see if they make sense for your application:

Ink/Pen

This is both for the new Tablet PCs and for other form factors that have stylus input or standalone tablet devices.  Is there an advantage to gearing workflow to this input style?  Will supporting gestures in a deep way help user productivity?  Can support of pens and digital ink be a source of differentiation from the competition?

Speech

Speech interaction with computers is just starting to be feasible and usable.  One of the barriers is that mouse/keyboard input to applications doesn't translate well to speech input.  There are interesting opportunities for designing interaction models around speech input that fully take advantage of the medium.  I caution that it is still early, and you would be wading into uncharted waters.  That said, the upside looks fantastic for those who can make it work in ways that users understand.

TV/Projection View

With Windows Media Center Edition there's another interaction model to think about: the living room setting.  If your application is running on a MCE PC, and it makes sense, you might want to have an interaction model geared towards the users being 10' away and running the PC with a remote control.  Think very big UI, easy to read, geared towards a remote control rather than a mouse, etc.  This is also relevant for PowerPoint scenarios where the UI for the application is being shown on a large screen, possibly for a large number of people.

Shell Integration

The line between the Windows Shell (explorer.exe) and applications is starting to blur.  Instead of launching a separate experience to interact with data and accomplish tasks, there's a move to a model where more functionality is integrated and seemless.  By creating Shell Extensions, you too can add functionality in an integrated and powerful way to increase your customer's productivity.

Cell Phone/PDA

Pretty straightforward; small screens and limited resources for graphics, memory, CPU, and storage.

Foundations: Globalization

Recently Joel Spolsky wrote an article on Unicode and character encoding that significantly shortens the length that I need for this article, so before we go any farther please go read "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)".

Back?  Great.  That's just the beginning of world-class global software, but it is required for what I hope are now very clear reasons.

The next major resource I want to recommend for this subject is the book Developing International Software, Second Edition.  The focus of the book is Windows-centric (as is this website), but there is plenty of information that you must know if you want to write international software no matter what platform it is for.  Most (if not all) of the subjects in this article are covered in depth in that book.

Planning for Localization

When you create software for an international market you normally write and design it for your native language or the language of the first market (usually English), and then get it localized into other languages and for other regions.  What needs to happen to localize software?

1. Translation of all the strings to the new language (this is the most obvious one).
2. Changing UI layout to properly display the new strings (German translations tend to be larger than English, Chinese tend to be smaller).
3. Handling RTL (or 'mirrored') locales (where the text lays out from right-to-left instead of the English left-to-right style).
4. Changing the way dates, times, currencies, etc. are handled to the appropriate style for the locale.
5. Make sure the fonts are appropriate for the locale and language.

For too many software products, localization is something that blindsides the product team either late in the cycle (near release date) or after the English release.  You have a successful product, you're selling like hotcakes, and now your sales team wants to expand into Europe, Asia, South America, Africa... anywhere they can make money!  Then begins a trek up a steep learning curve and often the need to rewrite large portions of code to take into account all the differences between all the different regions and languages in the world.

Pseudo-Loc

The first technique for mitigating the problems is to pretend like you're localizing the product without going through the (significant) expense of doing so, in order to flush out problems early.  This involves using characters in the language you're trying to test, making your strings larger or smaller than they are for English, setting the thread locale, etc.

Your test team is then able to find and file bugs against code related issues that can be fixed well ahead of the actual localization of the product.  It ensures a few very good practices:

• The differences between the executable code for the different languages is either minimal or (ideally) none.  This makes the testing matrix much more manageable.
• Localization and internationalization are on the team's mind throughout the whole product cycle.
• The processes for producing localized versions can be worked out early.

Separation of Localizable Resources

The first major step is to move all resources (strings, dialogs, etc.) that can change from locale to locale into a separate resource-only DLL.  Some method for the developers to communicate the intent of the string/dialog/etc. to the localizer is time saving.  The correlary is that only localizable resources should be in that DLL, any strings, bitmaps, or other resources that should not or will not change should not be in that DLL.

Once you have that separation you have a well understood item that needs to change during the process, and nothing else should have to be modified.  Let's pretend we have an application called myapp.exe that currently contains all the code and resources for the project.  If I give this to a localization team, they will have to both determine what needs to be changed and change it, an the result will be a different myapp.exe version for the new locale.

If I've got myapp.exe and myappres.dll, however, I separate the code from the resources and the only difference between my application in English vs. Traditional Chinese vs. Hebrew is which resource DLL it loads.  This is very important for supportability issues.  If my resources and code are all in one executable and I fix a nasty crashing bug and push it out to customers, I have to release a different version of that executable for each locale I've localized to.  If they're separate, I can release one version to fix the executable only for all localized versions.  Much easier to test the changes and release these fixes fast, too.

Common Controls

Writing globalized UI code is difficult and time consuming, which is why I heavily recommend leveraging the common controls provider by Windows whenever possible.  Even seemingly simple pieces of UI are very expensive once you add up all the different things that need to be done right to be used in a world class application.

MUI

Multilingual User Interface is a feature that was added to Windows 2000 Professional and is a very important for multi-national companies who want to simplify deployment, support, and multi-user computer use.

Each user account on the MUI Windows system can set their own locale.  This means that two users of a shared machine can each have the UI in their own language, it also means that support personnel can work on user's computers in their preferred language without disruption of the user's settings.  For deployment, it enables a single image/installation type worldwide.

If these kinds of deployments are important for your application, supporting MUI can be a big win.  The idea is that you have a MUI version of your application which installs a different resource DLL for each of the locales you support.  When your application is run it calls the appropriate APIs to determine which locale the user is running and loads the resource DLL with the most correct resources.

Notice how thoroughly doing the right thing end to end makes these kinds of features easy to do.

IMEs

IME stands for Input Method Editor, and is how you can type (for instance) Japanese on a US keyboard.  If you use common controls (as recommended) they are IME aware, if you do it yourself you need to make sure you understand the requirements and the level of support you want to provide.

Globalization Gotchas

Some other items to think about that may or may not have been called out above:

• Formats (and more!) can vary based on locale:
• • Time and date
  • Currencies
  • Numbers
  • Addresses, telephone numbers
  • Units of measurement, standard sizes
• String sorting and comparing is very difficult
• • Capitalization (uppercase, lowercase, when it is appropriate) is a big gotcha.
  • Line and word breaking is very language specific.

The default answer should be to use the built-in Windows APIs for all these functions and let them do all the hard work for you.  Windows has already paid the price to do this right, there's no reason for you to repeat it.