UNDERDOG of PERFECTION

A few weeks ago, I tweeted this:
[blackbirdpie id=”111598134282551297″]

Today at lunch SLP and I were discussing digital literacy and I was reminded of this tweet. On reflection, I’d amend it slightly. Being a computer expert isn’t 90% not being afraid of the unknown, as much as it’s 90% not being afraid of screwing up.

Everybody screws up. The only way you can avoid screwing up is by not doing anything in the first place. (Which is, I think, a kind of failure itself.) So, are you going to face that inevitability with confidence, or are you going to deny it by not even trying?

This doesn’t just apply to computers. It applies to everything. Computers (and other technological gadgets) are just perhaps the most obvious place in modern life where the fear of failure clearly manifests.

There’s something related to this fear and avoidance of failure: a lack of mindfulness. Again, not something specific to computers. When we are fearful, we can get absorbed in that fear, and forget to pay attention to what’s happening around us. Ironically, it is precisely that fear, leading to a lack of mindfulness, that can often be what leads to failure. By fearing failure, we make failure more likely.

On the other hand, by facing the potential for failure with confidence, knowing that failure isn’t doom, we can clear distraction from our minds, remove the clouds of confusion, and see what is before us, which is the most important key to accurately assessing a problem and finding a solution.

More specifically, when confronted with an unfamiliar technological interface, it’s easy to get overwhelmed, and to panic, and to either screw up or give up. But technology is nothing to fear. It’s merely a tool. Approach it with confidence, take your time, try things. Don’t be afraid to “break it.” If something could be broken so easily, it’s probably not worth bothering with anyway. It takes a lot to “break” a computer, generally involving a sledgehammer or being dropped from a 5th-story window, not a few errant mouse clicks.

There’s another benefit to mindfulness and confidence: it makes seeking help easier. I’ve worked tech support, and in that job there’s nothing more frustrating than having a user tell you something “doesn’t work,” with no further elucidation. At worst, it leads to the assumption that the user isn’t trying (or is stupid), and even at best it’s unproductive. But when you’re confident enough not to become overwhelmed, and mindful enough to pay attention to the details of what you’re doing, you can provide a much more thorough explanation of the problem to the person who’s trying to help you.

So, don’t be afraid. Your computer can’t hurt you. More importantly, you can’t hurt it. Take your time and, if necessary, a deep breath. Observe. Think. And if you screw up, try something else. It won’t hurt.

Like many Apple enthusiasts, I spent much of the day yesterday updating software. Mac OS X 10.7.2, iTunes 10.5, iOS 5, and… iCloud. I’ve been relying on MobileMe for a little over a year to keep my mail, notes and calendars (mostly) in sync. I was not an “early adopter” with MobileMe, so I escaped the first-day glitches that promted Steve Jobs to declare the system’s launch “not our finest hour.”

Less than a day into my experience with iCloud, I’d have to say that this launch also is not Apple’s “finest hour.” There have been numerous complaints today about iCloud mail outages (following what I have observed as several days of flaky MobileMe mail performance). But without a doubt the biggest issue for me personally has been related to iCal.

After completing the iCloud transition yesterday, to my dismay I discovered that all of my iCal events were duplicated! My MobileMe account and my iCloud account were both showing up, with all of the same events. Now, in retrospect, the correct thing to do would probably have been to go to Preferences > Accounts and just delete the MobileMe account from my iCal configuration. But is that what I did? Why, no, of course not! I proceeded to delete all of my individual MobileMe calendars. That appeared to do the trick. The iCloud calendars were still there, and every event was just showing up once.

But then this morning I sat down at my computer and discovered — to my horror — that everything was gone. At some point yesterday, when I wasn’t looking, MobileMe and iCloud synced up, and deleted all of my events.

Time Machine to the rescue!

I opened up my Time Machine backup from yesterday afternoon… sometime just before I had made the iCloud transition. I drilled down to [home]/Library/Calendars. (Note that Library is now a hidden folder, but I have my system set to show hidden files and folders*.) I found the multitude of .ics files that represent each individual calendar event, and dragged them into iCal. At first, things seemed great… until I noticed that one by one, the events started disappearing from my calendar again! Apparently iCloud didn’t like having these events show up in the calendar in this way — probably because it recognized them as being events I had “deleted” yesterday — so it “helpfully” removed them again.

AAAAARGH!!! How am I supposed to get these events back into iCal when iCloud just deletes them as soon as they’re added?! Then it hit me… you don’t have to put events into iCloud calendars.

iCal also allows you to created local calendars (“On My Mac”). My solution was to — temporarily — create new “On My Mac” calendars, add the events to those calendars, then export those calendars and import them back into the iCloud calendars. (Then the “On My Mac” calendars can be deleted.) It worked!

Here are step-by-step instructions to do what I did, in case you’ve found yourself in the same conundrum.

1. Find the old calendars in your Time Machine backup. You could open Time Machine to do this, but I like to just explore the disk in the Finder. (The remaining instructions assume you’re taking my approach.) The most important thing is to determine the date and time when your last “good” iCal backup would be. Drill down into that backup to your home directory (that would be something like [drive name]/Users/[username]), and then to Library/Calendars. (Remember that Library may be hidden; if so, see the footnote below.) You’ll see one or more weirdly-named folders. Each of these represents a separate calendar in iCal. Inside each is a directory called Events, and inside that are all of the events on that calendar, each with a filename ending in .ics. If you have more than one calendar folder, you can tell which calendar this is by selecting one of the events in the Finder; its icon will show its date and title. Keep this folder open; you’ll need to come back to it in a later step.

2. Create a new “On My Mac” calendar in iCal. Go to File > New Calendar > On My Mac. Call this calendar whatever you want. If you have multiple calendars, like I do, you’ll need to repeat this process for each of them separately (to keep your events from all getting jumbled together in one calendar).

3. Set the new “On My Mac” calendar as the default calendar. This can be found under iCal > Preferences > General > Default Calendar. When you drag events into iCal, it automatically assigns them all to the default calendar, so this is a pretty important step. Reassigning the events to a new calendar once they’ve already been imported can be a pain.

4. Drag all of the backed-up events into iCal. Go back to the Time Machine backup window you left open in step 1, select all of the .ics files, and drag them into the iCal window. Depending on how many there are, it may take a while for them all to load. Once they’re in, proceed to the next step.

5. Export the “On My Mac” calendar. It can be tricky to make sure you’re getting iCal to export the correct events. Click the Calendars button in the upper left of the iCal window (on the brown “binding” of the cutely skeuomorphic interface), find the “On My Mac” calendar that you’ve added all of the events to, and right-click (Control-click) that calendar to get a contextual menu. Click Export... and follow the prompts. I recommend saving the exported file to your desktop.

6. Set the appropriate iCloud calendar as the default calendar. This is a repeat of step 3, but this time you’re changing it to the iCloud calendar you want the events to be loaded into.

7. Import the exported calendar file into the iCloud calendar. Go to File > Import > Import... and locate the file you created in step 5.

8. Delete the “On My Mac” calendar. Once you’ve completed the import (and have confirmed that the events are not disappearing), you can safely delete the “On My Mac” calendar you created. Click the Calendars button in the brown “binding” again, right-click (Control-click) the “On My Mac” calendar, and select Delete from the contextual menu.

9. There’s no step 9!

* To get your system to show hidden files and folders, open up Terminal and type this: defaults write com.apple.Finder AppleShowAllFiles TRUE then hit Return, type this: killall Finder and hit Return again.

When I’m meeting with clients and collaborators to discuss building websites, I like to make analogies. As the representative “tech geek” in most of these meetings, I find them the best way to convey the meaning of esoteric technical concepts, even if they’re sometimes rather strained. (I make car analogies a lot, for some reason.)

The other day I was explaining my two favorite (and overlapping) current trends in web design: Responsive Web Design and Mobile First. (How convenient that A Book Apart has books on both topics. I mention A Book Apart a lot in meetings, too.)

Suddenly in the meeting it occurred to me that mobile-first web design has an analogy with the production of most of the Beatles’ albums. In the early and mid-1960s, popular music was released primarily in mono format. Most of the market for these albums was listening to them on small mono turntables, not expensive stereo equipment. (And apparently at the time mono equipment could not properly play back stereo records.)

When the time would come for the Beatles to prepare the final mixes of their albums, the band members would join George Martin in the studio and carefully perfect the mono mixes. Then the boys would all head to the pub and leave George Martin alone to hastily assemble the stereo mixes as an afterthought. (And, frankly, it shows.) But somewhere along the way (in 1968, specifically) stereo had caught on enough that the last few albums (Yellow Submarine, Abbey Road and Let It Be) were mixed in stereo first.

The web is kind of like those Beatles albums. Up until now, websites were designed for “mono”: a computer screen. Eventually enough people started using the web “in stereo” (on mobile devices) that mobile versions of websites became necessary, but they were a hasty afterthought. But we are presently arriving at a time when a lot of people are doing a lot, if not most, of their web browsing on mobile devices, of a variety of shapes and sizes and capabilities. It’s starting to make sense not just to consider mobile versions, but to start with the mobile design.

Fortunately, we’re also at the point (to, as usual, strain the analogy) where the mono equipment can play back stereo records. There’s no need to design two separate websites, one for mobile and one for desktop. Responsive web design (via the magic of CSS3 media queries) lets us build one site that works on any screen.

But why mobile first? I see two main benefits, stemming from one main factor: the small screen size. By targeting the smallest screens first, you 1) focus on what’s most important, and 2) can more easily see what’s not important… or, at least, less important.

Mobile first fits well with the model of best-practices web design I like to promote. The decisions you make to create the best mobile experience will generally create the best experience, period. Granted, the needs of a visitor on their way to your office and checking your site on their smartphone may well differ from those of the visitor casually browsing your site on their iPad in bed, or from the customer placing an order from their office PC, but it’s easy enough to enhance the experience for users of those larger displays after the core needs of the mobile user have been addressed.

It’s an exciting time to be a web designer. Things are really starting to… come together.

(Come on, you knew I had to end with a Beatles reference.)

Steve Jobs, 1955-2011

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.