On the etiquette of flashing: support sites and Flash interfaces don’t mix

The discipline of theodicy is a branch of theology and philosophy. It attempts to reconcile various belief systems with the existence of evil. By way of a simple – if fatuous – example, it addresses questions like why a god might allow bad things to happen to good people. A certain kind of cynic might conclude that this amounts to a system of conceptual pussyfooting and complex evasions – a way for spiritual thinkers to avoid the conclusion that there is at least no loving god, if indeed any to speak of.

That, rather obviously, is beyond the scope of this blog.

But the world of web design, usability, information design, and so forth is a little simpler. It has a problem of evil all of its own; and I have no qualm at all  concluding that anybody building a pure Flash help portal is not a loving designer, if indeed any designer to speak of.

I recently encountered a couple of all-Flash support portals, and they made me sad. One of them was the subject of a conference presentation. An hour on how to use the help. Gosh.

Problems of evil

Let’s assume you’re not completely ignorant of human behaviour on the internet. Let’s also imagine you create a knowledge base article on, say, a specific error message in your new product. You get the basics right – you call it “Error code 38Q when using the SuperFuntime-Widget-o-Matic“, it has clear headings, concise content, and a code snippet to help the user with a workaround.

You then decide to deliver this article in a Flash portal.

  • What if the user can’t right click, then cut and paste the code snippet, but is instead offered the wonderful opportunity of learning more about Adobe Flash Player?
  • What if a user types “38Q error SuperFuntime-Widget-o-Matic” into Google and doesn’t get your article?
  • What if a user with an immediate problem has to sign in, wait 30 seconds for the site to load, and laboriously browse a non-standard interface to your article?
  • What if a user has IE 6, with Flash player 5, in heavily locked down conditions?

If any of these things happen, you haven’t helped them properly. You knew, or could reasonably be expected to have known about that. You have done something bad.

Worse luck, it turns out the SuperFuntime-Widget-o-Matic makes shoes for orphans, but a 38Q error means it’s now killing kittens. Christmas is ruined, and it’s YOUR FAULT.

Seriously, though: how are you going to reconcile a broken Flash portal with your values as a content/information professional?

(yes, yes, they’re not all broken…)

Well, there are some things you can try to get right, if you’re absolutely set on having a Flash interface.

Path of least surprise

Web pages have been around for a while now. Users, you know, understand what a web page is. Web pages have accustomed behaviours around navigation, information architecture, and to an extent functionality. Users often also, get to web pages from other web pages. There are contexts and expectations.

If you really think you know better, you need to make damn sure you’re right.

I point this out because when you deviate from very well established user interaction norms, people find stuff harder to use. When you surprise them, they don’t like it. There’s a reason “how did you expect it to work?” is one of the more asked questions in usability testing.

It’s also worth remembering that folks are often already a bit fraught when they go looking for help. Try to impose no extra stress. You don’t get very far by making people struggle.

So if you’re going to take somebody who’s looking for information from a web page to a flash interface, you’d better make sure:

  • The navigation conventions are upheld
  • Contexts are obvious
  • It’s quick to get in and out
  • You still preserve best practices for web writing
  • It’s really, really, invisibly fast
  • They can open everything in a new tab

I’m going to bang on about that last one. What do you think a right click menu is for, I wonder, Mr Flash Portal Designer? Conventional wisdom says it might be, oh, I don’t know, a context menu. It might contain things you want to do quickly in a specific context. Things like copying text, something nifty form a Firefox plug-in, or just opening a link in a new tab. You almost certainly do not, when hovering over a promising-looking link, want “About Adobe Flash Player 10.”

Nobody wants that. Ever. Get it fixed.

Loading times

Some flash sites are a bit slow. Particularly if they’re trying to do a lot.

I’ve alluded, in blog after blog, to the fact that nobody wants to be in your help system. They want the fastest possible solution to their problem, and the one that takes them away from their workflow the least.

It is utterly, utterly incumbent upon us to give assistance-seeking users the help they need as quickly and as obviously as we possibly can. Make titles useful, keep cognitive load low, and make it easy to get in.

Paywalls, fancy designs, perceptible loading times, mandatory decisions – often really, really bad.

Visibility from Google

People use search. I’m fairly certain about that one. Rather than navigating your help system, many users will hammer the shape of their problem into Google, and expect to get your specific help, along with blog or forum solutions from other users. They’ll then pick the likely looking ones (they might even right-click to open multiple tabs.).

  • If your content isn’t visible to Google, it doesn’t exist for a whole bunch of users.
  • If your content isn’t visible from Google, it’s harder for users to get in and out quickly without deviating from accustomed behaviour.
  • If your content isn’t visible form Google, you’d better make damn sure your own search was built by magic space ninjas.

It’s only fair to admit here that yes, if you’re charging for support content, you don’t necessarily care about or need search visibility. Although complete invisibility may not be the best way to show off your value.

…Or just don’t use Flash

Not for the whole UI, at any rate. I’m by no means holding it up as a paragon, but Google Wave is choc full of fruity functionality whilst still behaving broadly like a web page.

Let’s face it, web pages actually aren’t that bad for delivering structured textual information.

If you really want a certain set of bells and whistles, you could build an AIR app, I guess.

If you’re going to use flash, you should probably use it for this