Usabilibloat or Websites Gone Wild

Apr 21, 2010

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.

Thinking in Pieces: Modularity and Problem Solving

Apr 12, 2010

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.

Almost Pretty: URL Rewriting and Guessability

Mar 29, 2010

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: rewriting

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

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:

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:

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.


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:

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:

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();

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.

Content: It's All About Objects

Mar 25, 2010

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.

It's a Fidelity Thing: Stakeholders and Wireframes

Mar 15, 2010

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.

  • Web Designers Rejoice: There is Still Room

    I’m taking a brief detour and talking about something other than user tolerance and action on your site. I read a couple of articles, which you’ve probably seen yourself, and felt a deep need to say something. Smashing Magazine published Does The Future Of The Internet Have Room For Web Designers? and the rebuttal, I Want To Be A Web Designer When I Grow Up, but something was missing.

  • Anticipating User Action

    Congrats, you’ve made it to the third part of my math-type exploration of anticipated user behavior on the web. Just a refresher, the last couple of posts were about user tolerance and anticipating falloff/satisficing These posts may have been a little dense and really math-heavy, but it’s been worth it, right?

  • Anticipating User Falloff

    As we discussed last week, users have a predictable tolerance for wait times through waiting for page loading and information seeking behaviors. The value you get when you calculate expected user tolerance can be useful by itself, but it would be better if you could actually predict the rough numbers of users who will fall off early and late in the wait/seek process.

  • User Frustration Tolerance on the Web

    I have been working for quite a while to devise a method for assessing web sites and the ability to provide two things. First, I want to assess the ability for a user to perform an action they want to perform. Second I want to assess the ability for the user to complete a business goal while completing their own goals.

  • Google Geocoding with CakePHP

    Google has some pretty neat toys for developers and CakePHP is a pretty friendly framework to quickly build applications on which is well supported. That said, when I went looking for a Google geocoding component, I was a little surprised to discover that nobody had created one to do the hand-shakey business between a CakePHP application and Google.

  • Small Inconveniences Matter

    Last night I was working on integrating oAuth consumers into Noisophile. This is the first time I had done something like this so I was reading all of the material I could to get the best idea for what I was about to do. I came across a blog post about oAuth and one particular way of managing the information passed back from Twitter and the like.

  • Know Thy Customer

    I’ve been tasked with an interesting problem: encourage the Creative department to migrate away from their current project tracking tool and into Jira. For those of you unfamiliar with Jira, it is a bug tracking tool with a bunch of toys and goodies built in to help keep track of everything from hours to subversion check-in number. From a developer’s point of view, there are more neat things than you could shake a stick at. From an outsider’s perspective, it is a big, complicated and confusing system with more secrets and challenges than one could ever imagine.

  • When SEO Goes Bad

    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.

  • Balance is Everything

    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.

  • Coding Transparency: Development from Design Comps

    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.

  • Usabilibloat or Websites Gone Wild

    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.

  • Thinking in Pieces: Modularity and Problem Solving

    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.

  • Almost Pretty: URL Rewriting and Guessability

    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:

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

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

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

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

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

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

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

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

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

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

  • The Browser Clipping Point

    Today, at the time of this writing, Google posted a blog stating they were dropping support for old browsers. They stated:

  • Creativity Kills

    People are creative. It’s a fact of the state of humanity. People want to make things. It’s built into the human condition. But there is a difference between haphazard creation and focused, goal-oriented development.

  • Reactionary Navigation: The Sins of the Broad and Shallow

    When given a task of making search terms and frequetly visited pages more accessible to users, the uninitiated fire and fall back. They leave in their wake, broad, shallow sites with menus and navigtion which look more like weeds than an organized system. Ultimately , these navigation schemes fail to do the one thing they were intended for, enhance findability.

  • OOC: Object Oriented Content

    Most content on the web is managed at the page level. Though I cannot say that all systems behave in one specific way, I do know that each system I’ve used behaves precisely like this. Content management systems assume that every new piece of content which is created is going to, ultimately, have a page that is dedicated to that piece of content. Ultimately all content is going to live autonomously on a page. Content, much like web pages, is not an island.

  • Party in the Front, Business in the Back

    Nothing like a nod to the reverse mullet to start a post out right. As I started making notes on a post about findability, something occurred to me. Though it should seem obvious, truly separating presentation from business logic is key in ensuring usability and ease of maintenance. Several benefits can be gained with the separation of business and presentation logic including wiring for a strong site architecture, solid, clear HTML with minimal outside code interfering and the ability to integrate a smart, smooth user experience without concern of breaking the business logic that drives it.

  • The Selection Correction

    User self selection is a mess. Let’s get that out in the open first and foremost. As soon as you ask the user questions about themselves directly, your plan has failed. User self selection, at best, is a mess of splash pages and strange buttons. The web has become a smarter place where designers and developers should be able to glean the information they need about the user without asking the user directly.

  • Ah, Simplicity

    Every time I wander the web I seem to find it more complicated than the last time I left it.  Considering this happens on a daily basis, the complexity appears to be growing monotonically.  It has been shown again and again that the attention span of people on the web is extremely short.  A good example of this is a post on Reputation Defender about the click-through rate on their search results.

  • It's Called SEO and You Should Try Some

    It’s been a while since I last posted, but this bears note. Search engine optimization, commonly called SEO, is all about getting search engines to notice you and people to come to your site. The important thing about good SEO is that it will do more than simply get eyes on your site, but it will get the RIGHT eyes on your site. People typically misunderstand the value of optimizing their site or they think that it will radically alter the layout, message or other core elements they hold dear.

  • Information and the state of the web

    I only post here occasionally and it has crossed my mind that I might almost be wise to just create a separate blog on my web server.  I have these thoughts and then I realize that I don’t have time to muck with that when I have good blog content to post, or perhaps it is simply laziness.  Either way, I only post when something strikes me.

  • Browser Wars

    It’s been a while since I have posted. I know. For those of you that are checking out this blog for the first time, welcome. For those of you who have read my posts before, welcome back. We’re not here to talk about the regularity (or lack thereof) that I post with. What we are here to talk about is supporting or not supporting browsers. So first, what inspired me to write this? Well… this:

  • Web Scripting and you

    If there is one thing that I feel can be best learned from programming for the internet it’s modularity.  Programmers preach modularity through encapsulation and design models but ultimately sometimes it’s really easy to just throw in a hacky fix and be done with the whole mess.  Welcome to the “I need this fix last week” school of code updating.  Honestly, that kind of thing happens to the best of us.

  • Occam's Razor

    I have a particular project that I work on every so often. It’s actually kind of a meta-project as I have to maintain a web-based project queue and management system, so it is a project for the sake of projects. Spiffy eh? Anyway, I haven’t had this thing break in a while which either means that I did such a nice, robust job of coding the darn thing that it is unbreakable (sure it is) or more likely, nobody has pushed this thing to the breaking point. Given enough time and enough monkeys. All of that aside, every so often, my boss comes up with new things that she would like the system to do, and I have to build them in. Fortunately, I built it in such a way that most everything just kind of “plugs in” not so much that I have an API and whatnot, but rather, I can simply build out a module and then just run an include and use it. Neat, isn’t it?

  • Inflexible XML data structures

    Happy new year! Going into the start of the new year, I have a project that has carried over from the moment I started my current job. I am working on the information architecture and interaction design of a web-based insurance tool. Something that I have run into recently is a document structure that was developed using XML containers. This, in and of itself, is not an issue. XML is a wonderful tool for dividing information up in a useful way. The problem lies in how the system is implemented. This, my friends, is where I ran into trouble with a particular detail in this project. Call it the proverbial bump in the road.

  • Accessibility and graceful degradation

    Something that I have learnt over time is how to make your site accessible for people that don’t have your perfect 20/20 vision, are working from a limited environment or just generally have old browsing capabilities. Believe it or not, people that visit my web sites still use old computers with old copies of Windows. Personally, I have made the Linux switch everywhere I can. That being said, I spend a certain amount of time surfing the web using Lynx. This is not due to the fact that I don’t have a GUI in Linux. I do. And I use firefox for my usual needs, but Lynx has a certain special place in my heart. It is in a class of browser that sees the web in much the same way that a screen reader does. For example, all of those really neat iframes that you use for dynamic content? Yeah, those come up as “iframe.” Totally unreadable. Totally unreachable. Iframe is an example of web technology that is web-inaccessible. Translate this as bad news.

  • Less is less, more is more. You do the math.

    By this I don’t mean that you should fill every pixel on the screen with text, information and blinking, distracting graphics. What I really mean is that you should give yourself more time to accomplish what you are looking to do on the web. Sure, your reaction to this is going to be “duh, of course you should spend time thinking about what you are going to do online. All good jobs take time.” I say, oh young one, are you actually spending time where it needs to be spent? I suspect you aren’t.

  • Note to self, scope is important.

    Being that this was an issue just last evening, I thought I would share something that I have encountered when writing Javascript scripts.  First of all, let me state that Javascript syntax is extremely forgiving.  You can do all kinds of  unorthodox declarations of variables as well as use variables in all kinds of strange ways.  You can take a variable, store a string in it, then a number, then an object and then back again.  Weakly typed would be the gaming phrase.  The one thing that I would like to note, as it was my big issue last evening, is scope of your variables.  So long as you are careful about defining the scope of any given variable then you are ok, if not, you could have a problem just like I did.  So, let’s start with scope and how it works.

  • Subscribe