Accessibility: Maximizing the Number of People Who Try Your Simulation
In the old days of classroom-only training, accessibility was about getting people who needed training into classes. It usually boiled-down to three issues- class frequency, size, and location. Providing training (including simulation training) on-line, at first seemed to have solved the accessibility problem. But in fact, it opened up a whole set of new challenges.
The Web gives control to the user. Giving individuals control over their own learning completely changes the power relationship between instructor and student. In a class, once you've decided to attend, it takes a sustained force of will to give up and get out of the class. With online material, including web simulations, students drop out after the smallest frustration. Therefore, improving accessibility for an online simulation means eliminating every possible frustration that the user might encounter.
As I said in an earlier article, accessibility is one of the four critical elements of F.A.C.E. value (fun, accessible, clear, educational) that makes a successful simulation.
Accessibility Hurdles
At this moment I am flying back to San Francisco after a trip to France and London. Sitting in an airplane flying at 33,000 feet as it crosses the Atlantic seems like a good place to write about accessibility. Actually, I enjoy these hours of inaccessibility while flying. I have time to read, do a little uninterrupted work, see another movie by Kevin Costner. However, being inaccessible means that things that I want are also inaccessible to me. For example, now would be a perfect time to do some online training or run a simulation. What's stopping me?
- A slow (and expensive!) airplane modem connection.
- Limited battery life of my laptop.
- My laptop screen is pretty small.
- Turning the sound on my computer would annoy other passengers and I don't have headphones with me.
- I'm using the touchpad so I can't do anything that requires a lot of mouse dexterity.
- The guy in the seat next to me feels like having a chat.
This last challenge, typically referred to as an environmental distraction, is really important. In a classroom there are few things to distract you. Everything is focused on the education. When simulations are run at work, at home, or on the road, there are dozen of alternatives-kids, TV, colleagues, telephone, etc. You've got to do everything you can to keep your users attention long enough to get them to the simulation.
Monte Carlo vs. Las Vegas
This past weekend I visited Monte Carlo. I don't like to gamble, but I've been to Las Vegas a few times for conferences and I always liked the James Bond movies where Bond gambles in a tuxedo in Monte Carlo's Grand Casino, so I wanted to check it out.
The Casino in Monte Carlo is vastly different than the casinos in Vegas from an accessibility perspective. First off, you can't park at the casino so you have to find a city lot where you pay for parking. Las Vegas casinos have huge free underground parking garages. Monte Carlo's casino has hours of operation while Las Vegas casinos never close. Monte Carlo charges admission to enter the casino, something that would be unthinkable in Las Vegas. If you're a tourist and have a camera with you (as I did) a security guard asks you to check it before entering. The casino has a dress code. The game rules are different than at other casinos, so the whole experience of trying to gamble is intimidating.
Monte Carlo's Grand Casino is beautiful and authentic in a way that Las Vegas casinos don't even try to be. However, the accessibility challenges definitely had an impact on my own participation. I spent about thirty minutes looking around the Casino in Monte Carlo. When I was last in Las Vegas, I went to The Bellagio with roughly the same level of ambivalence to gambling and ended up trying a table, staying for three hours, and losing $200. In Las Vegas, improved accessibility made the difference between playing and observing.
Accessibility and Eliminating Frustrations
Simulation accessibility is similar to casino accessibility. It's all about getting people to the simulation by making it as easy and painless as possible. And, like Las Vegas, once they're in, doing everything you can to get them to stay.
Accessibility is about much more than just getting your simulation up on the web. It's about removing every possible frustration for the user. Simulation accessibility frustrations come in four forms:
Frustration 1: It takes too long to load the simulation
Jacob Nielsen, in his excellent book Designing Web Usability, says "Fast response times are the most important design criterion for web pages." Ideally a web simulation page will load in less than a second, but the longest a user should have to wait for a simulation page to load is 10 seconds. According to Nielsen's research, if delays are longer than 10 seconds, users will want to perform other tasks while waiting for the page to load. Distractions lead to loss of user interest.
Response delay time is determined by two factors: the size of page being loaded and the user's Internet connection speed.
If you want your users to run your simulation at home, in a hotel, or on the road, you'll need to design for a 34 Kbps connection. This means:
- Limit your use of graphics and multimedia. There is a trade-off here because good multimedia can make your simulation more fun. Some multimedia formats, such as Macromedia's Flash can theoretically work well over slow connection speeds. But designers have a tendency to create huge Flash files. The problem occurs when the Flash object is too big, resulting in long download times.
- Quickly provide something enjoyable for the user to do. The most important concern in response time is how long it takes for the user to see a screen of information. This means that you can have a more complex web page so long as part of the page load quickly.
- Don't use client-side Java. It's tempting to use client-side Java because, in theory at least, you can load the entire simulation on desktop before playing. But most applications will take well over a minute to load and many will take over ten minutes at 34 Kbps. Most users will assume that their browser has stopped working or the site has hung and just move on to something else. Although client-side Java is a poor choice, server-side Java works great. Server-side Java creates the web-page on the server before sending it to the browser. So, if you have a reasonably fast server, the delay won't be noticeably different than straight HTML pages. Also Javascript works great and loads fast.
Frustration 2: There are too many steps required to get to the simulation
When users are required to do things before getting to actually playing the simulation, such as fill out a form, provide their email address, or complete a short test, they tend to drop out. So, although it's tempting to collect information from the user before starting the simulation, from a accessibility perspective, it can be disastrous.
A small firm run by software guru Joel Spolsky called Fogcreek Software did an interesting experiment that illustrates why collecting user data prior to starting a simulation is a bad idea. Fogcreek used to ask users to provide an email address before downloading a free software demo. The folks at Fogcreek wanted to learn how many people their email request was scaring away. They changed the demo signup so that 50% of potential customers had to provide an email address before downloading the software and 50% didn't. What they discovered was that about half the people gave up when asked to type in an email address.
Asking for something as simple as a single email address reduces accessibility by 50%.
To reduce the number of steps before getting to the simulation:
- Don't pretest users before allowing them to run your simulation.
- Don't collect user information initially (instead, do this when the simulation is completed).
Frustration 3: The simulation is incompatible with the user's hardware and software
There is a tendency to view the world from one's own perspective. People who use a desktop machine with a big monitor assume most people have big screens. If you use Windows it's easy to forget about all the people out there who use Macs.
When designing a simulation, keep in mind that people will be using your simulation with all kinds of hardware and software configurations. Although it's tempting to use the latest cool tools to design your simulation, if you do so, you're going to make your simulation inaccessible to many users. According to W3 Schools about 65% of Internet users use IE. That means that building a web simulation that is only IE compatible will eliminate about one out of every three users.
When building a web simulation, stick with widely-used browser-native formats. Right now, designing for IE and Firefox compatibility is a good target. Forio favors AJAX and Flash for simulation. Both are available on over 300 million browsers. Also screen size for the simulation should be no larger than 1024 x 768 and, for maximum accessibility, 800 x 600.
Frustration 4: The user faces environmental distractions
There are all sorts of environmental limits to simulation accessibility. When users are getting to the simulation, they can discover:
- Can't listen to sound because the user sits in a cubicle.
- The simulation user is asked to join a meeting in the conference room.
- Kids need help with a school project.
- TV is on in and the sports news comes on (if the user is interested in sports).
There is very little that a simulation designer can do directly about these environmental factors. Instead, the simulation should be compatible with environmental distractions. Here are a few suggestions for accomplishing that:
- The simulation should be designed so that it doesn't take more time to play than necessary. The shorter the play time, the more likely it is that the user will complete the simulation.
- If the simulation is meant to be played over several rounds over a period of days, then the simulation should save the state of the simulation if the user has become distracted by some other activity (this is usually indicated when the user hasn't changed anything for a while.
If the simulation is meant to be completed at one sitting, then the simulation should time-out and return the user to the beginning of the simulation after a significant amount of time has passed where the user hasn't changed anything.
- The simulation should be fun, so that it can successfully compete with environmental distractions. Avoid intimidating the user with complicated terminology, graphics, navigation, or rules (more on this when I write about usability).
As one of the four elements of F.A.C.E. value, accessibility is critical to creating a successful simulation. Improving accessibility can vastly increase the number of people who try your simulation.
|
Improving accessibility for an online simulation means eliminating every possible frustration that the user might encounter. Frustrations include:
|
Posted by Michael Bean
