Tag: Web Standards

How not to do the Internet: a case study in bad web UX

My Subaru dealership’s website(s)

My Subaru Outback is due for service. Time to schedule an appointment. This is the kind of thing I just love to do online. No human interaction necessary!

Unfortunately, my dealership (who shall remain nameless, although I am happy to tell you that their shoddy website experience, which I am about to detail for you, was delivered by auto dealership web development behemoth Dealer.com) has not made the online scheduling option easy. And by “not easy,” I mean “practically impossible.”

First of all, for no good reason, the scheduling interface is built 100% in Flash. I’m pretty sure this scheduling system predates the iPhone, and Flash was at the time a de facto standard, but I’ve been building web applications since 1999 and there was never a time when it made sense to build a system like this in Flash. I deliberately don’t have Flash installed, except the version built into Chrome, so I couldn’t even load it in my browser of choice (Safari). Strike one.

I don’t think so.

Switching over to Chrome, I was able to go through most of the appointment scheduling process, picking the service I needed done, etc., until I got to the point of actually scheduling it, where I was stuck in an endless loop of picking days that were marked “available” on a little calendar overlay, only to get an error message stating “Not available due to shop capacity.” Over and over.

All but giving up, I spotted a curious item at the bottom of the page:

Ooh, this looks promising! Except… wait. How can clicking a link on my computer download an app to my smartphone? Maybe I should visit this site on my iPhone and then tap the link. Except… wait again. This part of the interface is in Flash, so I wouldn’t even see the link on my iPhone. So, what happens if I click it, anyway?

Are you kidding me? We are now at a place where I am interacting with a Flash-based web app on my computer, having it send to my phone an SMS message containing a link to the dealership’s mobile website. I’d even prefer a QR code over this convoluted mess. Strike two.

This is not how you do the Internet.

So I just decided to go over to my iPhone and try loading their website directly. It “smartly” (using the term loosely) redirected automatically to a separate iPhone-optimized version of the site, which I can only assume must be the mobile site the SMS would have linked to. (That is a reasonable assumption, right? We shall see.)

Here’s what I found when I navigated through the iPhone-optimized site to the service department’s page:

That “Service” button calls the service department. The “Contact Us” button is a link to a general-purpose email form. There are no other options.

“The mobile site will let you create, modify, and cancel appointments.” That’s what the SMS form promised. I decided (solely for the purpose of this blog post at this point) to fill out that form, but have the link emailed to me rather than sent as an SMS message. Not surprisingly, the email ended up in my junk folder. Also not surprisingly, the link goes to a different site than the version my iPhone was automatically redirected to when I tried to load the dealership’s main website. (So this is three separate websites they have now.)

I loaded this other mobile site on my iPhone, and it works!

Except, no, wait… it doesn’t:

Except, no, wait again… despite that weird error message, it actually does work:

(How many “except waits” is that now?)

But since it apparently only lets you edit existing appointments, not make new ones, I guess it really doesn’t work, after all. Also, don’t ask me why the iPhone version of the site doesn’t even have a link over to this version, but I guess ultimately it doesn’t matter anyway. Strike three. And four, five and six. In fact, let’s just call the game. And I’ll call the dealership.

Conclusions

What have we learned here? Aside from the fact that I am willing to spend far more time writing a blog rant about this problem than I am just calling to schedule an appointment over the phone, I hope I have impressed the value of web standards. If this site’s interface had been built in simple HTML and JavaScript, instead of Flash, which I can tell you is 100% possible — there is absolutely nothing in the interface functionally, and not even really anything in terms of the design or interaction, that could not have been done with HTML, CSS and JavaScript, even several years ago — then it would have worked fine in Safari without Flash, and it would work on my iPhone.

There has always been a lot of temptation to use Flash to do things that couldn’t be done with web standards, especially when the standards weren’t up to Flash’s capabilities. But succumbing to that temptation led to two trends that were profoundly harmful to the open web, and the effects of which we are — and I am literally — still experiencing today.

Bad UX as standard practice

First, since the sky is the limit when designing Flash interfaces, it created a feedback loop where designers took excessive liberties in experimenting with how basic interface elements like scrollbars and buttons should look and function. Then, project stakeholders who didn’t have the requisite background to make informed UX design decisions made demands that further pushed how these elements look and function. And since Flash had so few constraints on interface design, designers could accommodate those expectations, and the situation spiraled out of control.

This problem is not exclusive to Flash, of course. These days CSS and JavaScript offer tremendous potential for messing with standard UX conventions, and I’ve gotten myself into trouble with this on occasion. Customized scrollbars, fixed-position content, etc. Always remember, just because you can do something doesn’t mean you should. Things in the future will change in ways you can’t anticipate. Those changes are likely to accommodate existing standards, but not your customizations, no matter how brilliant they may be.

Flash as an industry

Second, as Flash grew in popularity it created an entire industry of Flash developers. Suddenly you had people whose livelihood depended upon building interfaces in Flash, regardless of whether or not Flash was really the right tool for the job. And as someone who has always favored open web standards, my perspective is that Flash is only the right tool for the job when it’s the only tool for the job. Even if standards couldn’t do something in quite as… ah-hem… “flashy” a way, if they could do it at all they should be chosen over Flash. I recognize this is a bit subjective, but one thing I can say about it with objectivity is that favoring web standards over Flash for a system like the one I’m describing here would almost certainly have obviated all of the problems I encountered this morning.

A metaphorical lesson to all technology workers: when your only tool is a hammer, every problem looks like a nail. Diversify your toolbox. It will serve your clients better by ensuring that you’re using the best tool for the job, not just the tool you know best. And it will serve your career better by not limiting your job options.

Future-proofing the web

There’s an even bigger reason now that having built this kind of system then using web standards instead of Flash would’ve been a good idea. If this site’s forms had been built with semantic HTML, it would be a comparatively trivial task to build new CSS with responsive web design techniques, allowing a single site to deliver the complete user experience on any device, rather than having to pay for and build three separate, wholly inconsistent, and all inadequate websites. By supporting and adhering to standards in the past, we could (and did) build websites that still work fine today. And by continuing to adhere to standards today, we can build websites that will still work fine tomorrow, even if we don’t really know what tomorrow’s devices will look like, or how we will interact with them.

Responsive Web Design: On embracing the web’s uncertainty principle

What do Werner Heisenberg and Ethan Marcotte have in common? First and foremost is probably that I have just mentioned them in the same sentence. Second, whereas Heisenberg’s uncertainty principle paved the way for quantum physics (which revealed that matter and energy can exist as both a particle and a wave), Ethan Marcotte’s Responsive Web Design promises to usher in a new era where we discover that desktop and mobile websites, too, can be one and the same.

My analogy may be stretching thin, but the point remains that we are entering a new phase in web design. We can no longer assume websites are being viewed on a desktop computer screen of certain minimum dimensions. We also can no longer justify building and maintaining two (or more) discrete sites, shunting mobile users off to a scaled-back, limited experience while allowing desktop users access to the full version. And all of this means that we must consider the dynamic (and, in fact, increasingly so) nature of the web as a medium from the earliest steps in the design process.

Many examples of Responsive Web Design are beginning to crop up (including this site), but the best high-profile example so far is a site Marcotte himself consulted on: the new BostonGlobe.com. I’m hopeful that soon this design approach will become the norm for most websites.

But the challenges facing those of us who are ready to embrace Responsive Web Design are many. Getting a handle on the use of CSS3 media queries is the first and probably easiest of these, if you’re comfortable with code. Most of the leading innovators in web design have long worked directly in code — and knowing and working directly with HTML5 and CSS3 is pretty much a requirement for effective use of the Responsive Web Design approach.

But I would guess that the majority of web design going on today is still being done the “old fashioned” way. A graphic designer, usually with experience primarily in print, puts together a layout in one of Adobe’s creaky monolithic Creative Suite applications (Photoshop, Illustrator, InDesign), then (if we’re lucky) hands off that design file to a developer to build out as HTML. If the developer is with it, they will follow best practices and web standards, building out semantic HTML document structures with design properties defined in CSS. (No tables, please.)

There are many potential points of failure in this arrangement, because a design in an Adobe application bears little resemblance “under the hood” to an HTML/CSS layout in a web browser. It’s not just that the canvas you’re painting on is different, although there’s that. It’s that they’re not even both canvases. No matter how much Adobe tries to ease the transition for print designers, any process that forces you to start by specifying page dimensions just isn’t going to translate effectively to the nebulous, dynamic format of a website.

“Design in the browser” is the new mantra. And again, that’s great if the person designing knows how to do that. But many designers don’t, and it’s not necessarily fair to expect them to. The entire process needs to change. Developers and designers need to work together more collaboratively, and earlier on in the project. For years I’ve been promoting the importance of designers understanding HTML/CSS and the capabilities (and limitations) of web browsers, even if they don’t necessarily write the code themselves. It’s not just about knowing what certain browsers can or can’t do (like the fact that Internet Explorer didn’t support layered backgrounds until version 9). It’s about knowing all of the things browsers can do that can’t possibly be replicated or even represented in a static design built in an Adobe CS app.

There are so many aspects of this that have always been important (how best to slice up a design; what’s background/foreground; what should be images and what shouldn’t; when to use JPEG vs. PNG; optimal page widths; where the “fold” is and whether or not it exists even as a concept; the fluid nature of vertical elements; how users interact with elements and how the page gives feedback using JavaScript and/or CSS; etc.), but now on top of all of these concerns we have the additional complexity — and opportunity — of working with different classes of devices with radically different screen sizes, capabilities, and interaction methods.

Again, “design in the browser” is the ideal. But until we get there, it’s essential that graphic designers who aspire to work with the web take the time to really understand the medium: how it works, how varied it can be, how quickly it changes. Then, even if the designs are, for now, still delivered in an Adobe format, their structure and content will at least be better informed by the practical realities of the form they will finally take in a web browser.

So, as a designer, what’s the best way to get informed? Working with a developer who understands and is enthusiastic about Responsive Web Design is a great option (hint, hint), but at the very least I recommend reading Ethan Marcotte’s book. In fact, the entire A Book Apart series is essential reading for anyone who wants to build forward-looking websites. The future is coming. We may not know what it will look like yet, but it’s a safe bet that tools and techniques that were already antiquated a decade ago are not the way to get there.

I don’t want to end on a down note, so I’ll pose this final challenge to inspire and motivate any designers who might be reading this. Despite the potentially intimidating appearance of code, web standards are first and foremost about simplicity. The dynamic duo of HTML5 and CSS3 are a world apart from the hairy mess of table layouts and <font> tags that dominated the early web. Watching a design take shape directly in the web browser can even be fun! And with the powerful interactive capabilities of JavaScript tools like jQuery, and the typographic world that has been opened up recently with font embedding services like Typekit and Google Web Fonts, there’s never been a better time to be a web designer. The more you know about what goes into realizing your designs in a web browser, the better you will be at your job and the more opportunities you will have.

Web standards: a Win-Win-Win situation

Today is the fourth annual “Blue Beanie Day,” a tradition established by the father of web standards, Jeffrey Zeldman.

What are web standards? Simply put, they’re awesome. But seriously… the goal of web standards is to establish a set of best practices for web designers and developers, and a set of open, shared languages and tools for building websites and displaying them in a consistent manner.

At the heart of the modern web standards movement are a set of three core languages: HTML5, for organizing and structuring content; CSS3, for designing the presentation of that content; and JavaScript, for providing rich interaction with that content.

HTML5, CSS3, and JavaScript are all open standards. The specifications are published for anyone to see; they’re open and evolving, for anyone to contribute to; and they’re freely available for anyone to build an application for rendering content delivered via these languages (in common parlance, a web browser, but we’re starting to see “web” content appearing in all sorts of applications for computers and mobile devices these days).

But why are these three web standards so great? Because they create a win-win-win situation:

A win for web designers/developers. By establishing a common set of tools that are open and free to anyone, web designers and developers can get started with no barriers to entry. Plus, by standardizing these tools, the same skills can be applied anywhere a website is being built. And as web browser makers adopt these standards, the last 15 years’ worth of browser-to-browser inconsistency will fade. Our job is made easier, we can get more done in less time, and, with powerful frameworks like jQuery built on top of these standards, this power to do more with less will grow exponentially.

A win for site owners. If you’re paying to build a website, you want to know you’re spending your money wisely. You want your investment to last, and you want to make sure everyone who wants to access your site, can. Web standards are the key to an accessible, reliable, “future-proof” website. Some Internet technologies may come and go; jumping on the latest trend may make your site seem “with it” today, but tomorrow it will be painfully dated… if it even works at all. But these three core web technologies will always be at the heart of the web. Plus, a site built with web standards will automatically be structured well for search engine listings, without the need for expensive and questionable SEO tactics.

A win for Internet users. Web content that is built and delivered with a diligent adherence to web standards will work reliably with any device, any software, that is used to access the Internet. Plus, no well-formed, standards-compliant HTML page ever crashed a web browser.

Web standards: Win-Win-Win.

No one’s listening

Comments. Over the past decade, the Internet has become inundated with them. Ten years, ago, the concept of a “blog” was considered cutting edge, by those who even knew what they were. Now, they’re everywhere, and their general format — a dated archive of topical posts by one or a small number of authors, each of which is trailed by a string of reader comments — has become the standard structure for most news and information websites.

But… comments. Oh, comments. They help turn a one-sided online journal into a thriving community of engaged individuals. Or not. By now, the true nature of most comment threads — a bunch of morons yelling “FIRST” followed by a bunch of even bigger morons ranting at each other without ever engaging — is so well-known, so obvious, that it’s boring even to mention and somewhere between tiresome and excruciating to experience.

So, how long will it be before comments go the way of Internet Explorer 6 and Flash? (Oops… have I spoken too soon?) I think the day is coming soon.

Comment ça va?

Many prominent blogs, Daring Fireball for instance, have long eschewed comments (although the persistent commenters have found a way around that). Others are following suit. And now, it’s easier than ever for frustrated readers to take things into their own hands and silence comments wherever they go online.

I can’t tell you how tempting shutup.css is. I’ve spent more time angrily scrolling through insipid comment threads than I care to remember… but it’s driven me to rant before.

Jumpin’ Jack Flash

But, just like Flashblock (or, for you Safari users, ClickToFlash), I think if I were to try it, I would quickly go back, no matter how annoying the comments are.

Don’t get me wrong: I feel the same way about comments as I do about Flash. Both have potential, but far more often than not they are just intrusive and annoying rather than useful. I tried Flashblock for a few days last week, and I was happy not to be intruded upon with overlaid advertisements, intro animations, and other bandwidth- and time-wasting nonsense. But turning off Flash also meant I had to click an extra button to watch most videos, and even worse, to upload files on my WordPress blogs… not to mention the client sites I’m developing that have JWPlayer and YUI Uploader embedded in them. So, as much as I want to be rid of Flash, and as content as I am not to have it in iPhone OS, I decided I needed to turn it back on in Firefox on my MacBook.

The same goes for comments, but I don’t even need to try shutup.css to know I wouldn’t want to keep it. Sure, I hate the comments on most news and tech sites I read, but I like them on my own site, and I like them on the sites that I want to comment on.

Turn it on again

So, with both Flash and comments, there are proponents and opponents. It seems in the recent dust-up over Flash (or the lack thereof) on the iPhone and iPad, the most fervent supporters of Flash are Flash developers, or people who just hate Apple. And with comments, well, it’s pretty obvious: people who like comments (or, more specifically, like to make them) want them, and just about everyone else doesn’t. It’s clear to me that comments rarely add value, and they often detract from the sites they’re on. On the other hand, allowing comments on my sites has for the most part added value to them, and, critically, commenting on other sites has driven traffic to my sites.

Does this mean that the act of commenting is purely, or at least primarily, an act of shameless self-promotion? Perhaps. I wouldn’t post a comment if I didn’t think the comment had merit on its own, but I’ve also consciously posted comments on some sites knowing that doing so was a prime opportunity to bring some of those sites’ readers over to my sites.

And in the end…

By now it is becoming increasingly apparent to me that both Flash and comments are facing their demise. At least someone at Adobe gets it: Adobe is not in the Flash business, they’re in the “helping people communicate” business. Flash has been a tremendous tool for allowing people to communicate online for a long time where open standards have lagged behind. But by its nature, Flash is fundamentally opposed to what the web is really about. Nobody “owns” HTML or CSS or JavaScript. They’re open standards, and they’re the foundation of the web. Proprietary, closed technologies limit the web’s growth. Flash requires a plug-in (even if just about every computer comes with it preinstalled); Flash files are a “black box” to search engines and text-based systems; the technology resides in the hands of a single company whose fate will dictate the fate of all of the content locked into the format, and the fortunes of the creators of that content.

Comments, too, are about helping people communicate. But it’s become clear that — more or less, depending on the particular site — few people who engage in comments on a blog are really all that interested in communication. If comments cease to be seen as communication and instead become an ugly, depressing wasteland at the bottom of web pages, then they’ll die off too.

Looking forward into a new decade, I am beginning to see the old alignments of the Internet as we’ve known it falling away. There’s a convergence of new standards, new devices, and new means of communicating. And this naturally means that certain older ways, “standards” or not, will fade from our day-to-day experience. I’ll certainly be happier to see Flash go than comments, but then again, I think I’ll do just fine either way. Let me know what you think. Or not.

Zeldman on Outlook 2010

I’ll take Jeffrey Zeldman over Jakob Nielsen any day. (Case in point.) And Zeldman’s criticism today of Microsoft’s inexplicable use of the Word HTML rendering engine in Outlook 2010 despite IE8’s genuine efforts to become standards compliant is true to form. A quote worth repeating in its entirety, re-tweeting (if it weren’t over 140 characters), and having tattooed on your favorite body part:

Big companies love these fictions where one part of the company “pays” another, and accountants love this stuff as well, for reasons that make Jesus cry out anew.