Tag Archive for: HTML5

I’m going to make a bold prediction. Long after you and I are gone, HTML will still be around. Not just in billions of archived pages from our era, but as a living, breathing entity. Too much effort, energy, and investment has gone into developing the web’s tools, protocols, and platforms for it to be abandoned lightly, if indeed at all.

Let’s stop to consider our responsibility. By an accident of history, we are associated with the development of an important tool our civilization will use to communicate for decades to come. So, when we turn our minds, idly or in earnest, to improving HTML, we must understand just how far-reaching the ramifications of today’s decisions may be.

HTML 5, the W3C’s recently redoubled effort to shape the next generation of HTML, has, over the last year or so, taken on considerable momentum. It is an enormous project, covering not simply the structure of HTML, but also parsing models, error-handling models, the DOM, algorithms for resource fetching, media content, 2D drawing, data templating, security models, page loading models, client-side data storage, and more.

There are also revisions to the structure, syntax, and semantics of HTML, some of which Lachlan Hunt covered in “A Preview of HTML 5.”

But for this article, let’s turn solely to the semantics of HTML. It’s something I’ve been interested in for many years, and something which I believe is fundamentally important to the future of HTML.

The BBC recently announced that they would drop the hCalendar microformat from their program listings, due to accessibility and usability concerns with the abbr design pattern. This demonstrates that we have, beyond any doubt, pushed the semantic capability of HTML far past what was ever intended, and indeed, what is reasonably possible with the language. We have simply run out of HTML elements and attributes with which to mark up more richly semantic documents. If we continue to be clever with the existing constructs of HTML, more problems such as this will arise. But HTML suffers from a fundamental defect as a semantic markup language—its semantics are fixed, not extensible.

This is not simply a theoretical problem. Hundreds of thousands of developers use the class and id attributes of HTML to create more richly semantic markup. (They also use them as “hooks” for CSS styling, but that’s another matter.) Almost invariably, those developers use ad hoc vocabularies—that is, values they have made up, rather than values taken from existing schemas. It’s pseudo semantic markup at best.

Many pages around the web use microformats to add more structured semantics than available in HTML’s impoverished set of elements and attributes. In this case, the values used for the class attribute come from agreed-upon vocabularies, sometimes adopted from other standards, such as vCard, sometimes from newly minted vocabularies where no solid pre-existing standard exists (as is the case for hReview).

Extensible semantics

There is a very real problem that needs to be solved here. We need mechanisms in HTML that clearly and unambiguously enable developers to add richer, more meaningful semantics—not pseudo semantics—to their markup. This is perhaps the single most pressing goal for the HTML 5 project.

But it’s not as simple as coming up with a mechanism to create richer semantics in HTML content: there are significant constraints on any solution. Perhaps the biggest one is backward compatibility. The solution can’t break the hundreds of millions of browsing devices in use today, which will continue to be used for years to come. Any solution that isn’t backward compatible won’t be widely adopted by developers for fear of excluding readers. It will quickly wither on the vine.

The solution must be forward compatible as well. Not in the sense that it must work in future browsers—that’s the responsibility of browser developers—but it must be extensible. We can’t expect any single solution we develop right now to solve all imaginable and unimaginable future semantic needs. We can develop a solution that can be extended to help meet future needs as they arise.

These two constraints in tandem, present a huge challenge. But in the context of a language whose major iterations arrive a decade apart, and whose importance as a global platform for communication is paramount, this is a challenge that must be solved.

So, how is HTML 5 addressing this issue? HTML 5 introduces a number of new elements. Some of these are what I’ve termed “structural”—section, nav, aside, header, and footer. The dialog element is a kind of content element, akin to blockquote. There are also a number of data elements, such as meter, which “represents a scalar measurement within a known range, or a fractional value; for example disk usage,” and the time element, which represents a date and/or a time.

While these elements might be useful, and seem to have generated some interest, do they really solve the problem we’ve identified, particularly within the twin constraints of forward and backward compatibility?

Let’s consider each constraint.

Backward compatibility

How do current browsers handle these new elements, such as section? Well, the most recent versions of Safari, Opera, Mozilla, and even IE7 will all render a page as follows.

<h1>Top Level Heading</h1> <section> <h1>Second Level Heading</h1> <p>this is text in a section element</p> <section> <h1>Third Level Heading</h1> </section> </section> 

It looks like an excellent start. But when we try styling, for example, section elements with CSS that looks like this:

section {color: red}

…most of the above-mentioned browsers manage to style the element, but IE7 (and so presumably 6) do not.

So we have a serious backward compatibility issue with 75% of browsers currently in use. Given the half-life of Internet Explorer, we can predict that most users will be using IE6 or IE7 even several years from now.

If HTML 5 introduces these new elements, what is the likelihood they’ll be implemented by the vast majority of developers—given the knowledge that they’re essentially incompatible with the majority of browsers in use?

Unfortunately, if you are looking for alternative solutions to the CSS problem, putting class attributes on your section elements and then trying to style them using the class value won’t work in IE. Perhaps there is some kind of workaround out there, but unless there is, that looks like a deal breaker right there.

Let’s turn to forward compatibility, the second constraint.

Forward compatibility

We’ll start by posing the question: “why are we inventing these new elements?” A reasonable answer would be: “because HTML lacks semantic richness, and by adding these elements, we increase the semantic richness of HTML—that can’t be bad, can it?”

By adding these elements, we are addressing the need for greater semantic capability in HTML, but only within a narrow scope. No matter how many elements we bolt on, we will always think of more semantic goodness to add to HTML. And so, having added as many new elements as we like, we still won’t have solved the problem. We don’t need to add specific terms to the vocabulary of HTML, we need to add a mechanism that allows semantic richness to be added to a document as required. In technical terms, we need to make HTML extensible. HTML 5 proposes no mechanism for extensibility.

HTML 5, therefore, implements a feature that breaks a sizable percentage of current browsers, and doesn’t really allow us to add richer semantics to the language at all.

Several questions remain about the new elements. Where have these new element names come from? How was it decided that there should be a navigation element, and that it should be called “nav”? Why should the same term apply to page-level, site-level, and meta-site-level navigation?

Why not adopt an existing vocabulary, such as Docbook? Its document structure vocabulary is far richer and it’s been developed by publishing experts over many years. This is not an argument in favor of Docbook, specifically: the point is that the extremely important task of providing a mechanism for semantic richness in HTML is being approached in an ad hoc way, paying apparently little attention to best practices in related work going back 30 years or more. (The original work on GML began in the early 1970s.)

Some thoughts on a solution

So, having been critical of current efforts, do I have any practical suggestions on how to solve this problem? Well, I have the start of one.

If adding elements to HTML is out of the question, at least within the parameters of this discussion, attributes are the other logical area of HTML to concentrate on. After all, for nearly a decade, we’ve been using class and id attributes as mechanisms to extend the semantics of HTML. A great many developers are familiar and comfortable with this. The microformats project demonstrated that the existing attributes of HTML are not sufficient, as a generalized mechanism, to extend the semantics of HTML. So, if we are to use attributes to help solve this problem, we need to come up with one or more new attributes. Before we get into the mechanics of how that might work, it’s only fair to subject this suggestion to the same requirements we have for the new elements of HTML 5. Most importantly, is introducing new attributes to HTML backward compatible? And if so, does it provide a workable mechanism for semantic extensibility in HTML?

Let’s invent a new attribute. I’ll call it “structure,” but the particular name isn’t important. We can use it like this:

<div structure="header">

Let’s see how our browsers fare with this.

Of course, all our browsers will style this element with CSS.

div {color: red}

But how about this?

div[structure] {font-weight: bold}

In fact, almost all browsers, including IE7, style the div with an attribute of structure, even if there is no such thing as the structure attribute! Sadly, our luck runs out there, as IE6 does not. But we can use the attribute in HTML and have all existing browsers recognize it. We can even use CSS to style our HTML using the attribute in all modern browsers. And, if we want a workaround for older browsers, we can add a class value to the element for styling. Compare this with the HTML 5 solution, which adds new elements that cannot be styled in Internet Explorer 6 or 7 and you’ll see that this is definitely a more backward-compatible solution.

Extensibility through attributes

Instead of new elements, HTML 5 should adopt a number of new attributes. Each of these attributes would relate to a category or type of semantics. For example, as I’ve detailed in another article, HTML includes structural semantics, rhetorical semantics, role semantics (adopted from XHTML), and other classes or categories of semantics.

These new attributes could then be used much as the class attribute is used: to attach to an element semantics that describe the nature of the element, or to add metadata about the element.

This is not dissimilar to the role attribute of XHTML, but rather than having a single attribute “bucket” for all element semantics, we should identify the different types of semantics for an element, and separate them out.

For example, the XHTML role attribute works like this:

<ul role="navigation sitemap"> <li href="downloads">Downloads</li> <li href="docs">Documentation</li> <li href="news">News</li> </ul>

The values of the role attribute are a space-separated list of words from the default vocabulary, or from a defined vocabulary.

Why not simply adopt the role attribute as-is? Well, there are other kinds of semantics for which the term role doesn’t apply. For example:

<p rhetoric="irony">He’s a fantastic person.</p>

This demonstrates a theoretical type of semantics—“rhetoric,” which could be used to markup the rhetorical nature of a document. This element clearly doesn’t play the role of irony in the document. Rather, the contents of the element are ironic.

Here is another example. It’s increasingly obvious that HTML lacks a way to attach a machine readable version of a humanly readable value, e.g., a date. This is at the heart of the problem the BBC has with the hCalendar microformat that we referred to earlier. While <span role="2009-05-01">May Day next year</span> really doesn’t make sense, something along the lines of <span equivalent="2009-05-01">May Day next year</span> would.

Again, whether we use the specific term “equivalent” or some other term for this kind of semantic attribute is not the issue. What’s important to note is that it’s not as simple as using either the class attribute or the role attribute as a one-size-fits-all bucket to hold semantic information. For a properly extensible solution that provides backward compatibility and sufficient flexibility, a solution along these lines looks worth investigating.

I titled this section “some thoughts on a solution” because a significant amount of work needs to be done to really develop a workable solution. Open questions include the following.

  • How many distinct semantic attributes should there be? Should these categories be extensible, and if so, how?
  • How are vocabularies determined?
  • Do we simply invent the terms we want, in much the same way that developers have been using class values, or should the possible values all be determined by a standardized specification? Or should there be a mechanism for inventing (and hopefully sharing) vocabularies, using some kind of profile?
  • If we have a conflict between two vocabularies, such that two identical terms are defined by two different vocabularies, how is this resolved?
  • Do we need a form of name spacing, or does some other mechanism exist?

Rather than rushing to answer these questions, I’m posing them to highlight the issues that need to be addressed, and to start a dialog. The ramifications and reach of decisions made in HTML 5 are too great for decisions to be made in the absence of at least some input from those highly knowledgeable about linguistics, semantics, semiotics, and related fields.

Hopefully, if nothing else, then it’s clear that simply “making up new elements” isn’t a solution to how to increase the semantic capacity of HTML.

Let’s not rush into these decisions lightly—after all, with climate change we’ve saddled our grandkids with enough trouble as it is. Let’s at least leave them the best possible HTML we can.

Whether or not a project can accommodate new HTML5 and CSS3 features, we still turn to JavaScript to provide users with rich and meaningful experiences, including inline form validation, error handling and live page formatting. The key difference between JavaScript and traditional HTML and CSS is that the former is a programming language. Thus, JavaScript is capable of powerful results and tricky logic but is less friendly to sloppy coding and human error. This latter characteristic leads me to my main advice about using JavaScript on your new website.

Enhance, Enhance

The first rule in applying JavaScript to your website is to test failures. What happens in a browser that has JavaScript disabled? What happens if you make a request to a geo-location API that the user declines? If either of these paths make all or a portion of your website inaccessible or inoperable, then this solution would be unacceptable, and an error- and interruption-free approach would need to be found. Much like how we currently approach CSS3, JavaScript should be used as a tool to enhance the user’s experience, not as a band-aid for quick results. If you rely on it to deliver the experience, then you are setting your website up for failure.

This might make it seem like JavaScript is not worthwhile to the design process, and indeed in some situations it may not be. One of the dangers of using any dynamic or script-based solution is that they can be so much fun to implement. Designers often get caught up in how cool these tools are and get distracted from considering whether everyone would have the same experience.

On the other hand, for adding meaningful functionality to a design, such as those mentioned earlier, JavaScript can have a truly magical effect. One of the more common examples of good JavaScript usage is inline form validation. We have all made an error in a Web form only to find out after having hit the “Submit” button, forcing us to go back and re-enter the information; in many cases, sensitive information such as passwords and credit card numbers needs to be re-entered as well. Alerting users to mistakes in real time makes online forms significantly less frustrating. Of course, we have a lot of tools and libraries out there to help us with this, as well as other great interactive features.

InlineValidation1 in The Neglected Necessities Of Design

Keeping It Tidy

With all of these JavaScript tools at our disposal, going overboard and using as many as we can is easy, especially if we can justify their presence as enhancing the user experience. But keep in mind that with each new JavaScript library, plug-in or solution, we are adding files and lines of code to our pages that users have to download. With each bit of functionality, we have a trade-off with performance.

We can do some things to curb the performance trade-off. The most common way to optimize JavaScript is to concatenate and minify the files. Keeping multiple JavaScripts in a single optimized file reduces the number of calls that the website has to make to the server. For high-traffic solutions and clients who demand peak performance, this simple trick can save a lot of money. Of course, at a certain point, a single JavaScript file becomes too long and therefore a hindrance to the website and a nightmare to maintain.

Beyond optimization, there are techniques we can follow to keep JavaScript from weighing us down. One technique is parallel script loading. Loading your scripts in parallel will reduce blocks on the browser and save loading time, especially in older browsers that load linked resources one at a time. A great resource for this is the Head JS project.

Aside from parallel loading, developers have been taking advantage of selective loading techniques for years. This is often referred to as lazy loading, where you call external JavaScript files only where you need them. This is another resource-saving technique.

Pulling It All Together

Giving your website a clean and concise structure opens the door to myriad opportunities. Search engines will have an easier time indexing your content; screen readers and accessibility devices are less likely to be confused by the structure of your website; users on cellular networks can download your content faster; and designers will be able to expand with the latest and greatest techniques.

Let’s be honest, though. Putting a website together the right way does take more time and money up front. The whole team has to take extra caution and spend more time in the planning stages, making sure that everything is considered with the future in mind. Before a website is implemented and introduced to users, it needs to go through a scrubbing process that might not yield any changes in the front end. Finally, project stakeholders are forced to spend time thinking about scenarios (which may or may not happen) in which the natural order of their website is disrupted.

Many of these reasons have led us to implement less-than-ideal solutions in the past for the sake of meeting deadlines and budgets. But how often have we been forced to go back and fix something that wasn’t done correctly the first time? How much money are companies spending to get rid of bad practices that seemed harmless at the time but have left their websites expensive to update and maintain? Building rock-solid code and taking advantage of the power of modularity enables our websites to grow and saves much more than it costs by negating the need for another redesign just two years later.

It is for all of these reasons that the core necessities of a good website have been neglected for far too long.

When it comes to conservative code, CSS files usually get the short end of the stick. Grabbing all of the presentation and layout information from the HTML and dumping it in the CSS has finally become a standard process for most designers. (If it isn’t yet, make it yours.) While this is the exact purpose of a style sheet, there are plenty of methods by which a designer can make sure that the CSS that loads for every page is, like the HTML, as clean and concise as possible.

CSS as a Process

For many designers, the process of building a style sheet consists of starting with the outer containers of the HTML structure and working their way in, aligning and styling as they go. How many times have you sized and centered your #wrapper element, and then moved onto aligning the logo and primary navigation in the <header>, and then continued your way down the page? This process certainly works, but there is a much better and quicker way to handle CSS. Much as we did with the HTML, we can recycle code and use a modular approach in a way that makes more sense and takes less time.

Instead of designing a style sheet with the HTML in mind, we should carry over our mindset from the rest of the design process, putting the user first. In our new and improved CSS process, let’s start with the most important and prevalent elements of our design. These will almost always be the content. The whole point of delivering clean and semantic code is to ensure that no matter what the screen, device or context of our visitor, they will have access to the fantastic message that our website is trying to convey. For this reason, we’ll start the primary portion of our style sheet with the typography.

01 body, select, input, textarea {
02     font: normal .825em/1.25em Tahoma, Geneva, sans-serif;
03     color: #353838;
04 }
05 h1, h2, h3, h4 {
06   font-family: Georgia, "Times New Roman", Times, serif;
07   color: #202020;
08 }
09 h1, h2 {
10   font-size: 1.875em;
11 }
12 h2 {
13   text-align: center;
14   font-weight: bold;
15   line-height: 1.5em;
16   border-bottom: 4px solid #e5e5e5;
17   -webkit-box-shadow: 0 1px 0 #b2c6e1;
18    -moz-box-shadow: 0 1px 0 #b2c6e1;
19       box-shadow: 0 1px 0 #b2c6e1;
20   margin: 1em 1.25em;
21 }
22 h3, h4 {
23   font-size: 1.25em;
24   margin: .75em;
25 }

When it comes to text, we start with the most global rules and get more specific as we move down the style sheet, a pattern that should be repeated for other portions of the website.

Because typography is usually the most heavily used element on a website, it stands to reason that we should define our core font rules on a high-level element, such as the <body> element. If we want different typographic rules for headlines or certain page elements, we can declare them just after the default settings. If you have trouble figuring out which typographic declarations to add to your high-level selector and which to use as overrides, simply mark them all up and then identify which are the most common. Apply the most common declarations to the high-level element, and build specificity as you go forward.

With the typography set and the HTML structure solid, we have a website that could technically be delivered as a functional product to any device or browser. Anything we do from this point on should be to enhance the user’s experience.

For many designers, enhancing the experience starts with coloring the page. After typography, the color palette is arguably the element that most affects a website, and therefore should be next in the style sheet. I find that a good color palette is ingrained in every level of a design, and that breaking colors out into a separate section of the CSS leads to a lot of extra lines of code and a lot of selectors that are used solely for color but that have twins throughout the style sheet serving other purposes. I am not a fan of branching a single selector into different bits for the sake of lining up declarations. However, neither method is inherently good or bad. Find a system that works best for you, and maintain consistency across the project.

Finally, we get to the structure and layout of the website. With wonderful typography and eye-catching colors sprinkled throughout our website, we can line things up the way they should be and in a way that makes the website easy to read, navigate and interact with. We can continue with the method we adopted for the typography, putting the general rules first and then getting into the details later on. One thing that will hold us back is the lack of a hierarchy in HTML for anything other than typography.

Looking at the elements included in HTML4, the specification was clearly not prepared to support the complex layouts that designers and clients demand today. We had six levels of importance for headlines, but only abstract elements like <div> and <span> for structure, with no way to indicate hierarchy. HTML5 has gotten us closer, but we aren’t there yet. To make up for this, let’s look to the global class structure that we started implementing in our HTML earlier. We used the .contentContainer class to define the areas of our website that will be visual containers for our content. This class gives us the power to style a big portion of our website quickly and allows us to easily add new containers later without having to force them to fit the style of our website using CSS.

1 header, footer, .contentContainer {
2     background: #f1f1f1;
3     -webkit-box-shadow: 0 0 15px rgba(0, 0, 0, 0.25);
4       -moz-box-shadow: 0 0 15px rgba(0, 0, 0, 0.25);
5         box-shadow: 0 0 15px rgba(0, 0, 0, 0.25);
6     border-radius: 3px;
7 }

Reduce, Reuse, Recycle

Much like with HTML, style sheets can get pretty funky when we get to the point of adding and removing individual declarations in order to get an element to look or behave the way we want. The gracious way in which Web browsers handle CSS rules that they don’t understand or don’t need makes this practice rather common, thus bloating our style sheets. For this reason, go back through the style sheet at the end of the day and remove any rules that no longer serve a purpose. The task is a painstaking one, but as with most such tasks, plenty of tools exist to help us along.

Another task that can save size and space is to group selectors that have the same set of style declarations. From a technical standpoint, it makes sense to create a group of selectors whenever two or more share at least one declaration. I love to take advantage of grouping selectors by using something I call CSS effects. With some of the new CSS3 declarations, I’ve found that I can move the layer styles that I copy and paste in Photoshop right into my style sheets.

1 .mainBox, .secondaryBox, .footerBox {
2     background-image: -moz-linear-gradient(rgba(0, 0, 0, 0.3), rgba(0, 0, 0, 0));
3     background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, from(rgba(0, 0, 0, 0.3)), to(rgba(0, 0, 0, 0)));
4     background-image: -webkit-linear-gradient(rgba(0, 0, 0, 0.3), rgba(0, 0, 0, 0));
5     background-image: -o-linear-gradient(rgba(0, 0, 0, 0.3)), to(rgba(0, 0, 0, 0));
6     background-image: -ms-linear-gradient(rgba(0, 0, 0, 0.3)), to(rgba(0, 0, 0, 0));
7     background-repeat: no-repeat;
8     border: 5px solid rgba(0, 0, 0, 0.2);
9 }

We can apply this declaration stack to any element on our page to achieve a gradient. The use of RGBa allows us to retain the background colors of individual elements and to “outsource” the gradient style to a common selector.

CSSeffects in The Neglected Necessities Of Design

When combined with healthy HTML practices, spending more time on the essential pieces of solid Web design results not only in faster pages and a lighter server load but, more importantly, in a user experience that thrives on any platform regardless of the design method employed. Speaking of user experience, we still need to add one important piece to this puzzle.

As web designers, we all seem obsessed by HTML5 and CSS3 at the moment. Endless posts, tutorials and discussion about them dominate the blogosphere. But how much are we learning that can be applied today?

Don’t get me wrong. We all need to understand HTML5 and CSS3. And a lot of it can be used today.

My point is that we seem to be spending a disproportionate about of time reading up on the subject when so many other areas deserve our attention.

While others are reading yet another tutorial on CSS animation, why not broaden your horizons by researching subjects that will allow you to offer an even better service to clients?

I’ll share with you five areas that I believe are much neglected and that we need to learn more about.

Demo of a 3D sphere created in CSS3

Do you really need to know how to create a 3-D sphere in CSS3? (Image: Paul Hayes)

1. Customer service

“Customer service?!” you cry. “I don’t work at Starbucks!”

If that’s your attitude, think again. Customer service lies at the heart of everything we do as web designers, and yet we rarely think about it, let alone read anything on the subject.

A member of staff working in starbucks.

You may not work at Starbucks, but customer service is intrinsic to our role as web designers. (Image: ChiBart)

We need a good grounding in customer service for a couple of reasons. First, we are in the service business. We like to think that we build stuff, but actually we are offering a service to our clients. We don’t just build websites: we guide clients through an unfamiliar process and provide a lot of advice and support along the way.

Secondly, the majority of websites that we build have a strong element of customer service. We provide a service to end users in the form of either an application or, more often than not, information.

Whether we want to offer a better service to clients or end users, the message is the same: we need to brush up on our customer service skills.

My recommendation is to start by subscribing to a few customer service blogs. Customer Experience Matters a good starting point.

2. Psychology

Understanding of psychology should be woven into every aspect of our job, from sales to project management to user interface design to design aesthetics. Everything we do as web designers should be informed by knowledge of how people think.

Unfortunately, few of us have taken Psychology 101. What we do know we have learned instinctively rather than through any formal training. We design based on gut reaction rather than informed knowledge.

Being able to get inside the heads of others is crucial, whether it’s users or clients. Whoever it is, we have to know our stuff.

Stephen Anderson's psychology resources

A great introduction to the field of human psychology, curated by Stephen Anderson. (Image: Mental Notes)

Thankfully, Stephen Anderson has pulled together a great set of resources to introduce the field of human psychology. If his extensive list is a little intimidating, I recommend starting with “Made to Stick” or “Nudge.” “Neuro Web Design” is very good, too.

3. Context

There was a time when you could make an educated guess at the user’s context. Surfing the web was done at a desktop computer in relative quiet. Unfortunately, despite those days being long gone, many of us still assume that context when designing websites.

The reality is very different. For starters, we rarely have the user’s full attention. They are surrounded by distraction, both offline and on. The computer is now as likely to be in the family room with kids running amok as in a quiet study. While looking at your website, the user is probably also checking email, catching up with friends on Facebook and tweeting.

The problem doesn’t end there. We no longer just surf the web on a desktop computer. There are netbooks, tablets, televisions and mobile devices of all shapes and sizes.

Girl using a mobile phone while on a train.

We can no longer assume that people access the web from a desktop computer. (Image: Shutterstock)

Unfortunately, not a huge amount has been written on the subject, beyond my own rambling thoughts. But I am convinced this will be a defining factor in web design over the coming years.

If we want to continue creating cutting-edge websites, then we need to take context seriously. Ultimately, good web design is more about context and content than HTML5 and CSS3.

4. Content strategy

How did we ever decide that content was the client’s problem? Why should we expect them to know about writing for the web when we, as self-proclaimed web experts, do not?

Content is the foundation of every website. This includes content in all its forms: images, text, video, audio and functionality.

How a website is built and what it looks like pales in comparison to the content. Still, many of us regard it as the client’s problem.

Clients will be demanding a lot more help to get their content right, and if you don’t offer it, then they will turn to your competitors. I would be willing to bet my company on it.

Don’t get me wrong. You don’t need to become an expert content strategist. As McCoy would say, “Damn it, Jim! I’m a web designer, not a copywriter.” (Okay, he was a doctor, but you get the point.)

But just because you are not a content strategist doesn’t mean you can ignore the basics of writing for the web. You should know what a content audit is, how to make copy more scannable, and what goes into a style guide.

If you can’t answer these (and many other similar questions), then it is time to upgrade your skills. A good starting point is anything by Relly Annett-Baker, or get your hands on Kristina Halvorson’s book Content Strategy for the Web.

contentstrategy.com/

Kristina Halvorson’s book Content Strategy for the Web is great for learning the basics of content strategy.

5. Strategy

Things used to be so simple for the average client. They came to you, and you built a website that sold whatever service they were selling. Now we ask them complicated questions about business objectives, success criteria and calls to action. Compounding their worries, they have to think about Facebook, SEO, Twitter, user engagement and endless buzzwords.

In short, the average client is no longer looking for someone to just build a website. They are looking for a consultant to guide them through the confusing online world. They need someone who can look at their business and answer one simple question: how can the web best help them?

The problem is that most web designers are either frustrated artists or code monkeys (okay, maybe that’s a stretch). But we are not business advisers.

Geek Dressed as Business consultant

How much do we really know? (Image: Shutterstock)

We like to think that we know how the web can benefit a business. But we really don’t know that much. We are not schooled in business theory, marketing or economics.

Again, we don’t need to pretend to be something we’re not. But we do need to improve our basic understanding of these topics so that we are at least capable of having a discussion with business folk about how the web can help them.

When was the last time you read an article on direct marketing or corporate restructuring?

The problem

Herein lies the problem. We are so busy reading HTML5 tutorials and looking at CSS3 demos that we miss these other areas.

We are scared by what we do not know, and so we tether ourselves to subjects that we have a handle on. But as the web becomes more complex, we will need to broaden our horizons.

I am not suggesting that we all become generalists. I am saying that our skill set should be T-shaped. We need broad superficial knowledge of a lot of subjects and then deep insight into one area. The problem is that most of us don’t look beyond that one area of expertise.

If you don’t broaden your outlook, clients will look elsewhere.

Written exclusive for WDD by Paul Boag.