Leo Laporte interviews JZ

IN EPISODE 63 of Triangulation, Leo Laporte, a gracious and knowledgeable podcaster/broadcaster straight outta Petaluma, CA, interviews Your Humble Narrator about web standards history, responsive web design, content first, the state of standards in a multi-device world, and why communists sometimes make lousy band managers.

Product Management for the Web; Beyond Usability Testing

IN ISSUE NO. 357 of A List Apart for people who make websites:

Beyond Usability Testing

by DEVAN GOLDSTEIN

To be sure we’re designing the right experience for the right audience, there’s no substitute for research conducted with actual users. Like any research method, though, usability testing has its drawbacks. Most importantly, it isn’t cheap. Fortunately, there are other usability research methods at our disposal. The standouts, expert review and heuristic evaluation, are easy to add to a design and development process almost regardless of budget or resource concerns. Explore these techniques, learn their advantages and disadvantages, and get the low-down on how to include them in your projects.

Product Management for the Web

by KRISTOFER LAYON

Whether we prototype, write, design, develop, or test as part of building the web, we’re creating something hundreds, thousands, or maybe even millions of people will use. But how do we know that we’re creating the right enhancements for the web, at the right time, and for the right customers? Because our client or boss asked us to? And how do they know? Enter product management for the web—bridging the gap between leadership and customers on one side, and the user experience, content strategy, design, and development team on the other. Learn to set priorities that gradually but steadily make your product (and the web) better.


SINCE 1998, A List Apart has explored the design, development, and meaning of web content, with a special focus on web standards and best practices.

Illustration by Kevin Cornell for A List Apart Magazine.

Facebook goes native

“IF I WERE advising them on these decisions, I would have had them look at what people actually want from Facebook — fast access to their friends’ photos and posts — and … helped them design an HTML5 web experience that actually works for mobile.”

.net magazine: Facebook iPhone app to go native By Tanya Combrinck on June 28, 2012

Web Design Manifesto 2012

THANK YOU for the screen shot. I was actually already aware that the type on my site is big. I designed it that way. And while I’m grateful for your kind desire to help me, I actually do know how the site looks in a browser with default settings on a desktop computer. I am fortunate enough to own a desktop computer. Moreover, I work in a design studio where we have several of them.

This is my personal site. There are many like it, but this one is mine. Designers with personal sites should experiment with new layout models when they can. Before I got busy with one thing and another, I used to redesign this site practically every other week. Sometimes the designs experimented with pitifully low contrast. Other times the type was absurdly small. I experimented with the technology that’s used to create web layouts, and with various notions of web “page” design and content presentation. I’m still doing that, I just don’t get to do it as often.

Many people who’ve visited this site since the redesign have commented on the big type. It’s hard to miss. After all, words are practically the only feature I haven’t removed. Some of the people say they love it. Others are undecided. Many are still processing. A few say they hate it and suggest I’ve lost my mind—although nobody until you has suggested I simply didn’t have access to a computer and therefore didn’t know what I was designing. This design may be good, bad, or indifferent but it is not accidental.

A few people who hate this design have asked if I’ve heard of responsive web design. I have indeed. I was there when Ethan Marcotte invented it, I published his ground-breaking article (and, later, his book, which I read in draft half a dozen times and which I still turn to for reference and pleasure), and I’ve had the privilege of seeing Ethan lecture and lead workshops on the topic about 40 times over the past three years. We’ve incorporated responsive design in our studio’s practice, and I’ve talked about it myself on various stages in three countries. I’m even using elements of it in this design, although you’d have to view source and think hard to understand how, and I don’t feel like explaining that part yet.

This redesign is a response to ebooks, to web type, to mobile, and to wonderful applications like Instapaper and Readability that address the problem of most websites’ pointlessly cluttered interfaces and content-hostile text layouts by actually removing the designer from the equation. (That’s not all these apps do, but it’s one benefit of using them, and it indicates how pathetic much of our web design is when our visitors increasingly turn to third party applications simply to read our sites’ content. It also suggests that those who don’t design for readers might soon not be designing for anyone.)

This redesign is deliberately over the top, but new ideas often exaggerate to make a point. It’s over the top but not unusable nor, in my opinion, unbeautiful. How can passages set in Georgia and headlines in Franklin be anything but beautiful? I love seeing my words this big. It encourages me to write better and more often.

If this were a client site, I wouldn’t push the boundaries this far. If this were a client site, I’d worry that maybe a third of the initial responses to the redesign were negative. Hell, let’s get real: if this were a client site, I wouldn’t have removed as much secondary functionality and I certainly wouldn’t have set the type this big. But this is my personal site. There are many like it, but this one is mine. And on this one, I get to try designs that are idea-driven and make statements. On this one, I get to flounder and occasionally flop. If this design turns out to be a hideous mistake, I’ll probably eventually realize that and change it. (It’s going to change eventually, anyway. This is the web. No design is for the ages, not even Douglas Bowman’s great Minima.)

But for right now, I don’t think this design is a mistake. I think it is a harbinger. We can’t keep designing as we used to if we want people to engage with our content. We can’t keep charging for ads that our layouts train readers to ignore. We can’t focus so much on technology that we forget the web is often, and quite gloriously, a transaction between reader and writer.

Most of you reading this already know these things and already think about them each time you’re asked to create a new digital experience. But even our best clients can sometimes push back, and even our most thrilling projects typically contain some element of compromise. A personal site is where you don’t have to compromise. Even if you lose some readers. Even if some people hate what you’ve done. Even if others wonder why you aren’t doing what everyone else who knows what’s what is doing.

I don’t think you will see much type quite this big but I do think you will see more single-column sites with bigger type coming soon to a desktop and device near you. For a certain kind of content, bigger type and a simpler layout just make sense, regardless of screen size. You don’t even have to use Typekit or its brothers to experiment with big type (awesome as those services are). In today’s monitors and operating systems, yesterday’s classic web fonts—the ones that come with most everyone’s computer—can look pretty danged gorgeous at large sizes. Try tired old Times New Roman. You might be surprised.

The present day designer refuses to die.


Keep your site’s type right; let users work offline

IN ISSUE No. 350 of A List Apart for people who make websites: keep your web type looking right across browsers, platforms, and devices; let users do stuff on your site even when they’re offline.

Say No to Faux Bold

by ALAN STEARNS

Browsers can do terrible things to type. If text is styled as bold or italic and the typeface family does not include a bold or italic font, browsers will compensate by trying to create bold and italic styles themselves. The results are an awkward mimicry of real type design, and can be especially atrocious with web fonts. Adobe’s Alan Stearns shares quick tips and techniques to ensure that your @font-face rules match the weight and styles of the fonts, and that you have a @font-face rule for every style your content uses. If you’re taking the time to choose a beautiful web font for your site, you owe it to yourself and your users to make certain you’re actually using the web font — and only the web font — to display your site’s content in all its glory.

Application Cache is a Douchebag

by JAKE ARCHIBALD

We’re better connected than we’ve ever been, but we’re not always connected. ApplicationCache lets users interact with their data even when they’re offline, but with great power come great gotchas. For instance, files always come from the ApplicationCache, even when the user is online. Oh, and in certain circumstances, a browser won’t know that that the online content has changed — causing the user to keep getting old content. And, oh yes, depending on how you cache your resources, non-cached resources may not load even when the user is online. Lanyrd’s Jake Archibald illuminates the hazards of ApplicationCache and shares strategies, techniques, and code workarounds to maximize the pleasure and minimize the pain for user and developer alike. All this, plus a demo. Dig in.


Illustration by Kevin Cornell for A List Apart

CSS & Mobile To The Future | Embrace Users, Constrain Design | An Event Apart Seattle 2012 Day II

TUESDAY, 3 APRIL 2012, was Day II of An Event Apart Seattle, a sold-out, three-day event for people who make websites. If you couldn’t be among us, never fear. The amazing Luke Wroblewski (who leads a day-long seminar on mobile web design today) took excellent notes throughout the day, and shares them herewith:

The (CSS) Future is Now – Eric Meyer

In his The Future is Now talk at An Event Apart in Seattle, WA 2012 Eric Meyer talked about some of the visual effects we can achieve with CSS today. Create shiny new visual elements with no images using progressive enhancement and CSS that is available in all modern browsers.

A Philosophy of Restraint
– Simon Collison

In his A Philosophy of Restraint talk at An Event Apart in Seattle, WA 2012 Simon Collison outlined his design philosophy and how he applies it to web projects. Embrace constraints; simplicity and complexity; design aesthetic; design systems as foundations that prepare us for future projects and complexity; affordances and type; focus and content; audit and pause — prevent catastrophic failures and shine a new light on what you’ve learned with each project.

Touch Events – Peter-Paul Koch (PPK)

In his Touch Events talk at An Event Apart in Seattle, WA 2012 Peter-Paul Koch talked about touch support in mobile browsers and how to handle touch events in web development. Includes a ranking of current mobile browsers; interaction modes in mobile versus desktop (mouse) and keyboard — how do we adjust scripts to work with touch?; touch events; supporting modes; event cascade; and “stick with click.”

Mobile to the Future – Luke Wroblewski

Alas, Luke could not take notes on his own presentation. Here’s what it was about: When something new comes along, it’s common for us to react with what we already know. Radio programming on TV, print design on web pages, and now web page design on mobile devices. But every medium ultimately needs unique thinking and design to reach its true potential. Through an in-depth look at several common web interactions, Luke outlined how to adapt existing desktop design solutions for mobile devices and how to use mobile to expand what’s possible across all devices.Instead of thinking about how to reformat your websites to fit mobile screens, attendees learned to see mobile as way to rethink the future of the web.

What’s Your Problem? – Whitney Hess

In her What’s Your Problem? Putting Purpose Back into Your Projects talk at An Event Apart in Seattle, WA 2012 Whitney Hess outlined the value of learning about opportunities directly from customers. Understand the problem before designing the solution. Ask why before you figure out how. There is no universal solution for all our projects, we need to determine which practices are “best” through our understanding of problems. Our reliance on best practices is creating a world of uniform websites that solve no one’s problem. Leave the desk and interact with people. Rather than the problem solver, be the person who can see the problem.

Properties of Intuitive Pages
– Jared Spool

At An Event Apart in Seattle WA 2012, Jared Spool walked through what makes a design intuitive, why some users need different treatment, and the role of design. Current versus acquired knowledge and how to bridge the gap (how to train users, thus making your site or app “intuitive”). Redesigns and how to avoid disaster. Design skills. The gap between current knowledge and target knowledge is where design happens. Why intuitive design is only possible in small, short iterations.


Day III begins in 90 minutes. See some of you there.

Photos: AEA Seattle Flickr pool or hashtags #aea and #aeasea on Instagram.

Why I am letting my Google IO invitation expire

HI, [REDACTED]. Thanks for writing to express your concern about my failure to redeem my Google IO promo code. It’s kind of a funny story.

I received a Google IO invitation (copied and pasted below) but didn’t follow up on it because the invitation did not say anything about what Google IO is, who it is for, or why I would want to attend it (if it is an event) or use it (if it is software) or do something else with it (if it is something else).

The Google IO invitation merely gave me complicated directions to sign up for Google IO, no doubt on the assumption that I would gladly attend, download, or sign up for anything that comes from Google, even without knowing what it is; and that, as an unemployed millionaire, I would have plenty of free time to decipher and obey complicated sign-up directions without knowing anything about the product, service, or event.

One of the complexities Google mentions in their invitation letter which fails to explain anything about the product or service they want me to sign up for is that, to qualify for Google IO, I must start a Google+ account. They don’t explain what Google+ is, either, but as it happens, I already have a Google+ account.

My Google+ account is assigned to my Gmail address. But instead of writing to me there, Google wrote to me at my zeldman.com address. My zeldman.com address is actually managed via Gmail, so I should be able to log into my Google+ account whether I am signed in as my Gmail identity or my zeldman.com identity, but Google+ doesn’t work that way. Google+ only works for free Gmail accounts. It does not work for paid corporate accounts like mine. That has always seemed an odd decision to me: if you can only provide services to a subgroup of your users, why not choose the subgroup that pays? But I am not Google.

So Google wrote to my zeldman.com address, which they won’t allow me to associate with my Google+ address, to invite me to start a Google+ account (which I already have) on my zeldman.com account, which they won’t support. And if I do that (which I can’t), and some other complicated stuff, they promise that I will then be able to participate in Google IO, whatever that is.

And now they have written to warn me that my Google IO, whatever it is, will stop being offered if I don’t sign up (which I can’t) right away. And they even convinced you, my friend, to send a personal note ensuring that I don’t miss the opportunity to sign up for their unspecified product or service with the account they don’t support before the unexplained offer is terminated.

While I should be curious about Google IO and what I will miss if I fail to take advantage of the cumbersome offer, what I’m actually far more curious about is how an organization that can’t write an effective direct marketing email message has managed to become one of the most powerful corporations of the 21st century.


Hello,

We recently sent you an invitation to register for Google I/O 2012 and noticed that you have not redeemed your promo code, which will expire at midnight PDT on March 25.

[ How to register ]
1. Make sure you have a Google+ account as it is required to register. Get Google+ at http://www.google.com/+
2. Visit the registration page at
https://developers.google.com/events/register/promocode?code=[REDACTED]
3. Use Promo Code: [REDACTED]. This code can only be used once.

[ Tips to Ensure Successful Payment With Google Wallet ]

1. Make sure your Google Wallet account is tied to the same Google+ account you use to register.

2. In case your bank declines your purchase through Google Wallet, you may need to call the bank that issued your credit card and let them know that you want to make a large purchase. Some banks may decline large purchases that appear to be out of your normal purchase behavior.

3. If Google Wallet is not available in your country, please email googleio2012@google.com to have our support team process your payment.

[ Tips to Ensure Successful Registration With Google+ ]

1. Sign into your Google+ account before you try to redeem your code.

2. To ensure you have created a Google+ account, log into your Google account and go to https://plus.google.com/. If you land on a page asking you “To join, create a public Google profile.” then you don’t yet have a Google+ account and follow the instructions to create one.

3. If you have multiple Google accounts, be sure to sign out of all Google accounts and sign in with only your Google+ enabled account.

4. You can use a personal or company managed Google+ enabled account to complete your registration.

If you have any questions, please email googleio2012@google.com.

Sincerely,
The Google I/O Team

A List Apart No. 345: Responsive content: thinking beyond pages; from research to content strategy to meaningful project deliverables.

IN ISSUE NO. 345 of A List Apart, for people who make websites:

Future-Ready Content

by SARA WACHTER-BOETTCHER

The future is flexible, and we’re bending with it. From responsive web design to futurefriend.ly thinking, we’re moving quickly toward a web that’s more fluid, less fixed, and more easily accessed on a multitude of devices. As we embrace this shift, we need to relinquish control of our content as well, setting it free from the boundaries of a traditional web page to flow as needed through varied displays and contexts. Most conversations about structured content dive headfirst into the technical bits: XML, DITA, microdata, RDF. But structure isn’t just about metadata and markup; it’s what that metadata and markup mean. Sara Wachter-Boettcher shares a framework for making smart decisions about our content’s structure.

Audiences, Outcomes, and Determining User Needs

by COREY VILHAUER

Every website needs an audience. And every audience needs a goal. Advocating for end-user needs is the very foundation of the user experience disciplines. We make websites for real people. Those real people are able to do real things. But how do we get to really know our audience and find out what these mystery users really want from our sites and applications? Learn to ensure that every piece of content on your site relates back to a specific, desired outcome — one that achieves business goals by serving the end user. Corey Vilhauer explains the threads that bind UX research to content strategy and project deliverables that deliver.


Illustration by Kevin Cornell for A List Apart

State of the web: of apps, devices, and breakpoints

IN The ‘trouble’ with Android, Stephanie Rieger points out the ludicrous number of Android screen sizes on a typical UK client’s website and comes to this conclusion:

If … you have built your mobile site using fixed widths (believing that you’ve designed to suit the most ‘popular’ screen size), or are planning to serve specific sites to specific devices based on detection of screen size, Android’s settings should serve to reconfirm how counterproductive a practice this can be. Designing to fixed screen sizes is in fact never a good idea…there is just too much variation, even amongst ‘popular’ devices. Alternatively, attempting to track, calculate, and adjust layout dimensions dynamically to suit user-configured settings or serendipitous conditions is just asking for trouble.

I urge you to read the entire article—it’s brief yet filled with rich chocolatey goodness.

Responding to it, Marc Drummond concludes that responsive web design default breakpoints are dead and urges designers to “use awkwardness as your guideline, not ephemeral default device widths” and return to fluid design. (I believe he may actually be thinking of liquid layout—the kind we practiced back in the early mid-1990s when cross-platform and multi-manufacturer desktop screen sizes and pixel-per-inch ratios—not to mention strong user font, size, and color preference options—made fixed-width layout design challenging if not impossible. As I understand fluid design, it is merely another word for responsive design, in that it relies on CSS3 media queries set to breakpoints.)

We’ve lost our compass

Rieger and Drummond are hardly alone in feeling that “our existing standards, workflows, and infrastructure” cannot support “today’s incredibly exciting yet overwhelming world of connected digital devices” (futurefriend.ly) and that something new must be done to move the web forward. And of course ppk has been warning us about the multiplicity of platforms and viewports on mobile since 2009.

Agreed: that is an exciting and challenging time; that fixed width layouts do not address, and adaptive layouts (multiple fixed-width layouts set to common breakpoints) do not go far enough in addressing, the challenges posed by our current plethora of mobile screen sizes, zoom settings, embedded views (i.e. “browser” windows inside app windows, often with additional chrome) and what Rieger calls “the unintended consequences” that occur as these various settings clash in ways their creators could not have anticipated.

As consumers, we’ve all had the experience of seeing the wrong layout at the wrong time. (Think of a site with both mobile and desktop versions—whether these versions are triggered by CSS3 media queries or JavaScript and back-end magic is beside the point because technology is beside the point—good user experience is all this is supposed to be about. On a Twitter app on a mobile device, the user follows a link; the link opens in the browser built into the Twitter app. Which version of the site does the user see? The mobile one or the desktop? Often it is the desktop, and that can be a problem if the app’s version of the browser does not permit zoom. Even if it is a mobile version, it may be the wrong mobile version, or it may not fit comfortably inside the app’s browser window.) Considering our own experiences and reviewing Rieger’s chart, it is easy to share Drummond’s conclusion that breakpoints are dead and that all sites should be designed as minimally as possible.

If breakpoints are dead, responsive design is dead

Of course, if breakpoints are dead, responsive design is dead, because responsive design relies on breakpoints both in creative workflow and as a key to establishing user-need-and-context-based master layouts, i.e. a minimal layout for the user with a tiny screen and not much bandwidth, a more fleshed-out one for the netbook user, and so on.

But responsive design is not dead; it has only begun. It is not a panacea but was never intended to be. It is simply the beginnings of an approach.

I respect those colleagues who say breakpoints are dead, understand how they reached this conclusion, and am eager to see where it takes them in the coming months as they experiment with new methods, perhaps developing wonderful and unforeseen best practices. I hope design will be a brilliant part of these new methods, not something that gets abandoned to create a bland but workable lightweight experience for all.

But I also believe it is possible to draw a different conclusion from the same data. It is even possible, I believe, to say the present data doesn’t matter—at least not in the long run.

Tale of the chart

There was a time in the late 1990s when industrious web designers showed how atrocious CSS support was in browsers. Eric Meyer’s Master Compatability Chart for Web Review, formerly at http://www.webreview.com/pub/wr/style/mastergrid.html, was one of the best, but is no longer available for your historical viewing pleasure—not even at the mighty Wayback Machine. That’s too bad, as it would have perfectly illustrated my point. The chart used a variety of colors to show how each detail of the entire CSS specification was or was not supported (and if supported, whether it was supported correctly and completely, partially and correctly, partially and somewhat incorrectly, or completely incorrectly) in every browser which was available at the time, including, if memory serves, close to a dozen versions of Netscape, Explorer, and Opera.

Looking at that chart induced nausea and vertigo. It was easy to draw the conclusion that CSS wasn’t ready for primetime. (That was the correct conclusion at the time.) It was also easy to look at the table and decide that table layouts and font tags were the way to go.

That’s what most designers who even bothered looking at Eric’s chart decided, but a few (Eric and me included) drew a completely other inference. Instead of trying to memorize all the things that could go wrong in each browser, we created general rules for what worked across all browsers (e.g. font-size in px, floats for layout) and advocated design based on the things that work. This, I believe, is exactly what the futurefriend.ly and Move the Web Forward folks are doing now: trying to figure out commonalities instead of bogging down in details. (This is why some in our community have labeled futurefriend.ly and Move the Web Forward “WaSP II.”)

The other inference Eric, I, and others in the 1990s drew from Eric’s chart was that browser makers must be petitioned to support CSS accurately and correctly. We and many of you reading this engaged in said petitioning, and thanks largely to help from with the browser engineering community (from people like Tantek Çelik and Chris Wilson and organizations like Mozilla) it came to pass.

Of mice and markets

We cannot, of course, petition all the makers of, say, Android devices to agree to a set of standard breakpoints, because there are over 500 different Android devices out there, many of which will fail in the coming months—or if not outright fail, simply be replaced in the course of planned obsolescence AKA upgrading that drives the hardware segment. And each new product will in turn introduce new incompatibilities (AKA “features”).

In the short run it’s going to be hell, just as the browser wars and their lack of support for common standards were hell. But it is the short run.

500 standards is no standard. Give a consumer 500 choices and the price-driven consumer picks what comes with her plan, while the selective consumer begins gravitating toward a handful of emerging market leaders. Eventually this nutty market will stabilize around a few winning Android platforms (e.g. Kindle Fire) and common breakpoints will emerge. What The Web Standards Project achieved with browser makers, the market will achieve with phones.

Until that time, designers certain can abandon breakpoints if they can find a way to do good design under purely fluid conditions—design that pleases the user, satisfies the client, and moves the industry forward aesthetically. But designers who persist in responsive or even adaptive design based on iPhone, iPad, and leading Android breakpoints will help accelerate the settling out of the market and its resolution toward a semi-standard set of viewports. This I believe.

When I see fragmentation, I remind myself that it is unsustainable by its very nature, and that standards always emerge, whether through community action, market struggle, or some combination of the two. This is a frustrating time to be a web designer, but it’s also the most exciting time in ten years. We are on the edge of something very new. Some of us will get there via all new thinking, and others through a combination of new and classic approaches. Happy New Year, web designers!

Download in the Dumps (AKA Killing Me Softly With Adobe)

In which our intrepid reporter is unable to download and reinstall Adobe software he owns and paid for because Adobe.

I REMOVED Adobe CS5 from my studio Mac after it took on water damage during tropical storm Irene. Just as I was going to replace the machine, the water damage seemed to go away. (It actually never did go away, and as I write this it’s pretty bad, but for a week it seemed okay so I didn’t order a replacement.) As I need Photoshop this morning to work on a website, and as I’m still a registered CS5 owner, I logged into Adobe.com to download a “Trial” version of Photoshop. For all the good it did me, I could have eaten my own head.

Clicking “Download Photoshop” put an “Install Adobe Download Assistant” app on my desktop instead of downloading Photoshop. To download Photoshop from the web, you can’t just download Photoshop from the web. You have to download an installer that installs a downloader. There’s no benefit to the user for jumping through this extra hoop, but I guess Adobe Corporate wanted to show off its AIR-based software.

To download trial versions of Creative Suite software, you need to install the Adobe Download Assistant. After installation, the Adobe Download Assistant will start your product download automatically,

the website says. This is a lie.

Once installed, the downloader asks me to sign in again. Which is only logical. After all, between the time I clicked “download Photoshop” as a signed-in user and now, I might have been knocked unconscious by Photoshop pirates. Without a redundant double sign-in, the pirates would win.

So I type in my login and password again—same as I just did on the website to download this meshugah downloader installer in the first place—and guess what? Adobe says my login and password don’t match.

The login and password I used to download the installer downloader are unacceptable to the downloader. If you’re following this gibberish, God bless. If not, Adobe is telling me that the login and password I just used to install the downloader are no good.

Like a pimp pretending to help a runaway teen, a link in the unhelpful downloader now asks, “Having trouble signing in?” There being nothing else to do, I click the link, which takes me to a “Reset your password” panel. Only I can’t reset my password in the “Reset your password” panel; I’ll only be able to reset my password on a custom web page, whose address I will only learn once I receive an email from Adobe sending me a custom link. Excitingly, that “Reset your password” page (the one that will actually allow me to reset my password) will be generated on the fly via Adobe’s famous and ultra-reliable ColdFusion software.

I’ve now lost 30 minutes of work time but Adobe is not done with me. Oh, no. This is where the fun begins.

I spend long minutes reflexively checking my email, like a junkie scanning the corner in search of his busted dealer. The custom link email finally arrives, but the link never works. (It’s the cream of the jest!) Here is a screenshot of Adobe’s Chinese Japanese website, powered by ColdFusion, which is unable to generate a “Reset your password” page, allowing me to reset my password and use the AIR-based downloader software to download the software I already own.

Mission: not accomplished. Total time wasted: 45 minutes (not counting the writing of this blog post, which I do in the faint hope that Adobe will improve its customer experience). I still have no working copy of Photoshop and it’s clear I won’t get one today. The installer disks are gone from my office because I’m moving to a new studio soon and have been packing important pieces like installation disks ahead of time. (After all, I had reasoned, Adobe lets you download software from its website, so why keep disks around?)

To be fair, Hurricane Irene was not Adobe’s fault, and lots of people suffered much worse than a water-damaged iMac. Nor is water damage to my Mac Adobe’s fault. My decision to remove CS5 from the Mac was based on fear that if the Mac died and I hadn’t removed CS5, I would not be able to install it on the replacement machine I intended to purchase, as Adobe licensing (and the software itself) requires you to uninstall from Machine A before installing on Machine B. Adobe CS5 costs more than the computer I intended to buy, so it seemed prudent to remove it from the damaged machine, but of course I regret that decision now, because Adobe’s website won’t let me update my member information, and its downloader won’t let me download.

So I’ll be working from home tonight, doing what I should have done today. Five little letters: ADOBE.

Breathless Update!

Apparently Adobe’s entire membership section, powered by ColdFusion, is now down. Trying to do anything inside the member section leads to a Chinese “Sorry” page. This might be why the “downloader” failed to authorize my credentials. How much simpler it would be if Adobe simply provided a link to download its software (like in the old days) instead of forcing registered users to jump through broken hoops.