My last post was about finding a healthy balance between client- and server-side technology. My friend sent me a link to an article about SEO and Google’s “reasonable surfer” patent. Though the information regarding Google’s methods for identifying and appropriately assessing useful links on a site was interesting, I am quite concerned about what the SEO crowd was encouraging because of this new revelation.

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.

Earlier this year I discussed progressive enhancement, and proposed that a web site should perform the core functions without any frills. Last night I had a discussion with a friend, regarding this very same topic. It came to light that it wasn’t clear where the boundaries should be drawn. Interaction needs to be a blend of server- and client-side technologies.

Ultimately, it is rarely clear where boundaries are in a project. What is too much, what is too little? Somewhere between too much and too little is just right, much like what Goldilocks wanted in her porridge. We know that even the most limited of users should be able to access our sites within certain considerations. A photo gallery is, ultimately, little use to a blind person, but alt tags should still be in place. Sound clips of the Boston Philharmonic Orchestra would be useless to a deaf person, though a caption or indication as to what each sound clip is would be quite handy.

Coming back to the point, finding a balance point is critical to providing rich, meaningful interaction between your user and your site. Perhaps the first question which should be answered is “can this be done without Technology X?”

Technology X is always the hot technology everyone is dying to use. Flash, AJAX, CSS3, these all have fallen under the Technology X heading at one point or another. By using Technology X as your baseline interaction, you may be causing your users pain when you thought you were enhancing their experience.

A prime example of where Technology X is used when standard interaction would do is the Google login procedure. Many, if not all, of Google’s login boxes use AJAX for verification of user creds. It sounds cute and looks vaguely neat, but what happens when the browser barfs on their Javascript or you suddenly lose your internet connection? You have no clue what happened.

Your experience just took a nose dive and left you in the dark.

This is especially bad news for something like a login. Logging into a website should be a simple, straightforward, FAST experience. I want to type my creds, log in and be on my way to my dashboard. If something dies unexpectedly, I want a clean, clear indication as to what happened and why. If someone cut my ethernet cable in the next room, I want to know my computer lost network connectivity and that’s why I’m not seeing my dashboard in all its glory.

CSS is another item which can choke on users, leaving them feeling lost and confused. When things are hidden or altered with CSS in a way that makes them unreadable or unusable to the user, it can get ugly. The user sees a damaged site and moves along. Your rep falls to pieces and your user has moved on to greener pastures. This is especially true for people using Javascript to reveal something hidden with CSS.

The phrase “if it is to be shown with Javascript, hide it with Javascript,” carries a lot of weight with me. If your Javascript is going to die, it would be preferable that you err on the side of caution. Show everything. Make sure the page is as usable as possible.

So, the balancing act. I’m not saying there is no room for Technology X. The Technology X of today is the old standby of tomorrow. People will become familiar with new technology and learn to expect it. In the meanwhile it is important to consider what your user is aiming to do.

As a friend of mine likes to quote: Proper prior planning prevents piss poor performance. Know what it is your user is trying to accomplish by using your site. If they are there to purchase widgets, build a no-frills site which sells widgets. Use styles only to make the page more readable. Make sure everything makes sense without styles. Don’t use Javascript to do anything. Let the server do all the grunt work.

If you plan your site carefully and build something which is clear, usable and meaningful, adding Technology X will only make the site better. If something fails, your user will still be able to interact with the site and get things done. It may take them an extra click here or there, but it won’t be the show stopper it would have been if Technology X had been your only approach.

Balance is everything. Balance your plain site with your desire to incorporate interesting new technology. Just because it might be neat to see something done with AJAX doesn’t mean you should. Flash doesn’t solve all world ills. Sometimes a little bit of HTML a dash of simple CSS and some server-side elbow grease will do just fine. Build your sites for real use. Make your toys secondary. Think about your users’ goals and make the web a better place.

Since I am an engineer first and a designer second in my job, more often than not the designs you see came from someone else’s comp. Being that I am a designer second, it means that I know just enough about design to be dangerous but not enough to be really effective over the long run.

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.

It’s always great when you have the opportunity to built a site from the ground up. You have opportunities to design things right the first time, and set standards in place for future users, designers and developers alike. These are the good times.

More often than not, sites are already built and deployed for the world to view. Moreover, there are probably unintentional standards in place which get in the way of your best efforts to do right by the site, the content and the user.

It can be said that, much like user experience is either good or bad, there is no such thing as no standard, there is merely a good or bad standard. Once a project is underway, if there are no standards to work from, they will create themselves.

Pretty soon you find yourself in the corner holding a roller and a can of paint with a confused look on your face.

“How did I get HERE,” you ask.

Patterns become entrenched. People begin to rely on the uneven foundation. It is expected that things are going to be built around warps in the floorboards. Broken becomes the new fixed.

Suppose you approach a site that has a decade, or more, of this kind of entrenched patterning. You will quickly discover that doing any updating, making any change or acting upon the site in any way is a momentous task.

On one side of the fence stand the engineers who have cobbled together this house in the swamp and there you stand, Captain Ahab, looking at the white whale of usability and proclaiming you will have victory regardless of the cost.

This kind of standoff leads to what I refer to as usabilibloat. Usabilibloat is the unexpected and swift expansion of codebase and resource usage to support a cumbersome system and a user interface which may be little more than merely passable. Typically this kind of situation is not grown out of contention or malevolence but simply out of “organic growth.”

Organic growth, when controlled and directed, can allow a site, tool or other system to flourish and become a loved and trusted tool. When uncontrolled, organic growth of a site becomes malignant.

The first step to take when approaching a site which is in danger of developing usabilibloat is to assess what is easy to fix and what is hard. The hard things are typically systemic problems, likely related to cutting a corner years ago. Often, the person who cut said corner is long gone and others are left to pick up the pieces.

The easy problems should be evaluated as to level of efficacy regarding user experience and ease of maintenance in the long run. Don’t ignore any of them, but make a list and order the problems as they should be handled.

Sometimes easy problems reveal systemic ones, so be aware. If an easy problem starts to become a systemic problem, shift it from the easy list and move on.

Once you have sorted the easy problems in order of importance and immediacy, evaluate the ideal user experience. Note the key features and make a list of them. These are the do or die features. These are the “if our system doesn’t have these, it is a non-starter.”

Appraise the list of easy-to-fix issues and non-starter features and roll these out in the earliest version of your site. Forget about the other neato things you intend to put in place one day. Just get the site rolling with what you need and give people something to click on.

Something that is key for limiting usabilibloat: build an API. Create something to allow your UI to interact with the system below. It can be hacky. It can be ugly. It may not work quite right the first time you try it. Regardless, with a good programming interface, you can interact with the user in a consistent way while the developers pull the system back from the edge of the abyss.

By building an API, you separate the UI from the system and allow the pieces to move more independently. A major benefit you will gain from this approach is the ability to give your users something to click on early. The more user testing you can incorporate the better. If you can incorporate it early, you are doing well.

User testing will help to eliminate more usabilibloat. Your users will tell you if something works better, worse or about the same as what they were expecting. Sometimes you will discover you can cross items off your list as they are unrelated to what your user is truly interested in.

After you’ve accomplished these critical steps, continue to work through your site in much the same way, iterating in the UI elements as they are appropriate and refine the system to work more efficiently within the scope of the user needs.

Usbilibloat should be managed from the earliest possible moment. The only remedy available once usabilibloat sets in is time and sweat. If bloat is carried too far, your users will suffer for your sins.

The key to your salvation is planning. If you see your site heading for the edge, take a moment. Sit down with your developers and make a plan. managing the issue early will save lots of grief for both you and your users. Meet the problem head on. Break your UI away from the rest of the system. Save your users and make the web a better place.

I am big on modularity. There are lots of problems on the web to fix and modularity applies to many of them. A couple of posts ago I talked about content and that it is all built on or made of objects. The benefits from working with objectified content is the ease of updating and the breadth and depth of content that can be added to the site.

Something really exciting that came from my previous post was that functions are objects. By this, I mean, site function does not live in a separate world, outside of the content object ecosystem. Functions should be and ARE integrated right into the website.

This is the beauty of the modern web. Since functions are merely objects which can be included in pages, they can be built, tested and deployed independently and then integrated seamlessly into the web application. Typically we think of this kind of function as a plug-in, though plug-ins are merely objects in their own right.

Hagan Rigers (@haganrivers) is currently part of the Web App Masters Tour. Without giving too much away about her talk, she discusses managing site (and application) navigation as a function. She breaks navigation out of the system and handles it as a separate function of the site, independent of the content. If we consider this approach, then we can see something really important:

Navigation is a function.

Something we already know is that functions are simply objects to be plugged into a website. Moreover, we know we can AND DO build all kinds of interactivity and user-centric functions into websites. So, adding one more function to the site is no big deal, or is it?

Thinking about navigation as some object to simply plug into a website seems like a radical departure from good sense, doesn’t it? I mean, navigation is integral to the site. It’s the foundation upon which all is built, isn’t it?

I’m not sure that’s actually true.

Ultimately, there is only one thing on the web: content. If not for content, there would be no reason for the web. There would definitely be no reason for my blog. There would absolutely be no reason to ever think about navigation. Perhaps navigation really isn’t as foundational as we might think.

The real dilemma of all of this content-object business is that once everything becomes an object then there is no reason to think that any object is immutable or immovable. Everything can be updated, changed, moved around and even reinvented as the need arises.

This is not to say that any content-object is disposable. I would argue quite the opposite. It was said, as taken from Paddy Donnelly’s blog, “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” (quotation by Antoine de Saint-Exupery)

In short, if this is done correctly, each content-object should be indispensable and irreplaceable. This holds for everything from the main body of text you write to the RSS feed you pull syndicated content from, through the interactive functions of the site and finally to the navigation.

So, we’re 500 or so words in, what’s the big hubbub?

Here’s the thing, your user need not know that you’re dealing in objects. The key is integrating your content objects so well that your user feels as if they are immersed in a smooth, polished experience, each part completely inseparable.

Each object does not live in a vacuum, however all of your content of a certain type should be interchangeable with another. This is key as you move forward in building a site. Users will tell you what they want from you. This may be as direct as an e-mail detailing the things your user would like to as indirect as an inference based on analytics data.

When your site is built upon the content-object ideals, you can quickly rise to meet the wants and needs of your user. Users are fickle and what they may prefer one day, they will balk at the following. By managing your site in a modular way, it allows you to keep up with the users and their impossibly quick pace.

So, navigation and modularity.

What I have been driving at this whole time is modularity. Wonderfully, navigation falls right into that basket. As you build your site consider your content as objects, then think about your pages as objects containing smaller objects. Each of those objects is then contained inside the site.

Spinning yet?

The navigation should be your savior. The navigation, when done right, is the glue which holds everything together in a polished structure. Navigation is the wrapper that should bind your objects together and, at the same time, make the structure as transparent as possible.

In the end, what you will uncover is, content is drafted and the navigation describes it all as your user is guided through the experience. Since navigation is a function and all functions are objects, then navigation is simply a content-object which should be crafted with the same kind of care you pour lovingly into your media content-objects.

By breaking the entire site into independent objects and polishing each individually, you lay a strong foundation for building your site. Once each content-object is ready for inclusion in your site, begin thinking about your navigation. Pull the site together and buff everything to a high shine so you know your user will be nothing less than dazzled. I’ll let Hagan do the talking about how to think of navigation in even smaller objects. In the meanwhile, build your site modularly. Think about everything as an object. Keep up with your users. Fill their needs. Make the web a better place.