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.

Listed information can get tricky.

I poked around the web to see how people were describing their lists and presenting them to the world. In the end I came up with a set of STEPS to help break off bite-sized pieces to digest. I even came up with a cute little acronym in the process.

Here’s how it works: STEPS is Sort, Transform, Eliminate, Paginate and Search. It goes in that order, even.

Sort

The first thing to do with the list is sort it. Generally you’ll want to sort in order of general importance. Sometimes alphabetically will be better. Other times a different sorting algorithm may be useful. Depending on the sheer volume of the information you may be able to do this by hand or, much like the meat in Chicken McNuggets, your information will need to be mechanically separated. I won’t dictate the correct sorting algorithm since it will vary, but it needs to be sorted first. Sorting will make life easier through the coming steps.

Transform

Once you have the basic sorting figured out, you’ll need to run a basic transformation on the resulting list. This transformation usually includes chunking the sorted list into manageable portions, and preparing the set for display. It is key, at this point, that you have already assessed personas for your project. The personas you have developed, along with your understanding of business goals will be key in understanding how to effectively transform your information into something your users can use.

Eliminate

This is the first presentation step. Elimination may be done accessum priori or it may be done on the fly. This depends on your use cases. Often you will know something about what your user needs before they start digging in, so why not make their lives easier and pitch the stuff they don’t want?

Paginate

Even after eliminating all of the information your user doesn’t need, there may well be a large list left to sift through. Fortunately they are already sorted! Pagination helps to trim what the user is looking at and makes each group manageable. It’s easier to skim a short list without getting tired eyes, the same cannot be said for a list hundreds of items long. Keep the displayed list short.

Search

Even after doing all of this, you may still have page after page after page of information the user has to wade through. Don’t forget that users are generally search-oriented. If they can just type in keywords and get what they want, or at least get close, they will be much happier. Preparing information for search is at least a post in itself, so I won’t talk about it here, but this last step could be the critical piece that makes or breaks your user experience when looking for something.

This is just a skeletal framework you can use to help focus each step along the way when you are organizing long lists of information for your users. In the end, the way each step works will be defined by the scope of your project, the amount of information, business goals and chosen personas. The same information could look radically different depending on these factors. In the end, though, working step-by-step will help to focus efforts and steer you away from analysis paralysis. Try my 5 STEPS process 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.

That is, I didn’t find anyone, though they may well be out there.

I did find several references to a Google Maps helper, but, that didn’t help too much since I had an address and no geodata. The helpers I found looked, well… helpful once you had the correct data, mind you. Before you can do all of the maps-type stuff, you have collect the geodata and that’s where I came in.

I built a quick little script which takes an address and returns geodata. It isn’t a ton of code, it doesn’t handle paid accounts and it isn’t fancy. What it lacks in bells and whistles, it makes up for in pure, unadulterated Google Maps API query ability. Let’s have a look at how to implement the code.

First, download the file and unzip it. Place it in /app/controllers/components. That’s the bulk of the work. Once you have the component added to your components directory, just add it to the components array in your controller and call the getCoords() function like in the code below.

class FakeController extends AppController
{

     var $components = array("Googlegeocode");

     /* functions and whatever other code ... */

     function getGeoData()
     {

          $address = $this->data["ModelName"]["address"];
          $coords = NULL;
          if($address)
          {
               $coords = $this->Googlegeocode->getCoords($address);
          }
          $this->set("coords", $coords);

     } // End of function

} // End of class

There is more code there in general class setup and comments than there is in actually making the coordinate request. Note, do not URL encode your address before passing it into the function. This can have unexpected results as the geocoding component will properly encode the address for you.

There are a couple of other functions in case you need them. First is a call to retrieve the data set which is returned from Google.

// ... code ...
$geodataRecord =
     $this->Googlegeocode->getGeodataRecord($address);
// ... code ...

This will return an array built directly from the XML returned by Google. From this you can extract all of the information they typically return, including status, address information and geodata as well as several other odds and ends. There is actually quite a bit of data returned for each address.

Two other useful functions are the lastCoords() and lastGeodataRecord() functions. They are called as follows:

// ... code ...
$coords = $this->Googlegeodata->lastCoords();
$geodataRecord = $this->Googlegeodata->lastGeodataRecord();
// ... code ...

Once a record is retrieved, it is stored in memory until a new record is requested. You can refer to these as needed to recall the latest records retrieved from Google until the script finishes executing.

Though this isn’t the typical user experience related post, hopefully this will help you get moving more quickly on your project involving geocoding addresses for use with the Google Maps UI API. I hope you find my component useful and you use it to 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.

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.

©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.

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.

©2012 Chris Stead. All Rights Reserved.

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.

©2012 Chris Stead. All Rights Reserved.

The user.

Several articles I found talk about the SEO benefits of pretty URLs and whether it is very important to consider using them with a site as they don’t encourage a major boost anymore. “It’s ten years too late,” they say. It’s never too late, I say.

Rather than bashing SEO experts that cry “content, content, content” let’s look at content and wrap it up in an easy to guess URL the user can make sense of. Peter Morville argues for findability, meaning users are more likely to use resources which are easy to navigate. Moreover, users will naturally navigate to whatever satisfices their information needs.

I wonder why users are forced to satisfice when pretty URLs make it much easier to satisfy by simple guessing. Unfortunately, something that stands in the way of this guessability is the combination of SEO professionals considering pretty URLs as a lesser sin combined with technologies which stand in the way of smarter URL writing.

Actually, I don’t necessarily wonder much, at all, why users are forced to satisfice when attempting to find something on a site through URL guessing. Much of the available technology on the internet is fairly limited when looking at URL rewriting.

When working with PHP, Python, Perl or anything else that works well with Apache, rewriting is easy. If you are working with Java or anything that runs under IIS, rewriting gets tricky quickly. Some of the technology which lives under the skin of the web gets a little ugly when you want to start doing pretty things. We’ll talk about overcoming these obstacles soon.

See, here’s the issue. We really want to do URL rewriting, not maintenance-heavy URL trickery. I came across an article about creating pretty URLs which claims it is “pretty easy.” Technically it IS easy but the suggested method is to make a directory for every page and have a single index.php or index.html page in the directory.

Using this method is a one-way ticket to sites you’ll have to manually manage forever. If you are a maintenance thinker, this is fine. If you want to solve the problem correctly, once and for all, you’ll want to do a little URL rewriting, instead.

In case you are new to the idea of URL rewriting, here’s a quick overview. When someone arrives at a site using a URL of the following form:

http://www.chrisstead.com/search/url rewriting

The server captures the URL which was used and then works a little magic, making it look more like the following:

http://www.chrisstead.com/?s=url+rewriting&submit=Search

Which makes the whole URL much MUCH easier to manage and manipulate by, in this example, a PHP script. There are a couple of different reasons we would want to do this kind of rewriting. Let’s take a look at them.

Note: Yes, those both work. Give them a try!

Rewriting hides the underlying technology. This might sound like a strange thing to want to do, but there is learning in my lunacy. People interested in compromising your site will use any knowledge they can get to take advantage of common little flaws and loopholes. By disguising what technology you are using, it sets up a roadblock, making your site less interesting to attack. This isn’t really what I wanted to write about, however.

Rewriting makes gives you the opportunity to make your URLs guessable. If users start to notice a pattern in the way the URLs are structured, they can take advantage of the common themes. This means it is easy for the user to guess how to get to something they want directly and just type the URL. This might seem like kind of an obscure goal, but let’s look at something a little more reasonable.

Suppose you are a music retailer. If you write scripts to handle URLs like the following, your users might not be particularly keen on trying to guess how to rewrite things to find something else:

http://www.mymusicsite.com/query.aspx?s=records&key=LKIH8hi7iKJbkjykjBJ&artist=some%20artist

This looks a little intimidating to me and I know what I was trying to say. Let’s suppose you, then, rewrote URLs instead so what the user sees is this:

http://www.mymusicsite.com/search/some-artist

This looks a lot less intimidating and, better yet, your user knows precisely what happened without even looking at the results you present. They typed “some artist” in the search box, which took them to a search page. They then know how to type another artist in and get a result. It would be even better if you capture the URL and replace the spaces with dashes for them, they can just type the artist name in and get what they want.

When the day is done, the SEO work, usability and findability could and SHOULD work together to create a site that is friendly to search engines as well as your users. That single little string is the first, last and only direct link your user has with the underlying system that drives your website.

**Disclaimer**

If you are a designer reading my blog, you are welcome to stop here. If you have concerns about URL rewriting, I encourage you to contact me and I’ll address them. Take what you have read and make the web a better place. If you are comfortable programming in a web-friendly language, please read on!

**On with the code!**

That’s great and all, but this doesn’t really get us any closer to how you DO any of this rewriting. There are, of course, barriers which get in the way of making this all happen. See, if you are writing in PHP then you are probably serving everything with Apache. This is great since Apache supports URL rewriting directly. If you have any skill with regular expressions then you can work a little juju and be rewriting by this afternoon. Your work will start and stop in the .htaccess file.

Common rules will look like the following:

RewriteRule (.*) /command/directory/index.php?$1 [L]

This was totally made up, so I can’t promise it will work, but this is the basic idea. Apache URL rewriting is a cryptic art that I have yet to master. Fortunately, there are many people, much smarter than I, who can advise and direct your work.

Apache is the nice situation, however. When we look at two languages used on the web, things get tricky really quickly. The tools for rewriting get few and the machinations become more cumbersome. I’ve encountered problems with each of the following.

ASP/ASP.Net runs on IIS which does not natively support URL rewriting. If you are interested in writing your own module or paying for something someone else has written for you, I give you my blessing. However, this may not be an option for you. Fortunately, you can still write URLs of the form:

http://www.mysite.com/Default.aspx?/my/ugly/url

Sadly, this probably cause more pain than anything else. Java, through JSP, has much the same problem. Unless you are running a Tomcat instance, hiding behind an Apache instance where you can rewrite your URLs nicely, your URLS at best will look like this:

http://www.mysite.com/index.jsp?/my/ugly/url

Once you have written your URLs like this, you can get slick and tricky with the code by simply doing the following:

ASP with C# code behind:

String path = Request.QueryString.toString();

JSP:

String path = request.getQueryString();

Now that we have gotten that little piece of ugly out of the way, let’s look at a solution for that gorilla in the corner. ASP and Java are typically only used to solve problems in a business environment. This means your IT department probably has a router and a load balancer sitting between the world and their servers. Enterprise routers are typically highly configurable, and can do quite a bit of rewriting work for you.

The most difficult part of getting your IT department to rewrite your URLs for you is convincing them it’s worth the time and effort. If you can provide them with precisely what you want the end result to be in your efforts, they can probably create the right rules and get everything situated fairly quickly. Be ready to buy them beer.

In the end, pretty URLs, under the skin, are pretty ugly. When it comes to getting your user to the site, moving them through your vast amounts of information and converting the visit into a sale or a return, the pain is worth it. Just think about how much easier life will be for your users once you have taken the time to craft their journey even outside the carefully designed presentation of your website. Think about URL rewriting and guide your user gently. Make the web a better place.

©2012 Chris Stead. All Rights Reserved.