• 515 Kb page size (38 Kb just for the HTML)
• 7.08% code-to-content ratio
• Tables nested up to eight levels deep
• No accessibility, and metadata that sucks donkey tail
• All old URLs now generate 404 errors

We’ve all seen websites that go from great to suck. These sites have taken a massive step backward in time, and have become less accessible, less findable, less manageable and ultimately less prepared for the future.

Which begs the question: what can we as website builders be doing to ensure our work greets with open arms the next generation of browsers, search engines, and social networking tools? Of course we can create designs that rock, but this is subjective; if the CEO’s wife gets tired of the design, you’re screwed no matter how much awesome sauce you poured on it.

Instead, what are the tactical development tools we can deploy today to build for future browsing technology?

Mobile Style Sheets

Media-specific styles sheets are the new style switchers. Forget changing colors on your website; trade in the gimmicks for serving Crackberries, iOwnz and Palm Pees versions of the site that work effectively on a small screen. Not sites that can be stretched and rotated and pinched for squinty viewing, but sites that actually take advantage of the CSS-friendly environment while optimizing the design for reduced real estate. Example: foxnews.com is awesome on an iPhone, but bbc.co.uk is a nightmare.

Width Management

The trend toward netbooks shows that people are acutely interested in smaller, cheaper, web-powered devices. The average screen size for the leading models is 10.1” — a resolution of 1024×600. Yes, some d0rk5 have rows of 1600×1200 in their home office command center, but the world is regressing in screen real estate, so keep those designs nice and tight.

Microformats and RDFa

The age of embedded data structures is emerging from the paleozoic, and we’re entering the phanerozoic. If you are not already using microformats in your work, best to start now. The recent endorsement by Google is big (maybe), so take a cue and complement your standards-friendly HTML with a layer of truly semantic markup that makes your work more findable.

The F Word

With more and more content being delivered over mobile, using Flash for gratuitous animating flangdingies, useless scrolling bizzfnoggles, rotating banner jimmyjams and other thought-retarding “wow factor” will become even a worse idea than it is now. Proprietary plug-ins suck. Bandwidth-hogging files suck. Inaccessibility sucks. Let JavaScript libraries do the cosmetic work, and save Flash for the areas where it really shines: video delivery and banner ads with dancing wizards.

HTML 5?

A lot of recent noise about this one. All kinds of people regressing to HTML 4 and using semantic class names, all in the name of getting ready for HTML 5. (Others are justifying their choice for lamer reasons, but whatever.) I don’t fully understand this trendy backlash against XHTML; in my mind, an XML-driven web is the future, but too many people are globbing onto HTML 5 and just not letting go. There are not a lot of tactical to-do’s here except pay attention.

Socially Acceptable

As search and social media aggregate more and more of the Intarweb’s traffic, it is imperative to produce findable and shareable websites, and then providing the means to quickly share that content. Providing links to 900 social bookmarking apps is a start, but providing easy access to e-mail notifications and RSS feeds will be as important as ever. (This thing does a pretty good job if you don’t feel like rolling your own.) People continue to spend more and more time inside “social media” applications, so make sure you get part of the action.

301

This is the gotcha that too many sites fall into. I’ve seen libraries of good content become utterly lost when the website was redesigned, the URL structure changed, and nothing was ever redirected. This is especially problematic for media sites, where news articles simply disappear without explanation — sometimes within days of publishing — and it takes deep archive spelunking to find them.

These are just a few of the things that struck me going through this rebuilt client site as they utterly failed on every front.

I’ve been using microformats for years, and have standardized this adoption across client work, especially using rel attributes in anchor elements, (in particular, employing tags for site taxonomy) and the hCard standard for contact information. On the flipside, I’ve been following the Dublin Core initiative for longer, but have never found a practical application for applying the rich metadata language it offers, despite my hero Joe Clark futureproofing his entire book with the stuff.

With Google announcing support for forward-thinking data structures this week, it appears as if there might be a payoff for the additional development effort. Is it time to pay closer attention?

An Immediate Conflict?

The most obvious problem is the possible conflict of technology between microformats and RDFa. The former uses simple class and id attributes to describe data, which easily bolt onto contemporary HTML, even the aging 4.01 spec. RDFa employs more complicated XML structures, and requires a custom XHTML 1.1 doctype.

Evan Prodromou wrote a great article outlining the differences between RDFa and microformats, and I am not going to reiterate everything here. But my questions echo his.

• How quickly will frontend developers adopt new metadata attributes that are more complex than the user-friendly language of microformats, and only work with stricter XHTML 1.1 doctypes? Will implementation be relegated to only the cutting edge, or the techno trainspotters? Does Google’s sponsorship help move the meter on adoption?
• Can web page information be marked up in a hybrid of the semantic languages? Right now, there is no definitive answer.
• Is there room for both in the future semantic landscape? The world saw a massive stutter-step in the spread of syndication because of competing RSS standards. Ben Adida doesn’t think there is an issue: “Microformats are useful for expressing a few, common, well-defined vocabularies. RDFa is useful for letting publishers mix and match any vocabularies they choose. Both are useful.”
• Will developers actually spend time to write their own RDFa vocabularies, or simply re-use Dublin Core, FOAF, and others over and over and not bother with content that currently does not have established definitions? (If so, that defeats the entire purpose and everyone should just use microformats.) On a more pragmatic level, is there one core language that is superior to the others for similar schemas, or is it truly a choose your own adventure?

Yes, there are other big, big questions. These are just the ones that strike me as immediately pressing — as a huge advocate of web standards, I’m looking for a standard.

GOOG is not God

Google’s announcement is going to stir pots, especially in the SEO community. SEO experts have wishy washy consensus on whether semantic HTML influences ranking, especially in the use of our friend h1. (Even though our search engine du jour barely acknowledges semantic HTML, and certainly does not endorse W3C validation.)

We have all seen well-structured semantic websites fall short of competition that boasts a bajillion incoming links. This is by design. While Google plays lip service to structured data, does its use dictate a ranking advantage? Perhaps if all else were equal, structured data would offer a razor-thin ascendancy, but Google will never say that, and we plebeians have no way of knowing how it factors into their black box algorithm.

The Cart, the Horse, and the Order of Things

Finally, hardcore adoption of RDFa feels premature. With XHTML 2 many years away, and XML MIME types still not supported, it seems that the technology is almost stillborn. Who wants to use it when its power cannot be fully leveraged? I understand it’s compatible with XHTML 1.1, but the golden road toward an XML-driven web seems more difficult by the day.

On top of everything, HTML 5 seems to be gaining favoritism over XHTML 2. There is clearly confusion in the web development community, and some web illuminati are already building for the next version of HTML. If HTML 5 is the new standard that’s going to push the web forward, does this leaves RDFa out to dry, since it uses strict XML formatting? Are we all going to come full circle to HTML-friendly microformats? Or am I missing something totally obvious?

These are not rhetorical questions — I am not smart enough to even guess most of the answers.

Laately, I’ve been thinking about the concept of a team focused on a company’s corporate website. Zeldman wrote a good article about web teams awhile ago, and while it contains solid points, I categorically disagree with his conclusion that the web team has to be its own independent entity. I believe in its existence, but based on my personal experience, marketing is where it should live.

Monologues and Conversations

Mr. Zeldman asserts that marketing in a monologue, and the Web is a conversation. But in reality, marketing is not always a monologue, and the Web is not always conversation.

Most marketing professionals are more interested than ever in creating a conversation with customers, prospects and partners. Witness the rise of organizations using blogs, Twitter, Facebook, and more, and the constant movement toward creating communities, poring over visitor analytics, and the use of complex ecosystem tools like VML’s Seer. (For further evidence in the media, open up an issue of BtoB at any given moment to see this movement in full swing.) Marketing teams may not be fluent in conversation yet, but they are trying their dandiest to get it right.

By contrast, and almost by irony, most corporate websites are, quite frankly, monologues. Simply look at the labels in most top navigations — “About Us”, “Our Services”, “Contact Us”. The tone is constantly “how we can help you” instead of “how we can work together”. These are vehicles of old push marketing, digital brochures that inform without engaging, and are anything but a conversation. But they are marketing, by definition.

Aligning Corporate Interests

The dedicated web team, when it sits in marketing, allows these two ships to actually stop at the same port and have dinner together instead of passing each other silently in the night. It gives account planners and advertising specialists in marketing a dedicated resource with which to execute plans without bureaucratic red tape. It gives the whole of marketing an internal think tank that can provide training, best practices, technical prowess and a laser-like focus on emerging trends and technologies. And the web team itself has access to strategy, budget and veteran insight that would otherwise exist outside their domain. And because everyone is housed under the same division, there is a sense of common purpose and “we’re in it together”.

Creating islands of specialists — one for marketing, one for IT, one for the Web, one for sales, etc — simply results in more conflicting interests, more miscommunication, more mistrust, more wasted parallel initiatives, and most importantly, less collaboration and teamwork. It’s the same for other niche talents — graphic design, media planning, server administration, sales operations, and others all require specialized talents, but are grouped into broader departments to help align corporate interests.

Traditional marketing teams are not smart about the Web. And inexperienced, untempered web teams (like those found in the recent rash of agency “social media” divisions) are idiots when it comes to marketing. Mashing the two together gives companies the best of both worlds. So while some argue that a web team should not be inside marketing, I argue that marketing needs to learn how to have a web team.

In Part 2: The Anatomy of a Prototypical Web Team. Coming soon.

The first is an article on A List Apart titled The Details That Matter, which is a brief foray into what makes good designers great. The theme — there is no magic bullet. Success is measured by excelling at all of the little details that go beyond design, from intelligent question asking to reading the content. I am pleased with the positive feedback this garnered. It seems I am not alone in my thoughts.

The second is related to design career development. Creative Cohort is a new website for and about creative directors — what it takes to be one, how we think, the challenges, the terror and the adrenaline. I was kindly asked to contribute, and my first article is up there now, Does a Four-Year Degree Matter. It’s a bit of a controversial topic, for sure, but that’s how I roll. Please comment over there if you think my position is idiotic. I will be adding future content soon, but add this sucker to your feed reader because it’s going to be a great ride.

Finally, a bit for all you Textpattern nerds. Section and Article Navigation With TXP is a tragically titled bit on TXP Tips that explores how to use the new tag parser in 4.0.7 to achieve completely dynamic menus without plugins. It’s a bit long, but totally sweet. I guarantee a moment of TXP Zen when you’re done.

And if you’re really bored, you can always read the feedback from this bad boy posted almost a year ago. The perspectives from the crowd are interesting. At this time, over 160 people have felt the need to yell about it. I bet Sitepoint didn’t expect my little post to garner over 13,000 unique views and 25,000 words in feedback since its inception. And for the record, I stand by every damn word.

This may seem counter-productive at first. But clients are not designers, no matter what they think, and it’s your job to explain how they can spend their money in the smartest and most efficient way possible. There are few hard costs in building a website, so most of these tips revolve around keeping billable hours to a minimum, and avoiding the miscommunication and scope creep that can inflate the project cost.

1. Provide a Detailed Project Scope

Ensure the scope of the project is clearly defined from day one. No matter what written documentation you provide the client before signatures are slapped on paper — a scope of work, a response to a proposal, detailed meeting notes, whatever — make sure it completely and exhaustively outlines what will happen when, and how it will be done. D. Keith Robinson wrote an excellent piece on scoping web projects a few years ago, but it is still relevant today.

2. Meet the Client in Person

I’ve written before about meeting clients face-to-face, and to this day I cannot underestimate the value it brings to a working relationship. Once you shake a person’s hand, look them in the eye, and discuss expectations at length, so much personal ambiguity is cleared from the air that even long e-mail chains are bearable because you understand, just a little more, who you’re dealing with on the other end. Obviously this can’t happen every time — geography is a bitch — but for local clients, there’s nothing better than collaboration over coffee.

3. Keep the Design Phase Realistic

In my experience, a huge percentage of the project’s hours are spent in design. I explain this up front. This inevitably leads to a conversation about the design itself, which helps get a lot of ideas and expectations out on the table. It also keeps the client from diving down design rabbit holes, and avoiding useless iterations “just so they can see it.” One of the hardest things some people have to do is trust their designer. (And sometimes they never get there.)

4. Build a Turn-Key System

One of my key selling strategies for new clients is explaining that I build websites that clients can administer themselves. This is the beauty of content management systems. Once they discover that they can edit and create their own content, even manage content workflow and assign publishing privileges, all without getting a web developer involved, it’s like they’ve fallen out of Kansan tornado into a new world of color and talking animals. Websites should be scalable and adaptable, taking advantage of the dynamic nature of the CMS to empower the client. (Also, provide good documentation. The importance of this cannot be overstated.)

5. Get Visual Assets Upfront

In almost all cases, a website has some visual elements that are proprietary to the client: their logo, a particular illustration or diagram, photos of their headquarters, or photography of whatever it is they do or sell. Getting these assets upfront can shorten design time. Without them, mockups are riddled with pixilated logos or FPO images. Part of the proposal process is figuring out whether these assets need to be re-created (like product photography), and pricing accordingly.

6. Get Content ASAP

There is no doubt that any seasoned web designer out there can relate only too well to stories of clients lollygagging on content until the 11th hour. This always seemed odd to me. It feels like a lot of companies want this grand new website full of flash and dazzle, but only a small percentage have thought through exactly what they want to say. This inevitably drags the project to a halt. I have sat on fully built websites for months before the client finally got around to providing content, only to have that content redefine the navigation, costing them more in development time. My only suggestion is to apply pressure early and often, and cross your fingers.

7. Advise on Third-Party Services They Actually Need

This is a simple one, and will build trust with the client. Always advise on services they actually need for their website infrastructure. Hosting is a classic example; a Rackspace account is clear overkill when GoDaddy will work just fine. E-mail is another one. If a host’s off-the-shelf services work fine for simple POP accounts, they do not need an Exchange server. If a solid open-source solution works just as well as a complicated paid solution, explain — honestly — the pros and cons of adopting either one. Sometimes a paid version will have a lower cost of ownership because the time and effort needed to self-support an open source solution becomes too expensive over the long run.

8. Clarify Your Contacts and the Approvers

Always understand the personnel landscape you are entering. You need to know two important things: who your main contact is, and who approves the work. This is rarely the same person. Insist on a single point of contact within the company, otherwise communication will unavoidably get jacked up. Ask point-blank who will be approving the work. You may never cross paths with this second group, but knowing who to please is just as important as knowing how to please them.

Again, a lot of these tips center on keeping billable hours down. Explaining these things upfront can do wonders in not only managing expectations for the project, but will make the client think twice before throwing a wrench into a project and wasting everyone’s time. Are there any other tips you guys have?