Shirley Kaiser Interview

In: Interviews

By Meryl K. Evans

Published on October 23, 2006

Current State of Web Design and Working on a Project

Digital Web: Last time we interviewed you was four years ago. What’s your opinion on the current climate of web standards and browsers?

Shirley Kaiser: From my vantage point, I see continued improvements and positive growth. For example, I see a much more open attitude toward web designers and developers at Microsoft via their IEBlog and related employee blogs. Web designers and developers can finally communicate directly with Microsoft browser developers; we can see for ourselves now that browser developers are paying attention, working hard at eliminating CSS bugs, and supporting more W3C CSS recommendations.

It matters that we can actually make a positive difference in improving the IE browser. As we all know, IE6 was stagnant for around five years or so, even though other browsers such as Firefox, Opera, and Safari kept on moving forward and improving. Now that IE7 is just released, I’m curious to see the impact. IE still has catching up to do, as the other main browsers are still ahead of them in terms of supporting W3C recommendations and browser features, but the gap is getting smaller.

DW: How has web design changed in the last five years in terms of what designers are doing better and what needs improving?

SK: I’ve seen tremendous growth in awareness of the benefits of CSS, and the importance of W3C recommendations, web standards, and accessibility.

On the other hand, I continue to see far too many professional sites that don’t allow for a browser’s fluidity and flexibility, that are confusing and tough to navigate, and that don’t provide sufficient, if any, helpful accessibility features. I also still see so many sites with incredibly bloated tables for layout and all those spacer gifs and font tags. Many are old designs—even some of my own clients still have old designs online that I created for them years ago like that. What bothers me more, though, are new designs like that.

Companies and individuals needing web sites often don’t know anything about what needs to happen behind the scenes to create a lean, clean web site that’s as universally accessible as possible, search-engine friendly, and has user-friendly navigation. They often don’t know the first thing about creating good copy for their sites, or understand its critical importance.

While I believe that companies and individuals need to properly research and hire knowledgeable professionals to create their web sites, I also feel it’s our responsibility as professionals in this field to know what needs to happen behind the scenes and visually. When people hire a professional, they need to get a truly professional job. A couple of blog posts and resulting comments I enjoyed reading recently on this are both by Jeff Croft: What does it mean to be a ‘professional’ web designer? (01 Oct, 2006) and Five things I’m doing to get better at web design (16 Oct, 2006).

For my business, part of my work with clients is to answer plenty of questions and help educate them a bit when needed¹, such as explaining why their site needs to be user-friendly, why good copy matters, and why a search-engine friendly, accessible site matters. I explain that whatever is needed in terms of how these things will benefit them, such as bringing in more visitors, allowing more visitors to use their sites, and better possibilities for selling products and services. I keep my explanations geared toward their levels of understanding. This is also how and why my WebsiteTips.com site started—back in 1996, I started with one page of helpful links for clients and potential clients, and that turned into what it is today.

DW: When working on a design project for a client, how do you get started?

SK: When potential clients contact me about possibly building a site or doing a redesign, initially I need to find out as much as possible about what they have in mind. If they don’t send me a request for proposal (RFP) or a web site plan outline up front, I ask a few basic questions, initially to see if they’ve done any planning or not prior to contacting me, and to make sure they’re actually serious about potentially working together.

For example, I explore what their needs are, what the budget is, the anticipated size of the site, the volume and type of content, content management issues, if they have any particular ideas in mind, and a timeframe for launch. I also find out if they have a logo, photos, or other graphics that they’d like to use, if they have domain names yet, if they have a web host.

I usually also send them to my Planning Your Web Site FAQ, especially if they’re not sure where to start. The first four chapters² of my book³, though, go into this initial planning stage in much more depth. Now that my book is out, I’ll use both the outline and book to help them get started, and the book to get into the details.

Initially, there’s a great deal of fact-finding. During our discussion, I know they’re assessing whether or not they think I’d be a good fit for their needs, and conversely, I’m assessing whether or not I’d like to take them on as clients. If I have a good feeling about working together, I go ahead and prepare a proposal based on all these details. Once they accept the proposal, I prepare a contract that also spells out our work together. Once the signed contract and deposit are in hand, I move forward with their web site project.

DW: In the past, the biggest problem with designing an accessible web site was the lack of the alt attribute, and of course there’s more to it than that. What are the biggest problems today?

SK: I wish I could say that lack of alt attribute text is no longer an issue, but it is unfortunately still a problem! There are plenty of other problems, too, though. For example, along with far too many sites with little or no accessibility features, there are the continued misperceptions that an accessible site equates with a huge additional cost, that there aren’t enough disabled people visiting a site to bother with including accessibility features, that accessible sites only benefit the disabled, and that accessible sites are ugly.

Getting into some of the details, though, other problems include:

• Lack of flexible font sizing⁴.
• Lack of accessibility-friendly navigation (such as using Flash or JavaScript for navigation without providing accessible text link options, not providing skip links as needed⁵).
• Inaccessible or difficult-to-use forms (such as not using the label element, forms that won’t function without JavaScript⁶).
• Not allowing for vision and color deficiencies.
• Not allowing for cognitive disabilities.
• Not allowing for the hearing impaired with audio content.
• Not using semantic markup—such as heading elements for headings (h1, h2, h3, h4, h5, h6), paragraph elements for paragraphs, list item elements for unordered and ordered lists⁷.

In terms of cost, if accessibility is part of the entire process from the very beginning, there should be little or no additional initial cost. On the other hand, retrofitting for any reason can cost a lot in terms of lost customers, lost income, and the actual bill for retrofitting, whether accessibility, search-engine optimization, information architecture, a CMS, or something else.

DW: Tell us about testing on your average design project.

SK: As with accessibility, I consider testing an important, integral, and necessary part of the entire design, development, and long-term maintenance process, too. I test all along the way so that I can make changes and adjustments more easily as I go. I don’t consider testing, at least in general terms, an option. But your question made me ask myself what type of testing you were asking about since, as you know, there are quite a variety of testing possibilities for web sites, such as:

• Getting feedback about design ideas—such as basic questions about the appropriateness of the design and colors, and if the design accurately reflects the company, business, or individual.
• Cross-browser, cross-platform testing.
• Usability testing.
• Accessibility testing.
• Information architecture testing.
• Markup and code validation.
• Spelling and grammar checking.

Budget and needs certainly influence the levels and types of testing, though. What I mean by levels of testing are that I wouldn’t typically recommend doing massive usability tests with groups and a testing lab for smaller sites or even larger sites with limited budgets. Less formal usability testing can help stay within budgets while going a long way in making user-friendly improvements and changes.

Cross-browser, cross-platform testing includes testing with the latest browsers, making sure the site is still usable and readable in old browsers, testing with Lynx, a multitude of browsers on my computer, simulators for WebTV, PDAs, cell phones, and I test with my own PDA and cell phone. I also rely on BrowserCam, especially for Mac testing since I use a Windows PC.

Redesigning a Mega Site

DW: You recently redesigned the resourceful WebsiteTips.com. How did you tackle it? (You can read about the redesign here and the colophon.)

SK: I knew it would be a big job because everything about it was so out of date—the content and everything behind the scenes. In a nutshell, I spent about five months of my off-work hours on this redesign project.

I started by breaking the redesign into manageable bits.

• Create a new visual design.
• Overhaul the markup and CSS behind the scenes.
• Improve/rework the information architecture.
• Create an easy-to-manage template system or purchase a CMS.
• Update existing content, including researching and replacing more than twenty-four hundred annotated link resources, and updating articles and tutorials in the Articles section.
• Add a Recommended Books section, including researching new books to add, and writing as many short reviews as possible.
• Integrate recommended books into the Web Resources pages wherever possible.
• Evaluate and improve, if necessary, the search engine rankings.

From there I informally inventoried the existing content, making note of what I wanted to update, what was too outdated to bother updating, and identifying new content or features to add to the site.

Once I figured out the information architecture and the content needs, I created a template system to manage the site and site contents (rather than going with an existing CMS), and I noted some ideas of how I might go about it using PHP.

At that point, I had also figured out enough to begin creating some visual design sketches, first for the main homepage, then for an interior page. I went back and forth between Photoshop and TopStyle trying and implementing possibilities.

Figuring out and creating the easy-to-use template system, though, took concentration and work, especially since I don’t really consider myself a programmer. The effort paid off, though, as now that it’s been live for several months, I’m finding the approach easy to update, extend, and manage. I wrote a tutorial recently, User-friendly Contextual Navigation with Simple PHP Includes, and a follow-up, Part 2: User-friendly Contextual Navigation with Simple PHP Includes, which show the basic approach that I developed and greatly expanded upon for my template system. My site gets much more complex than this basic introductory tutorial, but that’s how I started. I’ve learned just enough PHP to make use of some easy-to-understand if/else logic and PHP include files.

In addition to setting up PHP includes for the usual navigation, headings, and footer areas, I also use PHP include files to help with the site’s search-engine optimization. For example, I use a PHP include file for my title element tags to easily manage them within one file. I also have a PHP include file for all the goodies between the head element tags, such as external links to CSS files and meta information.

Throughout this entire process, I tested constantly, and I had others check out the private test area and provide feedback for improvements. My primary testing tools are CSE HTML Validator, the W3C’s validating tools, Lynx, a multitude of browsers on my computer, BrowserCam, simulators for WebTV and screen readers, and my own PDA and cell phone. I used them all for this project. I also pay attention to and listen to all the feedback I get from anyone who takes the time to send me an email about what they like, what they might find problematic, whatever.

DW: Congrats on the publishing of your book, Deliver First Class Web Sites: 101 Essential Checklists. Did you pick up any new design tips or strategies yourself while you were writing it?

SK: Thanks for the wishes. My goal with the book is for readers to use it as a guide to help them make sure they’ve covered all the bases from planning, creating, designing, and implementing, all the way through long-term management. It doesn’t teach you how to create a web site. Instead it provides best-practice checklists, tips, and resources as guidance to check that you’ve covered what matters the most for your web site. I learned a lot more about wireframes and paper prototyping, which I found fascinating.

Web Design Business

DW: You’ve been self-employed for more than ten years. What challenges do you face as a self-employed web designer?

SK: Promoting my business all the time, especially as I don’t have a salesman type of personality. It can also be tough to keep to my business hours at times, as it’s too easy for me to work far too many hours, especially with a home office. I also don’t like paperwork, but it’s got to be done.

DW: How should designers deal with charging clients?

SK: Oh, this question comes up so often in discussion lists from designers, especially when they’re feeling stuck, when they feel taken advantage of in some way, and when they don’t know how to deal with clients who don’t provide their materials to them. I don’t think there’s any one right way to deal with charging clients, but I do feel it’s important to handle your business finances and charging clients professionally.

For my own business, I always have a signed contract and deposit before I start any work. Prior to drawing up the contract, we discuss as much detail as possible, which is then written into the contract, such as timeframes, when each phase will be completed and the specifics of each phase spelled out clearly, when their content, images, and other materials are due, the amounts and when they need to pay me, etc. I also itemize what is included in as much detail as possible, along with a list of what is NOT included in the contract, too, just to be extra clear. I spell out the details as much as possible right in the contract.

We also discuss and set up realistic timeframes and deadlines for the client to provide all their materials to me, which also gets spelled out in the contract. The contract also states that if they don’t make the deadline that I can cancel the project, or their project can be bumped to the bottom of the waiting list and they’ll need to sign an amended contract with new dates. I rarely need to do this, though, which I think is because we set up realistic goals for everyone at the beginning.

Why do I go to all this effort with all this detail in my contract? When I first started my business I had clients not turning in materials to me on time, a couple of projects dragging out forever, and then those same people suddenly contacting me and wanting to have their sites finished yesterday. It really made a mess of trying to schedule projects and work. I had to implement a system to help everyone stay on schedule and to get our work done together in a timely fashion. Working out realistic timeframes and spelling it all out in our contract has eliminated all these problems. So this approach has worked beautifully for my business.

What counts so much is clear communication, being professional at all times, and staying within your contract stipulations.

Music

DW: You’re a pianist with your own CD, Journey Within. Can you tell us more about your love of music?

SK: I couldn’t last a day doing my work without listening to music. It energizes me, helps me focus, everything. I’m a classically trained pianist, and I’ve always gravitated toward classical music, but I play just about every genre of music, and I love it all. I also write my own music, and I tend to compose and play what I write the most these days. In terms of playing other instruments, I play a friend’s tambura a bit, which is a long-necked stringed instrument from India with a beautiful, resonating sound.

---

Footnotes

¹ Often people hire me because they already know that I specialize in user-friendly, accessible design and development so I don’t need to explain any of that, and sometimes they ask me questions about why it matters so they can be better informed.

² Chapter 1: Let’s Get Started…but How?; Chapter 2: What to Find Out: Initial Questions to Answer; Chapter 3: Preparing Web Site Content; Chapter 4: Managing All the Content.

³ Deliver First Class Web Sites: 101 Essential Checklists, by Shirley Kaiser. SitePoint Pty., Ltd., July 2006.

⁴ See WebAIM’s article, Fonts, specifically the section “Font Sizes;” Accessible Web Typography, by Jim Byrne.

⁵ See Jim Thatcher’s Skip Navigation Links for an insightful analysis of a variety of skip links approaches and practical tips; Skip Link Pros and Cons, by Gez Lemon and Mike Cherim from Accessites.org (1 May 2006); W3C’s Understanding Guideline 2.4: Provide mechanisms to help users find content, orient themselves within it, and navigate through it from Understanding WCAG 2.0, W3C Working Draft 27 April 2006).

⁶ A couple of helpful tutorials on creating accessible forms: Accessible HTML/XHTML Forms by Ian Lloyd via The Web Standards Project site (May, 2004), WebAIM’s Creating Accessible Forms.

⁷ Regarding accessibility and semantic markup, that’s what sparked my blog post four years ago now, Don’t Fake Your Markup: Accessibility Issues for CSS, and my more recent article, Semantics, HTML, XHTML, and Structure.

Related Topics: Accessibility, Web Design, Client Management