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.

Both articles focused on content and how it gets passed around. The problem is, there is a lot more going than just content on the web. What both articles overlook is the work of the web developer or web engineer. No, this isn’t an attempt to shoehorn engineers into this discussion. It’s about the fact that they are needed to produce function.

Beyond the world of content is a whole slew of function on the web. Web apps have become increasingly important in the landscape of the web. As a matter of fact, you’re currently visiting a web app. Yes, you’re seeing content, but you are also interacting with an application which allows me to manage and publish that content for you to see.

Other things which happen on the web include buying insurance, banking, playing games, posting comments, public forums, meeting whiteboards, chat and many other items which are missing from my list. Web applications are vital to the new web experience.

So, what about the web designers?

Web designers are needed to make all of the extant and constantly emerging applications sensible and enjoyable. Regardless of the particular language or server structure used to produce the web apps you use every day, one of the primary interfaces is still the browser. This means what is an application in one sense is a web page in another. Who designs these pages you see? Web designers.

This link between the design world and the application world has been developing for decades. Designers are vital in the production of web applications just as much as the engineers are. The world of applications today isn’t the same as it was even in the 1990′s.

Users crave satisfaction.

As little as 15 or 20 years ago, to simply have a working application was a feat unto itself. If you could enter input and get a meaningful result in return, the application was launched. People, today, expect more. They want to be able to enter what they need and get the meaningful output they expect, but they also desire rich interaction. They crave visually stimulating and sensible interfaces. Users have gotten more design savvy and they won’t stand for mediocre if they can have the best.

Regardless of where the content, which is fed from a website, is displayed, neither Facebook nor Google will ever be able to serve the function you provide on your site. Moreover, they will not give your user the experience they expect from your company. Only by interacting directly with YOUR site will the user ever find the satisfaction they seek.

Ultimately, the people responsible for bridging the gap between the engineer and the user are designers. Designers come in various flavors from the jack-of-all-trades to the specialist interaction, user experience and interface designers. Designers make the user comfortable. Designers provide the problem-solving expertise which is so crucial to making an interface meaningful and usable.

In the end, to say that the future of the internet has no room for designers would be just as foolish as saying the future of the internet has no place for engineers. I mean, there are all of these turnkey software packages out there, what do you need an engineer for?

It’s foolishness.

Ultimately, engineers and designers are both critical to the web experience. They have been until now and the need is only expanding. Even as content is served out to other distribution channels, the home still needs to be somewhere. Even as content is still king, the sea of applications continues to expand. Much like Jell-O there is always room for designers. Go, design and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

It is reasonable to say that no two people have the same patience for waiting and searching. Some people will wait and search for an extraordinary amount of time while others get frustrated quickly and give up almost immediately. To expect that all of your users will hold out until the very last moment of the predicted 13, or so, seconds hardly reflects reality.

Instead, we can say that we have some maximum tolerance, L, which we can compute which the very last holdouts will actually wait for. Unfortunately, we also know that a majority of users, if they have to wait very long, won’t even see your site since they will fall off before the page finishes loading. This means that the bulk of the users which see your site will be something less than the number of users who actually attempted to load your site.

There were some really smart guys who lived about 100-200 years ago and did lots of math. The really neat thing is they did a lot of work that I don’t have to reproduce or prove since they were smarter, more patient and far more talented than I am. One of them was named Carl Friedrich Gauss, who some refer to as the Prince of Mathematics. He was really smart. Newton smart. Possibly smarter than Newton.

What does Gauss have to do with user experience?

Gauss is the guy who figured out how to evaluate (1/(2pi)^.5)e^(-1/2*x^2) when integrated from negative to positive infinity. Did I just see your eyes glaze over? It’s alright. That happens to me a lot.

What this really translates to is, Gauss figured out how to work with the statistical standard normal curve. This probably means a lot more to you, right? This function happens to be really useful in developing something meaningful regarding users and their falloff over time from initial click through to our tolerance, L.

I spent an entire weekend where I slept little and did math a lot. During that time, I developed a function, based on the standard normal curve which says something reasonably meaningful about users and how long they are willing to stay on your site and either a) search for what they need and b) not satisfice. I’ll give you the function without justification. Contact me if you want all the formalities, I have them in a folder, on the ready.

Our function looks something very much like the following:

u(t) = u_0^(1-(t/L)^2)

What this says is that the number of users still on your site, at time t, is equal to the initial users times some falloff function evaluated for t. The cool thing is, we already know everything that goes into this little gem when we are testing. We know how many users we started with and we know what L is. The really interesting bit is, when t>L, u(t) is less than one. This means that the probability we will have a user after we reach the maximum tolerance is exactly what we expect it to be.

Below is an estimation of what the graph would look like for your analysis:

User Falloff Over Time

This may not seem like much of a revelation. We all know that, as people run out of patience, they leave the site. What this does is it gives us something we can plug into our calculators and project some sort of quantified result. What this also means is, if you can produce results which fall beyond the bounds of this graph as you are testing, you know you are outperforming expected results. You can also use this to compare to the number of people who satisfice during testing.

Probably one of the most important things is comparing the number of users who remain on a site for an expected amount of time to the amount of time needed to produce a conversion. This offers a real, concrete means to offer up ROI on your efforts to encourage users to remain on your site.

The uses of this modest function are so numerous I can’t afford the space here to list them. I will offer up more insight into this function as well as other, related, functions which can be used for further prediction. I encourage you to sit and play with this. See how it compares with your test findings. Gauge how you are performing against the model. Improve and test again and, above all else, make the web a better place.

©2012 Chris Stead. All Rights Reserved.

Before we start down this particular rabbit hole, there’s a bit of a prerequisite for our discussion. It is important that you understand Fitts’ Law and its generalization, the Steering Law. These are critical to understanding how much time a user will be willing to dedicate to your site the first time they arrive, or after a major overhaul, before abandoning their goals and leaving the site.

So, let’s suppose you have users visiting your site, or, better yet, you are performing user testing and want to evaluate how your site is performing with the users you are testing. It is important to have a realistic expectation regarding what users would really tolerate on the web before they leave so you can evaluate the results of your test accordingly.

Most users have some sort of tolerance level. By this, I mean most users are only willing to give you a fraction of their day before they get fed up. Reasonably, some users will have a shorter fuse than others, but all will eventually blow the proverbial gasket and leave your site, never to return. Let’s call this tolerance for pain and frustration ‘L.’

L is the amount of time, typically in seconds, that your user is willing to spend time looking over your site and trying to accomplish their goals. It is becoming common to say that a user will attempt to satisfy a goal and, ultimately, they will attempt to satisfice if nothing else seems to work.

When they hit the satisfice point they are reaching their tolerance for frustration. The satisfice action comes quickly, so we have very little time to fully satisfy the user. There are actually 3 items which go into the base tolerance before satisficing occurs:

1. The maximum acceptable page load time (p)
2. The maximum time it takes after page load to locate a satisfactory action to achieve their goal (g)
3. The Fitts’/Steering time it takes to get to their preferred action item (fs)

The maximum acceptable page load time seems to range from one to ten seconds depending on who you talk to or read on the web. I am opting to take the average and say that the maximum page load time should take around five seconds, though this can vary depending on other factors which are outside the scope of this discussion.

Users, once the site has loaded, have a maximum time they will spend searching for something to satisfy their goals. The number I keep seeing thrown around is seven seconds, so I am going to accept that as my number for a general baseline for user behavior.

Finally we have Fitts’ Law and the Steering Law. This lends a little complication to the matter as these functions will return varying results. The simplest case would be a Fitts’ law case where the user can move directly to an item on the screen without interruption or interference. Each person knows how much time it takes them to move from one place to another on the screen and they will, generally, allow for time to move the cursor to a target.

If the screen does other, unexpected things while the user is moving their pointer, like opening and closing ads, displaying inline pop-ups which cover the target or other interferences, the user will get distracted and frustrated. This is where a Fitts’ Law asset can become a Steering Law liability. A frustrated user is far more likely to leave than a satisfied user. For each item which interferes with the user’s ability to move to their target, their patience will wane. Reasonably, then, using the variables I defined above, we can calculate the tolerance constant as follows:

L = p + g + fs – (sum of all subsequent change in fs)

Better yet, if we plug in the basic values I collected from around the web, we get this:

L = 5 + 7 + fs – (sum of all subsequent change in fs) = 12 + fs – (sum of all subsequent change in fs)

Moving from one place on the screen to another is a relatively quick motion, so we can see, given there aren’t major issues with user-flow interruption, that the average user tolerance is going to be between 12 and 13 seconds for a site from beginning to end. That’s not a very long time, but to a user, it’s an eternity. Don’t believe me? Sit and watch the clock for 13 seconds, uninterrupted. Go on, I’ll wait.

Kind of a painful experience, isn’t it? Keep this in mind as you create your site and watch users test it. During your next test, run a stopwatch. If it takes your tester more than a quarter of a minute to sort everything out and do what they were tasked with, you have some serious issues to consider.

I threw a lot out in one little post, today. Let it soak for a while and tell me what you think in the comments. As you work on guiding users through your site and as you test, think about the 13 seconds just watching the clock tick. Consider your user and their tolerance for frustration and pain. Keep the journey quick and painless and 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.

Years ago, I built a project tracking system for the Creative department at my current company which they use for everything. More projects come and go through the Creative project queue than I had planned on, but it has held together reasonably well. That said, the Engineering director would like to get everyone in the company on the same set of software in order to streamline maintenance efforts.

In theory, this unification makes lots of good sense. Less money will be spent maintaining disparate software and more will be spent on keeping things tidy, making for a smooth experience for all involved.

Unsurprisingly, I was met with resistance from the Director of Communications. She told me she was concerned about the glut of features and functions she had no use for. She prefers the simple system because the creative team is a small team of three. Tracking all of the projects a small team has is just challenging enough to require a small system, but not so challenging that she needed all the heavyweight tools a team of 50-100 people would.

I am currently acting as negotiator between the Engineering and Creative departments. Proposals and counter proposals are being thrown back and forth and I’m caught in the middle. The challenge I see sneaking about in the grass is that the Engineering team doesn’t know their customer.

This doesn’t mean the Engineering team is bad. It doesn’t mean they don’t care. It simply means they don’t live in the same headspace the Creative team does and they don’t have enough time to think about it.

This puts me in a sticky situation.

I worked exclusively with the Creative team for the first two years I was with the company. I ate lunch with them, worked with them, met their deadlines, played by their rules and build 95% of the tools they use today. It was a really great insight into what a creative time is really like. Something many engineers never have the opportunity to experience.

Now, I am part of the Engineering team again and playing by their rules. Engineers think differently. I am an engineer and my father was an engineer before me. I know a thing or two about engineers and their quirks. Ultimately, I can see both sides of the argument and the standoff is looking a little hairy.

“So, where are you going with all this,” you might ask.

If you are going to propose a solution to a problem, instead of learning all you can about the solution you are going to offer, learn about your customer instead. Don’t try to shoehorn a customer into a solution saying “it kind of does most of what you need as long as you need the stuff it does.” It will never work out for you.

Learn your customer’s language. Uncover little secrets about them and figure out how they really work. Customers will rarely pony up and say “here’s everything you need to know about us and our problem.” Almost always, they say “here is our problem. Fix it.”

If you don’t know your customer, you’ll never solve their problem. If, on the other hand, you DO know your customer, you have a fighting chance. Mind you, even if you know your customer, they may still disregard your solution anyway, but at least you know you gave them the best you had.

Don’t fret if it takes some time to learn to think like your customers, though. It’s not something that comes overnight. I know it took a while for me to stop thinking like an engineer for 30 seconds and think like a designer. One day, I woke up and everything had to be diagrammed. There were so many things which could only be said through images. The shift happened and the code disappeared.

Look for the transparency. If you can stop and step into your customer’s head for a few minutes you may discover that the real problem is not the issue they have with the solution you offered, it may be with the solution that doesn’t solve their problem. Creatives, engineers, accountants, executives and marketing people all work in different ways. Businesses are much the same. Find how their problem is different and you will find the solution. Know thy customer and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

It is important to consider search engines during the site building process, however I feel the SEO guys often get carried away. In this article it is suggested that you de-emphasize navigation and forget footers along with lots of other questionable advice.

These two suggestions alone are enough for me to consider this article, at best, a crackpot spouting extremist ideas. SEO experts often seem to forget a very important element on the web: the user.

Something designers are told and people are wise to heed is, pretty things work better. Do they ACTUALLY work better in some sort of quantifiable way? Probably not, but that doesn’t matter to the user. If a site is attractive and seems easy to use, the user is more likely to invest the time to learn how it works.

User experience people know that navigation is key to moving a user through the site. Let’s take, for example, Amazon. They are a top-rated site for Google searches. Have they gone and done away with navigation? No. Why? They know users rely on navigation to move through the site. Moreover, their designers know that pretty navigation works.

While the SEO nuts will scream “de-emphasize navigation,” Amazon bucks the “trend” and keeps on doing what they know works best for making money: directing users.

Regarding forgetting about footers, if anyone in the SEO world ever thought footers were there for search engines, they are fooling themselves. Footers are only ever implemented for the user. Information which a small group of users may want is typically stored in the footer. This kind of information is stuff like license numbers, contact information and other legal odds and ends.

Other common footer items include convenience links, brief site navigation and polish elements which finish out a site. Footers, especially those of the fat variety, were never intended to be SEO tools. They are for the user.

If an SEO guru were to design a site, it would probably be a huge mass of text with a few peppered images, some meta information at the top, a link which says “home” and the required legal information at the bottom in a big, unattractive text block.

Though a page like this would garner a couple of extra points from search engines for being easy to parse, it would lose mega points for being completely useless to a user. The more useless your site is, the fewer users will return. The fewer return visitors you have, the lower your site rank will be. Ultimately, you will win the battle and lose the war.

Moreover, what is really making the money, the search engine or your product? Trust me, if you have a product everyone wants, the search engines will bump you up the list even if your SEO stinks. On the other hand, if your SEO is top-notch, but your site fails to deliver conversions you may as well pack it in now.

Finally, something I never seem to hear SEO people talk about which should be absolutely top of their list is the semantic web. The semantic web can be horribly complex which seems a little daunting, but it doesn’t have to be. Simply remember to use the right tags at the right time and you’ll be on your way to better SEO without all of the extraneous pain involved in new metadata information embedded in your pages.

Remember to do things like break your pages up into headers, divisions, paragraphs, lists and tables. If you want to get really fancy, add definition lists. This will score big points with the search engines and it will also score big with your audience. The more you can divide your information into digestible chunks and then style with CSS, the happier everyone will be. Users will be able to quickly skim the page in search of what they are there for and the search engines will be able to parse your pages better, potentially leading to better overall ranking.

In the end it is best to build your pages the right way: semantic tagging, strong user focus and dense metadata components. There are many SEO techniques which work better for both search engines and users. Forget about completely re-building your page just to impress the Google spider, because you won’t. Think about the user, build a compelling site, mark it up correctly and make the web a better place.

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

The web is moving away from exclusivity. When the web started, documents were shared, whole, and people had to visit a particular site to view their content. It rarely came to you, typically requiring you went to it. This was the face of the web in the 1990′s. Autonomous operating sites maintained individually for the sake of the content maintained within.

The modern web, as I discussed last week, is constructed with a blend of autonomous content and content-objects from across the web. This kind of shared content structure is a natural development beginning with sites maintained as interfaces interacting with content sources like databases.

By creating an exclusive web application you gain certain benefits. You control your environment. You get to set the rules and everyone who uses your system must obey. You maintain the images. You store the copy. You define the network. Everything you do lives within the ecosystem you create.

For as good as it sounds to have supreme power over a web ecosystem, there are drawbacks. You are solely responsible for maintaining the system. When things break, it is your job to fix them. When enhancements are made, you are the one on the hook to build them. The onerous is on you and you alone.

There is another issue that comes with maintaining a partially or fully closed ecosystem. You can lose trust. People get wise when others start watching everything they are doing. This kind of realization hurts companies. Facebook appears to be suffering from just this kind of loss of trust right now. As they get more aggressive with sharing user data, they lose user trust. Since Facebook is a closed ecosystem, an exclusive web application, and users are aware they are being watched, trust in the system wanes.

Inclusive web applications, on the other hand, lend a feeling of freedom and sharing due to the transparent sharing of information across the wire. The inclusive web draws information in from APIs and RSS feeds across the web. Just as information flows in, the local API allows information back out again.

When the inclusive web also allows people to manage their own privacy, users feel more secure. They know they can collect the information they want and share it with whomever they like without feeling the burden of filtering or censoring their preferences in order to please people they neither know nor are aware even exist.

The benefit you gain from running an inclusive web application is the ease of production. You maintain the code base for a hub and your unique function while allowing other services to manage the content they specialize in. This community development process leads to many different groups acting in a specialized way and supporting a subset of the total code that builds the end user experience.

For the gains available in the inclusive web, there are pitfalls as well. Privacy management becomes a more complicated task for the user. Instead of managing the privacy controls at a single dashboard, they are required to manage their privacy as it applies to each system they touch. This can become a burden if a user suddenly decides to overhaul the privacy settings across their personal social ecosystem.

Another concern to weigh against is control. The more inclusive your application is the less control you have over the experience your user has when they interact with the ecosystem in its entirety. Within the scope of your application, users can, and should, have a consistent experience.

All APIs, however, are not made equal, so preparing and presenting an interface for your user does not mean you will be able to give them the same rich experience they would have when interacting with the primary service. On the other hand, this may be preferable as you can offer a subset of functions which relate directly to your service without directly mirroring the function of the service you are interacting with.

With these control issues in mind it is likely still a greater benefit to be inclusive rather than exclusive. Through acting in an open, inclusive way your site becomes a boon to the user, enhancing their experience and making the web a friendlier place to be.

In the end, however, the inclusive web is where users truly live. No user interacts solely with any specific web application forsaking all others. They look to constantly enhance their experience on the web through richer interactions. These interactions, however, are not just with a machine. They are interactions with people. People don’t all live in once place.

Instead of trying to fight the inevitable rise of the inclusive web as an expectation of the user, embrace it. Think about the sites and services your users prefer. Engage your users with new ways of acting with and upon the web around them. Provide your users an open, inclusive experience. 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.