If you’re anything like me, you’ve used the alert message function as a means to figure out where things were falling apart. That’s great and all, except that it sucks. I hate needing popup messages to debug things like mouseovers. It’s no fun. If you forget to pull one out of your code before it goes to production, it can be miserable trying to track it down later when users are getting alerts that say things like “Why doesn’t my function work??”

Whoops.

So, I started thinking about developing in pretty much any other language out there, but mainly Java since I have to touch that only slightly less than I touch PHP scripts. Java is great because you can output directly to a console, so you can log stuff and watch as the mayhem unfolds while your program bombs. It’s REALLY helpful.

SO…

I decided I wanted a console I could output to at any time. Something I could review on the fly and see what is happening. This would allow me to review any logged output I wanted in real time, and I could avoid the alert box altogether. Hmm… what could I output to? The DOM!

Right??

I sat down and cranked out a handy dandy script that will write to whatever div you decide to use as a console. If you are lazy, like me, then it will also do something really spiffy and just append a console to the end of your document.

The nice thing is you can just define a console div and write to it. When you send your code to production, you can just style your console with display:none. If you forgot to pull a write statement out of your code somewhere, the world won’t come to an end, and your users will be none the wiser. (For the record, I still strongly encourage you to NOT leave test code in your production code. This is just a CYA measure.)

So, where is this code and what do you do to make it go?

Let’s start with the “making it go” part first. Include the script in your code, I’ll give you a link to the file in a moment. Then add this line of code to your document:

var ow = new OutputWriter();

Tadaaa!!

You now have a console on your page you can write to. If you want to write to the console for whatever reason, it goes a little like this:

ow.writeln(“your message.”);

If you made your own console, and you want to write to it, then instantiate the writer thusly:

var ow = new OutputWriter({ consoleId: “your_console_id” });

There are other things it can do as well, like clear the console:

ow.clear();

Store and retrieve cleared history:

var ow = new OutputWriter({ consoleId: “your_console_id”, storeHistory: 1 });
ow.clear();
var history0 = ow.gethistory(0);

You get the idea.

There are more parameters you can set too. I put them all in the comments at the top so you can decide what to use and what to skip. They are all 100% optional, so don’t worry about it if you don’t want to set them.

So, on with the script, already! Just download this one little file and you have everything you need to do all of the console-writing magic I described and, potentially, more. Debug your code with grace and style and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

Listed information can get tricky.

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

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

Sort

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

Transform

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

Eliminate

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

Paginate

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

Search

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

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

©2012 Chris Stead. All Rights Reserved.

The main requirement for a microwave is that one be able to set the time for which their food will receive a nuclear blast, converting last night’s roast beef into magma. Either there is a “time cook” button, or you simply enter the time directly. The uranium-235 does the rest.

In all seriousness, people expect time and power level entry to exist with a clear designation. If a microwave has no designation, people often assume it is reasonable to simply begin keying a time. This microwave is different.

My coworkers avoid the evil microwave because it doesn’t do things the way they expect. If you begin keying time, it sets off “auto cook” mode and cooks food for some pre-designated time in full-minute increments from 1-6. There is no “time cook” button, only a “power” button. It appears there is no way to enter the exact time something should cook for.

As it turns out, there IS a way to enter an exact time. If you press “power” you can freely key in your time. Yes, by opting to enter your power level, you are free to enter the amount of time to cook your food.

Clearly someone decided it would be efficient to trim the “time cook” button out of the process because it was an “unnecessary” action that make the overall process slower. What they forgot to take into account is what people actually look for: how to enter the time.

Translation to the rest of the world?

Fewer clicks is just that: fewer clicks. Just because you took away a couple of clicks in order to get the user to their destination doesn’t mean you did them a service. They may have relied on that waypoint on your site. Though it cost them an extra click, they knew each click was an important step upon the journey. You helped build their confidence in your site by marking the path clearly. If you eliminate a critical sign at a fork in the road, your users may get lost.

If you find your users getting derailed at a certain point on your site, look for the missing “time cook” button. Take care in guiding your users carefully through your site, adding an extra step if it makes the entire journey clearer. Users only mind extra steps if they don’t lead to clarity. Avoid building the efficient and impractical microwave and make the web a better place.

*I intentionally use the bad microwave. Since nobody knows how to use it, the traffic to that appliance is low. Food for thought.

©2012 Chris Stead. All Rights Reserved.

In the early days of the web, a website was mostly HTML and associated miscellany. There were some content management systems and dynamic utilities out there, but they were typically purpose-built and totally proprietary. One company I worked for had a system that, essentially, took in HTML snippets and stored them in a database as a web page that was 90% constructed, doing the last of the construction for presentation on the fly. It wasn’t graceful, but it served its purpose.

Today websites are web apps and vice versa. There are fewer and fewer business sites on the web that are old-fashioned HTML. The company I work for now, has a broad-reaching infrastructure for its web presence which involves various computers and disparate web services. This is all very important to the experience the end-user is going to have when they visit your site.

Information Architects today need to be cognizant of the systems they will be working with, the limitations of technology already implemented and the latitude they have regarding direction for the site and the user’s end interactions.

Let’s assume you have a list of items you already account for in your work: page layout, important items both for users and internal, site hierarchy, taxonomy, findability of information, etc.

Here are other items which should be considered:

Content Management

What kind of a system is being used? Is there an e-commerce solution in place? What e-commerce package is being used? Does it integrate with the existing content solution or is it a separate tool?

Integrated or Decoupled Site/Content System

Is the site being run on a simple WordPress/Movable Type/Drupal install where the site management is tightly coupled with the website itself? Is the website requesting content across the wire from a service on another site/computer/continent? How will this impact speed? How easy is it to integrate custom features and functions?

Data Transport

This is a biggie. If you have an old-school web project, this is unimportant. If you are sending data across a wire to a custom tool or application, this becomes VERY important. How do you want to connect to the data? Do you want to make a direct remote connection to the database or do you want to send the data as a single package across the wire? If the data is being sent as a package, what do you want to use? JSON? XML? Serialized string? Something sneaky I don’t know about?

These sound like much more engineery/techy/geeky considerations, but they are important in the end. Perhaps you are pulling information from your company’s database, a Twitter feed and pictures from Flickr. All of a sudden, you are working with mixed coupling. You will need to know this in case something fails. You are the one they are going to ask when they need an error screen.

Why data transport? Simple. You don’t need to know how to implement it, but if you work with the engineers and pick a standards-compliant data transport system, you will save them lots of headaches and yourself extra work in the end. By understanding the way data is being passed across the wire, you can start to understand how to better integrate RSS feeds into a design, present useful information to users and do it in a way that will be quick to implement and easy to maintain. Ultimately, if you want to invent a better wheel, you’ll want to be armed with a damn good reason.

Ultimately, there is a lot of information that needs to be shaped and directed. In order to best your user, yourself and your company, you need to consider things that are more than skin deep. By tackling the tough questions about your project early, you can write a more clear and useful specification. In the end, by peeling back the layers, you help to make the web a better place.

©2012 Chris Stead. All Rights Reserved.

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.

I have one last function to look at. This function will let us sort out how long a certain percent of our users will hang out at a site, trying to accomplish their goals given a random population interacting with a page or site they have never visited before. By having the ability to calculate the output of the user falloff function, we can compare user test results to our falloff curve without plotting the entire curve to show anticipated versus actual results.

We’ve already talked about the user tolerance constant (L) and our starting number of users (u_0). These are all the elements we need to figure out at what time (t) we will have a percentage (p) of our users left actively seeking on our site. The actual number of users remaining is trivial to calculate after you pick a percentage, i.e. p*u_0.

(Reminder: percentages should always be expressed as a decimal between 0 and 1.)

Without further ado, here’s the function of the day:

t = L*[ln(1/p)/ln(u_0)]^0.5

There are some interesting features of this function which are a direct result of the falloff/satisficing function we talked about last time. First, as we get closer to 100% (or p gets closer to 1) t gets closer to 0. This shows us that, at least at one end, this function must be meaningful since none of our users should have fallen off before the testing or site loading began.

At the other end, we can see that as we get closer to 1% (or p gets closer 0.01) then time is going to approach L, our user tolerance limit. This means our function is actually behaving the way it should and our results will prove to be reasonably meaningful, regarding our test population.

This function is probably as important, if not more so, for testing than our falloff function because you can actually see how you are performing in your test group against a theoretical control group. This means, if you take your testing group, collect data and analyze it against standard statistical curves, you should be able to get a reasonable estimate of how your users are measuring up against when visiting your site.

On the other hand, if you are underperforming, you now have a reasonable metric to deduce when things are going wrong. You can do things like plug in .68 for the percent and see if you are actually capturing the first standard deviation of your users within the allotted time.

In the end, this should all relate back to one question: are my users accomplishing what they want to do before they are getting too frustrated to continue with my website? If the answer is ‘yes,’ then pat yourself on the back and then make it even better. If, on the other hand, your answer is ‘no,’ it’s time to start evaluating how your site is impacting the users who visit it.

Are they suffering from unintended ad-blindness as the users tested for the US census website were? Are you suffering from a hover-and-cover anti-pattern which is causing your users to have to steer all over the page to get to what they need? Are you not using language that makes sense to your audience?

All of these questions and many more should come to mind to improve your performance against the baseline we’ve defined. Just remember, even when you are consistently beating my model you can still improve more. Surprise and delight your users. Beat the curve and then improve again. Think about your users, make your site a delight to use 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.

This person will remain unidentified as I don’t want gobs of people spamming his site, nor do I want to give his poor judgement any extra exposure. That said, the basis of the post was, it is preferable to make users authenticate with Twitter every time they logged into the system as opposed to storing the keys and remembering who the users of the site are.

The take-away message was, paraphrased, “it’s a simple back and forth between your site and Twitter each time they log in. It won’t bother the user and it is preferable to storing all of those authentication keys.”

Let me say it again: he was evangelizing inconveniencing the user and stating this was actually the preferable thing to do.

This idea is wrong-headed in so many ways. First, let’s look at Twitter and see how they would feel about it, shall we?

Suppose we stored the keys for the user. Twitter would have to generate a key just once for each user. Once that work was done, they would simply take requests as usual and the day would go on. Their API is built around using stored user authentication so this is no extra burden. Instead it is business as usual.

Now, suppose you make your user re-authorize every time they signed in to your web app. This means that each user would have to hit the Twitter authorization page once per login. Now Twitter has to burn the extra cycles to generate a new key for YOUR user. On top of that, there is storage of that key. Each time you request a key, you are taking up space on their server.

The more times you make your users request authentication, the more it costs Twitter. It might be no big deal to you, but that is money out of THEIR pocket. That is the very same pocket which is financing that lovely API you are using to update your user’s timeline. We haven’t even started talking about your users yet. This is just the mess for Twitter.

Let’s have a look at your user. If you store their authentication, they have to hit the Twitter authentication screen just once. Once they do that, they will probably forget all about it, carrying on with using your application, like they want to. That’s it.

Suppose you, on the other hand, make your user authenticate every time they log in. One of two things is going to happen. Either you make them authenticate through an account screen and they will assume, after the first time, that they are done. The other option is, as soon as your user logs in, they will be faced with a Twitter authentication screen.

Suppose you make them authenticate through an account screen. Your user will reasonably assume this was a one-time thing. Later they will discover that Twitter isn’t being updated by your app anymore. They will check their account and see they have to re-authenticate.

Rinse, repeat.

Eventually, your user will figure out that you expect them to re-authenticate EVERY time they log in. If your application relies heavily on Twitter updates, you will lose that user. If that user liked your application because it updated twitter, you will lose that user. In the end, you are likely to lose users over the choice.

Suppose you force your user to re-authenticate each time they logged in. Your users are going to view logging in to your service as a chore. Eventually they will tire of the whole process and leave. This is the most direct route to losing users.

Regardless of the path you take, you are bound to lose users if you make them re-authenticate through a service each time they log into your service. Also, the more services your app interacts with, the more services your user will have to re-authenticate each time they log into your app. This compounding effect will only drive users away faster.

In the end, what this person was really evangelizing is simply laziness. It is unreasonable to expect your user to go through a litany of special operations each time they log in before they can fully use your service. In this day of “less is more” user interaction, asking the user to perform unnecessary actions is a sure-fire way to drive users from your site and fast. Think about your user. Do a little work for them and make the web a better place.

©2012 Chris Stead. All Rights Reserved.