Keith Robinson is a Web Designer and Developer (and lots more besides) living in Seattle, Washington. He has been a working Web professional for going on 10 years now and has worked with companies like Boeing, Microsoft (don't hold it against him) and Sony. He is Editor In Chief of Digital Web as well as running his own site, Asterisk, where he shares his thoughts on web development. When he posts, web developers pay attention!
Keith: Oh boy! What doesn't it involve? It actually involves quite a bit, but it's something I very much enjoy doing. To sum it up -- what I do is lead the editorial process for Digital Web with lots of help from the other Digital Web volunteers. I'm the guy who has the final say in what gets published. Theoretically anyway. I work with our authors, editors and columnists to ensure we're publishing articles that are valuable to our audience.
I do some editing, but it's mostly at a very high level. What I try to do is make our articles and columns valuable and readable for our audiences while at the same time retaining the author's voice.
That's it in a nutshell, there is much more, but I don't want to bore you! As well, even though I've been in this role for Digital Web for a while I'm still working on making it mine and getting a handle on how best I can push Digital Web forward. We've actually got quite a bit of interesting things on the horizon, including a redesign (Web standards-based of course) and some more audience focused features and content.
Keith: For Web developers the advantages to using Web standards are many, it would take quite a while to go over them all. By coding with Web standards you insure that your pages are future-proofed, easy to maintain, and predictable in function. By using the latest standards (XHTML + CSS for example) you can save yourself loads of time and effort. For example a site designed with standards based, semantic XHTML using CSS for the presentation layer will:
I realize at the beginning some aspects of Web standards (namely CSS) can be a bit hard to grasp, but it gets easier as you get to know it. Making the switch to Web standard HTML or XHTML markup is a no-brainer though. It's actually much simpler. If you remove all the non-standard markup from your code you have less tags to deal with. Who wouldn't want that? Take it all the way to XHTML strict and you've removed even more tags.
Keith: It doesn't happen all that often. I'd just run into a string of problems, every one due to the way Internet Explorer renders CSS, that I had trouble resolving. Usually I have very little problems with CSS based design. The vast majority of what I've done works the way I feel it's supposed to, but occasionally I'll stumble across a problem I can't easily resolve. At times I've reverted to a table to solve those problems.
I do my best to avoid CSS hacks as well. That could have something to do with it. To me the table is the mother of all CSS hacks and if I can't do it without hacks, a table is just as good as anything else. Right?
Well, maybe not, but it can be practical and at the end of the day I'm a very practical Web developer. If I'm starting to spend too much of my time, or my client's money, on something just to placate IE, I figure at times it's just not worth the effort. Hopefully this will change somewhere down the road with better support for Web standards from Microsoft and a better understanding of how to get things to work correctly on my end.
Keith: This is a tricky one. I do feel it's important and I see validators as very useful and important tools. However, I don't think, in this day and age anyway, validation is the be-all end-all measurement of quality and success. I would say that it is preferable to have everything you develop validate, but there are times when, again, it's just not all that practical.
Say, for example, you are working with a CMS and you'll need to spend hundreds of hours working with your templates to get them to validate, especially if you're having browser issues. You could very well be better off concentrating on making your content as valid as possible while making sure your templates display correctly cross-browser, as your content is what is going to last. There is no real benefit in future-proofing and building a valid template that you'll be disregarding in a few years, especially when the most popular browser out there doesn't concern itself with that validation.
Don't get me wrong, I wish this wasn't the way it was, but as long as we have browsers that don't fully support the standards, there will be a point when validation butts up against practicality and resources.
Keith: I think there are many ways to go about this, especially when you are able to build from the ground up. I think the first thing I'd do is start with clean, semantic XHTML code. A semantic and well structured base for a Web site can do quite a bit in getting you set up for accessibility. I'd tackle the design as a separate piece all-together and marry the two a bit down the road.
If your site functions well sans-design elements, at least from an accessible level, you've taken a huge step in making sure your site will at least function for the widest range of potential users possible. Accessibility and usability go hand in hand.
Keith: Yes and no. I do feel that this can be the case at times, but lately it seems that there has been more focus put on things like ROI, usability and the whole people aspect of the Web. I think this is a good thing. Web standards enables all of those things, but in lots of ways it's just a means to an end. I still think there is quite a bit to be said, but it's good to keep these other issues on people's radars as well.
Is there anything wrong with focusing on all of these issues? I don't think so.
Keith: Not as often as I'd like I'm afraid. Down at the hospital where I work we try and keep pretty good tabs on our users and get together with them every other month or so. I also do quite a bit of "user observation" on the side, pretty much whenever I get a chance, but it's less valuable than some of the more formal usability studies I have done.
I can't stress enough how important I feel it is to have as many people involved with a Web site as possible get some face time with the users. I think it's something that is beneficial to everyone, from Web developers to Marketing people, to writers and everyone in between. User advocacy is an area where there needs to be more work done. I feel it's one of the ways we can make the Web a better place for everyone.
I've been saying for years that "The Web is about people" and I feel like we're just getting to the point where it's catching on. As more Web professionals jump on this bandwagon, I think more stakeholders and clients will as well. That should provide more resources devoted to the study of our users and give more opportunity for folks like myself to get in there and try to really understand how people use the sites I design and build.
Keith: Ha, ha. The "Golden Triangle" I talk about is simply a metaphor I use to illustrate the delicate balance of goals that should be laid out for any successful Web project.
The basic premise is that when building a Web site you've got three basic types of goals:
Business goals. These are goals that relate to the bottom line. These are what usually dictate the need to have a Web site at all. These could be tied to money, communication or branding. Basically this is what drives the project forward.
User goals. These are the goals of the users of the site. These are important because without people to direct your business goals to, there isn't much point having a Web site.
Organizational goals. These are a bit harder to define. In a corporation this could be things like "ease of maintenance" or "the ego of our CEO". They might seem like they should be trumped by both the business and user goals, but, as many Web people know, they can often have a huge effect on the outcome of a project. In an ideal world we would not need to worry about them much.
I don't think there is such a thing as a perfect Web site, but if there were such a thing, it would take into account all of these various goals and balance them in such a way as to satisfy them all. Thus the Golden Triangle.
Unfortunately in the real world, business and organizational goals often take precedence over user goals. This is going to happen, at least for the forseeable future. By using the Golden Triangle metaphor I can more easily explain to the stakeholders in various groups, the potential pitfalls of focusing on one group of goals and not the others.
I guess in that way it is related to the Bermuda Triangle. Don't take the time to focus on the user's goals and that is where they'll end up. The Web site will usually follow.
Keith: It depends on the project I guess. Ideally the answer would usually be "no". The problem is that there often isn't anyone in place to focus on the client. I know this has fallen to me many, many times. That is one of the reasons I've got into writing and became involved with Digital Web.
I saw an opportunity to grow my skills toward something I felt would be incredibly valuable to my clients and to the teams I work on. Many Web teams can't have a full time person in to manage content -- hell, many don't even have an editor. Like it or not this often falls to the designers and developers to take care of.
My hope is that this would change in the future as clients and organizations begin to realize the value of their content and the value of the Web as a channel to deliver that content. It's still far too often that the Web plays second fiddle to print or is seen as an afterthought.
Keith: Ohh, fun. Ok. Well I think I'd go for something like an agency model. I've worked on teams like that before and it's worked very well. I'd have a Program Manager person to oversee the whole team, and make the big decisions. I'd have a Creative Director / Editor in Chief (that'd be me) who kind of managed the vision, kept the team together and lead the projects from a conceptual level. I'd have a Project Manager / Producer person, or two, to lead projects, manage content and keep everyone organized. Then I think some kind of Sales or Account Representative person would be good. On the creative end, I'd have an Art Director and a Web designer or two. On the development side, I'd need a front-end developer, a back-end developer and a systems admin. Then I'd have at least two editors / content managers and a writer.
Wow, that'd be a big team, but not too big -- 12 people. Yeah, I think a team like that could get a whole lot of great work done. Big enough to tackle and manage most projects, small enough to actually get things done and keep everyone feeling they're part of the team.
Copyright © Web Standards Group 2012