Through all of the usability, navigation, design, various user-related laws and a healthy handful of information and hierarchical tricks and skills, something that continues to elude designers and developers is pretty URLs. Mind you, SEO experts would balk at the idea that companies don’t think about using pretty URLs in order to drive search engine placement. There is something else to consider in the meanwhile:

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.net/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.net/?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.

    

When I wrote my first post about object-oriented content, I was thinking in a rather small scope. I said to myself, “I need content I can place where I need it, but I can edit once and update everything at the same time.” The answer seemed painfully clear: I need objects.

Something funny happened between then and now. I realized that content is already made up of objects. All at once, I discovered I was one with all of the content scattered across the web. It was a very zen moment I’m not sure I could recreate on my best day.

See, we are already working with content objects everywhere, but we just haven’t noticed. Take Twitter for instance. Twitter specializes in the content object. It’s a very small object, but it’s there all the same. Take, for instance, a tweet from my feed.

My one tweet is both content on its own and it is part of my feed which is also content. The same can be said for blog posts, RSS feeds, Facebook status updates, YouTube videos, that picture of your cat and any other of a number of things scattered across the web.

The funny thing is, these pieces of content are already broken up for you and made ready for consumption. So, let’s head back to your site for a moment. That footer information you have posted on every page is managed as an object. This can be further demonstrated by the fact that CSS uses the box model to manage the content on your page. Those boxes are objects.

This is getting a little esoteric. Let’s bring things back around for a moment, shall we?

Content is more than just the sum of its parts, i.e. words, images and video. Content is something so real it can almost be touched. It’s a building block. Without content, the web would be nothing and the only reason the web is something WITH content is because content is something.

Still a little weird, right? When you build a site, you could simply throw content at the screen without containers. This would result in a rambling page with no breaks, no sense and no way to logically decipher it. This would be something akin to the center of the sun: lots of elements, really dense and really REALLY hard to live around.

In order to make the content more presentable to the user, we break it up into pieces we can manage and format. As soon as you have done this, you no longer simply have words and other garbage on a page, you now have divisions, paragraphs and images. Outside the page, those divisions are meaningless.

Says who?

If a paragraph from a book were written, longhand, on a sheet of paper, it doesn’t lose the quality of being a paragraph, it simply loses its association with the book from whence it came. This means the content structure is actually meaningful outside of the original context.

This is really useful when you deconstruct and reconstruct a page. All of a sudden you aren’t trying to figure out where to put this image and that word. Instead, you are filling a bucket. That bucket happens to have a name, and that name is ‘page.’ The best part of this whole exercise is, we have now separated content from the page it lived in.

Why do this?

Once you’ve broken the content out of the page, it doesn’t really matter where the content comes from. This means you can start drawing smart boxes on your page and simply filling them with the content you want. Need an RSS feed? I’ll draw a box for that. Want a piece of home-grown content? I’ll draw a box for that too. After all of the box drawing is done, you can start pulling in pieces from all over the web and putting them right into your site.

Much of this isn’t new. We’ve been dropping content into sites like this for years. Where this can get really interesting is when you are working on blended content/application sites. All of a sudden something really magical happens. Functions aren’t programs which live off in a separate ecosystem. The functions become OBJECTS!

When your functions become objects, they stop being scary and just become part of the content flow. Forms go here, dynamic items go there and the page comes together. By simply realigning ourselves and looking at content as objects, instead of words, images, feeds, functions and all the other odds and ends available to us in spades, putting a site together becomes something of a spiritual experience. All of the wonders of the web come together to form a cohesive whole.

For your next project, go crazy. Imagine you are playing with blocks and throw away your content notions altogether. Use the APIs available in the wild and build a smarter page. The magic of the web is the fact that everything exists a mere request away. Think about objects and build your site. Make the web a better place.

This morning I read a post about wireframes and when they are appropriate. Though I agree, audience is important, it is equally important to hand the correct items to the audience at the right times. This doesn’t mean you shouldn’t create wireframes.

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.

With the advent of Ruby on Rails (RoR or Rails) as well as many of the PHP frameworks available, MVC has become a regular buzzword. Everyone claims they work in an MVC fashion though, much like Agile development, it comes in various flavors and strengths.

So, what is really going on here?

The idea behind MVC as well as many other design patterns, is to break programming tasks into chunks and handle them independently. MVC typically fills a need on the web as the view or UI is what the user ultimately sees and keeping it uncluttered makes life easier for the creatives to work their magic after the programmers have performed theirs.

Though frameworks typically make it easy to keep the models, views and controllers separate, programmers tend to get a little heavy with the code. There is a project of which I know, and will remain unnamed, that incorporates business and model logic into all parts of the code. This sets the developers up for two distinct issues:

Requirements change

Maintenance is a nightmare

First, we know that requirements change. Someone is going to say “gee, I wonder if we could do x.” When it is an executive that says this, the whole sentence can be rewritten simply as “do x.” If the code is scattered across views, controllers and models then changing direction is kind of like redirecting an aircraft carrier. You can do it, but it is slow going.

If the code is packaged into neat little controllers and the view is completely separate, then adding new function is much less labor intensive. In the end, functions almost materialize before you, taking a task which could have been a month project and turning it into something which gets done in an afternoon. The savings is tremendous.

Second, the maintenance nightmare. There are many factors that come into play when writing maintainable code, but let’s focus on the single aspect of good, modular practice. When writing code, be it in an MVC design or some other separation scheme, putting together solid modules makes everything a little easier to maintain.

Imagine you have your same, scattered code. A little of the work is done here. Some of it is done there. In the end, it takes fifteen files to get a job done. Suppose something breaks. Don’t say your code never breaks.

All code breaks.

Once something breaks, you have to maintain it. Now, was that function here or was it over there? What all did it do? Where do I find it?

Perhaps you haven’t touched that code in three years. It happens. You could spend a day just tracking down the bug, forget about fixing it.

Now, I don’t want to make this all about MVC, because it’s not. This is about simply keeping the presentation separate from the business logic. Perhaps your business logic is broken into 15 layers. Great. Make sure that none of those layers is the presentation.

So, what does this have to do with delivery?

I’m glad I asked.

Rhetorical questions suck.

On the web there is one goal. Deliver content to the user. I don’t care who you are or what you do. In the end you are delivering something to the user. Sometimes it’s e-mail. Sometimes it’s a blog. Sometimes it’s a way for them to do their taxes. It is all about delivery.

Users on the web are demanding. They want it all and they want it now. If there is a bug, they don’t want to wait for the next five build cycles to see it fixed, they want it now. The simpler you make things for yourself, the easier it is to get down to the business of delivery.

Another benefit you will see is the ability to quickly change direction. If your creative team wants to completely redesign the website, it won’t cost the rest of your life to make this happen. You can keep all of the infrastructure you already have and simply make it look new.

I am currently working on a project using JSP. I am collecting website content from an outside source and presenting it within a JSP page. I could have build a heavyweight page that does all of the collection and presentation, but I opted against it. Instead I built several classes, each meant to perform a single clear task. One collects menu information, another collects the content. Yet another produces nicely formatted menus.

You’ll note there are two classes for menus. This is intentional. I don’t want to have to dig through all of the menu collection code to rewrite the menu presentation engine. These should live separately.

In the end, all the actual JSP page does is present the pre-collected, pre-formatted content I prepared using plain old, run-of-the-mill Java. The extra added benefit: because most of the function is compiled to run in a virtual machine, rather than parsed and executed by an interpreter, the collection and presentation is blazing fast.

The lesson to be gleaned from my rambling post is this: regardless of the particular design model you choose, break pieces apart. Keep the UI separate from the business logic. It will save some gray hair, hours of lost time and it might even make your program function better. Develop for delivery, keep your code tidy and make the web a better place.

How many times have you been on a website and said those very words? You click on a menu item, expecting to have content appear in much the same way everything else did. Then, BANG you get fifteen new browser windows and a host of chirping, talking and other disastrous actions.

Boy, I didn’t expect THAT to happen.

You’ve fallen prey to a violation of what I call page-behavior taxonomy. In short, page-behavior taxonomy is a set of rules that certain items must follow when they perform an action or page-behavior. Wikipedia does a reasonable job of telling the user what they should expect after they perform an action as each type of link looks a certain way.

In the current age, a typical website has links that behave in all kinds of ways. Some links move the user to a new page. Some links display information inline. Some links move the user away from the site altogether. The user anticipates the behavior of a link based upon page context and presentation.

Each of the links on a page fall under a particular taxonomical definition. The written list of taxonomical definitions is all but hidden to the user. In the best situations the taxonomy can be used to define the user journey and experience, creating a smooth flow of content from the web to the user.

The most common page-behavior taxonomy I use categorizes links into the following groups: inline content links, intra-website content links, extra-website content links, object display links and other javascript behavior.

When the taxonomy is considered, the user will understand the function of a link given the context they discover it under. This means, if they see a calendar icon next to a date entry field, they won’t be surprised when they click the icon and a calendar pops up. It relies on expectation of the user and the fact that the link was part of the “other javascript behavior” kingdom.

What brought this discussion about was my discovery of a set of tabs that violated the page-behavior taxonomy. I won’t provide the site because they were giving away a script to let others recreate the effect. We discourage bad Ux around here.

The tabs I encountered were AJAX enabled. This means the user clicks a tab and the content is requested and displayed inline. I was generally okay with the behavior. It was something the user could reasonably anticipate or even be pleasantly surprised by. I didn’t see any way for the tabs to degrade gracefully, but I won’t go into that now.

As I clicked through the tabs, I had a nice, consistent experience.

Click -> content, click -> content, click -> content.

Then I clicked the last tab and my browser window was hijacked. I was sent off to a new page entirely. I didn’t know where I was. I didn’t know what I was supposed to gain from the page. I was lost. All I wanted, after that, was to go home.

The designer had kept me distracted while the developer got behind me and crouched. The designer pushed and I fell over. I felt betrayed. How could my friend, the designer, or my colleague, the developer, play such a dirty trick?

This sentiment is shared by users when they visit a site that tricks them. The user, in the end, feels they were somehow dealt an unfair hand. They feel betrayed. They lose faith. They leave.

The important item to note is, no single person is responsible for this kind of manhandling. First, the UxD has to betray the user by not telling them something is going to happen. Then the developer has to build a function to enable this kind of behavior. In the end, both parties were to blame.

The solution to this is to build a taxonomy. Consider the terms you will use. Select copy that is meaningful to your user and use it consistently across your site. Develop a list of page behaviors and implement them, projected against your taxonomical dictionary. Make page-behavior rules clear to your user. If you plan on surprising them, do it by understanding ease-of-use.

Carefully consider your link behavior and develop it against a backdrop of user understanding. Make your site easy to use. Think of your user and don’t give them unpleasant surprises. Construct a page-behavior taxonomy to structure your site around and make the web a better place.