Content: It's All About Objects

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.

It's a Fidelity Thing: Stakeholders and Wireframes

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.

Developing for Delivery: Separating UI from Business

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.

I Didn't Expect THAT to Happen

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.

Degrading Behavior: Graceful Integration

There has been a lot of talk about graceful degradation. In the end it can become a lot of lip service. Often people talk a good talk, but when the site hits the web, let’s just say it isn’t too pretty.

Engineers and designers work together, or divided as the case may be, to create an experience that users with all of their faculties and a modern browser can enjoy. While this goes down, the rest of the world is left feeling a bit chilly.

What happens is, the design starts with the best of intentions and, then, the interactivity bug takes hold. What comes out is something that is almost usable when slightly degraded, but totally non-functional when degraded to the minimum.

Website Overhaul 12-Step Program

Suppose you’ve been tasked with overhauling your company website. This has been the source of dread and panic for creative and engineering teams the world over.

Some people, in the panic and shuffle, opt for the fast-and-loose approach. They start throwing anything they can at the site, hoping something will stick. Anything means ANYTHING. All marketing ideas go in the bucket, then the executive mandates, the creative odds and ends, some engineering goodness and all of that. This almost always results in a disaster.

Others look to collect everything that people want and need, do a ton of marketing research and then follow that up with user testing. Though this may lead to a usable site, this method probably won’t generate a site that actually solves user needs.

Pretend that they're Users

Working closely with the Creative team, as I do, I have the unique opportunity to consider user experience through the life of the project. More than many engineers, I work directly with the user. Developing wireframes, considering information architecture and user experience development all fall within my purview.

Typical engineers, on the other hand, live in a world separated and buffered from Creative and, subsequently, the user. They work with project managers, engineering supervisors and other layers of businesspeople that speak on behalf of the user, alienating the engineer from the world they affect.

It becomes easy to dissociate and refer to the user as clients and eventually abstract the interaction by focusing on the system and the software client that will interact with the functions being built. People as users become a vague notion that is hardly considered as functional pieces are built and pushed out.

User Experience Means Everyone

I’ve been working on a project for an internal client, which includes linking out to various medical search utilities. One of the sites we are using as a search provider offers pharmacy searches. The site was built on ASP.Net technology, or so I would assume as all the file extensions are ‘aspx.’ I bring this provider up because I was shocked and appalled by their disregard for the users that would be searching.

This site, which shall remain unnamed, commits one of the greatest usability crimes I’ve seen: they rely only on Javascript to submit their search. In order to give you, dear reader, the scope of the issue, I always test sites like these by disabling Javascript and testing the function again.

The search stopped working.

Predictive User Self-Selection

Some sites, like this one, have a reasonably focused audience. It can become problematic, however, for corporate sites to sort out their users, and lead them to the path of enlightenment. In the worst situations, it may be a little like throwing stones into the dark, hoping to hit a matchstick. In the best, users will wander in and tell you precisely who they are.

Fortunately, users often leave hints as to who they are without knowing it. They (hopefully) travel through your site, touching certain pages and avoiding others. They also arrive from somewhere.

When trying to select your user and direct them, your initial response may be to directly ask them who they are and what they want. This works well if you are an e-tailer like Amazon, but the rest of us don’t have quite the same luxury.

Mapping the Course: XML Sitemaps

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

I say XML sitemaps are good!

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