- Phase 4: Production and QA
- Establishing Guidelines
- Setting File Structure
- Slicing and Optimization
- Creating HTML Templates and Pages
- Implementing Light Scripting
- Populating Pages
- Integrating Backend Development
- Understanding Quality Assurance Testing
- Creating a QA Plan
- Prioritizing and Fixing Bugs
- Conducting a Final Check
- Phase 4 Summary
Implementing Light Scripting
Figure 6.10. On the home page of http://www.diverseworks.org, the rollover is a dithered close-up shot of artwork that rolls over to become sharp. ON and OFF states for the rollover are specified in the layers palette of the graphic template.
As software improves, implementing light scripting and special features (such as media requiring plug-ins) gets easier and easier. This should come as no surprise. If you used Fireworks to slice out and optimize your graphics templates, you were able to attach simple behaviors such as MouseOvers and SwapImages as you optimized and exported. If you exported an HTML file of the graphics template, much of your light scripting is already done.
Include all light scripting at this point in your workflow. Add browser sniffers and redirects. Drop in QuickTime or Flash files. Test all added functionality against specified browsers and against your audience's capabilities. Test, test, test. Look for errors. Yes, there is still QA coming up, but don't wait until then to catch bugs.
Smaller Is Better
Yes, you are responsible for maintaining the K-size for the file. This includes more than just the K-size of the graphics involved; make sure to take note of HTML K-size (source code) and any outside programming. You have a target, and now you have a "finished" piece. Too big? Go back and reoptimize. See if you can shave off a few bytes here and there. Make some decisions. Adjust.
Jeffrey Zeldman on Web Standards
Write once, publish everywhere. That's the goal.
To achieve it, the Web Standards Project (http://www.webstandards.org) has called on browser makers to support a core group of standards. These standards have several names (CSS, HTML 4, XML, and so on), but they all support a very basic idea: the separation of style from content.
What does this mean? It means your design lives in one place (for instance, in a Cascading Style Sheet [CSS]), and your content lives elsewhere (for instance, in HTML or XHTML documents, or in a database of XML- formatted text entries).
Why would web designers want this? Why would we want to separate our design from our data? For one thing, if the template for an entire site (or a section of a site) lives in a single CSS document, redesigns are a piece of cake. Need to change your background image, color scheme, margin widths, text size, fonts, and/or leading? Edit one CSS document, and an entire site (or section) instantly changes to reflect the new design. Try doing that with traditional "HTML-as-design-tool" markup. You can't. Even with sophisticated HTML editors, you're looking at hours or days of monkeywork, not to mention additional hours of browser- specific testing and debugging.
For another thing, if you can separate your design from your data, then people using nontraditional browsers will no longer be barred from your site. Whether they're on web- enabled cell phones, Palm Pilots, nongraphical browsers like Lynx, or special browsers to accommodate a physical disability, they will now enjoy full access to the site's content. With the separation of style from content, you don't have to create alternate versions of entire sites to support these folks (an expensive and time-consuming process in its own right); you simply add a rule or two to your style sheet.
With full support for web standards that facilitate the true separation of style from content, our jobs will get easier, mindless and repetitive tasks will be greatly lessened, and larger audiences will be able to access our sites with fewer problems. Instead of wasting our time and our clients' money on alternate versions and cumbersome hacks and workarounds, we can spend it on richer content, enhanced design, and additional functionality.
I creative-direct A List Apart, a weekly online magazine for people who make websites (http://www.alistapart.com). Because I control the site it's not something I handed off to a client and forgot about and because I update the content each week, I am also constantly upgrading the site's design and user flow in small and large ways. It's an ordeal because my style and content are tragically yoked together in a manner that is practically unsustainable. I use CSS to control typography, but because of current browser limitations (especially in 4.0 browsers), I still abuse HTML tables to control the layout. So any design change, even the smallest, takes hours.
When I finally get that page where I want it, can I automatically upgrade the rest of the site to work like that page works? No, because each page is a nest of painfully interdependent, hand-coded table cells. It's too complex for global search-and-replace. And I have no production budget (the site is independent and noncommercial). So there's an archeological effect as you delve back into older issues: The design is always subtly worse than the issue you've just read. A redesign downward, as it were. That may be interesting as a historical curiosity, but site-wide, consistent branding and user flow go right out the window.
Within the next 18 months, if standards compliance improves across all browsers and users upgrade, I'll redo the layout entirely in CSS, which will enable future redesigns to take minutes instead of hours giving me more time to spend developing site features and cultivating guest authors. I'm currently trying to make changes like that, but with 10 percent of our readers using Netscape 4 and another 25 percent sporting IE4, I can't really move.
I've described a simple, content-based site. Imagine bigger and more interactive sites, liberated by standards like XML, CSS, and the DOM. Imagine one team redesigning while another implements new functions without either team worrying that they're canceling each other's work. It's going to be amazing, but we're not there yet.
Jeffrey Zeldman, (http://www.zeldman.com), the author of Taking Your Talent to the Web (New Riders, 2001), is also the publisher and creative director of A List Apart, a weekly magazine "For People Who Make Websites"; co-founder and current group leader of The Web Standards Project, a grassroots coalition fighting for standards on the web; and founder of Happy Cog, the New York City web agency least likely to go public. In his free time, Zeldman, a popular speaker at web conferences, writes columns for Adobe Web Center, PDN-Pix Magazine, and Creativity.
Cascading Style Sheets and DHTML
Cascading Style Sheets and DHTML
Hand-Coding vs. WYSIWYG (What You See Is What You Get)
They say hand coding is a lost art... or is it? Many projects require the knowledge and flexibility that comes with an advanced level of HTML expertise. For many of these projects, the HTML production designers create code one tag at a time called "hand coding" using programs such as BBEdit or a hybrid such as Homesite. Hand coding almost always results in "cleaner" code than WYSIWYG editors generate. And as HTML purists tend to be adamant about the crispness of their code, many coders avoid WYSIWYG editors not only because they tend to add extra and sometimes cumbersome proprietary code, but also because WYSIWYGs often don't allow tweaking to as fine a level as can be achieved by hand.
With recent versions, WYSIWYG editors have enabled individuals who are not HTML savvy (designers and nontechnical team members) to create HTML pages with drag-and-drop ease. Adobe GoLive and Macromedia Dreamweaver, the two industry-standard WYSIWYG editors, are each making huge strides to offer more than just an easy-to-use interface. One of the biggest advantages of WYSIWYG editors is saving time. Hand coding can be a tedious and lengthy process.
Even though WYSIWYGs have their downsides most notably the extra source code these applications are excellent for getting started in web design and are definitely appropriate for a large percentage of projects. But learn the HTML, too. You will be better able to tackle any development challenge.