A Web Standard is both a guide and a measure. I believe that Web Teams that invest enough time and the enough effort into Web Standards, will reap the benefits. We covered this in a previous post. Today, we dive straight in with a concrete example: URL Naming Web Standard. Note, just to keep this post to a reasonable length, I’ve had to trim it down. Rest assured it does have enough meat in there to illustrate what is a Web Standard.
URL Naming
A URL Naming Scheme clearly outlines how information is accessed across a Web Site.
Rationale
A clear, consistent and agreed upon URL Naming Scheme leads to better site organisation. It also has the added benefit for improved crawling of site documents by search engines.
URL Naming aims to create friendlier URLs for visitors to link to site content. Early consideration of a URL Naming Scheme addresses key questions around:
- How content owners expect site visitors to access content.
- What content providers should be thinking about when contributing content, and
- How information is organised.
A clear and upfront understanding of the URL Naming Scheme informs Content Structure, which in turn informs Site Design.
Conditions
1. All letters in the URL should be lowercase.
2. Use ‘-‘ to separate words in rather than spaces or underscores (‘_’).
3. All items on the URL Name Path should contribute to the understanding of the content.
4. Use
real names
for actual documents rather than
ids
where possible.
5. Opt for a ‘wide and shallow’ URL Naming Scheme over a ‘narrow and deep’ one.
6. One URL, one document. Do not have multiple URLs referring to the same document.
Examples
Consider the following URLs:
1. http://www.guardian.co.uk/politics/2010/may/08/david-cameron-faces-tory-anger
2. http://news.bbc.co.uk/1/hi/uk_politics/election_2010/8669508.stm
They both adhere to recommendations 1,2 3, 5 and 6. However, for recommendation 4, the Guardian does better than the BBC which unfortunately uses a less meaningful id of 8669508 for a similar story.
Multiple URLs for the same content can creep in by:
1. Having sub-domains access the same content (e.g. www.domain.com/mycontent.html vs. docs.domain.com/mycontent.html).
2. Mixing www.domain.com and domain.com versions of URLs within the site. Always use the www.domain.com version.
3. Using odd capitalisation of URLs (e.g. www.domain.com/MyContent.html vs www.domain.com/mycontent.html). For Windows IIS Web Servers these pages will be served back no problem, and hence you have two URLs for the same content.
Dependencies
Not Applicable.
Sources
http://www.google.com/webmasters/docs/search-engine-optimization-starter-guide.pdf
Tags
seo, url, design, domain
Using Web Standards
If you develop Web Sites, you can’t escape the URL question. It’s always there. But after years of asking the same questions, project after project, and getting the same answers, time and time again, the Web Standard embodies 90% of the common sense thinking. No need to re-invent the wheel. The Web Standard outlines the agenda. The starting point for discussion within the Web Team and between third party contributors. Feedback is given and a Web Standard specific to the project in question is the end result.
For a particular Client, a URL Naming Web Standard may hold for all its Web Sites. Or maybe for one department. Or just for its Microsites and have slightly different versions for extranets and/or intranets. What’s important is that the Web Team has a useful and useable guide for URLs that is measureable. Moreover, the Web Standard is clear, actionable and digestable. Not a verbose, obtuse, wall of text that unfortunately is the mental image most people conjure up when they hear the dirty words ‘Web Standard’. It doesn’t have to be this way.
Best Practice or Web Standard?
I get this question a lot. Is URL Naming a Best Practice or a Web Standard? Well that depends largely upon how it is enforced. Again, an example. You and your Web Team have been asked to build a new Web Site. You agree upon a URL Naming Scheme, tweaking it here and there. Finally, you’re happy and you communicate its rationale to all members of the Web Team. Now, URL Naming is a Web Standard if:
- It’s mandatory.
- Steps are taken to ensure the Web Sites URLs are compliant.
- The Web Site fails Quality Assurance because its conditions have not been satisfied.
If the use of URL Naming is optional and its application is NOT enforced, it’s considered best practice.
A Web Standard does not have to be hundreds of pages long. It doesn’t have to be approved by industry bodies or Internet task forces. A Web Standard is a means by which the quality of your Web Team’s deliverables can be measured. With this, the Web Team has a clear benchmark for success or failure. The QA Team knows how to define success. The Web Standard is enforceable. A welcome hoop that the QA Team makes the Web Development Team jump through.
Web Standard Template
Okay, I’ll leave you with an updated version of a Web Standard Template. This is a works in progress. If you have any suggestions for making this better and/or examples of your own, please leave a comment.
Name
The What: What does the Web Standard do?
Rationale
The Why: What is the reasoning behind the Web Standard; the problem its attempting to address.
Conditions
The How: The list of conditions that must be met in order to satisfy the Web Standard.
Examples
Demonstrate by example how best to apply the Web Standard.
Show how the Web Standard satisfies its conditions, highlight key trade-offs and the results of applying it.
Dependencies
What other standards, best practices, recommendations does the Web Standard rely upon?
Sources
Provide links to reference material, articles and supporting documentation.
Tags
Improve the Web Standard’s findability.
Tag with phrases the Web Team will use search/refer to the Web Standard.
For example: seo, design, authoring, workflow, accessibility.
