If you’re anything like me, you’ve used the alert message function as a means to figure out where things were falling apart. That’s great and all, except that it sucks. I hate needing popup messages to debug things like mouseovers. It’s no fun. If you forget to pull one out of your code before it goes to production, it can be miserable trying to track it down later when users are getting alerts that say things like “Why doesn’t my function work??”

Whoops.

So, I started thinking about developing in pretty much any other language out there, but mainly Java since I have to touch that only slightly less than I touch PHP scripts. Java is great because you can output directly to a console, so you can log stuff and watch as the mayhem unfolds while your program bombs. It’s REALLY helpful.

SO…

I decided I wanted a console I could output to at any time. Something I could review on the fly and see what is happening. This would allow me to review any logged output I wanted in real time, and I could avoid the alert box altogether. Hmm… what could I output to? The DOM!

Right??

I sat down and cranked out a handy dandy script that will write to whatever div you decide to use as a console. If you are lazy, like me, then it will also do something really spiffy and just append a console to the end of your document.

The nice thing is you can just define a console div and write to it. When you send your code to production, you can just style your console with display:none. If you forgot to pull a write statement out of your code somewhere, the world won’t come to an end, and your users will be none the wiser. (For the record, I still strongly encourage you to NOT leave test code in your production code. This is just a CYA measure.)

So, where is this code and what do you do to make it go?

Let’s start with the “making it go” part first. Include the script in your code, I’ll give you a link to the file in a moment. Then add this line of code to your document:

var ow = new OutputWriter();

Tadaaa!!

You now have a console on your page you can write to. If you want to write to the console for whatever reason, it goes a little like this:

ow.writeln(“your message.”);

If you made your own console, and you want to write to it, then instantiate the writer thusly:

var ow = new OutputWriter({ consoleId: “your_console_id” });

There are other things it can do as well, like clear the console:

ow.clear();

Store and retrieve cleared history:

var ow = new OutputWriter({ consoleId: “your_console_id”, storeHistory: 1 });
ow.clear();
var history0 = ow.gethistory(0);

You get the idea.

There are more parameters you can set too. I put them all in the comments at the top so you can decide what to use and what to skip. They are all 100% optional, so don’t worry about it if you don’t want to set them.

So, on with the script, already! Just download this one little file and you have everything you need to do all of the console-writing magic I described and, potentially, more. Debug your code with grace and style and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

In the early days of the web, a website was mostly HTML and associated miscellany. There were some content management systems and dynamic utilities out there, but they were typically purpose-built and totally proprietary. One company I worked for had a system that, essentially, took in HTML snippets and stored them in a database as a web page that was 90% constructed, doing the last of the construction for presentation on the fly. It wasn’t graceful, but it served its purpose.

Today websites are web apps and vice versa. There are fewer and fewer business sites on the web that are old-fashioned HTML. The company I work for now, has a broad-reaching infrastructure for its web presence which involves various computers and disparate web services. This is all very important to the experience the end-user is going to have when they visit your site.

Information Architects today need to be cognizant of the systems they will be working with, the limitations of technology already implemented and the latitude they have regarding direction for the site and the user’s end interactions.

Let’s assume you have a list of items you already account for in your work: page layout, important items both for users and internal, site hierarchy, taxonomy, findability of information, etc.

Here are other items which should be considered:

Content Management

What kind of a system is being used? Is there an e-commerce solution in place? What e-commerce package is being used? Does it integrate with the existing content solution or is it a separate tool?

Integrated or Decoupled Site/Content System

Is the site being run on a simple WordPress/Movable Type/Drupal install where the site management is tightly coupled with the website itself? Is the website requesting content across the wire from a service on another site/computer/continent? How will this impact speed? How easy is it to integrate custom features and functions?

Data Transport

This is a biggie. If you have an old-school web project, this is unimportant. If you are sending data across a wire to a custom tool or application, this becomes VERY important. How do you want to connect to the data? Do you want to make a direct remote connection to the database or do you want to send the data as a single package across the wire? If the data is being sent as a package, what do you want to use? JSON? XML? Serialized string? Something sneaky I don’t know about?

These sound like much more engineery/techy/geeky considerations, but they are important in the end. Perhaps you are pulling information from your company’s database, a Twitter feed and pictures from Flickr. All of a sudden, you are working with mixed coupling. You will need to know this in case something fails. You are the one they are going to ask when they need an error screen.

Why data transport? Simple. You don’t need to know how to implement it, but if you work with the engineers and pick a standards-compliant data transport system, you will save them lots of headaches and yourself extra work in the end. By understanding the way data is being passed across the wire, you can start to understand how to better integrate RSS feeds into a design, present useful information to users and do it in a way that will be quick to implement and easy to maintain. Ultimately, if you want to invent a better wheel, you’ll want to be armed with a damn good reason.

Ultimately, there is a lot of information that needs to be shaped and directed. In order to best your user, yourself and your company, you need to consider things that are more than skin deep. By tackling the tough questions about your project early, you can write a more clear and useful specification. In the end, by peeling back the layers, you help to make the web a better place.

©2012 Chris Stead. All Rights Reserved.

Both articles focused on content and how it gets passed around. The problem is, there is a lot more going than just content on the web. What both articles overlook is the work of the web developer or web engineer. No, this isn’t an attempt to shoehorn engineers into this discussion. It’s about the fact that they are needed to produce function.

Beyond the world of content is a whole slew of function on the web. Web apps have become increasingly important in the landscape of the web. As a matter of fact, you’re currently visiting a web app. Yes, you’re seeing content, but you are also interacting with an application which allows me to manage and publish that content for you to see.

Other things which happen on the web include buying insurance, banking, playing games, posting comments, public forums, meeting whiteboards, chat and many other items which are missing from my list. Web applications are vital to the new web experience.

So, what about the web designers?

Web designers are needed to make all of the extant and constantly emerging applications sensible and enjoyable. Regardless of the particular language or server structure used to produce the web apps you use every day, one of the primary interfaces is still the browser. This means what is an application in one sense is a web page in another. Who designs these pages you see? Web designers.

This link between the design world and the application world has been developing for decades. Designers are vital in the production of web applications just as much as the engineers are. The world of applications today isn’t the same as it was even in the 1990′s.

Users crave satisfaction.

As little as 15 or 20 years ago, to simply have a working application was a feat unto itself. If you could enter input and get a meaningful result in return, the application was launched. People, today, expect more. They want to be able to enter what they need and get the meaningful output they expect, but they also desire rich interaction. They crave visually stimulating and sensible interfaces. Users have gotten more design savvy and they won’t stand for mediocre if they can have the best.

Regardless of where the content, which is fed from a website, is displayed, neither Facebook nor Google will ever be able to serve the function you provide on your site. Moreover, they will not give your user the experience they expect from your company. Only by interacting directly with YOUR site will the user ever find the satisfaction they seek.

Ultimately, the people responsible for bridging the gap between the engineer and the user are designers. Designers come in various flavors from the jack-of-all-trades to the specialist interaction, user experience and interface designers. Designers make the user comfortable. Designers provide the problem-solving expertise which is so crucial to making an interface meaningful and usable.

In the end, to say that the future of the internet has no room for designers would be just as foolish as saying the future of the internet has no place for engineers. I mean, there are all of these turnkey software packages out there, what do you need an engineer for?

It’s foolishness.

Ultimately, engineers and designers are both critical to the web experience. They have been until now and the need is only expanding. Even as content is served out to other distribution channels, the home still needs to be somewhere. Even as content is still king, the sea of applications continues to expand. Much like Jell-O there is always room for designers. Go, design and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

I have one last function to look at. This function will let us sort out how long a certain percent of our users will hang out at a site, trying to accomplish their goals given a random population interacting with a page or site they have never visited before. By having the ability to calculate the output of the user falloff function, we can compare user test results to our falloff curve without plotting the entire curve to show anticipated versus actual results.

We’ve already talked about the user tolerance constant (L) and our starting number of users (u_0). These are all the elements we need to figure out at what time (t) we will have a percentage (p) of our users left actively seeking on our site. The actual number of users remaining is trivial to calculate after you pick a percentage, i.e. p*u_0.

(Reminder: percentages should always be expressed as a decimal between 0 and 1.)

Without further ado, here’s the function of the day:

t = L*[ln(1/p)/ln(u_0)]^0.5

There are some interesting features of this function which are a direct result of the falloff/satisficing function we talked about last time. First, as we get closer to 100% (or p gets closer to 1) t gets closer to 0. This shows us that, at least at one end, this function must be meaningful since none of our users should have fallen off before the testing or site loading began.

At the other end, we can see that as we get closer to 1% (or p gets closer 0.01) then time is going to approach L, our user tolerance limit. This means our function is actually behaving the way it should and our results will prove to be reasonably meaningful, regarding our test population.

This function is probably as important, if not more so, for testing than our falloff function because you can actually see how you are performing in your test group against a theoretical control group. This means, if you take your testing group, collect data and analyze it against standard statistical curves, you should be able to get a reasonable estimate of how your users are measuring up against when visiting your site.

On the other hand, if you are underperforming, you now have a reasonable metric to deduce when things are going wrong. You can do things like plug in .68 for the percent and see if you are actually capturing the first standard deviation of your users within the allotted time.

In the end, this should all relate back to one question: are my users accomplishing what they want to do before they are getting too frustrated to continue with my website? If the answer is ‘yes,’ then pat yourself on the back and then make it even better. If, on the other hand, your answer is ‘no,’ it’s time to start evaluating how your site is impacting the users who visit it.

Are they suffering from unintended ad-blindness as the users tested for the US census website were? Are you suffering from a hover-and-cover anti-pattern which is causing your users to have to steer all over the page to get to what they need? Are you not using language that makes sense to your audience?

All of these questions and many more should come to mind to improve your performance against the baseline we’ve defined. Just remember, even when you are consistently beating my model you can still improve more. Surprise and delight your users. Beat the curve and then improve again. Think about your users, make your site a delight to use and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

This person will remain unidentified as I don’t want gobs of people spamming his site, nor do I want to give his poor judgement any extra exposure. That said, the basis of the post was, it is preferable to make users authenticate with Twitter every time they logged into the system as opposed to storing the keys and remembering who the users of the site are.

The take-away message was, paraphrased, “it’s a simple back and forth between your site and Twitter each time they log in. It won’t bother the user and it is preferable to storing all of those authentication keys.”

Let me say it again: he was evangelizing inconveniencing the user and stating this was actually the preferable thing to do.

This idea is wrong-headed in so many ways. First, let’s look at Twitter and see how they would feel about it, shall we?

Suppose we stored the keys for the user. Twitter would have to generate a key just once for each user. Once that work was done, they would simply take requests as usual and the day would go on. Their API is built around using stored user authentication so this is no extra burden. Instead it is business as usual.

Now, suppose you make your user re-authorize every time they signed in to your web app. This means that each user would have to hit the Twitter authorization page once per login. Now Twitter has to burn the extra cycles to generate a new key for YOUR user. On top of that, there is storage of that key. Each time you request a key, you are taking up space on their server.

The more times you make your users request authentication, the more it costs Twitter. It might be no big deal to you, but that is money out of THEIR pocket. That is the very same pocket which is financing that lovely API you are using to update your user’s timeline. We haven’t even started talking about your users yet. This is just the mess for Twitter.

Let’s have a look at your user. If you store their authentication, they have to hit the Twitter authentication screen just once. Once they do that, they will probably forget all about it, carrying on with using your application, like they want to. That’s it.

Suppose you, on the other hand, make your user authenticate every time they log in. One of two things is going to happen. Either you make them authenticate through an account screen and they will assume, after the first time, that they are done. The other option is, as soon as your user logs in, they will be faced with a Twitter authentication screen.

Suppose you make them authenticate through an account screen. Your user will reasonably assume this was a one-time thing. Later they will discover that Twitter isn’t being updated by your app anymore. They will check their account and see they have to re-authenticate.

Rinse, repeat.

Eventually, your user will figure out that you expect them to re-authenticate EVERY time they log in. If your application relies heavily on Twitter updates, you will lose that user. If that user liked your application because it updated twitter, you will lose that user. In the end, you are likely to lose users over the choice.

Suppose you force your user to re-authenticate each time they logged in. Your users are going to view logging in to your service as a chore. Eventually they will tire of the whole process and leave. This is the most direct route to losing users.

Regardless of the path you take, you are bound to lose users if you make them re-authenticate through a service each time they log into your service. Also, the more services your app interacts with, the more services your user will have to re-authenticate each time they log into your app. This compounding effect will only drive users away faster.

In the end, what this person was really evangelizing is simply laziness. It is unreasonable to expect your user to go through a litany of special operations each time they log in before they can fully use your service. In this day of “less is more” user interaction, asking the user to perform unnecessary actions is a sure-fire way to drive users from your site and fast. Think about your user. Do a little work for them and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

It is important to consider search engines during the site building process, however I feel the SEO guys often get carried away. In this article it is suggested that you de-emphasize navigation and forget footers along with lots of other questionable advice.

These two suggestions alone are enough for me to consider this article, at best, a crackpot spouting extremist ideas. SEO experts often seem to forget a very important element on the web: the user.

Something designers are told and people are wise to heed is, pretty things work better. Do they ACTUALLY work better in some sort of quantifiable way? Probably not, but that doesn’t matter to the user. If a site is attractive and seems easy to use, the user is more likely to invest the time to learn how it works.

User experience people know that navigation is key to moving a user through the site. Let’s take, for example, Amazon. They are a top-rated site for Google searches. Have they gone and done away with navigation? No. Why? They know users rely on navigation to move through the site. Moreover, their designers know that pretty navigation works.

While the SEO nuts will scream “de-emphasize navigation,” Amazon bucks the “trend” and keeps on doing what they know works best for making money: directing users.

Regarding forgetting about footers, if anyone in the SEO world ever thought footers were there for search engines, they are fooling themselves. Footers are only ever implemented for the user. Information which a small group of users may want is typically stored in the footer. This kind of information is stuff like license numbers, contact information and other legal odds and ends.

Other common footer items include convenience links, brief site navigation and polish elements which finish out a site. Footers, especially those of the fat variety, were never intended to be SEO tools. They are for the user.

If an SEO guru were to design a site, it would probably be a huge mass of text with a few peppered images, some meta information at the top, a link which says “home” and the required legal information at the bottom in a big, unattractive text block.

Though a page like this would garner a couple of extra points from search engines for being easy to parse, it would lose mega points for being completely useless to a user. The more useless your site is, the fewer users will return. The fewer return visitors you have, the lower your site rank will be. Ultimately, you will win the battle and lose the war.

Moreover, what is really making the money, the search engine or your product? Trust me, if you have a product everyone wants, the search engines will bump you up the list even if your SEO stinks. On the other hand, if your SEO is top-notch, but your site fails to deliver conversions you may as well pack it in now.

Finally, something I never seem to hear SEO people talk about which should be absolutely top of their list is the semantic web. The semantic web can be horribly complex which seems a little daunting, but it doesn’t have to be. Simply remember to use the right tags at the right time and you’ll be on your way to better SEO without all of the extraneous pain involved in new metadata information embedded in your pages.

Remember to do things like break your pages up into headers, divisions, paragraphs, lists and tables. If you want to get really fancy, add definition lists. This will score big points with the search engines and it will also score big with your audience. The more you can divide your information into digestible chunks and then style with CSS, the happier everyone will be. Users will be able to quickly skim the page in search of what they are there for and the search engines will be able to parse your pages better, potentially leading to better overall ranking.

In the end it is best to build your pages the right way: semantic tagging, strong user focus and dense metadata components. There are many SEO techniques which work better for both search engines and users. Forget about completely re-building your page just to impress the Google spider, because you won’t. Think about the user, build a compelling site, mark it up correctly and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

When I say I am a designer second I mean I am, in fact, a design school dropout. I went, I learned just enough to “get it” and then I ended up dropping out. I did go back to school and I got a math degree, but that is a different story for a different day.

If there is anything I learned from design school, it was that everything in design is done for a reason. Mind you, this is when design is at its best. Every designer that is working to solve a problem and communicate with the viewer has incorporated elements and done things so a specific message comes through.

Unfortunately, many of my engineer colleagues don’t have this insight. Typically people who opt for the engineering route do so when they are in high school or earlier and rarely set foot into the creative world. They may be proficient hobbyists in a particular art or craft, but their real love is engineering. Typically they really have little or no knowledge of design whatsoever.

People who don’t understand design make really poor designers.

Sorry, it’s true. This is not to say people without design skill can’t convey messages, but they tend to be inconsistent and unpredictable. Moreover, engineers, in specific, are typically more interested in solving a puzzle than making the final presentation precisely “so.”

This is the benefit of design comps. Designers, unlike engineers, are trained in design and are able to consistently and deftly communicate ideas with a clear voice. When they create a design comp for a website, or several depending on circumstances, they are creating a visual roadmap to communicate with the world.

Engineers, even as wonderfully detail oriented as they are, tend to see the big-picture items like color and location of items on a page, but they miss items which are equally important, like typography, subtle shading and other items which create a polished look that tells the user this is something made by professionals.

Ultimately, what happens is engineers color the design with their desire to finish slapping that UI together so they can solve the really meaty problems. When I joined Arrowhead, the company I currently work for, much of the Creative-specific projects looked pretty good, though the code was abominable. The collaborative work between Creative and Engineering seemed to suffer.

Mind you, this does not mean the engineers here are bad at what they do. Quite the contrary. They simply colored the output when they worked on it. Designs would fall apart as content was added and the best laid plans met the real world.

Engineers and developers need to work on being more coding-transparent. Regardless of how ugly the first iteration of the code might be, get the page looking good. When you think you’re done, take a printout of the original comp and hold it next to the completed page. Do the look the same? Do they look different? How do they differ?

In order to achieve coding transparency it is important to take a moment and understand what the designer is trying to communicate. See what the pieces of the design do when they work in concert. Understand the intention.

Ultimately, this may lead to asking the designer questions. They don’t mind answering questions like “what am I supposed to be doing here,” or “when I add content, the design seems to break like this, any thoughts?” Questions like these help designers to work with you and, hopefully, develop a more robust design, capable of handling what the world throws at it.

Designers, on the other hand, hate questions like “what is this for? Do you really need that?” The answer is typically “yes,” so don’t ask. Try to implement it and then ask questions if something breaks.

As you work through a design, you may find you have to interpolate or extrapolate on a designer’s idea. If it is clear how to build from what they have done, just go for it and brace yourself for minor tweaks. It’s okay, changes happen. If you don’t understand what they want or it’s not clear how the design extends to what you are currently working on, then stop and ask questions.

When engineers ask questions which lead to better design decisions, designers feel more confident about how the end product will turn out. Much like engineers feel when people ask questions about whether items are possible to implement rather than just assuming they are and promising the world.

In the end, coding transparency is all about communication. It is about communication between the designer and the engineer and it is about communication between the designer/engineer team and the user. If communication breaks down anywhere along the way, the message will never reach the user or worse, it does and it’s ugly.

In the end, everything we do is intended to reach an audience. The more we can do to facilitate the message as it comes down the wire, the better. So, the next time you receive a comp and rush through, slapping elements into place without review, imagine what your system would look like without testing and code review. Practice coding transparency and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

The web is moving away from exclusivity. When the web started, documents were shared, whole, and people had to visit a particular site to view their content. It rarely came to you, typically requiring you went to it. This was the face of the web in the 1990′s. Autonomous operating sites maintained individually for the sake of the content maintained within.

The modern web, as I discussed last week, is constructed with a blend of autonomous content and content-objects from across the web. This kind of shared content structure is a natural development beginning with sites maintained as interfaces interacting with content sources like databases.

By creating an exclusive web application you gain certain benefits. You control your environment. You get to set the rules and everyone who uses your system must obey. You maintain the images. You store the copy. You define the network. Everything you do lives within the ecosystem you create.

For as good as it sounds to have supreme power over a web ecosystem, there are drawbacks. You are solely responsible for maintaining the system. When things break, it is your job to fix them. When enhancements are made, you are the one on the hook to build them. The onerous is on you and you alone.

There is another issue that comes with maintaining a partially or fully closed ecosystem. You can lose trust. People get wise when others start watching everything they are doing. This kind of realization hurts companies. Facebook appears to be suffering from just this kind of loss of trust right now. As they get more aggressive with sharing user data, they lose user trust. Since Facebook is a closed ecosystem, an exclusive web application, and users are aware they are being watched, trust in the system wanes.

Inclusive web applications, on the other hand, lend a feeling of freedom and sharing due to the transparent sharing of information across the wire. The inclusive web draws information in from APIs and RSS feeds across the web. Just as information flows in, the local API allows information back out again.

When the inclusive web also allows people to manage their own privacy, users feel more secure. They know they can collect the information they want and share it with whomever they like without feeling the burden of filtering or censoring their preferences in order to please people they neither know nor are aware even exist.

The benefit you gain from running an inclusive web application is the ease of production. You maintain the code base for a hub and your unique function while allowing other services to manage the content they specialize in. This community development process leads to many different groups acting in a specialized way and supporting a subset of the total code that builds the end user experience.

For the gains available in the inclusive web, there are pitfalls as well. Privacy management becomes a more complicated task for the user. Instead of managing the privacy controls at a single dashboard, they are required to manage their privacy as it applies to each system they touch. This can become a burden if a user suddenly decides to overhaul the privacy settings across their personal social ecosystem.

Another concern to weigh against is control. The more inclusive your application is the less control you have over the experience your user has when they interact with the ecosystem in its entirety. Within the scope of your application, users can, and should, have a consistent experience.

All APIs, however, are not made equal, so preparing and presenting an interface for your user does not mean you will be able to give them the same rich experience they would have when interacting with the primary service. On the other hand, this may be preferable as you can offer a subset of functions which relate directly to your service without directly mirroring the function of the service you are interacting with.

With these control issues in mind it is likely still a greater benefit to be inclusive rather than exclusive. Through acting in an open, inclusive way your site becomes a boon to the user, enhancing their experience and making the web a friendlier place to be.

In the end, however, the inclusive web is where users truly live. No user interacts solely with any specific web application forsaking all others. They look to constantly enhance their experience on the web through richer interactions. These interactions, however, are not just with a machine. They are interactions with people. People don’t all live in once place.

Instead of trying to fight the inevitable rise of the inclusive web as an expectation of the user, embrace it. Think about the sites and services your users prefer. Engage your users with new ways of acting with and upon the web around them. Provide your users an open, inclusive experience. Make the web a better place.

©2012 Chris Stead. All Rights Reserved.

There is an inherent problem with simply not creating wireframes before the design process begins. If the designer is handed a stack of content and a few images that represent what the stakeholders would like to see incorporated, the project can land, very quickly, in a swamp.

The designer won’t have user data to work with. The site may lack important flow and the information presented may become lost in a design which is appealing and hard to use. Wireframes do more than simply offer a low-fidelity idea of what the design is going to look like in the end.

When wireframes are carefully thought out and developed, they define the skeletal structure of the site as well as important user interaction. Wireframes reveal an underlying architecture that should become all but invisible once the final design is implemented.

User interaction with the information architecture should be transparent. This cannot be done with a pretty design alone. Functional specifications come from wireframes. Documentation comes from wireframes. Even code is defined from wireframes.

Let’s consider concerns regarding why people are building wireframes. If a designer decides to build wires for a project simply because they have heard or seen others doing it, they are definitely making wires for the wrong reasons. If the client, on the other hand, demands wireframes simply because they heard a new buzzword, they are asking for the wrong thing as well.

The important issue surrounding wireframes and audience is not whether they should be made or not. The issue is what the fidelity of the wires should be. At the beginning of the thinking process, hand-sketched wires are a great way to get ideas on the table with little time invested. These wires are typically not provided to the customer unless they were sketched at a client meeting.

Once the basic concept is sorted out, more formalized functional wires can be created and presented. These will typically be more fleshed out, accounting for the general states of the site they are intended for. Often times these frames will accompany a document detailing the information hierarchy and user flows. This set of documents is important for the developers and designers to aid in constructing a site that conforms to expected layout and behavior.

After the formal frames have been created, it is time to discuss appropriate fidelity of wireframes for presentation to the stakeholders. If project stakeholders are visionaries, capable of looking through low-fidelity wires to see a final product, then present what you have. Low fidelity is an acceptable choice here. If, on the other hand, you have users that are much more responsive to a final product, it may be time to beef up your wires with some graphics and real content. This is a high-fidelity presentation.

Speak to your client in their native tongue. If you are talking to bunch of engineers you may be able to simply hand them a spec for the views and the business logic and they will extrapolate the rest themselves. On the other hand, executives often don’t have time to review detailed documents. Instead, give execs a nicely presented, medium- to high-fidelity set of frames and comps which they can glance over and make a decision on. Knowing your stakeholders makes all the difference.

In response to the article mentioned early on, wireframes are an important part of the site development process. In order to provide the customer with an optimal product, wireframes should be an integral part of the development process.

The development team will know, immediately, if their work hit the mark when the stakeholders try to click on printed copies of the wireframes to see more information. Wires don’t define the graphical elements of the site, they define how the graphical elements drive the user to move. Wires don’t define how website function will interact with underlying code, they define how the user achieves their goals through using what the developers will build.

Wireframes are not an early version of something pretty, they are an interface tying visual appeal, function and user journey together. In the end, the question should not be, “do I make wireframes?” The question should be “what fidelity should my presentation be to have the greatest impact?” When presenting to stakeholders, consider their needs too.

As a designer, engineer, IxDA or any other element in a project, your users are your goal. Stakeholders are your clients. Build a better user journey. Think about presentation fidelity. Give the stakeholders something to believe in. Make the web a better place.

©2012 Chris Stead. All Rights Reserved.

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.

©2012 Chris Stead. All Rights Reserved.