Menu

Browsers

My other iPad is a Kindle

The new Kindle has a lot going for it. It’s inexpensive compared to a full-featured tablet computer like the iPad; you can slip it in your back pocket, where it’s more comfortable than an old-style paperback; and it includes a Webkit browser. This last point is where folks like us start to give a hoot, whether we’re fans of epub reading or not.

The flavor of Kindle’s browser concerns us because it affords us the ability to optimize the mobile viewing experience with a single line of markup. You can see this in action in the photo at the head of this article (published and discussed on Flickr).

I made no tweaks for Kindle per se; the Kindle is simply responding to a line of markup I’ve been putting into my web pages since 2007—namely, the viewport meta element, which controls the width of the viewport, thus enabling mobile devices with a limited number of pixels to focus all available pixels on your site’s core content (instead of, for instance, wasting part of the small screen on a background color, image, or gradient). The technique is as simple as web design gets:

meta name="viewport" content="width=770"

(Obviously, the value of “width” should be adjusted to match your site’s layout.)

I learned this little trick from Craig Hockenberry’s Put Your Content in My Pocket (A List Apart, August 28, 2007), which I naturally recommend to any designer who hasn’t seen it.

I guest-edit .net magazine

A List Apart and .net magazine have long admired each other. So when .net editor Dan Oliver did me the great honor of asking if I wished to guest edit an issue, I saluted smartly. The result is now arriving in subscriber post boxes and will soon flood Her Majesty’s newsstands.

In .net magazine Issue No. 206, on sale 17th August in UK (and next month in the US, where it goes by the name “Practical Web Design”), we examine how new standards like CSS3 and HTML5, new devices like iPhone and Droid, and maturing UX disciplines like content strategy are converging to create new opportunities for web designers and the web users we serve:

Exult as Luke Wroblewski shows how the explosive growth of mobile lets us stop bowing to committees and refocus on features customers need.

Marvel as Ethan Marcotte explains how fluid grids, flexible images, and CSS3 media queries help us create precise yet context-sensitive layouts that change to fit the device and screen on which they’re viewed.

Thrill as Andy Hume shows how to sell wary clients on cutting-edge design methods never before possible.

Geek out as Tim Van Damme shows how progressive enhancement and CSS3 make for sexy experiences in today’s most capable browsers—and damned fine experiences in those that are less web-standards-savvy.

You can also read my article, which asks the musical question:

Cheap, complex devices such as the iPhone and the Droid have come along at precisely the moment when HTML5, CSS3 and web fonts are ready for action; when standards-based web development is no longer relegated to the fringe; and when web designers, no longer content to merely decorate screens, are crafting provocative, multi-platform experiences. Is this the dawn of a newer, more mature, more ubiquitous web?

Today’s web is about interacting with your users wherever they are, whenever they have a minute to spare. New code and new ideas for a new time are what the new issue of .net magazine captures. There has never been a better time to create websites. Enjoy!

HTML5, CSS3 default templates

Free for use in all web projects, professional or personal, HTML5 Reset by Monkey Do! is a set of HTML5 and CSS templates that jumpstart web development by removing the styling native to each browser, establishing basic HTML structures (title, header, footer, etc.), clearing floats, correcting for IE problems, and more.

Most of us who design websites begin every project with bits and pieces of this kind of code, but developer Tim Murtaugh, who created these files and who modestly thanks everyone in the universe, has struck a near-ideal balance. In these lean, simple files, without fuss or clutter, he manages to give us the best-practices equivalent of everything but the kitchen sink.

Tim Murtaugh sits beside me at Happy Cog, so I’ve seen him use these very files (and earlier versions of them) to quickly code advanced websites. If you’re up to speed on all the new hotness, these files will help you stay that way and work faster. If you’re still learning (and who isn’t?) about HTML5, CSS3, and browser workarounds, studying these files and Tim’s notes about them will help you become a more knowledgeable web designer slash developer. (We need a better name for what we do.)

My daughter calls Mr Murtaugh “Tim the giant.” With the release of this little package, he earns the moniker. Highly recommended.

SlideShowPro adds HTML5

Most of us web folk are hybrids of one sort or another, but Todd Dominey was one of the first web designers to combine exceptional graphic design talent with serious mastery of code.

Being so good at both design and development that you could easily earn a fine living doing just one of them is still rare, although it looks like the future of our profession. One of the first serious designers to embrace web standards, Todd was also one of the few who did so while continuing to achieve recognition for his work in Flash. (Daniel Mall, who came later, is another.)

Finally, Todd was one of the first—along with 37signals and Coudal Partners—to abandon an enviably successful client services career in favor of full-time product development, inspiring a generation to do likewise, and helping bring us to our current world of web apps and startups.

A personal project that became an empire

In Todd’s case, the product was SlideShowPro, a project he designed for himself, which has grown to become the web’s most popular photo and video slideshow and gallery viewer. When you visit a photographer’s portfolio website, there’s an excellent chance that SlideShowPro powers its dynamic photo viewing experience. The same is true for the photo and video gallery features of many major newspaper and magazine sites, quite possibly including your favorites.

But deliberate lack of Flash support in the iPad and iPhone, while lauded here on February 1, 2010 as a win for accessible, standards-based design (“Not because Flash is bad, but because the increasing popularity of devices that don’t support Flash is going to force recalcitrant web developers to build the semantic HTML layer first”), presented a serious problem for developers who use SlideShowPro and readers who enjoy browsing dynamic photo and video galleries.

SlideShowPro Mobile is an entirely new media player built using HTML5 that doesn’t require the Flash Player plugin and can serve as a fallback for users accessing your web sites using these devices. But it’s not just any fallback — it’s specially designed for touch interfaces and smaller screen sizes. So it looks nothing like the SlideShowPro player and more like a native application that’s intuitive, easy to use, and just feels right.

The best part though is that because SlideShowPro Director (which will be required) publishes the mobile content, you’ll be able to provide the mobile alternative by simply updating the Flash Player embed code in your HTML documents. And just like when using the SlideShowPro player, because Director is behind the scenes, all your photos will be published for the target dimensions of these devices — which gives your users top quality, first generation images. The mobile player will automatically load whatever content is assigned to the Flash version, so the same content will be accessible to any browser accessing your web site.

A public beta will be released in the next weeks. Meanwhile, there is a video demo. There’s also an excellent Question and Answer page that answers questions you may have, whether you’re a SlideShow Pro customer or not. For instance:

Why mobile? Why not desktop?

We believe that (on the desktop) Flash is still the best delivery method for photo/video galleries and slideshows for it provides the most consistent user experience across all browsers and the broadest range of playback and customization options. As HTML5 support matures across all desktop browsers, we’ll continue to look into alternate presentation options.

Bit o’ nostalgia for the old folks

And now, Google

THE long-planned inevitable has now been announced. With open-source-licensed web fonts, web font hosting, and add-a-line-to-your-header ease of configuration, Google has joined Typekit, Font Squirrel, Ascender, Font Bureau and others in forever changing the meaning of the phrase, “typography on the web.”

The Google Font Directory lets you browse all the fonts available via the Google Font API. All fonts in the directory are available for use on your website under an open source license and served by Google servers.

Opera loves my web font

And so do my iPhone and your iPad. All it took was a bit o’ the old Richard Fink syntax and a quick drive through the Font Squirrel @Font-Face Kit Generator (featuring Base 64 encoding and SVG generation) to bring the joy and wonder of fast, optimized, semi-bulletproof web fonts to Safari, Firefox, Opera, Chrome, iPhone, and Apple’s latest religious device.

Opera hates my web font

So I’ve wanted to use a condensed, bold Franklin typeface for my site’s headlines since, well, forever. So I bought Fontspring’s fine Franklin Gothic FS Demi Condensed and licensed it for @font-face use for a mere $2.99, an incomparable value.

It looks great in Safari, Chrome, and Firefox, but not so nice in the latest version of Opera, where it resembles the inside-out test monkey in Cronenberg’s “The Fly.” (Okay, okay, it looks like a ransom note, but the monkey simile was more picturesque.)

And this, my friends, is why Typekit exists. Because even when you find a great font that’s optimized for screen display and can be licensed for CSS @font-face use, guess what? There is almost always some glitch or bug somewhere. And Typekit almost always seems to find and work around these bugs. It’s the kind of grueling task designers hate dealing with, and Typekit’s team loves solving.

If this were a client site, I’d switch to Typekit, or try licensing a different vendor’s Franklin, or (if neither of those options proved satisfactory) dump web fonts altogether and use Helvetica backed by Arial instead. But as this is zeldman.com, I’d rather nudge my friends at Opera to look into the problem and fix it. This will make browsing zeldman.com in Opera a somewhat weird experience, but hopefully it will help all Opera users in the long run.

Implementation Notes and Details

I haven’t made an SVG version yet, so the web fonts don’t work in iPhone or iPad.

iPhone and iPad see normal weight Helvetica instead of bold Helvetica, because if I leave “font-weight: bold” in the CSS declaration, Firefox double-bolds the font. This is not smart of Firefox. Fixed via technique below.

In order to match the impact of the previous Helvetica/Arial bold, I boosted the font-size from 25px to 32px. (This also helps smooth the font. Web fonts need more help in this regard than system fonts.)

Camino ignores @font-face and supports the first system font in the font stack, Helvetica Neue (correctly styled bold).

The dog ate my bookmarks

It’s been years (or is it weeks?) since something odd, implausible, and inexplicable happened to one or more of my Apple computers that doesn’t happen to anyone else’s. You know you want to hear this.

So yesterday morning I’m in my hotel, finishing some work on my laptop before leaving for the airport, when MobileMe alerts me that in order to sync the bookmarks on my laptop, it will need to delete some and add some. I click OK. A few seconds later, I have no bookmarks in Safari.

That’s strange, but it’s a bit liberating, too. I feel lighter. That kink in my neck is gone.

Heck, I can re-create the few bookmarks I really need and do without the rest, right? (Besides, I imported my Safari bookmarks into Chrome a few weeks ago, and I sync Chrome bookmarks via Google, so the bookmarks aren’t really gone, they’re just gone from Safari.)

I re-create five or six bookmarks in my laptop’s Safari bookmarks bar, close my laptop, and fly home.

Here’s where it gets weird.

At home, after midnight, sleepless, jetlagged, I turn on my iMac. MobileMe wants to sync my bookmarks. It says it will delete quite a few of them and create a handful of new ones. There is no option to send my iMac’s bookmarks to MobileMe instead. There is no option not to sync. I can skip sync for now, but eventually I’ll have to sync, and that means I’ll have to let MobileMe wipe my many old Safari bookmarks off all my computers. No sense delaying the inevitable.

I click OK.

My old bookmarks are gone, but the new ones I created on my laptop have not been sync’d. I have no bookmarks.

I start re-creating them from scratch, and as I create them, they disappear.

I create a Flickr bookmark. It works. I create a zeldman.com admin bookmark. When I look up, the Flickr bookmark has disappeared. I create a Twitter bookmark. When I look up, the zeldman.com admin bookmark has disappeared. A moment later, the Twitter bookmark has disappeared.

I begin quitting Safari immediately after creating a bookmark (in order to force Safari to save it). This seems to work. When I re-start Safari, the bookmark I just created has been saved. I do this six times in order to create and save the few bookmarks I really need in order to work.

I don’t bother re-creating the dozens of JavaScript bookmarklets I use daily. I figure I can do those in the morning. I verify that Safari now contains six bookmarks. I run a backup via SuperDuper and go to bed.

In the morning, my bookmarks bar is blank again. Overnight, all my bookmarks have disappeared.

It can’t be from syncing via MobileMe, because the computer should have gone to sleep as soon as the backup finished (and it was asleep when I woke up this morning).

At this point all I can figure is that Apple wants me to switch to Chrome.