Ajax offers the ability to avoid both needless browser behavior like page reloads and useful browser behavior like error handling. When good web apps go bad, Peter Quinsey’s guidelines and techniques can help you and your users stay informed and productive.
Sooner or later, nearly all web projects fall afoul of simple, preventable problems—problems like building the wrong features or creating a platform that can’t be upgraded. A proper process can help you manage scope, develop site features that actually match your objectives, and catch fatal flaws before your site is produced.
Standardistas adore the Mozilla Firefox browser for its advanced support of web standards. (How good is it? The Web Standards Project considered declaring victory and closing shop when Netscape Corp. announced in 1999 that it would heed our advice and dump its non-compliant software in favor of the Gecko rendering engine that powers Firefox today.)
Though Firefox and related Mozilla browsers deserve credit for their unsurpassed handling of everything from the Document Object Model to MIME types, Firefox’s way with text leaves much to be desired, as the following screen shots show. Indeed, if reading is mostly what you do on the web, and if accurate typography makes reading more of a pleasure and less of a strain, then Apple’s Safari is superior to Firefox.
Lucida, Test One: with genuine italics
Zeldman.com is designed to be read in Lucida Grande, and the site originally listed “Lucida Grande” first in its style sheet. Alas, Lucida Grande lacks true italics. Fortunately, Lucida Sans has them. In a version of our style sheets used to capture the following screen shots, we’ve listed Lucida Sans first, Lucida Grande second, and substitutes thereafter. Both browers handle the site like a dream—but it is only a good dream in Safari. Open the screen shots in tabs:
In Firefox, why does the text “now in its second edition. I can’t” display midway between roman and bold, and why is it so poorly antialiased? Apparently, Firefox bungles roman text that follows italics.
In Firefox, why doesn’t hyphenation work? My gosh, people, it’s nearly 2007. IE5/Mac supported hyphenation.
Lucida, Test Two: using a font that lacks italics
Remember: Lucida Grande does not have italics; Lucida Sans does. But as Test One showed, Firefox can’t handle Lucida Sans correctly. So we’ve revised the style sheet. With Lucida Grande listed first in the style sheet, and Lucida Sans deleted, Safari still trounces Firefox. The experience of reading text is smoothly beautiful in Safari, much less so in Firefox.
Both browsers fake the italics. But Firefox does the job crudely: a child could tell that its “italics” are faked. (Firefox slants the roman text.) By contrast, Safari fakes its italics so well (by substituting a true italic from the next available listed font that contains one) that only graphic designers and type hounds will realize that the font they’re viewing contains no true italics. See reader comments for delicious details.
In Firefox, hyphenation still does not work.
It’s worth pointing out that these tests were done on Macintosh computers, which are known for their superior handling of text, and that Lucida is not some strange face chosen to prove a point. It is the default font in Mac OS X (not to mention on apple.com). Moreover, Lucida Sans Unicode, the first Unicode encoded font, shipped with Windows NT 3.1 and comes standard with all Microsoft Windows versions since Windows 98.
When I showed a friend and fellow designer these simple tests as I was working on them, he asked if I had reported “the bug” to the makers of Mozilla. But as I count it, there are multiple, overlapping Firefox bugs happening here—too many to fit into a bug-report form. I suspect that the problems have to do with Mozilla’s reliance on its cross-platform display environment. If you scuttle what an individual operating system does well in favor of what a cross-platform environment does poorly, you get what we’re seeing here. It’s not good enough.
Inferences for best practices
If your content will sometimes include italicized text, you naturally want to specify a font that contains italics. That’s just common sense. Unfortunately, as our screen shots have shown, common sense works against you here, because Firefox, although superior to other browsers in many ways, handles text like a drunken fry-cook.
When you specify the font that contains genuine italics (as we did in Test One), Firefox mishandles the roman text that abuts italicized words. When you replace that font with one that contains no italic (Test Two), Firefox fakes the italics crudely, but overall display and legibility are better than the unusable results of Test One.
Obviously there are fewer problems if you limit your website to Verdana and Georgia, but more constraints on typography are not what the web needs.
Discussion is now closed. Thanks to all who shared.
The fault lies not with Basecamp or Boxes & Arrows or JPG. Nor is it strictly because you’re using an Intel Mac. Camino, Firefox, and Opera still let you upload images over http. The problem is Safari. But not every Intel-Mac-wielding Safari user suffers from it. Many continue to upload files after upgrading to 10.4.8. They glance pityingly at you out their passenger windows as they speed past.
What is the problem? You’re a web designer. As a web designer, you’ve used a third-party product like Safari Enhancer to disable caching in your browser.
If you don’t disable caching in your browser, then Safari becomes kind of useless to you as a web development tool, because Safari hangs onto files like a junkyard dog clomps onto a postman’s thigh. Safari will hold onto outdated CSS, outdated text, outdated images. You’ll quit and restart. You’ll check your SFTP settings repeatedly, wondering why you keep uploading updated content to your web project, but Safari keeps showing you outdated content.
Safari shows outdated content for hours after other browsers (even browsers with caching enabled) have recognized that something changed. Safari does this because it makes browsing faster for ordinary users who are not web designers. It works. Unfortunately, what makes Safari fast and fun for ordinary users makes it a pain for web designers—unless they disable caching.
Before 10.4.8, you could disable caching in Safari and still upload files over http. After 10.4.8, you can’t. It’s not a feature, it’s a bug. Until Apple fixes it, you can leave caching disabled in Safari and use Firefox, Camino, or Opera as your default browser—or re-enable caching, and add an hour of Stupid Time to your web development and testing process.
[tags]web design, apple, mac, os x, safari, browsers, web development[/tags]
We are now offering new T-shirt designs that tell the world you are a rebel, a maverick, an original in a world of copies (and you know HTML): Web 2.0, -9999px, and Redesign/Realign. We’ve also stocked gently remixed classics: Warning Sign and XHTML Fist AKA Six Fingers of Doom. And, yes, traditionalists can still stock up on timeless, unchanged ALA logo shirts, avec wreath.
As you can imagine, choosing the right T-shirt production and fulfillment partner required a massive mental effort, supported by modern research methodologies. We studied all the production and fulfillment companies out there, analyzing market data and poring over spreadsheets. But we didn’t stop there.
We completed a 72-hour card-sorting exercise (with no bathroom breaks), ran double-blind focus groups, and even hired our friends who used to call themselves information architects.
Sure, it was work—weeks of it. But it was worth it. Our grueling, science-based efforts paid off by revealing, as no sloppy shortcuts could have, the best possible choice of vendors. In short, we hired Jason’s wife’s company (also Nif’s!). They are awesome. (More shirt coverage is available at Jason Santa Maria dot com.)
All this … and content, too!
But this issue of A List Apart is not merely about re-opening our store’s doors. It’s about opening your mind. And in this issue, Rob Swan and Matthew O’Neill help us do just that:
We’ve all had bad clients. All too rarely do we find ourselves working for someone who understands what we do, respects our craft, and defers to our judgement. But do bad clients get a bad rap? Can we turn bad client relationships into good learning experiences? Can our worst clients help us better understand and articulate our highest beliefs about our calling? Well, anyway, Rob Swan thinks so. Read this and see what you think.
Gradients and bevels, bevels and gradients. Bevels, bevels, bevels. Gradients, gradients, gradients. And sometimes, drop-shadows. But mostly, and especially, gradients. Nothing says “Buy me, Google,” like a nice gradient background—especially in a navigation bar. Wouldn’t it be swell if you could get all that goodness without opening Photoshop every time you needed a little gradient bliss? Matthew O’Neill explains how you can. Happy coding and selling out!
Tim Berners-Lee, inventor of the web and founder of the W3C, announces reforms:
It is really important to have real developers on the ground involved with the development of HTML. It is also really important to have browser makers intimately involved and committed. And also all the other stakeholders….
Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn’t work.
Our Australian friends set up camp in Vancouver, for what looks like a great two-day conference on standards-based design and development (Vancouver Canada, February 6-8 2007). Speakers include Kelly Goto (Gotomobile), Andy Clarke (malarkey), Adrian Holovaty (Chicago Crime, Washington Post), Douglas Bowman (Google Visual Design Lead), Dan Cederholm (SimpleBits), Joe Clark (joeclark.org), Dave Shea (CSS Zen Garden), Cameron Moll (Authentic Boredom), Molly Holzschlag (Molly.com), Veerle Pieters (Veerle’s Blog, Duoh!), Kaitlin Sherwood (Google Maps US Census mashup), Tantek Çelik (Technorati).
By Andrew Kirkpatrick, Richard Rutter, Christian Heilmann, Jim Thatcher, Cynthia Waddell, et al. Don’t let the unsexy title fool you. Vast and practically all-encompassing, this newly updated classic belongs on every web designer’s shelf. (Better still, open it and read.)
Readers read web pages. Readers print web pages. In 1999, the way to help readers print web pages was obvious to every major site owner: buy a proprietary, multi-million-dollar content management system avec service contract to generate multiple versions of every page. After all, you needed seven versions of every page to handle all the browsers out there; you might as well treat print the same.
In 2001, A List Apart started promoting print style sheets, and by 2003, all the cool kids were doing it. They were also mostly using free or low-cost, generally open-source, content management systems. Yay, open source! Yay, web standards!
But a problem remains: all those ponderous 1999 websites have trained readers to expect a “print this page” button and subsequent in-browser preview. How can you satisfy this basic user expectation while still enjoying all the benefits of web standards?
show how the page will look when it’s printed, perhaps display a preview message explaining what this new view is about, and then automatically print the page.
McVicar’s method isn’t the only way to do this—others will likely be mentioned in the comments—but his technique is straightforward and clean, and it takes care of users without making the mistake of trying to educate them about something in which they’re profoundly uninterested (namely, web development).
Also in this issue: “How to be a Great Host,” by John Gladding. These days, many people’s web business plan looks something like this: “Ajaxy goodness + ???? = Profits!” Other straw men seem to think five blog posts plus text ads by Google plus discussion board software guarantees a buyout by Google. It doesn’t.
Building a community takes time and work. No amount of social bookmarking and tagging can rush that process. But you can learn to avoid mistakes. And you can save time by following time-tested approaches. (Learning from your mistakes is overrated.) Gladding’s article is filled with smart, “first do this, then do that” tips that can help you grow your site’s audience with discussion that works.
Black’s back! Black blogs! Site design by Rob Hunter. Love the “simplify” button. Red-and-black visual joke works, but shade of red needs fine-tuning. Having to employ drop-shadows on every character of body text (only Safari supports this) should be clue, if one were needed, that the background color doesn’t work.
“A is for Aaron, who fell down the stairs. K is for Kevin, menaced by bears.” No wait, those are just the notes from our last staff meeting. Jack Pickard offers a lighter look at the world of web standards.
[tags]design, a list apart, alistapart, textsize[/tags]
ALA 222: wraparounds and wordsmithing
Save time by tricking PHP into managing your tricky text-wrap problems; use that time to fix your About page. Everybody wins in Issue 222 of A List Apart, for people who make websites:
Wouldn’t it be great if there were a way to get text to flow around an irregularly shaped image? Wouldn’t it be even better if we could automate the process? Have no fear: Rob Swan is here to show us the way.
[tags]design, a list apart, alistapart, webdesign, php, writing, copywriting, about[/tags]
Get your kicks on Pier 66
Sorry, An Event Apart Seattle is all sold out!
There are still a few seats available for An Event Apart Seattle, featuring Kelly Goto, Erin Kissane, Jason Santa Maria, Eric Meyer, and Zeldman. Grab them (the seats, not the speakers) before the price goes up! Our early bird discount ends this Friday, August 18th. (Schedule | Map | Registration)
[tags]design, events, seattle, aneventapart, an event apart[/tags]