Mock-up to valid XHTML: how to build a web page – part 1

Posted on Apr 1, 2009 in Design, Web Dev | 0 comments

What an auspicious title! I recently had an opportunity to create a web page to support an event—Opportunity Knocks—for Quadrant Homes. I was given a professionally-designed PDF file, which was essentially a flyer with a few web-page trappings added, and asked to create a web page.

Easy, right?

Sure, it could be a three step process: open the PDF in Photoshop, slice it up and export the whole thing as HTML, upload it to the server and call it a day. But there is an artistry as well as a science to building web pages correctly, and I decided I’d do it right for the sake of doing it right. This two-post series will first examine why the slice-and-dice method is fraught with problems. Then, I’ll outline the steps I took to build the page in valid XHTML and CSS (including how I addressed the sticking points common to web standards development). More importantly, I’ll explain why doing it this way is worth the (minimal amount of) additional work.

Part one begins after the jump. Part two will come in a few weeks. [Update: Part two of this series is now available]

What’s wrong with Photoshop slicing-and-dicing?

The approach many web developers take to putting up a page based on a mock-up from a client (“client” can mean boss, too!) is the “quick and dirty” method described above. Open a PDF in Photoshop and use its tools to create slices—rectangular sections—of the image, all of which can then be exported along with Photoshop-generated HTML to build a “web page” of the design (usually with tables, though it is possible to have it output absolutely-positioned DIVs instead). I’ll be clear: this is a useful tool in some respects. But it’s no substitute for properly building a page.

Common reasons this method is used, followed by my argument against that reason:

• Little web skills (or, “I don’t know how else to do it”) – Simply put, slice-and-dice is easy. Many graphic artists’ first foray into web design is realizing their preferred software tool can build a web page. With a limited understanding of good web development, they don’t see a reason to move beyond this level.
  I don’t have an argument against this; it’s a fact of life. I’ve done my share of slice-and-dice and it was a good starting point for me. I’d encourage any graphic artist dabbling in web development via Photoshop kick it up a notch.
• Little time (or, “I don’t have time to do it right!”) – Faced with improbable deadlines from clients, developers who know better sometimes opt to “cheat” with a quick slice-and-dice.
  Sure, building a page properly takes an upfront investment in time, but its benefits (see below) outweigh that initial cost. And in my experience, proper web development saves time in the long run due to the inevitable tweaks, alterations, and changes clients and bosses usually request. Want some text moved down a bit? Or was there a misspelling you didn’t catch? When you slice-and-dice, the worst-case is you’ve got to do the whole thing over again. Best-case is you can edit the text in the native Photoshop document, re-save that one slice, and replace the “bad” image on the server. Either way, changes are cumbersome and time-consuming.
• Cross-browser compatibility (or, “Why develop styles for multiple browsers when images display the same on all browsers?”) – This protest holds a bit of weight, as cross-browser hurdles are frustrating at times. Goodness knows I’ve built a nice design in Safari that looks hot in Firefox (on a Mac and a PC), only to see it mangled in Internet Explorer.
  Building a page with proper web standards should accommodate nearly all modern browsers. IE is, of course, the elephant in the room. But there are plenty of well-documented solutions to the IE problem that are not difficult to implement. (But hey, at least it’s not Netscape 4.7. Anyone else remember that steaming pile of a browser?).
• Pixel-perfect precision (or, “I can’t get things lined up just right unless it’s an image.”) – Developers sometimes cite the client’s desire for an exact replica of the mock-up as reason for slice-and-dice.
  To quote Sam Beckett from Quantum Leap: “Oh boy.” If your clients are demanding pixel-perfect fidelity from mock-up to web page, they need to be educated. The web isn’t (or shouldn’t be) a high-tech way to distribute a flyer. If that’s truly their aim, they could save you a lot of hassle and themselves a lot of money by simply posting a link to a nice, printable PDF–no translation to webpage needed. The web is about interaction, fluidity, information, and usability. Despite striving for it, pixel-perfect precision should take a back seat to the other (primary) purposes of the web.

Besides my counters to excuses for this approach, there are other reasons it should be avoided:

• Page weight – Graphics are “heavier” than text. No matter how optimized your GIFs and JPGs are, a page comprised mostly of images will always be significantly larger in file size–and therefore download time–than a properly-built page. (Not to mention over-optimized GIFs look dull and flat as “developers” try to shave 10 more kilobytes from an image by reducing its colors. And JPGs usually start to display artifacting and pixelization when they’re ratcheted down in file size.)
• Accessibility – Face it: some of your users can’t see. Should they be excluded from visiting the page? They are if they use a screen reader. Sure, you can add alt text to your images, which helps. But for any page that has a lot text, alt text just doesn’t provide the same experience. Oh, and what about the poor saps who are stuck using the aforementioned steaming pile, Netscape 4.7? Or maybe just an older version of IE or Safari that a significant percentage of your visitors still use? (A number you can and should know thanks to web logs or Google Analytics). You can build your page properly so as to give all visitors, regardless of their “user-agent” (that’s a fancy term for web browser), the information they came for. If they have a modern browser and can enjoy all the bells and whistles, that’s gravy.
• Maintenance – As mentioned above, change happens. Text is easy to change, images aren’t. Also, what if the client later switches to a content-management system (CMS) or wants to re-use the information in another page, XML datafeed, etc.? You can’t do that with images but well-structured mark-up can easily be moved to a database, XML, or simply repurposed with a new CSS stylesheet.

Related: If you liked this, check out:

1. M-dashes not allowed in XHTML comments I found out today that one of my favorite punctuation...
2. Why Photoshop Isn't A Web-Design Tool If you’ve never had the pleasure of using a web...
3. My first official "microsite" for QH As faithful readers of this blog know, I recently began...
4. Use WordPress for everything This may be a weird post but I simply couldn’t...
5. Hyphenation on the web If you're not a print designer who commonly works with...