Mobile detection: When people visit your main website there should be a script that checks if they are using a mobile browser. If so, they should be redirected to your mobile site.

Ability to switch from mobile to full site: Unless you are confident that your mobile site completely replicates the functionality and content of your desktop site, there should be a link on your mobile site to switch back to your desktop site. You should also be aware that people may be sharing the URL of your mobile site’s pages to social networks, and people on desktop computers may then click on those links. If warranted by your traffic, you may want to consider having a script on your mobile site that sends desktop users to your primary site.

Button size: The buttons on your mobile site should be uniform in shape and color, and stand out from the rest of the content on the page. You’ll want buttons to be large enough for people to hit easily, generally at least 30 x 30 pixels.

Easily clickable links: Ease of use in clicking is important with text links as well. If two links are placed near each other (either horizontally or vertically), there should be enough space between them to not make accidental selections.

Non-hover based navigation: Many websites use hover menus, but these won’t work on most mobile devices.  If your standard website doesn’t have an easy way to navigate to subpages, outside of a hover-based menu, that is a significant reason by itself to start thinking about designing a mobile version of your site.

Minimalist approach to form input: Entering information is much more difficult on a mobile device, so reduce the fields required to a bare minimum. You can always ask them for more information when they get back to their desktop. In addition, wherever possible, user should be offered the choice to select from options, rather than being required to type out response. You can also leverage mobile phone’s personalization capabilities to automatically fill in personal information. Predictive text suggestions for open text fields can also help minimize the amount of typing required.

Form usability: Many of the best practices of desktop site design become even more important on a mobile form. For example, all checkboxes and radio buttons should allow users to select the text labels next to them, rather than only allowing people to click on the button / box. For more advice, take a look at these articles on mobile form design from Luke W, Smashing Magazine, and UX Booth.

Large images containing text: If you have a large image, be aware that it will be sized down significantly on a mobile device, and any text contained within it may no longer be readable (think infographics, for example)… or will require a lot of zooming and panning! Images should be designed to resize without breaking.

Links to files:  If there are links to files on the website, those files shouldn’t be essential to any primary user tasks. (An example of this is downloading and filling in a word document registration form that needs to be emailed in.) File types should be clearly indicated near the file download links, as well as an indication of file size (especially for larger files).

Flash:

We’ve helped a lot of nonprofits set up their mobile sites, so if your nonprofit is considering adding a mobile site, feel free to contact us.

• web-based card sorting to learn how your audience groups and labels content
• tree testing to validate your navigation
• task-based “first click” testing to get insight into how people navigate your site
• usability testing on clickable prototypes, to evaluate a new site structure / IA

And there are new tools being introduced all the time.

So, which approach is best for your website? Are some more effective than others? Do low-cost, rapid methods produce the same results as traditional usability testing studies?

If you’ve found yourself asking these questions and would like to hear opinions from a range of experts, check out the panel I’m proposing for SXSW 2012: UX Smackdown! User testing techniques in the ring. After registering for the SXSW panelpicker, you can give a “thumbs up” vote and leave comments to help this panel become a reality.

The panel speakers are:

• Aviva Rosenstein is lead UX researcher at Salesforce.com — you may recognize her from UIE’s recent Web App Master’s Tour!
• John Whalen of Brilliant Experience has over ten years of user-centered design experience and has most recently presented on the topic of persuasive design
• Kyle Soucy of Usable Interface has created interfaces for everything from web sites to touch screen devices. You may have seen her speak at a past UPA or IA Summit conference, or read one of her articles at UX Matters.
• Michael Summers of SUMMERS Consulting has watched over 1000 consumers make real end-to-end purchases on the web. He was one of the earliest adopters of eyetracking technology for UX research.

I would love to have the opportunity to pick their brains and get some UX testing tips — if you would too, head on over to the Panel Picker to vote and comment before Friday’s deadline!

Usability practitioners are celebrating in all sorts of crazy ways – attending some of the myriad workshops and demos and online events, buying t-shirts and, of course, tweeting through it all.

At Beaconfire, I’m celebrating by thumbing through the copy of Rocket Surgery Made Easy that arrived in my office this very morning. I’m giddy.  I had wanted the book since listening to Steve Krug, the author, at the UserFocus conference in DC last month.  His previous book, Don’t Make Me Think, put forth a ‘common sense approach to usability testing.’ It’s a simple but insightful resource that makes the concept of usability accessible for a wide range of people.

In his follow-up, Rocket Surgery Made Easy, Krug provides a how-to guide for creating, running and evaluating usability testing sessions.  A caveat here… he says, “If you can afford to hire a professional to do your testing for you – and it doesn’t consumer your entire budget in one session – do it.”  I support that idea completely and encourage you to contact Beaconfire if you are looking for usability consulting.  :)

On the other hand, if you are interested in making your site more usable but your budget is tight, grab this book and then spend some time watching your web site users interact with your site.  It will make you see your website in an entirely different way.  I promise.

I’m going to save the point-by-point review for you until I’ve actually read the book.  Remember, I just got it this morning. In the meantime, if you’ve done usability testing on your site – especially sessions that you’ve designed and run in-house – how did they go?

Pfizer had funded an independent research project conducted by Penn State to analyze if health care companies could benefit in the long-run by covering smoking cessation products and the resulting report is 637 pages long: http://www.lungusa.org/stop-smoking/tobacco-control-advocacy/reports-resources/cessation-economic-benefits/reports/SmokingCessationTheEconomicBenefits.pdf. 

From the get go, we know we don’t want to lose the visitor by displaying too much data and make it difficult for them to find key points.  But we also never want to “dumb it down” so as to lose the richness of the story the data can tell. The solution is making the most pertinent data easily accessible and present a clear compelling picture. In this case, the homepage of the report would be the US map (www.lungusa.org/cessationbenefits) which would present key data points when the user moused over a state.

American Lung Association, Pfizer and Penn state identified 3 key points that would plainly state the results:

• Average cost of a pack of cigarettes,
• Cost to state per pack of cigarettes and
• Return for every $1 spent on smoking cessation treatments. 

The user gets these first—and they are pretty shocking. From this high-level, they can click into a state to see more specific data and details like:

• how much smoking costs a state per year in direct health care expenditures,
• workplace productivity losses and premature death
• how a state can save money by providing smoking cessation treatment to curb direct health care expenditures and reduce workplace productivity.

Then if the user wanted to see all of the data concerning that state,  they can download the full state report from the state fact sheet page.

For users who weren’t as comfortable navigating the map, there is also a navigational link to view a list of all of the state and click to the state fact sheet from there. And finally, the user could access the whole report of 637 pages from the Data By State page as well.

Bottom line: offer the user key points to draw them in, then provide a bit more detail and finally allow them to access all the data if they want to dig into it.  Providing more than one entry point into the data is the user-centric way to go.

Since all the panels up for evaluation deal in some way with nonprofit technology goodness, we’re just going to point you in the direction of what we think is a stellar line up of panels that we have submitted for inclusion. We’d love your vote — and would especially appreciate any comments on what you’d like to see in these or future panels.

Practical HTML5/CSS3 for Nonprofits (or “How to Party Like it’s 2011 When it’s Really Still 1999″)
More neat stuff is being done with HTML5 and CSS3 every day and we all want to jump on the bandwagon and make Web sites that are really, truly, awesome. But what does HTML5 really mean? Non-profits have unique technology requirements, including the need to support visitors to your site who may be browsing on really old browsers over really slow connections, so will HTML5 even be viable? (“This will work in IE6, right?”) Will HTML5 make our site work on mobile devices? Is it the Flash killer that you may have heard it was? (spoiler alert: a REALLY BIG “maybe”) Can you start using it right now? (“Please oh please oh please”.)

You can hack it… but should you?
You’re adding a new feature to your website; maybe an online community, or peer-to-peer fundraising, or better Facebook integration. What’s more expensive: investing in a new piece of software, with a new set of features, and integrating it with your existing system? Or stretching the limits of your existing system, making it meet your changing needs? Sometimes it’s worth the cost to make updates with the click of a mouse, instead of making your developer tear her hair out to achieve the same result. Other times, your tools may surprise you, and a little hacking can go a long way. Learn the tricks for extending your existing toolset, and guidelines for deciding which route to take. We’ll share examples of how tools like Convio, WordPress, and Ning can do more than you’d expect… and some cases when they can’t do quite enough.

Money for Nothing and your Software for Free
Free beer! Free kittens! Free software! We all love to get something for free, especially when budgets are tight. We dream of the product that will, like magic, solve our problems without costing a cent. (If you aren’t, your boss probably is.) But free things almost always come with hidden costs, and free software is no different. It won’t give you a hangover, or get fleas, but it could eat up your staff time, control your data, or change the rules on you without notice. This was spectacularly clear when Ning eliminated free accounts, leaving nonprofits with the choice of paying up, or losing years of hard work. Or when Facebook suddenly turned fans into “likers,” forcing page administrators to change their outreach strategy. But not all free software is created equal, and it’s not just about open source vs. closed source. Some tools give you great power – but you have to know how to use it. Others may limit your options, or ignore what you really need. But some may be just what you’re looking for. We’ll explore the ins and outs of free and low-cost software, and ask: what does free software really cost?

Guerrilla UX
While the importance of web usability is indisputable, the sad truth is that paying for usability experts, their tools and facilities often doesn’t fit into the nonprofit web budget. Turns out, it doesn’t have to be this way. You can go guerrilla with usability testing in either your approach and/or the tools you use and still achieve effective results.

Method Tweeting for Nonprofits: Much Ado About Something
When organizations use Twitter to promote themselves, it’s largely about playing a role. The person tweeting is tasked to be on message as the voice of the organization while creating a unique and engaging personality to draw an audience in. At the theater, we gladly accept this fake-me-out, but in social media where do we draw the line between being the playwright and playing a character?

Just ‘Cause: Can Technology Make Brand Irrelevant
Thanks to technology, the line is starting to blur between the power of a household name brand and the passion of scrappy mission-focused organizations. Yet when it feels like nothing short of a crisis will engage people with your cause, how do you compel them to act? The battle of Cause vs Brand is on.

“A what?” he said?

“You know, “ I said, “A widget.”

But he didn’t know. I had ventured into that underworld of web jargon.

Most of us were introduced to the widget in our fourth grade math class: If one person at a factory can make 30 widgets in an hour, how many widgets can a factory that employs 3 people make in the course of a standard work day.

To those of us in the web business, a widget is a kind of mini-web application that can be easily distributed to any Web site. If you’ve got a petition campaign, and you can give your blog some code so that the campaign appears on their Web site, then you’ve got a widget.

But if our fourth grade widget factory can make 720 widgets in a day, it takes just a little bit longer for web developers to make just one. One mistake common mistake when it comes to widget design and development it to toss the widget aside as I kind of “mini-me” to the Web site, and assume it does not need much more in the way of design or development than the original application. But its tiny size can sometimes be a huge hurdle. Here are some things to consider when making a widget:

• Widgets come in all shapes and sizes. Make sure actions can fit in the space that a widget allows.
• Since your widget is a minified version of your larger web application, make sure you shrink any necessary elements (such as your logo).
• Put tracking in place so you can tell who your best promoters are.
• Widgets aren’t magical – if you want people to use your widget, you have to promote it.

Don’t treat your widget like an afterthought. If you put the time and effort into its layout, design, and functionality, you’ll have increased your reach faster than it takes three employees to make 500 widgets!

HTML Code

<div id=”skip-nav”>
<strong>Shortcut Navigation:</strong>
<ul>
<li><a href=”#content” accesskey=”p” title=”Skip to page content”>Page Content</a></li>
<li><a href=”#nav” accesskey=”n” title=”Skip to main navigation menu”>Site Navigation</a></li>
<li><a href=”#search” accesskey=”s” title=”Skip to search”>Search</a></li>
<li><a href=”#footer” accesskey=”f” title=”Skip to footer (ctrl/alt + f)”>Footer</a></li>
</ul>
</div> <!– end skip-nav –>

Most often, skip nav is hidden from visual users by shifting the content outside of the page viewing area (be sure to use a positioning property as display:none can render your content invisible to some devices). In this way traditional users who can scroll to what they’re after aren’t burdened with extra visual cruft while visually impaired users can jump around to the content they want.

Unfortunately, this approach ignores a number of different users. For example, skip nav could also be useful to sighted users who are unable, or simply choose not, to browse with a mouse and opt for a keyboard or other assistive device. Unfortunately, hiding this content off of the viewing area can create confusion.

One way we can improve this implementation is by using JavaScript/jQuery to display the content when it receives focus. This way we’re being accommodating to non-traditional users while still preserving the aesthetic integrity of the site.

The Plan

To do this we’ll test if any of the skip nav links have focus, and if so, show the container. We’ll set a timer that checks every 100ms to confirm a skip nav link still has focus, and if not we’ll run a function to hide it.

The JavaScript

Because only the links in the container can receive focus (at least without tweaks like tabindex) we’ll use their status to control when to open the container. So:

1. If a link receives focus add class nav-focus to the link, animate the container and give it class active.
2. Use setTimout to test if nav-focused no longer exists, and if so, close the container(use this instead of focusout to keep the container from closing when switching between links)

That’s the logic, here’s the demo beaconfire.com/blog/demo/skip-nav/.

To add it to your site add the HTML to your page and skipNavigation('name-of-container-id'); to your jQuery documenty read function

One last issue concerns the possiblity that JavaScirpt is turned off. A good habit is to use JavaScript to initialize elements rather than having default behaviors baked into the CSS. We’ll remove the CSSthat hides the skip nav, and do it with JavaScript.

$('body').addClass('js');

Now the following code hides the skip nav only if JavaScript is available:

.js #skip-nav {position:absolute; margin-left:-9999px;}

Note: This concept is based on a CSS based promoted by jimthatcher.com/skipnav.htm

Flash

The best way to think about Flash – for the purposes of this discussion – is as a bit of magic, included on a Web page just like an image, that can do all kinds of really cool animations, transitions, play sound and movies, and nearly display nearly identically on nearly all browsers that have the flash plug-in installed.

Flash has been around for quite a while and has a very robust set of tools (made by Adobe, and formerly by Macromedia).  It has been used to create the sites, movies, slideshows, or multimedia players, that you see on millions of Web sites.  For the sake of this comparison, I am going to talk specifically about slideshows that are created in Flash compared to those using  jQuery because that is the vast majority of the Flash that we have traditionally used in our projects.  And ’cause that’s what this post is titled.

Flash Advantages

• Great looking fonts
• Smooth, complex animations
• Robust development tools

jQuery

You may have noticed that I have referred to “slideshows created in Flash” and “slideshows using jQuery.”  This is a fundamental difference between the two.  While Flash is an embeddable object created in a specific application, jQuery is a JavaScript library that can add a bunch of really neat-o functionality and effects to elements that already exist on the page. This means that you have HTML, and then on top of that, you have jQuery making that HTML jump through all kinds of hoops, sit, roll over, and even sometimes, though hopefully not often: play dead.  jQuery is JavaScript, which means that some experience with the ubiquitous scripting language is going to make things much easier.  There are hundreds of plugins which exist as additional JavaScript files along with the HTML they need to act on that you can simply copy and paste in to your web page to add whatever slideshow you want.  Many of these existing plugins slideshows have comprehensive documentation that even those without lots of experience with JavaScript can follow.  Basically, if you know your way around HTML and CSS, you can figure out how to at least use jQuery.

The jQuery library can either be downloaded from the jQuery Web site, or you can link to hosted versions from jQuery, Google, or Microsoft. I tend to use the Google-hosted version because it is very popular and likely in use on many other sites. Because of that, if your visitors have previously visited a site using the same linked library that you do, their browser will not have to download it again and you’ll save the 150-ish KB of download that the library requires.

jQuery Advantages

• Generally smaller, and quicker (150KB+ though, for the main library)
• Less time to create, very simple to manage
• Superior accessibility and findability
• Works on iPhones
• Free

Picking One

There are many questions to consider before you when even decide to use a slideshow (see “Parting Shot” below).  I’d say that, if you do decide to add a slideshow to your page  jQuery will be the best choice in 98% of cases.  It offers most of the abilities of Flash (depending on how adept you are at JavaScript) and has the added advantage that it is used to animate images and text that already exist in the page.  This is of monumental importance to search engine optimization, accessibility, and cross-browser/cross-platform support.  That your images and text already exist in the page means that it is basic content that you manage in your authoring system.

Even if a visitor has all styles and JavaScript disabled in their browser** the content contained in your slideshow will be present for them to see (albeit in a way that may break the beautiful layout of your page which is already the case if they have styles turned off).  This is the essence of accessibility: that all content on your page is available to all visitors regardless of how they access your page.

There is no cut-and-dried answer to the question “Flash or jQuery,” though I’d argue that in the limited scope of slideshows jQuery has a decided advantage.  In the end it really depends on what you are trying to communicate, to whom you are trying to communicate it, and how you want it to look.  If you want to be able to use any beautiful font available to your designer, utilize sophisticated transitions (though jQuery can match much of Flash’s capabilities in this regard), ensure that your slideshow works on all browsers with the Flash plug-in installed, and don’t need to support iPhone users, then Flash may be your best bet.  If you are, however, willing to limit your font options, want to be sure that your content is available to all users, on all browsers, regardless of platform, and are willing to limit slightly the sophistication of transitions and animations, then jQuery is the clear winner.

Parting Shot

And that brings us to the end, but I simply cannot leave without a final parting shot regarding putting  a lot of time and money in to designing and developing a slideshow.  I, and others in the office are looking with an increasingly critical eye toward the effectiveness of using slideshows at all to highlight important information.  A too-cursory review of too-few site analytics begins to suggest that very, very (very!) few visitors see more than the first slide of any slideshow; Even fewer engage with the sideshow controls (if present, to move forward, back, or pause);  And fewer still click on any links found on slides beyond the first.  Do not assume that the third, or even second, slide will get any attention at all.

One of the drawbacks of many new interface options presented by Flash or jQuery (or any of the other JavaScript libraries out there) is that they have offered an easy solution to a very old problem: gigantic homepages where every department in an organization demands a presence.  Similarly to simply adding more and more content to a homepage until visitors have to scroll tens of screens down to read it all, we are now asking visitors to engage more and more frequently with tabs, slideshows, accordion widgets, and more to access the same “too much content.”  Have we just shorted the all-too-important conversation about focusing an organization’s message and simply allowing “all of it” to go on the homepage?  And what about people who don’t or can’t use these new widgets? Perhaps another blog post?  I nominate Jo!

** Chances are pretty good that if styles and JavaScript are disabled in a browser, so is Flash.  If your slideshow reads its content from an XML feed, the path to which you define in the JavaScript call to the Flash object, your slideshow will not work even if Flash is enabled but JavaScript is not.

One site, which was tested using an eye-tracking study, demonstrates how a slow-loading promotional banner plus a large number of widgets on the site, create confusion for the user rather than the engagement opportunities that were intended.

Long page load times can cause user drop-off

When you think about your own site, what do you know about the load times — and the corresponding distractions that might result from slow-load times? The UseIt article gives some helpful guidance on how to get at those questions.

If you don’t read the full article, here’s a helpful tidbit:

…  From UseIt.com ….

The 3 response-time limits are the same today as when [Jakob Nielsen] wrote about them in 1993 (based on 40-year-old research by human factors pioneers):

0.1 seconds gives the feeling of instantaneous response — that is, the outcome feels like it was caused by the user, not the computer. This level of responsiveness is essential to support the feeling of direct manipulation (direct manipulation is one of the key GUI techniques to increase user engagement and control).

1 second keeps the user’s flow of thought seamless. Users can sense a delay, and thus know the computer is generating the outcome, but they still feel in control of the overall experience and that they’re moving freely rather than waiting on the computer. This degree of responsiveness is needed for good navigation.

10 seconds keeps the user’s attention. From 1–10 seconds, users definitely feel at the mercy of the computer and wish it was faster, but they can handle it. After 10 seconds, they start thinking about other things, making it harder to get their brains back on track once the computer finally does respond.

A 10-second delay will often make users leave a site immediately. And even if they stay, it’s harder for them to understand what’s going on, making it less likely that they’ll succeed in any difficult tasks.

Interesting stuff.  Check out the full article here: http://www.useit.com/alertbox/response-times.html

Just like your house, your website needs a little special attention sometimes.  There are things you need to do once in a while to keep it performing its best.  Depending on your needs, you might want to do these quarterly or yearly, but you should check up on them at least once a year and make sure everything looks good. It’s not sexy or exciting, but it will help keep your website running smoothly. And now is the perfect time to get started.

• Clean up your email database. Most eCRMs give you tools for cleaning and de-duping your email list. No matter how you import supporters to your database, over time, you’ll end up with some bad data as people move, change their email addresses, or accidentally create duplicate records when they take actions on your site. Get rid of bad data, and consolidate your duplicates as much as possible. This is a big task, but it’ll give you more accurate metrics, improve your spam reputation, and reduce the chances that you’re bugging people with multiple copies of your messages.
• Update outdated content/actions. Take an hour and browse your site with fresh eyes. Are your news stories recent? Do you still have a promo, buried on your subpages, for a campaign that finished a year ago?  Is the contact information up to date? What about that little typo that bugs you every time you visit the site? Set aside time to find and fix these little errors – over time, they can really pile up.
• Fix broken links. Link-checking can be fast and easy.  There are many tools to scan your site and identify bad links, both within your site and to external sites.
• Look at your 404 pages. While you’re at it, take a look at your 404 (Page Not Found) errors. Your analytics tool can tell you what missing pages people are trying to visit, and where they found them.  Maybe Google is still indexing old content, or another site has a link with a typo. Some of them, you may be able to fix.  This is also a good time to look at the content on your 404 page itself. Are you providing useful information to help visitors get where they wanted to be?
• Check your “hidden” content. Welcome messages, autoresponders, donation forms, error text… all this content is “out of sight, out of mind” when you’re running a website day-to-day, but it’s very present for many of your visitors.  You know that good Thank You messages are critical for engaging new subscribers and first-time donors, but when was the last time you took a critical look at your default messaging?
• View your site in new browsers. Unless you just redesigned your website, there have probably been new versions of some major browsers since it was developed.  Look in your analytics to see what browsers and versions most of your visitors are using.  If some of the new ones are on the rise, download them (or find a friend who has them installed) and spend a few minutes browsing the site to make sure everything looks okay.
• Test your SEO. Type the name of your organization into a search engine. Where do you rank? What does your listing look like? Do the same for a few non-branded keywords that describe your org. Do the most relevant pages show up first?  Where do they rank?
• Review your site search. If visitors are having trouble finding something on your site, chances are they’ll search for it.  So reviewing your site search analytics is a great way to see what stumbling blocks users are finding on your site.  Not every search term that’s used will indicate a problem – but site search is the one part of your site where users tell you exactly what they’re looking for, and it’s worth paying attention.
• Long term reporting. Chances are there is some data you’ve been meaning to sift through.  How have your emails performed over the long term? What’s the churn rate on your email list? How are you doing on those important goals you set way-back-when?  Now is a good time to look into some of those questions you never got around to answering, or just to spend some time with your analytics tool and see what you find.