Website accessibility is obviously an integral part of user experience; a negative user experience is certain to occur when a consumer cannot access a commercial website, which, in turn, almost always carries negative business consequences. To make matters worse, an inaccessible website may also expose the site owner and/or designer to legal liability.

Accessing the Internet as an Individual with a Disability

Since the Internet transitioned from a predominantly text-based to a graphics-based phenomenon, accessibility of websites has been an issue for individuals with disabilities, most notably those with vision or mobility impairments who cannot easily use standard computer equipment. The number of Americans with such disabilities (already in the millions) is growing each day as aging baby boomers—who have disposable income and are accustomed to spending that income online—develop these disabilities. Individuals with these disabilities rely on adaptive technologies, such as screen reading software, to provide them with feedback that helps them navigate through web pages, obtain information, purchase goods, and contract for services. As a result, website designers should observe some well documented, basic programming tenets when creating or updating webpages to allow users of adaptive technologies to access websites.

Indeed, a website created in accordance with "universal design" typically benefits both disabled and nondisabled users. For example, a website designed to be universally accessible is typically organized better than an inaccessible site, permitting better ease of use and a superior user experience. Further, simple programming techniques allow a universally accessible website to be as aesthetically pleasing as the designers' imaginations will permit. In other words, accessibility is not mutually exclusive of creativity.

Why Accessibility Is Important

There are several reasons it is important to proactively make a website accessible. First, an accessible website expands a business's market to include individuals with disabilities who use the Internet to shop and do research in the same way nondisabled individuals do. In fact, most disability communities share amongst each other which sites to use because they are accessible and which to avoid because they are not. Second, retroactively correcting years' worth of inaccessible programming consumes vastly more financial and programming resources than taking simple steps to make a website accessible when it is initially designed or substantially updated. Third, an accessible site avoids exposure to potential lawsuits.

The Americans with Disabilities Act and the Internet

The principal law pertaining to accessibility of commercial websites is the Americans with Disabilities Act (ADA), 42 U.S.C. § 12101 et seq. Title III of the ADA prohibits discrimination against an individual "on the basis of disability in the full and equal enjoyment of the goods, services, facilities, privileges, advantages, or accommodations of any place of public accommodation…." Discrimination includes denial of participation as well as provision of separate, but unequal, goods or services. "Public accommodation" is defined to include operations that "affect commerce;" the law provides 12 general categories of covered businesses such as hotels, restaurants, places of entertainment, sales and rental establishments, service establishments, places of recreation, and places of education. The law also requires affirmative "reasonable modifications" of "policies, practices, and procedures" to make them equally accessible.

The United States Supreme Court has yet to specifically rule that Title III requires private companies to make their websites accessible, but there has been significant guidance from the lower federal courts and the United States Department of Justice (DOJ), which enforces the ADA, that Title III does apply to commercial websites. Many major businesses, including AOL, Amazon, and Target, have relied on this guidance in deciding to make their websites accessible pursuant to Title III.

One of the landmark cases on this issue is Carparts Distribution Center, Inc. v. Automotive Wholesaler's Ass'n of New England, Inc., 37 F.3d 12 (1st Cir. 1994). Although Carparts does not actually concern the Internet, it is important because it establishes that "public accommodation" as defined in Title III is not limited to physical structures. Another federal appeals court later adopted the logical foundation laid by the Carparts decision and added that the purpose of Title III

is that the owner or operator of a… Web site, or other facility (whether in physical space or in electronic space) that is open to the public cannot exclude disabled persons from entering the facility and, once in, from using the facility in the same way that the nondisabled do.
Doe v. Mutual of Omaha Ins. Co., 179 F.3d 557, 559 (7th Cir. 1999) (citation omitted).

Like Carparts, however, Doe did not specifically involve a claim regarding accessibility of a website.

The Target Case

Subsequent litigation, however, leaves little question that Title III requires commercial websites to be accessible. The key legal decision in this regard is National Federation of the Blind v. Target Corp., 452 F. Supp. 2d 946 (N.D. Cal. 2006). In that case, the plaintiffs claimed that Target's website, target.com, which offered goods for sale and provided information regarding services offered at brick-and-mortar Target stores, was inaccessible and thus in violation of the ADA and California state law. Target moved to dismiss the claim on the grounds that the laws did not apply to the website. The court rejected Target's argument and focused on the plain language of the ADA in ruling that Target's brick-and-mortar stores are "public accommodations" under the definition set forth in Title III.

The court then determined that target.com was a "service" of Target's stores in light of the transactional and informational connections between the two. It was just a matter of finishing the syllogism that, as a service of a public accommodation, Target.com was subject to Title III. The ruling in Target was based on the "nexus" between the website and the brick-and-mortar stores. Another court in an earlier case, Access Now v. Southwest Airlines, 227 F. Supp. 2d 1312 (S.D. Fla. 2002), reached a different conclusion than the Target court because the website at issue was not related to a physical place of business. This factor, however, may no longer be part of the analysis after the DOJ issues proposed regulations regarding the ADA's applicability to the Internet.

Upcoming Regulations and the Probable Expansion of the Target Ruling

In conjunction with the 20th anniversary of the ADA, the DOJ has clearly expressed that it regards commercial websites as being covered by the ADA. On April 22, 2010, Samuel R. Bagenstos, the Principal Deputy Assistant Attorney General for Civil Rights, testified before a House subcommittee that

[t]he Department of Justice has long taken the position that… websites of private entities that are public accommodations are covered by the ADA. In other words, the websites of entities covered by… Title III of the [ADA] are required by law [to be] fully accessible to individuals with disabilities.
Emerging Technologies and the Rights of Individuals with Disabilities: Hearing Before the Subcomm. on the Constitution, Civil Rights, and Civil Liberties of the H. Comm. on the Judiciary, 111th Cong. 5 (2010).

Bagenstos went on to describe the DOJ's two "friend of the court" briefs filed in federal appeals courts where the Department expressed the position that "a business providing services solely over the internet is subject to the ADA's prohibitions on discrimination on the basis of disability." Id. at 6. Then, in July, the DOJ released a notice that it was considering regulations on the subject of commercial websites' compliance with the ADA. Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities and Public Accommodations, 75 Fed. Reg. 43460 (proposed July 26, 2010). The notice reiterated the position previously stated by Bagenstos and declared that "the Department is focused on the goods and services of public accommodations that operate exclusively or through some type of presence on the Web—whether hosting their own Web site or participating in a host's Web site…" Id. at 43465 (emphasis added). This clearly indicates that the DOJ is considering an expansion of the Target and Access Now decisions to require public accommodations that do not have a brick-and-mortar presence to make their websites accessible.

Other Laws and Designer Liability

In addition to the ADA are state laws, such as California's Unruh Civil Rights Act and Disabled Persons Act, which are at least co-extensive with the ADA in terms of scope and permit damage awards. These monetary damage awards are even more incentive for a business to make their websites accessible than the standard consequence under Title III of a court compelling a website to be made accessible. The Unruh Civil Rights Act also makes it illegal to aid or abet discriminatory activity, which implicates the actions of website designers as well as website owners. Further, these state laws could very well be interpreted to extend even further than the ADA with respect to accessibility of commercial websites, particularly in the context of online-only businesses.

What Does This All Mean?

In sum, it is clear that Title III applies to commercial websites and there are increasing indications that the DOJ intends to make no distinction between businesses with brick-and-mortar locations and those that operate solely online. In addition to the legal considerations, there are sound business reasons to design accessible websites, including a better user experience for all consumers, avoiding higher costs of retroactive compliance with the law, and increased revenues by capitalizing on an expanded market. Who ever said doing the right thing had to be difficult?

About the author(s)

Gregory P. Care is an attorney at the law firm Brown, Goldstein & Levy, LLP in Baltimore, Maryland where his practice includes disability rights. Brown, Goldstein & Levy was one of several firms that represented the plaintiffs in the National Federation of the Blind v. Target Corp. class action lawsuit that resulted in a settlement to make Target.com accessible. 

One of the things that has bugged me about the WP Super Cache settings page was how it was laid out. Well, the next version of the plugin will display a simplified settings page to new users. If you’re upgrading, you’ll get the same old page as ever, don’t worry.

This version also adds a new method of serving cache files. It uses PHP, but serves supercache files. So, it’s a halfway house between using mod_rewrite (difficult to install for some users), and the legacy caching of WP Cache. That caching will be what is activated for users who use the simplified settings page.

There are lots of other bug fixes. The cache tester works if WordPress is installed in a sub directory, the admin page is separated out into tabs now to make it easier to find things. Error messages show up as “update messages” at the top of the browser now, making it easier for new users to figure out when mod_rewrite rules need updating and when other house keeping tasks need doing.

The code is red hot, liable to bend and break and may cause problems but it works fine here and on a test multi site install but I need testers to hammer on it and do things I don’t expect. If you’re brave, grab the development version off the download page. Thanks!

Related Posts

• WP Super Cache 0.8.4, the garbage collector
• WP Super Cache 0.8.7
• WP Super Cache 0.9.9

Here are some battery saving tips for Android phones. I’m going on a long flight in a few days time so I’ll be trying these tips out before I go!

• Go into Settings->About phone->”Battery use” to see what’s chewing up your battery.
• Turn off haptic feedback. That’s vibration alerts when you press your screen. Turn off vibration as a notification too.
• Apparently 3G uses more power than wifi so make sure wifi is always on. (Settings->Wireless and network->Wifi Settings->Advanced->Wifi sleep policy and select “Never”). My Galaxy S switches to 3G when the screen blanks by default but apparently this is a big battery saver. Only when you have a wifi network around I guess.
• Always press “BACK” when you want to exit an app.
• Turn off GPS. If your phone uses the cell network to find your location turn that off too.
• Turn on power saving, and reduce the screen timeout so it goes black faster.
• Turn off wifi when you leave your house or work. That stops your phone trying to connect to a network.
• Turn off bluetooth when you don’t need it.
• Turn off 3G and use 2G. (Ugh, slow!)
• Turn off background data and syncing.
• Turn down the brightness on your display.
• Don’t use your camera.
• Don’t use a live wallpaper, what’s wrong with a static picture?
• Don’t use a homescreen widget that pulls data and updates all the time.
• Task manager are generally frowned upon but some apps misbehave and don’t close properly. “Watchdog Lite” is a useful app that tells you how much CPU each app running on your phone consumes. Beware closing apps too much. They may look like they’re running, but they’re not. Android keeps them in memory, so they start up quickly next time.
• Get Juice Defender off the Market. Besides a ton of battery saving features, the like of which I’m still trying to understand, it has a handy widget that will disable mobile data completely. Nice!

I’d love if Android phones totally disconnected from the Internet when I closed the browser, Tweetdeck or whatever app was using the network. My old Nokia 5800 did that. It connected each time I opened the browser and had wonderful battery life.

So, what other tips can you suggest for power hungry smartphones?

Related Posts

• Apple Store Promotion Code
• How much of your Macbook’s battery is gone for good?
• Tips for Using a Point & Shoot …

In the last few years, more and more organizations have come to view UX design as a key contributor to successful products, connecting teams with end-users and guiding product innovation within the organization. Though it’s fantastic to see this transition happen, there are growing pains associated with becoming a user-driven organization. These are the pitfalls that I see organizations grappling with most often.

Pitfall 1: It’s easier to evaluate a completed, pixel-perfect product so new products don’t get vetted or tested until they’re nearly out the door.

Months into a development cycle and just days before the release date, you realize that the UI has serious flaws or missing logic. If you’re lucky, there is enough flexibility in the schedule to allow grumbling engineers to re-architect the product. More likely, though, the PM will push to meet the original deadline with the intent to fix the UI issues later. However, “later” rarely happens. Regardless, everyone wonders: how could these issues have been caught earlier?

The UI is typically built after the essential architectural elements are in place, and it can be hard to test unreleased products with users until the very last moment. However, you can gather feedback early in the process:

• Don’t describe the product and ask users if they would use it. In this case, you are more likely testing your sales pitch rather than the idea itself. If you ask users if they want a new feature, 90% of the time they’ll say yes.
• Test with the users you want, not the users you already have. If you want to grow your audience with a new product, you should recruit users outside your current community.
• Validate that the problem you are solving actually exists. Early in the design cycle, find your future users and research whether your product will solve their real-world problems. Look for places where users are overcoming a problem via work-around solutions (e.g., emailing links to themselves to keep an archive of favorite sites) or other ineffective practices (e.g., storing credentials in a text file because they can’t remember their online usernames and passwords).
• Verify your mental models. Make sure that the way you think about the product is the same as your user. For instance, if you’ve been pitching your product idea to your coworkers as “conversational email” but your actual users are teenagers who primarily use text messaging, then your email metaphor probably won’t translate to your younger users. Even if you don’t intend to say “conversational email” in your product, you will unconsciously make subtle design choices that will limit your product’s success until you find a mental model that fits that of your users, not of your coworkers.
• Prorotype early. Create and test a Flash-based or patched-together prototype internally as soon as possible. Even if your prototype doesn’t resemble a finished product, you’ll uncover and develop confidence in the major issues to wrestle down in the design process. You’ll also have an easier time seeing the areas of the product that need animations, on-the-fly changes, or other issues that require significant engineering time that weren’t recognized in the project scope because the product was only explored in wireframes and design specs.
• Plan through v2. If you intend to launch a product with minimal vetting or testing, make sure you’ve written down and talked about what you intend for the subsequent version. One of the downsides of the “release early, release often” philosophy is that it’s easy to get distracted or discouraged if your beta product doesn’t immediately succeed. Or upon launch you might find your users pulling you in a direction you hadn’t intended because the product wasn’t fully fleshed out, or dealing with weeks of bug-fixing and losing sight of the big picture. Once the first version is out the door, keep your team focused on the big picture and dedicated to that second version.

Pitfall 2: Users click on things that are different, not always things they like. Curious trial users will skew the usage statistics for a new feature.

Upon adding a “Join now!” button to your site, you cheer when you see an unprecedented 35% click-through rate. Weeks later, registration rates are abysmal and you have to reset expectations with crestfallen teams. So you experiment with the appearance of your “Join now!” button by changing its color from orange to green, and your click rates shoot up again. But a few days later, your green button is again performing at an all-time low.

It’s easy for an initial number spike to obscure a serious issue. Launching a new feature into an existing product is especially nerve-wracking because you only have one chance to make a good first impression. If your users don’t like it the first time, they likely won’t try it again and you’ve squandered your best opportunity. Continuously making changes to artificially boost numbers leads to feature-blindness and distrustful users. Given all of this, how and when can you determine if a product is successful?

• Instrument the entire product flow. Don’t log just one number. If you’re adding a new feature, you most likely want to know at least three stats: 1) what percentage of your users click on the feature, 2) what percentage complete the action, and 3) what percentage repeat the action again on a different day. By logging the smaller steps in your product flow, you can trace the usage statistics within all of these points to look for significant drop-offs.
• Test in sub-communities. If you are launching a significant new feature, launch the feature in another country or in a small bucket and monitor your stats before launching more widely.
• Dark-launch features. If you are worried that your feature could impact site performance, launch the feature silently without any visible UI and look for changes in uniques, visit times, or reports of users complaining about a slow site. You’ll minimize the number of issues you might have to potentially debug upon the actual launch.
• Anticipate a rest period. Don’t promise statistics the day after a release. You’ll most likely want to see a week of usage before your numbers begin leveling.
• Test the discoverability of your real estate. Most pieces of your UI will have certain natural discoverability rates. For instance, consider adding a new temporarily link to your menu header for a very small percentage of your users just to understand the discoverability rates for different parts of your UI. You can use these numbers as a baseline for evaluating future features.

Pitfall 3: Users give you conflicting feedback.

You are running a usability study and evaluating whether users prefer to delete album pictures using a delete keystroke, a remove button, a drag-to-trash gesture, or a right-click context menu. After testing a dozen participants, your results are split among all four potential solutions. Maybe you should just recommend implementing all of them?

It’s unrealistic to expect users to understand the full context of our design decisions. A user might suggest adding “Apply” and “Save” buttons to a font preference dialog. However, you might know that an instant-effect dialog where the settings are applied immediately without clicking a button or dismissing the dialog makes for an easier, more effective user experience. With user research, it’s temptingly easy to create surveys or design our experiments so study participants simply vote on what they perceive as the right solution. However, the user is giving you data, not an expert opinion. If you take user feedback at face value, you typically end up with a split vote and little data to make an informed decision.

• Ask why. Asking users for their preference is not nearly as informative as asking users why they have a preference. Perhaps they are basing their opinion upon a real-world situation that you don’t think is applicable to the majority of your users (e.g., “I like this new mouse preference option because I live next to a train track and my mouse shakes and wakes up my screen saver”).
• Develop your organization’s sense of UI values. Know which UI paradigms (e.g. Mac vs. Windows, Web vs. desktop, etc) and UI values (e.g. strong defaults or lots of customization, transparency or progressive disclosure) your team values. When you need to decipher conflicting data, you’ll have this list for guidance.
• Make a judgment call. It’s not often helpful to users to have multiple forms of the same UI. In most cases it adds ambiguity or compensates for a poorly designed UI. When the user feedback is conflicting, you have to make a judgment call based upon what you know about the product and what you think makes sense for the user. Only in rare cases will all users have the same feedback or opinion in a research study. Making intelligent recommendations based upon conflicting data is what you are paid to do.
• Don’t aim for the middle ground. If you have a legitimate case for building multiple implementations of the same UI (e.g., language differences, accessibility, corporate vs. consumer backgrounds, etc.), don’t fabricate a hodgepodge persona (”Everyone speaks a little bit of English!”). Instead, do your best to dynamically detect the type of user situation upfront, automate your UI for that user, and offer your user an easy way to switch.

Pitfall 4: Any data is better than no data, right?

You are debating whether to put a search box at the top or the bottom of a content section. While talking about the issue over lunch, your business development buddy suggests that you try making the top search box “Search across the Web” and the bottom search box “Search this article” to compare the results between the two. You can’t seem to place your finger on why this idea seems fishy though you can see why this would be more efficient than getting your rusty A/B testing system up and running again. Sensing your skepticism, your teammate adds, “I know it’s not perfect, but we’ll learn something about search boxes, right? I don’t see a reason not to put it in the next release if it’s easy?”

The human mind’s ability to fabricate stories to fill in the gaps in one’s knowledge is absolutely astounding. Given two or three data points, our minds can construct an alternate reality in which all of those data points make flawless sense. Whether it’s an A/B test, a usability study, or a survey, if your exploration provides limited or skewed results, you’ll most likely end up in a meeting room discussing everyone’s different interpretations of the data. This meeting won’t be productive and you’ll either agree with the most persuasive viewpoint or you’ll realize that you need a follow-up study to reconcile the potential interpretations of your study.

• Push for requirements. When talking with your colleagues, try to figure out what you are trying to learn. What is the success metric you’re looking for? What will the numbers actually tell you? What are the different scenarios? This will help you determine the study you should run while also anticipating future interpretations of the data before running the study (e.g., if the top search bar performs better, did you learn that the top placement is better or just that users look for site search in the upper left area of a page?).
• Recognize when a proposed solution is actually a problem statement. Sometimes someone will propose an idea that doesn’t seem to make sense. While your initial reaction may be to be defensive or to point out the flaws in the proposed A/B study, you should consider that your buddy is responding to something outside your view and that you don’t have all of the data. In this scenario, perhaps your teammate is proposing running the search box study because he has a meeting early next week and needs to work on a quicker timeline. From his perspective, he’s being polite by leading with a suggestion without realizing that you don’t have the context for his suggestion. However, after pushing him for what problem the above study will resolve, you can also help him think through alternative ways of getting the data he needs faster.
• Avoid using UX to resolve debates. UX might seem like a fantastic way to avoid personal confrontation (especially with managers and execs!). After all, it’s far easier to debate UX results rather than personal viewpoints. However, data is rarely as definitive as we’d like. Conducting needless studies runs the risk of slowing down your execution speed and perhaps leaving deeper philosophical issues unresolved that will probably resurface again. Sometimes we agree to a study because we aren’t thinking fast enough to weigh the pros and cons of the approach, and it seems easier to simply agree. However, you do have the option of occasionally saying, “You’ve raised some really good points. I’d like to spend a few hours researching this issue more before we commit to this study. Can we talk in a few hours?” And when you do ask for this time, be absolutely certain to proactively follow-up with some alternative proposals or questions, not just reasons why you think it won’t work. You should approach your next conversation with, “I think we can apply previous research to this problem,” or “Thinking about this more, I realized I didn’t understand why it was strategically important to focus on this branding element. Can you walk me through your thinking?” or “After today’s conversation, I realized that we were both trying to decrease churn but in different ways. If we do this study, I think we’re going to be overlooking the more serious issue, which is…”

Pitfall 5: By human nature, you trust the numbers going in the right direction and distrust the numbers going in the wrong direction.

Hours after a release, you hear the PM shout, “Look! Our error rates just decreased from .5% to .0001%. Way to go engineering team! Huh, but our registration numbers are down. Are we sure we’re logging that right?”

Even with well-maintained scripts, the most talented stats team, and the best intentions, your usage statistics will never be 100% accurate. Because double-checking every number is unrealistic, you naturally tend to optimize along two paths: 1) distrust the numbers that are going in the wrong direction and, more dangerously, 2) trust the numbers that are heading in the right direction. To make matters worse, data logging is amazingly error-prone. If you spot a significant change in a newly introduced user activity metric, nine times out of ten it’s due to a bug rather than a meaningful behavior. As a result, five minutes of logging can result in five days of data analyzing, fixing, and verifying.

• Hold off on the champagne. Everyone wants to be the first to relay good news so it’s hard to resist saying, “We’re still verifying things and it’s really early, but I think registration numbers went up ten-fold in the last release!” Train yourself to be skeptical and to sanity-check the good news and the bad news.
• QA your logging numbers. Data logging typically gets inserted when the code is about to be frozen. Since data logging shouldn’t interfere with the user experience, it tends not to be tested. Write test cases for your important data logging numbers and include testing them in the QA process.
• Establish a crisp data vocabulary. Engagement, activity, and session can mean entirely different things between teams. Make sure that your data gatekeeper has made it clear how numbers are calculated on your dashboards to help avoid false alarms or overlooked issues.

One of the main tenants of user research is to constantly test the assumptions that we develop from working on a product on a daily basis. It takes time to develop the skills to know how to apply our UX techniques, when our professional expertise should trump the user’s voice, or when to distrust user data. As a researcher, you are trained to keep an open mind and to keep asking questions until you understand the user’s entire mental picture. However, it’s that same open-mindedness and willingness to understand the user’s perspective that makes it easy to assume that because their perspective can make sense, that it should also justify changes within our product design. Or, because we are so comfortable with a particular type of UX research, we tend to over-apply it to our team’s questions.

While by no means a complete list, I hope these five pitfalls from my personal experience will be relevant to your professional lives and perhaps, provide some food for thought as we all strive to become better researchers and designers.

It’s still a work in progress but I want to get a new release out as soon as I can for current users who are using the basic auth that doesn’t work any more. If you’re feeling adventurous give the development version on the download page a go and tell me what you think!

99% of the OAuth code was ripped from Alex King’s Twitter Tools which in turn uses Abraham Williams’ twitteroauth.php library and OAuth.php from oauth.net. Thank you all for doing the heavy lifting required!

Related Posts

• Tweet Tweet
• Tweet Tweet 0.1 for WordPress
• TechLudd Cork 2008

All smartphone app ideas start somewhere—an entrepreneur starts scribbling on some napkins at the local coffee shop, a visionary sketches on a whiteboard, a team has a brainstorm. Regardless of how your app begins, most app ideas are relatively vague at first, perhaps a basic drawing or a few bullet points of things you want the app to do.

With all the design templates available for Photoshop, Illustrator, and OmniGraffle, many designers may be quick to translate their app ideas into wireframes. While diving right into wireframing may work in some cases, most apps can benefit from some level of upfront user research. User research helps define the high-level product vision, and enables your team to make informed decisions throughout the product life cycle.

In this article, I'll introduce three complementary user research techniques that are well suited to mobile design: shadowing, and field interviews combined with diary studies. I chose these techniques because they can help mobile app designers understand their app's context of use. In contrast to the desktop context, which is relatively self-contained, the mobile context is influenced by many external factors, e.g., people, objects, the cellular network, etc. Understanding these external factors will help mobile designers create great user experiences.

Shadowing

In shadowing, the researcher follows participants over a period of time and records their observations. In contrast to user interviews, the data may be more reliable since user behaviors are observed in their natural context by a researcher. This is often referred to as a "sit back" technique; the researcher may probe with some questions but it's generally undirected. In addition to shedding light on the participant's environment, shadowing may help uncover less tangible influences such as social norms and user perceptions.

Shadowing sessions can take one hour or up to a full day—the context and duration will vary based on the app and the research goals. Imagine that you want to develop an app that enables parents to easily record and share their newborn's special moments. Because the app may be used in a variety of contexts throughout the day, it may require a full day of observations to get an adequate understanding of the parents' needs. In contrast, much less time would be needed for an app for museum visitors to learn about museum artwork since participants could be shadowed in the museum for only the duration of their visit.

Photo from shadowing session with an art dealer. She uses her iPhone to take photos for clients, convert art prices into foreign currencies, and to make sure artwork is level (using the iHandy app.)

Field Interviews

Field interviews, which are derived from anthropological research techniques, are one-on-one sessions with participants in their natural environments. The interviews are semi-structured, meaning the researcher will prepare questions in advance but will adjust the script based on the participant's responses. They typically occur in one place for 1–2 hours, excluding travel. Given these time and context limitations it may be difficult to get a complete picture of the participants' mobile usage. As a result, mobile researchers often supplement field interviews with a diary study. Diary studies, discussed in the next section, can provide more insight into the participant's context over a much longer period of time.

Choosing one place for a mobile-oriented interview can be a challenge. Ideally, the interview should occur where the app will be used most often, providing researchers with a better understanding of the context of use. In the earlier example of the museum visitor app, holding the interview at the museum would enable participants to easily refer to exhibit information and explain what works or doesn't work well for them. If the interviews were held at an offsite location, it would be harder for participants to reference such information and for the researcher to understand the influence of the museum context. Additionally, it would require the user to recall behaviors or memories about the app, which can be less reliable than studying their app usage in context.

Sample Excerpt From a Field Interview With a College Student

"I would have chemistry in the morning for five hours, Trig in afternoon, English at night. My chemistry teacher would lecture for two hours. I would have my periodic table open. I was in class one day and forgot my periodic table. I Googled it and found an iPhone periodic table app. I showed everyone in class and then they downloaded it too. It's free and they have a light version. A lot of people in class have an iPhone—half the class. Everybody is on the iPhone, especially on the train.

"I'd also use my scientific calculator. If you turn the iPhone landscape, it expands. I removed the other calculator app I had installed before. I don't like a ton of apps on my phone at once. So the iPhone replaced my TI89. The other app allowed more numbers than the built-in calculator app, and could do longer equations than the built-in iPhone app. I looked in the App Store under 'scientific calculator,' looking for graphing one. I got this one [shows me]. There was a pop quiz one day so I asked: can I use the phone? Professor said yes but some would say no."

Diary Studies

Diary studies shift the burden of data collection onto the participant. Instead of the researcher shadowing participants for an entire day, participants record their activities over the course of one or more days. When combined with field interviews, diary studies can approximate the depth and richness of data gathered during shadowing sessions. Consider using a diary study under the following circumstances:

• Participants can easily capture the kind of data you are seeking
• You need to collect data over a long period of time, such as in cases where the app is used only intermittently
• You need a non-intrusive way to gather information

Although this approach can lead to valuable insights, there are some limitations. First, participants may not record activities that seem trivial to them but would be of interest to researchers. Second, since participants are mobile, stopping to document their activities could be disruptive or impractical (e.g., when the participant is driving.) Third, diary studies are less effective at ascertaining the how and why behind behaviors. Because of these limitations and others associated with self-reporting research techniques, researchers often combine diary studies with other methods such as field interviews.

Sample Diary Study Entries and Field Interview Clarifications

Choosing a Research Approach

Most smartphone apps will benefit from a combination of user research methods. The optimal mix will depend on the app, your research goals, and the design phase. Very early stage apps will benefit from observational methods, whereas mid-stage apps should benefit most from observational methods as well as prototypes. These app stages are discussed in more detail below.

Early Stage Apps

Companies without a clear concept may conduct user research to help uncover app opportunities. Even though the company has not formulated an app concept, they should have a well-defined audience or problem space in mind. For example, young children often use their parents' iPhones. Shadowing these parents is one way a researcher could uncover app opportunities for this demographic. Similarly, a company may be interested in offering an Android solution for small business owners, thus they may want to interview these types of users to better understand their needs.

Mid-Stage Apps

Companies with a rough app concept can utilize a variety of user research methods. In addition to shadowing and field studies, they may find it beneficial to introduce early app sketches to prospective users. These sketches can be presented in a demo format—meaning the researcher will walk through the sketches and elicit feedback on the ideas—or through a paper prototype study. If the concept is not fleshed out at the user interface level, another option is to create a concept video that will give prospective users a feel for the idea. You can find an example here: http://vimeo.com/2420799

Existing Apps

Apps already in the marketplace may conduct upfront research before designing a significant feature or embarking on a redesign. Regardless of the project scope, the research typically incorporates the existing app. For example, it would be valuable to shadow existing customers as they use your app, or have them diary their app usage over a specified period of time. Alternatively, the app creator may consider running a usability study to establish a benchmark for the app. Lastly, a user feedback survey at this stage can be beneficial for getting a broad reading on features that you may then want to delve deeper into with qualitative research.

Summary

Upfront user research can benefit both new and existing smartphone apps, shedding light on prospective users' context of use, perceptions, pain points, language, and customs. Understanding context of use is critical for smartphone app design since context can be a driving force in your app's user experience. With a solid user research foundation, app creators can make informed decisions throughout the product development process. Moreover, user research can reveal new app opportunities and inspire innovative solutions.

Time to put the phone and laptop away and take the Kindle to bed.

We all have visited cultural attractions, whether it's the Louvre in Paris or a botanical garden down the road. But you may not be aware that cultural attractions and public venues have been evaluating the experiences they provide for visitors. The unique approach to experience design these attractions are taking can enrich your thinking about UX design.

In the cultural attractions sector—museums, parks, zoos, gardens, and libraries—UX principles are slowly being adopted and applied. Managers of these attractions are unlikely to follow UX literature, have much less money than for-profit entities, and generally haven't been run using customer-focused business models. But this is rapidly changing with the economic downturn. As funding sources have dried up, cultural attractions have to bring in new revenue by getting creative about inducing visitors to return and spend more money. Cultural attractions have extremely tight budgets—sometimes only in the hundreds of dollars—to spend on improving experiences above and beyond their core missions.

Public gardens can benefit from UX design just as much digital systems or other types of public spaces. Perhaps because gardens are primarily outdoor experiences, or because they are less likely to incorporate technology than other types of museums, they have been less likely to adopt UX design practices.

Descanso Gardens is nestled in the foothills above Los Angeles at the edge of the Angeles National Forest. Descanso was gearing up for a special event that was to take place in their peak visitation season, Spring 2007. The event was projected to more than double their attendance during this already busy time, and Descanso staff members were excited at the opportunity to bring more people to the garden through this special event, many of whom were unlikely to have visited before. The staff members wanted to make sure that the experience was an excellent one—one that new visitors would want to repeat. They also wanted to ensure that regular visitors and members had a good experience so as not to hurt existing business.

Descanso's concern was focused on their entry and ticketing windows. They had approached several Los Angeles architecture firms and were told that it was a minimum of $10,000 to redo their entry, which was far outside their budget. They were familiar with my work through my book and conference presentations, so they contacted me hoping I could suggest some less expensive changes and improvements.

Tip 1: See the big picture. As with any UX project, the practitioner's role is to think through the experience from the customer's perspective to determine realistic solutions that will make that experience flow smoothly and logically. By taking a broader view of the entry experience and how visitors might use it, we were able to greatly improve their entry with low-cost solutions. The engagement also provided positive spillover effect into other areas of visitor services, like the Garden Shop. This scenario can also apply to other venues such as restaurants hosting a festival, retail stores at peak shopping times, and office buildings holding special events in their foyers.

Descanso was focused on improving the ticketing windows, but the visitor experience starts long before that. I always look at the holistic visitor experience, ideally starting from the visitor's home (where they use the organization's website), to the transit approach, to the parking or walking entry, and so on. To avoid the expense of two site visits, I gave Descanso instructions on how to photograph the site for my analysis, noting on their map where they had shot the photographs. Easy, inexpensive site surveys can also be done using simple cell phone video, too.

When analyzing site photographs and videos, I look for many things:

• What is my overall impression if I haven't been there before?
• Are signs placed in the best possible locations?
• Does plant material obstruct any signs?
• What kind of message am I getting about this experience and this brand from the beginning?
• Am I being clearly led from Point A to Point B?
• Are they building anticipation in me as a visitor as I approach?

Analyzing the photographs from Descanso highlighted three problem areas:

1. A lack of welcome or orientation to the parking area overall.
2. Difficulty finding the entrance from the parking lot.
3. The proposed location of the ticketing trailer for this upcoming special event.

Descanso wasn't even aware of the first two issues. This is the norm for this type of project; it's almost impossible to see your workplace with the fresh eyes of a first-time visitor or customer. Part of the role of a UX practitioner is to bring that fresh, objective perspective.

We addressed the issues with colorful vinyl banners, tree trimming, and placing the ticketing trailer in a different location.

The initial plan was to situate the temporary ticketing trailer to the left of the entry area, which would mean ticket buyers would be obstructing the garden's exit path. This cross-traffic situation would have been extremely problematic, so I suggested the trailer be moved to the right of the entry building, with the queue off to the far right. This would allow cars to drop off people and put them directly into this line without impacting the membership or regular ticket lines. When planning queue lines, it's important to think about how customers will locate the correct line, where they will stand, and how the queue might impact other traffic.

Tip 2: Dig deeper. I asked Descanso to send me attendance numbers for the previous several years for this time period so I could see how many members and regular visitors they typically had during this season, who would need to be accommodated along with the special event guests. While Descanso had the data available, it hadn't occurred to them to use it in this analysis. The simple solution—bright banners hanging over each entry lane—worked beautifully and was highly cost-effective.

Before coming to the site I prepared a short PowerPoint presentation, overlaying mockups of my suggestions on Descanso's photos. This might be obvious to designers, but non-designers often have a very difficult time visualizing solutions. Even simple mockups help people see how the solution will benefit them. It's always best to provide figures for scale in proposed layouts and show signage mockups overlaid on photos of the site.

As we began walking the entry corridor, another issue became apparent. Descanso asked for my input on the gift shop, which is always an important revenue source for nonprofit cultural attractions. They wanted suggestions on how to increase traffic to the store. One permanent issue for the store is its location on the right side of the entry lane, meaning that visitors have to cross incoming foot traffic to get to the shop as they are leaving Descanso. Visitors don't want to shop as soon as they've bought tickets, they want to shop at the end of their visit.

The right-hand bias—people tending to turn and reach to the right—is well documented in design literature, but seems to be frequently overlooked when sites and buildings are designed. It wasn't possible to move the gift shop to account for the right-hand bias, but we were able to make it more attractive so people would cross left to reach it. A large, raised planter bed in front of the store took attention away from the store entrance on the side, and also created a problem with traffic flow as visitors tended to sit on the front of the planter. (As an aside, there is never enough seating in public spaces, so visitors will sit on anything they can.) In brainstorming ideas, someone suggested that we simply take out the planter altogether.

Tips 3 & 4: Leverage in-house assets; ask if something can be moved. While they had very limited funds to spend, they had the labor and equipment on site to make this possible. We also discussed the possibility of moving the store's entry door from the side of the building to the front. While this would remove some cabinet and display space inside, it was definitely a better option. It would not only visually open up the store to visitors, but would allow them to display merchandise out in front of the shop in a way hadn't been possible.

Results

Using UX principles and spending only about a tenth of what an architect would have charged, we greatly improved Descanso Gardens' entry, ticketing area, and store, and made a high-profile special event run smoothly. Conducting experience reviews can empower staff to take on problems and begin to look at more aspects of their operation from a visitor or customer perspective. Applying UX design principles to this problem had positive spillover into other areas of their operation; not only did Descanso remove the planter in front of the store, they also moved the store entry door to the front and have reported an increase in sales. They got so excited about rethinking the garden entry that they relocated the garden's exit entirely, thereby opening up the entry space wholly to incoming traffic. All in all, they were thrilled with the results of the changes for this special event, and leveraged the opportunity to make permanent positive changes in their visitor experience.

Takeaway Tips

1. While the client does define the problem, it's up to the UX specialist to see the bigger picture. You can fix the defined problem but not address something that's a bigger issue than the client realizes. It's up to you to show them solutions that will benefit them the most in the long run.
2. Ask deeper questions, always thinking about how customers or visitors are going to use the space, product, or function. Your solution has to work with all the different users, not just the one audience segment that might be defined in the project scope. If they have user data, apply it to inform your solution.
3. Utilize all the resources the client has available to them. Figure out how to leverage in-house talent or equipment to help make the most impact.
4. If something isn't set in concrete (or even if it literally is), ask if it can be moved or changed. Sometimes the answer will be “yes,” and that will lead to a better solution.
5. While you're there, teach staff how to think about UX so they have an even greater benefit after your project is over. This leads to referrals and return engagements.

A small update, I’m slowly working through the WP Super Cache admin page in an effort to make it better. You can in fact download the development version if you want to follow along.

What you see above is my first pass. An effort to make the first options section match the look and feel of the standard Settings pages in WordPress. It’s all likely to be mixed around and moved about before the next release, so please, dig in and lend a hand!

Related Posts

• WP Super Cache 0.9.6.1
• WP Super Cache 0.8.3 “Speedy”
• WP Super Cache 0.8.4, the garbage collector

I’m feeling old. I’ve been in this business long enough that I remember thinking how cool I was for working on a website. That Internet thing was just taking off. Ask Jeeves was the edgy new way to search and Google was a little known website, not a verb. I worked Amazon.com, which was still positioning itself as "Earth’s Biggest Bookstore." It was all Web all the time, and improving the experience on websites was all I thought about.

Then two things happened to broaden my perspective. First, I got a smartphone. Now I could check the traffic before choosing the bridge route, or walk down the street while browsing for a Cuban-Asian restaurant with outdoor seating. And then I started working for REI, a company that had been around over 50 years, whose website was just the youngest sibling in a successful brick-and-mortar, catalog, and call-center business. Using the REI website was just one way people interacted with us, and their perception of their experience with our company was influenced by any other interaction they had with us, whether digital or physical. Suddenly my website only focus seemed limited when I considered all of the other touchpoints my new company had with its customers.

My team could optimize the user experience on the website, email, or mobile, but what about when a customer researched a product online and bought it in one of our 100+ stores? This is not an uncommon practice. According to Forrester, 53% of U.S. online consumers say they research products online that they subsequently buy offline. Other studies have placed that percentage even higher. The experience a customer has in a store or via a call center (terrible IVRs, anyone?) can be just as critical as the website to their overall experience and satisfaction.

With the potential for mobile phones replacing credit cards just around the corner in the U.S. and already prevalent in Asia, we may no longer need our wallet to make a brick-and-mortar purchase. Capabilities like mobile payments are driving personal technology to merge more and more with our physical environment and experiences. The Internet is no longer a separate experience where we have to sit down in front of a computer.

We Need to Think About Integrated Experiences

New technologies and capabilities have caused consumers to be even more demanding. We expect to choose when and how we interact with products and services. We often interact with a brand/company over time via multiple sites, apps, and services instead of through just a single event. I recently went on a cross-country trip and, as usual, I bought my plane tickets via the airline's website. The 24-hour flight check-in came along and I wanted to change my seat. But I was enjoying time by the pool and didn't want to leave to find a computer. Isn’t that what my iPad or iPhone are for? But the airline hadn’t done the work to provide me ability to change my seat with either of these devices. I wanted to interact with the airline's services via a different touchpoint at a different point in time, and I wasn't allowed to do so.

UX professionals can’t constrict a user’s experience to specified devices, touchpoints, or time periods. As devices integrate with each other and with the real world, we have to design for this integration and blurring. This new world requires a different way of thinking about UX and design.

The UX community spends a lot of time talking about how much technology is advancing and how to respond to the rise of touch and gestural interfaces. These subjects are important, but I think it is even more critical to work on the holistic customer experience—across channels, across devices, and across time and space. I can do yoga with my Wii, order delivery of artisan pizza via an iPad, or use Skout on my iPhone to virtually flirt with people within a walkable distance and then meet them in person at the local bar.

UX Professionals Need to Design for the 'Space Between'

The true impact of new technological capabilities that integrate with our lives is a blurring of the line between physical and digital experiences. We need to design for the space between—the space between touchpoints, interfaces, and channels. The space between making a flight reservation online, changing my seat via an app and then getting to the airport and only then discovering that my "approved" carry-on luggage actually doesn’t fit that style of 737. We can’t just think about optimizing a retail website experience when the physical store experience doesn’t connect. Often the signage, prices, and even the products themselves are different.

Even companies without physical presences should think about the on- and off-ramps to their websites. As customers rely on Google and social media to direct them to pages deep within relevant websites, we can no longer just design for people landing on our home page. For many companies’ websites, traffic from those sources is greater than from direct load via a URL. Word-of-mouth references are exploding via Twitter and Facebook, and QR codes can take us from Times Square to a mobile site. Our users are coming from everywhere!

The Rise of Customer Experience

We should be thinking about all of the interfaces with users. This broader perspective is often called customer experience, and it’s gaining tremendous traction with our marketing peers and in business strategy for corporations and non-profits alike. I’ve been to many marketing conferences, and every session in the last couple of years has seemed to focus on improving the customer experience. Of all of these marketing seminars, I can only remember one that was presented by someone with a UX-related background. And yet, who are the best people to be planning, prioritizing, and strategizing for improved customer experiences? As practitioners and thinkers in a discipline that has always been all about the customer, aren’t UX professionals the best people to lead this effort?

As UX professionals, we need to extend our reach beyond just experiences for the Web and mobile applications. A website or mobile app might comprise just one interaction—one touchpoint—in the end-to-end experience that users have during their journey to complete their goals. For users, these interactions are usually a means to an end, a path to a desired goal rather than the goal itself. I don’t want to buy a tent; I want to have a warm and dry shelter so that I can enjoy an overnight experience in the outdoors. I don’t want to read a new article railing against BP for the oil spill disaster; I want to feel as though I’m part of a tribe of like-minded individuals. UX professionals can participate in delivering that desired goal by designing for the whole experience across touchpoints and channels.

Information Scent Across Touchpoints

Creating the design and interactions of an engaging experience is only one piece of the customer experience puzzle. We also have to think about providing information scent across experiences and touchpoints. There need to be clues and cues for our customers that are clear and consistent, and that entice them toward their desired outcome. A consistent and integrated customer experience requires consistent information architecture and design principles that can be leveraged across all interactions with a company.

Andrea Resmini and Luca Rosati discuss the need for "a holistic approach to information architecture and user experience," stressing that information has become pervasive across channels and touchpoints. Peter Morville feels that this is an "era in which information blurs the boundaries" across experiences and that we need to consider better ways to design our information to support the variety of digital and physical interactions that make up our current experiences.

Next Steps

There is a wealth of rich, new challenges for available for us in designing, architecting, and building these holistic customer experiences that engage, satisfy, and inspire across channels and mediums. UX professionals should be excited, not stressed, about all of these new concepts that will help us stay relevant and provide the best possible experiences. We can continue to do what good UX designers have always done: borrow from other professions. Wayfinding, service design, and customer experience management are just a few disciplines that offer helpful tools and methods. In my next article, I’ll review some specific tools and ways of thinking that can help us design for the space between and the full customer experience.

The concept of the "digital dinosaur" used in this article’s title was from a session proposal for SXSW 2011 that I submitted jointly with Jess McMullin, who came up with the session title.

Chances are, you've encountered remote user experience research. Perhaps you've read about it in an article or have seen the book. Everyone from the scrappiest startup to the most established corporation is beginning to incorporate remote methods into their research arsenal.

Currently, the most common remote research protocols incorporate screen sharing and task analysis, often employed at a late stage in the product development process. While screen sharing is a relatively new technology, task analysis has been the standard usability method for 30 years. But since then, user habits and behaviors have changed significantly to accommodate the tech-filled world we live in.

Instead of buying a washing machine by walking into Sears, today people can choose from many different washing machines by reading online reviews, asking friends on Facebook for recommendations, or doing head-to head-comparisons across manufacturers. Thus doing a remote research study focusing solely on the Sears website would not capture these other activities that are part of the buying process, even if the purchase is eventually completed on sears.com.

We see real value in the ways remote research can contribute to developing a broader view of what people actually do in their natural environments. Think of it like low-cost field-testing for the purpose of understanding rich and complex real-world experiences. This can be done to a limited degree through screen sharing of website interactions, but as interactions span the physical and digital worlds and have myriad social influences, remote research can be a valuable contributor to understanding these touchpoints as well.

Thus, remote methods are particularly suited for understanding context of use. We should be asking questions that reveal the broader context in which customers are using a website. For example:

• What brought users to the website, and what will they be doing when they leave?
• How long have they been doing a given task?
• What other sources do they use for getting information and how does that influence their experience on our website?
• Are they making decisions with their friends?
• Are they doing things offline that contribute to the experience?

These are hard questions to answer even in full-blown field studies. Because remote methods give you access to users in their native environments, it's much more likely that you'll gain insight about physical and social contexts in a remote study than in a laboratory study.

Remote research for physical contexts

We recently used remote methods to help LendAround, a London-based startup, learn about potential customers' DVD sharing habits. LendAround's platform for peer-to-peer physical media sharing (primarily of DVDs) was in early beta. Needing to move quickly and be frugal meant that in-person field research was not feasible, particularly since the team wanted to focus on participants who lived outside of the Bay Area tech bubble where the research project was based.

The team developed a study that involved remotely recruiting and interviewing people in their homes where their DVD collections were kept. To begin, they posted a survey on Mechanical Turk and paid "Turkers" to complete it. The survey results were used for two purposes: to identify target interview participants and to address some initial research questions.

In the next phase, we conducted research using that most basic of tools—the phone. Our questions covered many aspects of how participants share and borrow DVDs. And since DVDs are physical products that are kept in people's homes, it was important to interview participants in the environment where they had their DVD collections. When we asked about their sharing habits, they could simply walk over to where they kept their DVDs to look around and estimate how many they had and how many they'd lent to friends. This led to insights about the rich context of how people use and share DVDs that wouldn't have been captured in an in-person laboratory study.

Remote research for social contexts

We have also used remote methods to learn about online social interactions. One study in particular was focused on how services like Twitter, Facebook, and Flickr help friends connect, discover content, and synthesize new information. Our goal was to understand how social interactions affect perceived content value within a set of friends.

We set up a remote study in which three friends submitted desktop recordings of their online interactions over the course of three weeks. We paid particular attention to times when one participant was referenced by or communicated with another participant, and we asked both of them about the interaction. Also, when multiple participants read the same news item we asked each person whether they remembered the content, whether it was meaningful, and whether other people had talked or commented on that story since.

It became clear that people's interactions and the value they found in social content were dependent on a number of factors, from context cues they picked up in the interface to social factors such as reputation and trust. For example, participants skimmed Twitter focusing only on avatars, and when they saw an avatar of someone they respected they read the associated tweet more closely and were more likely to share it with others.

Doing this study remotely allowed us to uncover social interaction patterns that would not have been captured in an hour-long screen share/task analysis of a single participant's desktop.

Conclusion

Though late-stage remote task analysis is valuable, remote methods can also establish an understanding of the unspoken and often unseen contexts, both physical and social, of a product, program, website, interaction, or decision-making process. Creative and thoughtful use of remote research methods can improve product development practices across the board—for startups and large, established companies alike.

I’ve had a Nokia 5800 for almost a year now. I was really excited when I bought this phone last year. My first touchscreen smartphone! It took some getting used to, having mostly been a Nokia S40 user. It didn’t take long, and in fact now I try to press the screen when I use older phones!

The phone itself does all the usual things and frankly, there are many in-depth reviews out there. Here are a few:

• Nokia 5800 review
• Nokia 5800 Xpress Music (Unlocked)
• Nokia 5800 XpressMusic hands-on

I love this phone. It’s the best phone I’ve ever owned. It’s not perfect by any means but the pros outweigh the cons!

1. I love the on-screen keyboard for entering texts. It will switch from portait to landscape mode when you turn the phone on it’s side. When I first bought the phone I could use predictive text in both portrait and landscape mode but the latest firmware upgrade changed that. In landscape mode I can’t use predictive text now. That sucks.
2. The GPS works reasonably well though. Using Windows or Mac OS X software you can download maps for your area to the phone. Unfortunately the GPS chip in the phone is Assisted GPS. It makes a network connection almost every time it needs to find it’s location. I actually bought a data add-on simply because the phone seemed to “leak” data for no apparent reason but it was probably because I had loaded Nokia Maps.
3. Nokia recently made their navigation system free of charge and it works, sometimes well, sometimes not. Unfortunately it sends us driving in round about ways on occasion. Our journey may be directly down a road but the map told us to cross the river, drive for a bit and then drive across a bridge further up!
4. The camera is decent enough. It has a flash too. There’s a plastic cover over the lens on the back and unfortunately it cracked. I bought a cheap cover on Amazon but now the light leaks from the flash so I usually disable it when I can.
5. Reception is very good. Phone calls don’t drop very often, and texts go through all the time. Data calls drop occasionally, and will drop back to Edge if required. No “grip of death”! (har har, bet you’re all sick of that now aren’t you?)
6. My favourite apps would have to be Gravity, a Twitter application, and Opera Mini for browsing. Opera Mini loads the mobile version of Gmail and Google Reader quickly and display them with little lag. There’s also the free Youtube app which is excellent but I prefer to use a computer for watching videos. I also have numerous free apps and games installed, almost all from the Ovi store.
7. The Ovi store is Nokia’s application store. It’s basic, but it’s quite good. You can search for apps, and sort and display by different criteria. Only want free apps? There ya go! Installing is a sinch, but it would be nice if they made reviews more accessible. You have to click through to them.
8. Battery life is pretty good too. If you’re browsing the net and making phone calls it’ll last well over a day but add GPS and suddenly battery life drops like a bomb. If it has to hunt for a signal that hurts too unfortunately.

So, there it is. The Nokia 5800 is an excellent phone. It’s not perfect but I can heartily recommend it.

My next phone? I already bought it. It’s the Samsung Galaxy S, an Android powered smartphone. While the 5800 is an excellent phone it’s showing it’s age. Using the new phone is like moving from Windows 3.11 on a 486 to Windows 95 on a Pentium. Hmm, time to update my analogies?

Related Posts

• Nokia – Nokia 7650 Phone Suppo …
• Mac OS X Leopard and Nokia N73 Bluetooth Problems
• Long term review: Sony Ericsson W810i phone

Greenskeepers

Of the Leporidae variety.

Asleep in the Hay Rack

I know what you're probably thinking. Video games may be extremely cool. They may be innovative. They may make tons of money. But they're ultimately, unavoidably, just entertainment. And persuasion is serious business; if you want to convince people to change their minds or to act differently, games probably aren't the way to do it… right?

But I say firmly and with conviction: wrong. Every medium is a channel that can convey many types of content. Books, television, and charcoal sketches each have the capacity to entertain, educate, and make powerful statements. But the unique ability of video games to command a player's attention may in fact make them an ideal way to persuade.

I'm not alone in thinking that there's potential in persuasive gaming. In March 2010, the USDA and Michelle Obama's "Let's Move" campaign announced a contest challenging designers to create games that would persuade kids age 9 through 12 to eat healthier. I worked with a brilliant team (Andrew Karetas, Bri Lance, Jim Chiponis, and Amanda Ferrara) that created an entry titled Fitter Critters

Below I explain how we attempted to combine principles of both UX and game design to demonstrate the persuasive potential of video games.

The Core Message

A persuasive game has to be built around a focused message. Vaguely defined messages lead to confusing game experiences, so it's important to get specific before moving on to finer details of the design.

When our team was designing Fitter Critters we had a general sense that we wanted to create a virtual pet game, but we didn't really know how it would work. So we took some time to write down what messages we wanted our game to impart, and came up with two core messages:

• Eating a varied diet rich in vegetables, fruit, and whole grains leads to a better quality of life.
• Eating junk food may have short-term advantages, but in the long run it's not worth the negative health consequences.

Now that we had something to work with, the basic game mechanics snapped into place:

1. The players need to shop for food their critters and feed them on a daily basis.
2. A set of scales show the critter's progress toward daily nutritional needs like vegetables and whole grains, as well as limits on fats and added sugar.
3. If the player consistently makes better nutritional choices, the critter will be healthier and lead a more prosperous life.

Players need to provide the critter with food to fill the bars at the bottom of the screen.

A clearly articulated core message also helps designers decide which proposed gameplay ideas to adopt. An effective message needs to be communicated clearly. Digressive game mechanics risk muddying the message and need to be dropped. For example, one of our early ideas was to have the game track when the critter gets full, after which it would reject any more food. But the concept had no meaningful punch. A critter's fullness had nothing to do with whether you'd fed it healthy food or junk food—it was just full. This gameplay element also would have forced players to return to the game several times a day to feed their critters, interfering with the message. By leaving aside this feature, we gave our game a more focused design, and kept the project's scope limited to building only those features we absolutely needed.

Designing Discovery

Players naturally tend to seek out the most efficient ways to meet the objectives of a game. Discovery is an especially effective way to teach through games because it gives players a feeling of ownership of new information. Rather than being directly instructed that the core message is true, players internalize the message as a working hypothesis and use the game to prove to themselves that it's true. To succeed in the game, they need to buy into its point of view.

Exploiting this principle of gameplay design,Fitter Critters creates opportunities for discovery in multiple ways. First, players need to shop for their virtual pet's food. The grocer offers over 600 food choices, each with a label listing its nutrition information. One of the key challenges in the game is sifting through the multitude of options to discover the food items that will fill the nutrition requirements as quickly as possible while keeping fat and sugar as low as possible. For example, players may discover that sorbets are among the best dessert choices available, since they're free of fat and added sugar and actually provide valuable servings of fruit.

Players also discover the advantages of maintaining a garden and using it as a source of food. Harvesting free food from the garden allows players to use their resources more efficiently and save money for other things (as in real life). Creating such optional activities that offer real advantages to players who invest the extra effort is a great way to enable persuasion through discovery.

Players can shop for food or harvest for free from the garden.

Finally, Fitter Critters lets players get creative by combining foods into cooked meals, which can be sold for up to a 500% profit depending upon the healthfulness of its ingredients. Using tactics like this, game worlds can create a perception of tangible value for discoveries that might be harder to perceive in the real world.

All of these discovery opportunities were designed to persuade children to think differently about the foods they eat every day, while at the same time modeling the real-life skills needed to make thoughtfully discriminating choices about their diets. To be successful, players of persuasive games need to internalize the game's core messages and get used to applying them in the real world.

Meaningful Choices

A game designer's trap was hiding inside the game's overall concept: if healthy food offered only benefits and junk food only drawbacks, then the game would present no real choice at all. Players would always pick the healthy food since there would be no reason to consider anything else.

Interesting games offer players meaningful choices. Imagine if a racing game offered players the choice of two cars, one fast and the other slow. Which would you pick? Not only would winning this game feel distinctly unfulfilling, but the player would also never need to weigh the real advantages and disadvantages of different types of cars. Games with simplistic choices create no opportunities for players to learn.

It sounds weird, but there has to be some advantage to making some wrong choices. It's best if choices fall on a smooth continuum from right to wrong, with a competing set of advantages and disadvantages all along the way.

In Fitter Critters, there are two built-in advantages to consuming high-calorie foods. First, your critter needs to have a certain minimum level of energy to participate in the sports games. Calorie-rich foods fill up your critter's energy bar quickly, giving it immediate energy to play more games. Second, a higher energy level also allows the critter to earn more money each day from work (although this caps at 2000 calories). That bacon double cheeseburger offers a fast track to higher energy levels.

Energy allows players to participate in sports.

Of course, unhealthy food choices also have important consequences. Exceeding daily limits on calories, fat, or sugar brings down the critter's health over time. An unhealthy critter will lose the sports games more often and earn less money at work. It will be more likely to get sick and lose an entire day's wages. The critter will also develop a taste for junk food and start to reject healthier choices, making it harder to get it back to a healthy lifestyle.

This gives players a meaningful choice. It also supports the second core message of the game: whatever short-term advantages there are to eating junk food, they're outweighed by the damage done to health and quality of life. And by creating meaningful choices involving real trade-offs, this message is learned instead of simply taught.

Rewards

Games build engagement with players by offering structured rewards in exchange for actions—actions ranging from jumping over barrels to killing enemy soldiers. In Fitter Critters, all player rewards are based on nutrition choices. We arranged the rewards in the game in a laddered structure, so that one type of reward leads to another. This gives the game a dimensionality that unfolds over the course of play.

At the bottom rung, eating well increases health and reduces body fat. Players are offered simple praise as they meet their critter's nutritional requirements, and get the satisfaction of watching its bars fill. All games offer these kinds of fleeting rewards, but they're not enough to sustain interest for very long.

Moving up one step, healthier characters earn more money. Critters are paid a salary once a day, and the amount of the paycheck is determined by their health and energy (which also affect productivity in the real world). Staying healthy puts critters at lower risk of getting sick, and sick days cost an entire day's wages. Healthier critters will also win sports games more often. When players win sports games, their critters are paid $50 in game cash. It can be fun to watch your purse grow, but game money is ultimately worthless without anything to spend it on.

Farther up the ladder, players can use money to decorate their critter's home. The decorations range from inexpensive lamps to topiaries to an extra window. In the near future, players will also be able to build extensions to the house and upgrade home furnishings. Customization is a much more tangible reward, but what good is it if no one else can appreciate your creativity?

Earning money allows players to trick out their homes.

At the top rung, more decorations earn you a higher ranking on the game's leaderboard. Starting in the fall of 2010, critters will also be able to visit one another's houses to see how they've been tricked out. Social rewards like these are among the most powerful motivators that games can offer players.

But all of these rewards ultimately depend on the nutritional choices the player makes for his or her critter, making it the essential foundation of the critter's lifestyle. In a persuasive game, effective rewards need to have a clear relationship to the design's core message.

Games in the Real World

If we dismiss video games as nothing more than frivolous entertainment, we're cheating ourselves out of a potent way to communicate with an audience. When players feel engaged with a game, they are highly focused on figuring out what it'll take to win. This state of heightened attention creates an opportunity to bring about real change in people by building a message into the structure of the gameplay. Much attention is paid to whether games contribute to social problems, but not enough attention is given to their capacity to solve them.

John Ferrara is the author of the upcoming book Playful Design: Creating Game Experiences in Everyday Interfaces, to be published by Rosenfeld Media in 2011.

You can play Fitter Critters at www.appsforhealthykids.com/application-gallery/fitter-critters. It is currently open for public voting, so if you find it fun and interesting, its creators would welcome your support!

Motherhood

Every discipline has its own names, lingo, and jargon to talk about what they do and how they do it. The world of UX has its own jargon too, but a complicating factor is that UX professionals come from such different backgrounds that our jargon often doesn't match. We think we are all on the same page, but are using the same term to mean different things, or using different terms to mean the same thing. These confusions can even make or break the success of a project. Here are some examples from my life as a consultant:

Terminology Gone Awry

"What's a template?"

The project was going smoothly. We'd done our user research, designed a set of 15 template screens, and were preparing the deliverable to show to the client. We thought we were almost done. All we had to do is get the client feedback, iterate the templates one more time, document the templates, and then we'd be done. In our minds, being "done" meant having delivered a full set of templates: a set of screens that defines the navigation, interactions, and visual design. All the detailed design screens could be created by taking one of the template screens and customizing it for that particular screen's task.

We had brought together our main client contact and some of the project's lead developers to present the templates we'd created. Everyone seemed satisfied; they only asked for a few changes to a few interactions. But as we are packing up someone asked, "So what's next? When will we get the rest of the screens?" It turns out that the developers on the project never really understood what we meant by the word "template." They thought we were designing all 200 screens in the application!

"Of course we have personas."

Before a project even starts, I ask our client whether they already have personas we can use, or if we have to add persona development into the project. The answer is, "Yes, we have personas." But, as we later discover, what they actually have is a short list of the general demographics of their current customer base with no details and no information about who the users are for this particular part of the website or product. Since we don't have actual personas, we have go back and figure out how to get them into the project even though time and budget weren't allotted for that work.

"Why do you need to do user research and stakeholder interviews?"

I was walking through each of the activities planned for a potential new project: a meeting to plan the project, then interviews with key stakeholders within their organization, and then user interviews and observations. The client stopped me and asked, "Wait, the stakeholders and users are the same people, right? So why do you need to talk to them twice?" I'm so familiar with these two terms that I don't realize the distinction between the two might not be clear to others.

"But we've already done use case scenarios…"

I've also confused clients by saying I planned to develop user scenarios as part of the project. Eying me with suspicion, they say, "Look, we've already got use case scenarios." But what they have is just a set of 350 small use cases—combinations of user actions with the system's responses, and all the associated behind-the-scenes processing. The term use case has had such a long (and tortured) history and so many disparate definitions that I try not to use the term at all. I prefer the term user scenario instead, which I define to be a description of how the users will use the product I am designing. A user scenario takes into account the particular personas and the task the users are trying to accomplish, as well as information about the environment they are in. I usually create about a dozen user scenarios for a product I'm working on. These keep a high-level focus on user behaviors, rather than a detailed, granular, and technical focus on 350 small use cases.

"But where's the site map?"

One of the deliverables on a project was a site map that documented the navigation of the website, showing the top level all the way down to the third or fourth level. Our documentation was about five pages long, with about 10 to 30 "boxes" per page designating certain content categories. "This is a great diagram of the navigation," said the client, "but where is the site map?" For him, a site map meant a detailed description of every page in the site. For me it meant the high-level navigation.

Top 10 Ways to Avoid Terminology Problems

These are a few instances where terminology caused problems, but fortunately most of the projects I've worked on over the last several decades went very well. These terminology problems stick out in my mind because they all could have been avoided. And the problem is likely to compound as businesspeople get more hands-on in projects, and now that more and more people are entering the UX field coming from a broad diversity of educational and professional backgrounds.

So how can terminology problems be avoided? Here's my top 10 list. Do you have any more you can add to the list?

1. Don't make assumptions. Don't assume that people know what you are talking about. Don't assume that the term you are using is understood, or that it means the same thing to the person you are talking to.
2. Go over the plan more than once. The people you initially plan the project with may not be exactly the same as the team of people you work with over the course of the project. You will probably have to walk through the planned deliverables more than once to more than one group.
3. Show examples. Don't describe in words what a particular deliverable will be. Instead show examples of what it is and maybe even what it is not.
4. Provide incremental deliverables. Rather than waiting until the end of the project to deliver a big finished product, give lots of deliverables along the way. That way any misunderstandings can emerge much earlier.
5. Be alert for new people joining a team. If you are working on a project for more than a few weeks, it is very likely that new people will join the project in some capacity. You may need to explain terms to them, as they have missed the definitions and examples you provided early in the project.
6. Make sure your team is using the same terminology. If you have a UX team that is working on different projects within the organization, make sure they are using the same terminology. The confusions in terminology could be emanating from your own UX group.
7. Make sure you are using consistent terminology. The problem may be very close to home—maybe it's you! UX terminology has changed over time. If you've been doing UX work for a long time then you have probably changed what you call things. Chances are you revert to a previous name or use different words interchangeably to refer to the same thing. You understand what you mean, but it may be confusing to others around you.
8. Create a glossary to share within the UX group and with your clients. It's probably more work than you realize, because you will find that you are discussing (even arguing!) with members of your team about what the terms mean. But that's a good thing because it will point out where the discrepancies are. When you have the glossary completed, include examples and pictures of the different items and then publish it to your intranet and encourage your clients to use it too. Remember to also include processes in the glossary. For example, what does it mean to do card sorting? Usability testing?
9. Print a set of cards that you can use in conversations with the stakeholders and project team. On one side of the card is the term and definition, and on the other is a picture or example. Now you can pull out the card for wireframe and put it side-by-side with the card for visually treated screen and show the difference.
10. Revisit your glossary and keep it updated. The UX field changes. Once a year, take the glossary out and revisit the terms. It's an opportunity to make sure your UX group is still in sync.

Terminology issues may seem at first to be just an annoyance of miscommunication, but defining, describing, and communicating clearly what we do and how we do it is the hallmark of a mature practice. And it will save you lots of headaches and time by not having disappointed or upset clients.