The term “autism spectrum” is a bit of a misnomer, as it’s not actually spectrum in a linear sense at all.
In this post on my other blog, I illuminate how I’ve tackled the problem and hopefully created a more accurate, easier to understand diagram explaining where an individual might be on the so-called autism spectrum.
Today I was the first person at work, and upon entering the office I heard the warning beep of our burglar alarm. I panicked for a moment, and then mentally scrambled to remember the code to disarm the system.
When I entered what I believed to be the correct code, the system presented me with the message “Not ready to arm.” My nerves were on edge, as I knew that if I’d entered the code incorrectly the alarm would go quiet (as it had) and the police would be arriving at any moment.
Unfortuantely, the alarm system offered little solace. “Not ready to arm.” What does this mean? If I’d entered the correct deactivation code, shouldn’t it say “Alarm deactivated”? At the very least, wouldn’t the proper message be “Ready to arm,” reflecting the state of an alarm that was not presently armed?
I’m sure in the alarm system’s functional requirements, the phrase “Not ready to arm” makes sense to someone somewhere. But to me, the groggy morning user, it made absolutely no sense. I decided not to fuss with it any longer; if the police showed up, I’d plead ignorance.
But I was reminded, yet again, how important it is to write alerts, messages, warnings, tips and cues that are concise, telegraphic, and accurate. Most importantly, they should be contextual and attempt to anticipate and answer the most pressing user question at that particular point in whatever process is taking place.
Vagueness and ambiguity — great when you’re writing the screenplay for an indie film — don’t help the user in the least.
PS Apparently “Not ready to arm” does in fact mean that the code I entered was correct. I will remain out of jail for another day. Go figure.
The effect of infographics on intelligence: an infographic
Click the image to enlarge
After the New York Times introduced its new digital subscription pricing policies, there was much confusion. Frankly, even the NY Times’ own explanations are a bit baffling. Therefore, I’ve created the quickie infographic above in order to (hopefully) clarify things. (You can click it to see a larger version.)
It all begins with a sketch.
If you’re like me, you usually start your prototypes or wireframes on paper. However, it can be hassle to sketch out all the browser elements and grid anew for every page in a project. That’s why I created the 970 pixel wireframe sketch template that you can download (PDF) and use for your own work.
The grid is set to mimic 970 pixels, with 12 columns of 68 pixels width each, with a 14 pixel gutter between them. There are also 14 pixel gutters on the left and right sides, so the true width of the page would be 998 pixels if you wanted that padding.
As I’ve recently discovered, the 970 pixel grid is, in many ways, more accommodating than the popular 960 pixel grid.
In case you missed it, here is the template again: download.
The 970 pixel grid.
I’ve been using the 970 pixel grid for a little while now, and I agree with those who argue it has many advantages over the traditional 960 pixel grid. For more information, read this article. To download a layered Photoshop file with grid and measurements that I developed, click here.
The term User Experience Design or UX, as applied in a Web or mobile setting, can be confusing, as it seems to mean different things to different people. Some think of it as information architecture, while others consider it to be usability; some use it interchangeably with user interface design. The common mistake here is confusing a subset of activities with the whole.
I’ve created the graphic below to show a summary view of the unique disciplines, activities, and artifacts that can be identified as part of User Experience Design. This diagram is not all-inclusive, and some may disagree with certain elements, but I think it provides an accurate overview.
Although I’ve broadly categorized the disciplines found in UX Design as Information Architecture, User Interface, and Content (and I’ve excluded Technology), these do not necessarily map to specific professions. For example, while information architecture is often practiced by information architects, it’s not unusual to see information architecture done by the UI designer, or content developed by the information architect.
Now, while some employers want unicorns (one mythical beast of a person who can do everything), others want specialists (several people narrowly focused on specific tasks and artifacts). Nonetheless, experienced UX professionals may have talents and skills that span two or more disciplines. The graphic below, for example, shows the areas I personally consider my strong suits, and those I do not.
Note: I have included HTML and Flash implementation as part of User Experience Design and not Technology, because they represent the manifestation of the final user experience.
Over the years, I’ve used many apps for wireframing, from Mockflow to Mockingbird, Dreamweaver to Flairbuilder, Protoshare to Balsamiq, Omnigraffle to Indesign and Illustrator. And, of course, everything still begins (and sometimes ends) on paper. But I’ve yet to give Fireworks a whirl, despite the fact that some UX people rave about its strengths as a wireframing and prototyping tool.
So last night I began developing some wires using Fireworks, and thus far I’m pretty impressed. I can export the wireframes as clickable PDFs or as PNGs with HTML hot spots, or as sliced HTML files with rich interactivity, making them easy to share with clients and colleagues.
A wireframe done in Fireworks.
Supposedly I will be able to bring them directly into Photoshop for UI design when they’re complete. All wireframe pages are stored in one Fireworks file (Fireworks uses a flavor of PNG that permits multiple layers and states, as well as vector shapes, symbols, and interactivity). I can use standard Adobe keyboard shortcuts. And, I can work the way I’m used to working: like a designer, not a programmer.
The biggest challenge so far hasn’t been learning Fireworks, but forgetting Photoshop: both apps are very similar in terms of form and function, yet they are different in subtle but critical ways. I seem to keep trying to do things the Photoshop way, and it doesn’t always work. Nonetheless, it’s a familiar environment, and that’s pretty helpful.
Some of my friends have said they don’t understand why I try to so many apps when there’s probably one that works better than others (and they each have their own preferences, of course). In my case, however, either I haven’t found the perfect tool or, more likely, in my opinion, each project requires a different tool.
In any event, I’m going to try to slug it out with Fireworks on this project, and I’ll report my progress when I’m done.
Update: Well, that was fast. After one day of use, I can state without equivocation that I won’t be trying to tackle this project using Fireworks. I wrestled for a couple of hours with the States / Layers / Pages confusion. Adobe’s help application was confusing, verbose, and incomplete. I’m sorry to report that Fireworks won’t be at the top of my tools of choice for wireframing, as I believe a great tool should be fairly self-explanatory, especially when it comes to basic tasks like exporting pages and states.
The following white paper, written by me, was originally published at Netsoft-USA.
Thinking of going mobile? If so, there are some important things you should consider. First and foremost, does going mobile make sense for your business? If so, should you build a mobile application (or app) or simply offer a mobile-optimized version of your website?
Netsoft's HealthMobile app puts vital information where it belongs: in the hands of users.
As always, the answer begins — and ends — with your target audience. If they’re not mobile, you shouldn’t be either. For example, if your target audience spends all day tethered to a computer, a mobile version of your offering might be superfluous.
If your target audience is mobile, then it’s time to ask some questions that will help determine the best course of action:
If the answers above indicate that you can and should go mobile, then you’ll need to determine which platforms to target and whether or not you should build an app or a mobile-optimized website.
It's like the browser wars of the late 90s all over again.
With such a wide variety of mobile platforms available today — including iPhone, Android, Blackberry, Palm, and so on — you might feel overwhelmed in deciding how to approach your customers. However, it’s not as confusing as it sounds.
Most importantly, you need to find out which platforms your target audience is using. If, for example, they are corporate clients who use Blackberry devices, targeting iPhone or Android platforms would not be a wise choice. If, on the other hand, they use a mixture of devices, then you should determine which platforms are most prevalent and target them first.
To start, interview a representative sampling of potential users to determine which devices they use. Next, if you’re building a mobile website, review your current site’s analytics, if available, to see which devices are being used to view your site.
Mobile apps and mobile websites are not the same thing, so understanding each is critical in determining which to build.
A mobile app is really just software designed to run on a mobile device. Apps are often one-trick ponies, but they do their one trick very well. They’re so useful and engaging that they’re fueling the explosive growth of the smart phone market.
Like traditional software applications, mobile apps are often platform-specific, so if you want an application to run on multiple platforms (e.g., Blackberry, iPhone, Android), you need to develop multiple versions of your app and market it through the appropriate channels. This can add significant expense, so knowing your target platforms is critical.
In addition, as tablet computing grows in popularity, as it looks likely to do with the runaway success of Apple’s iPad, it may be worth considering an application that takes advantage of the tablet platform’s larger display and unique capabilities. But, as always, you should only go down this route if your audience is already there or will be there very soon.
Do you know if your users are mobile?
A mobile website is similar to a non-mobile website, except that it has been optimized for the more limited experience of accessing the Web on a mobile device. For example:
If you do decide to build a mobile version of your site, it’s important to understand that this effort is more involved than simply “screen scraping,” or pulling your existing site’s content into a mobile format. You should prioritize and skinny down your site to the items your mobile users will want, and ditch the rest.
In addition, there are a wide variety of mobile browsers — some better than others — which means that there may need to be multiple formats of your mobile website designed to work with each browser. That said, there is a move toward standardization, and both the iPhone and Android platforms use the WebKit browser as a common platform, and soon Blackberry devices will use the WebKit browser as well.
Many companies and organizations provide both a mobile app and website to their users, ensuring all their bases are covered. For example, Facebook has an app available for the major mobile platforms, and they offer a mobile version of their website for users who choose not to download and install the free app. For technical reasons, the Facebook app and mobile websites are slightly different in the experiences they provide; however, by having a mobile website and an application, Facebook avoids losing any users who prefer one technology over the other.
By providing similar features and functions on both its mobile app and website, Amazon lets users choose how they want to shop.
Alternatively, you might find that some of your information is best presented via a mobile website, while other information is better suited to an application. For example, some companies have a mobile website for their public Web presence but a feature-rich app for their corporate intranet. Likewise, some financial institutions have mobile websites for public content and an app that provides transactional capabilities for their account holders.
Don't be afraid to listen to your users before, during, and after lanuch of your mobile site or app.
Once you put your mobile website or app in the hands of your users, the fun really begins. By keeping an open line of dialogue between your team and your audience, you will learn what works, what doesn’t work, what you should improve, and what you shouldn’t touch.
Don’t be afraid to take an iterative approach. Launch with a few features you know work well, and only add new features once they’re ready for prime time. Like any technology endeavor, embrace the concept of permanent beta. It doesn’t mean you’re never done; it means you’re always on a journey.
Going mobile needn’t be a daunting undertaking. All you have to do is stick to the basics:
Here’s a great information display showing HTML5 and CSS3 compatibility and readiness of major modern browsers. The creators also developed the helpful website whencaniuse for Web developers.
Update: when I first posted this, I didn’t realize the interactivity is, of course, created via (wait for it) HTML 5!
Another useless infographic.
Thanks to Richard Smith for pointing me to this fun (and actually useful) flow chart.
Another Infographic.
Where ideas strike.
I saw this great set of venn diagrams today, so I thought I’d make my own:
What's Your Type?
We are in a new age. The interactive graphic has killed the humble pie chart. Graphical displays of complex information needn’t be flat and abstruse; instead they can be entertaining and engaging and, therefore, far more effective.
Many examples of this new breed of infographic can be found online, including this lovely example of what people were doing in 2008, courtesy of the New York Times. Here are some other examples:
The lesson is this: when presented with the chance to tell a story with facts and figures, consider not only the graphical presentation of the information, but opportunities for the user to interact with that information as well. Doing so will allow users to go from passive to active, greatly improving the odds that they will also be engaged in the information exchange.
Do you have other examples? Please let me know!
