So, we all know about FireBug, right? That handy dandy little debugging utility for Javascript. It’s great and all as long as you actually have a syntax error in your script. The console says a lot about the issues it found, unrecoverable errors and all that. What if your script doesn’t actually bomb, it just doesn’t do what it’s supposed to? Continue reading »
Information comes in all shapes and sizes. Some is simple. It’s copy that goes on a page. It’s an image. It’s a sound file. It’s a single PDF. It’s whatever atomic piece of information you can imagine. Then there is the molecular level, for instance, whole web pages with mixed content. Then there is listed information: movie titles, collections of documents, retail products, animals with feathers, types of beer, whatever.
Listed information can get tricky.
Continue reading »
As is typical with the break room at many offices, we have a microwave. Actually, we have two, but there is one in particular that everyone knows about and avoids. Everyone but me*, that is. It is a machine crafted in the forges of bad usability and total misunderstanding of user journey.
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. Continue reading »
Most of what I have seen on the web regarding Information Architecture has been related, primarily, to what the user sees and interacts with directly. This means, what users see, and how the site is, ultimately, hierarchically constructed. Very little consideration is given for what is ACTUALLY going on with the site. Continue reading »
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.
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. Continue reading »
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?
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. Continue reading »
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.
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. Continue reading »
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.
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. Continue reading »
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.
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. Continue reading »
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.
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.” Continue reading »
Comments Off