I just read a short, relatively old blog post by David Naylor regarding why he believes XML sitemaps are bad. People involved with SEO probably know and recognize the name. I know I did. I have to disagree with his premise, but agree with his argument.

I say XML sitemaps are good!

The real issue with XML sitemaps does not lay in the technology but the use. If a site is well designed, well developed and has a strong information architecture, it should spider well and indexing should occur. Moreover, if the HTML/XHTML supporting the information on the site is well formed, the site should get decent rankings. This is where I agree with David.

I disagree on the grounds that there is nothing XML sitemaps do that other SEO best practices won’t do. There is one clear item on this docket. Update frequency. There is no better tool I know of for announcing update frequency than an XML sitemap.

Within the standard for sitemap generation, update frequency can be denoted. By setting the update frequency appropriately, the spider will have an indicator to how often it should visit. This is really important in assuring that a spider will revisit your site and pick up new pages regularly, especially for new sites. Established sites may not suffer from the same kind of crawl frequency, but even there, it is good practice to make things as easy for the search spider as possible.

While we are on the topic of unique features, XML sitemaps also offer an opportunity to reinforce your navigation hierarchy. Page priority can be specified, giving the search engine an early indicator to what will be found in the site. Search spiders dislike hunting through site links to discern information for which they could, otherwise, have a pre-set baseline.

It should be stated that XML sitemaps, when held isolated, do not cure all ills. They are merely one more tool in the locker that allows a site to grow and benefit from good search ranking. When sitemaps are coupled with strong content, good code, description tags, thoughtful information architecture and careful navigation, they can only be a boon to your site.

When used correctly, an XML sitemap will drive search spiders to key pages faster and ensure early indexing of the entire site. Once this initial indexing is managed, it is up to the people who maintain the site to ensure that the path is clear to access information across the site.

Ultimately, David does not argue against sitemaps but, instead, chooses an easy target like poor navigation and concludes that because there are users that don’t use a sitemap properly, the technology must be bad. This is disappointing as it seems to lead potential SEO professionals astray. XML sitemaps are your friends and when treated with the kindness and care a friend deserves, they will only be a boon to your site. Build your site well, use sitemaps intelligently and make the web a better place.

Today, at the time of this writing, Google posted a blog stating they were dropping support for old browsers. They stated:

The web has evolved in the last ten years, from simple text pages to rich, interactive applications including video and voice. Unfortunately, very old browsers cannot run many of these new features effectively.

I made a case to move in the same direction at my company less than a month ago. I reviewed the visitor statistics and discovered less than 10% of all visitors to our sites use Internet Explorer. Months ago, Digg posted a blog asking whether they should block Internet Explorer 6 from viewing the site. Their statistics represented similar numbers to our own.

This would be a fairly radical move as blocking someone from viewing a site seems like a fairly aggressive move on Digg’s part. My proposal was much more relaxed and forgiving. I proposed that I upgrade Internet Explorer on my computer and stop supporting version 6. This doesn’t mean I plan to block people from the site if they haven’t upgraded, it just means I’ve consciously deprecated their choice.

A while back, I posted a blog about browser wars and how people were behaving on the web. I would never condone a conscious exclusion of one visitor or another simply to support my favorite browser. This is unfair and, moreover, can alienate the user in a way that will discourage people from ever returning to my site, even if they opted for my preferred browser.

I am certain someone is asking why 10% is a good threshold for clipping browser support. I assure you, the number is arbitrary. Some people may want to choose a higher or lower number, depending on what their audience needs. Regardless of the particular number, the important thing is the direction the percentage is headed.

When Firefox first hit the market, to say it wasn’t interesting as a browser because it didn’t have a large enough market share would have been perceived as foolish. Firefox use was on the rise, so catering to the users would have been in the best interest of all involved.

Internet Explorer 6 use is on the decline and the dropoff is getting steeper. As users buy new computers and upgrade their software, IE6 gets wiped out. Moreover, Microsoft started campaigning years ago for users to upgrade to a newer version of Internet Explorer.

Something of note, Internet Explorer has been around for almost a decade now. As technology moves forward, IE6 only becomes more obsolete. One of the easiest examples to point to is the support for alpha-transparency PNGs. IE6 renders PNGs with alpha transparency with a blue background. Unless your site is already the particular shade of blue which is rendered, the transparent graphics are going to look cludgy and out of place on your site.

Other items of note, which are important to developers more than users, are things like new Javascript technologies and updated CSS specifications. As these technologies improve and grow, IE 6 will continue to to seem more and more obsolete, much like how IE5.5 appeared after IE6 hit the market.

To be fair, there are other old browsers which also fall down when pushed to render web sites using new technologies. The difference is, new browsers have built-in functions to test for updates. IE6 is old enough that Microsoft didn’t think to build that kind of functionality. They relied on users going to the Microsoft website and upgrading by hand.

In the end, we have reached a breaking point. Old browsers which are no longer supported, even by the company that built them, will eventually need to be clipped from the support regime that so many companies and individuals adhere to. Instead of blocking them, however, try the gentler approach of simply forgetting about them and letting them fade into the past. Be kind to your users, give them a gentle nudge to update and upgrade. Never push them off the cliff. Be aware of the browsers you support and make the web a better place.

People are creative. It’s a fact of the state of humanity. People want to make things. It’s built into the human condition. But there is a difference between haphazard creation and focused, goal-oriented development.

Andy Rutledge states that creativity is not design. I agree with him. Creativity alone does not solve problems. Creativity, when allowed free reign, is as much a destructive force in business projects as it could be a productive partner.

Creativity can be a great driver for new ideas, but when creative focus remains the primary focus, the end product is bound to suffer. Web sites can prove a noteworthy breeding ground for creative direction overriding good problem solving.

I will avoid mentioning any sites that I have found which are better macaroni and finger-paint project than they are solutions to existing problems. I tend to agree with Steve Krug that it is hard to make a really effective site and easy to botch the job.

Andy Rutledge has already said quite enough about creativity versus visual design that I don’t feel I should elaborate any further. There are plenty of other aspects of a project that people get slick and tricky with.

Visual elements within a design can be a killer when you have someone that wants to expend lots of time being creative. Regardless of the fact that the visual elements on a site can be referred to as artwork, it is not art like they have in your local coffee shop.

Before I started working at my current company, there was a designer that was interested in photography. When working on a particular marketing folder, he spent weeks creating a set, cutting out styrofoam letters and shapes. He set up backdrops and lights. Eventually he came away with just the right shot. Truth be told, it looked so perfect I swore he rendered it in a 3D imaging program.

The problem is he was more focused on being creative than working on business needs, The folder he created looked nice but it was far too costly in time and salary. Creativity can be a major expense on a project for only a small improvement, if there is improvement at all.

Even if your designer stays sharp and focused, other issues can arise. Copywriters can get creative, which can be as detrimental to the message as any overwrought design. A good copywriter will stay focused on company goals, speak in simple language and cut straight through the goals of the business.

Bad copy can take a good design and tell your user that the company looks great on the outside, but suffers from a lack of direction on the inside. Creative copy can be painful. Often, a creative writer is going to show their love of the language so they will use too much of it. Focus and simplicity is key.

The last problem I am going to bring up, though there are a large number of other issues that arise out of overly creative thinking, is creative development.

Development involves anything from site hierarchy and architecture to coding and various other elements which make the site recognizable as an interactive information machine.

When an information architect or user experience designer/developer allows creativity get in the way of focusing on the user, the results can be disastrous. The site flow will suffer and navigation will become obvious to the user.

Obvious site navigation and structure is painful. The user notices because they find themselves frustrated and lost. Lost, frustrated users leave, never to return.

Finally, the engineering development which goes into the site must be clear. Problems must be solved in a clean, thoughtful way, but creativity cannot drive this aspect of the project.

One of the most detrimental things to a project life cycle is a creative engineer. Engineers that are being creative first and solving problems second are engineers looking to add unnecessary features.

The cliche of the feature-happy engineer comes from a creative engineer. Good engineering requires a smart, creative problem solver. The key is solving a problem. If an engineer is allowed to create a solution that lacks a problem, the engineer is guaranteed to derail your project as fast as you can imagine.

In the end, business solutions require a clever, focused team. Creativity should be harnessed and directed toward solving existing problems. When creativity is allowed to run rampant in a business environment, the results can be damaging to the user experience and the business image. Go forth, solve problems and make the web a better place.

When given a task of making search terms and frequetly visited pages more accessible to users, the uninitiated fire and fall back. They leave in their wake, broad, shallow sites with menus and navigtion which look more like weeds than an organized system. Ultimately , these navigation schemes fail to do the one thing they were intended for, enhance findability.

Though one of my latest projects was the final straw, prompting this post, I’ve seen teams approach sites with the goal of findability and navigability in mind, only to end up with a system of menus and a field of links that are almost impenetrable to even the most tenacious of webonauts. Documents, pages and external links mingle in a taxonomic and architectural nightmare.

Perceived site architecture is to blame for this iniquity, regardless of the real information hierarchy. Although broad and shallow architecture is fine for small, simple sites, it is unforgiving as the site grows and the number of pages needed to contain all of the information provided balloons up.

Broad and shallow architecture is precsiely what it sounds like. Instead of crafting a set of taxonomical structures and an architecture that reflects the hierarchy of information on the site, broad and shallow architecture offers all pages at the same level and provides no understanding of the interrelation between pages and the information they contain.

When search and analytics data is taken without proper insight, it can quickly become confusing to try and unravel the intent of the users visiting a site. Users search for strange items and land on pages that may not reflect what their intent was originally. Often, frustration mounts and they will search for anything that seems related to what they want. Ultimately, the user will become discouraged and leave the site angry and unfulfilled. Angry users are never return customers.

These frantic searches can lead to unexpected search terms. Someone who is unskilled in assessing user data is likely to assume that pages need to be accessible directly from the home page of a site. Eventually buildup occurs and ever page becomes a direct link from the home page. When this happens, a broad and shallow architecture emerges from the mire. With Draconian enforcement, teams will inflict “usability” upon the user in heaps and gobs.

The only way I know to solve this kind of problem is to strip a site down to nothing and begin again. It’s a hard pill to swallow and many teams respond horribly to this kind of news. I typically revel in this kind of situation because it gives the site new hope for a fresh beginning.

The best thing any team can do is uncover a clear hierarchy and stick to their guns. Often, it’s not the information hierarchy, but the navigation architecture and highlighted links that kill the user experience faster than anything else. Undestanding information importance and subordinance will always provide for a solid foundation to build a site with longevity and scalability.

After a solid, clear hierarchy has been laid in place, select clear, descriptive language to describe the categorizaion. Be certain you are using the user’s parlance. Review search terms, both internal as well as search engine referer sourced, to select the right verbiage. These carefully selected, key terms will be fundamental in guiding your user in a comfortable, transparent manner that will provide comfort to their experience.

Find key terms which are most searched for and focus on guiding your users there. Most often the users that are searching on your site are not finding what they are looking for. Even if the pages are clearly defined in the information hierarchy, the path to arrive there may not be so clear. Provide road signs for the user to follow.

Signs on your site should be sparse, much like signs found describing the roads on which you drive. Don’t inundate your user with directions to get everywhere. They have a goal. Find out what it is and lead them to the promised land. Guide them gently and let their discovery feel like their success.

Ultimately, large sites should avoid the broad and shallow approach, opting for a narrow and deep approach instead. Give signs along the way to ensure the user experiences incremental success. Guide your user gently and let their success be a rewarding experience they will look forward to recreating when they return next.

Most content on the web is managed at the page level. Though I cannot say that all systems behave in one specific way, I do know that each system I’ve used behaves precisely like this. Content management systems assume that every new piece of content which is created is going to, ultimately, have a page that is dedicated to that piece of content. Ultimately all content is going to live autonomously on a page. Content, much like web pages, is not an island.

Six months or a year ago, I had an epiphany. Content can be handled much like programming, i.e. in an object-oriented manner. Web sites often have repeating elements which could be broken out into individual pieces and reused throughout the site. These pieces could be considered objects in their own right, and they would share quite a bit with objects in programming. After building a proprietary Content Management System around this concept, I coined the phrase “Object Oriented Content.”

Object Oriented Programming (OOP) has roots dating back as far as the 1960’s and came into common use in the early 1990’s, according to Wikipedia. Since its widespread adoption, OOP has become commonplace among engineers and is expected to be part of a programmer’s standard arsenal. Though object orientation (OO) has become commonplace with engineering professionals, some of the inherent benefits of OO have been overlooked in other, non-geek circles, especially within creative groups.

Though content will never demonstrate all of the principles found in programming, as it is written copy and not a programming language, there are some striking similarities between OOC and OOP. Principles such as encapsulation, inheritance and abstraction come to light as content is broken into objects and removed from the page in which it will be displayed.

Content, once broken into objects, is an abstraction from the page it was intended to be displayed on. We can look at this as, distinct copy is an instance of the object content and content is what goes on a page to solve the content question on the web. In English, this means any copy I create is, ultimately, content. A content object is an abstract idea that is used to answer the question of content on the web.

This abstraction of content from the page provides great power in managing a website and trimming time off the process of maintaining a website. Content objects can be reused again and again throughout your site. Moreover, since the content is not tied directly to a particular page, it offers greater flexibility in the operation of gathering and presenting content on the web. The power comes from the ability to edit content in a single place in the system and update across an entire site, or across multiple sites.

A content object is, by its very nature, encapsulated. All parts of the content are maintained within the content object and no part of the content is outside of the object. The site page on which your content is to be displayed is totally unaware of the content contained within the object, but simply that it is a chunk ready for human consumption.

For the non-programmer, this means your end display does not look for what kind of content is being displayed or what the content says specifically. Your client-facing site simply receives a prepared object and displays it as it is, without meddling in the affairs of the copy writer and editor.

Ultimately, display properties may vary based on things like CSS and container wrappers in your site, but the content, itself, will remain wholly intact and unedited. This translates to a high-fidelity in content presentation based upon what the author intended.

Finally we will look at content inheritance. Content inheritance must work differently than programming inheritance. Engineers will argue that what I am offering here is not the same effect, but for copy writers and editors the world over, this will be a great benefit for you.

If you create a content instance and store copy in it, you can reuse it. This we know. Within my proprietary system, you can also inherit content from an existing instance. Once content is stored, it can be included in a page. Suppose you would like to make a change to your content, but only on one page. You can clone the content and edit it accordingly. What you’ve done is inherited from the original content, but modified it to suit the new use.

There is an issue with this definition of inheritance. If you modify the original content, your modified content does not change with it. This is, however, a boon to your editor as they expect content to behave this way. If your modifications change, or revert to some other form, it would lead to a great deal of frustration.

In the end, moving away from a static page-content model and to a more flexible and fluid content object model provides a great deal of power and ease when preparing a site for production. From the creation of content, which can be reused, to editing content where a single change can affect multiple pages, the process of updating content prepared for the web because fast and easy, allowing all parties to spend less time managing pages and more time doing what they specialize in, providing content to the user. Consider applying this approach to your site and make the web a better place.