is a predictive model of human movement primarily used in human–computer interaction and ergonomics. — Wikipedia
Basically it’s a law which can accurately predict the amount of time taken to move to and select a target. Put simply, Fitts’s Law states “…the time to acquire a target is a function of the distance to and size of the target”. As the distance increases, movement takes longer and as the size decreases selection again takes longer.
Now it’s nice and all to give a thorough clarification of how the law works and give the different mathematical formulas but I believe it would be far more useful to explain it’s application into the graphical user interface.
The size of a target and its distance from the user’s current position within the user interface affect user experience in a number of ways. To give a blunt example:
I think the majority if not all would consider Button B to be easier to click than Button A. For some the answer to why it is so is obvious: Button A is further away from the cursor and smaller than button B. And this is exactly what Fitts’s law is about.
Of course there are other examples which might be so obvious.
Take screen edges for instance. If we put an interface element there, it will have infinite size since if you were to try to hit it with a mouse, your mouse would never leave the screen and would always remain on the button.
Thus, it makes sense to put the important elements at the very edge of the
screen. This way the users can quickly slam their mouse cursor onto the edge without worrying that it will miss its target.
For touch screens unfortunately, this does not apply. There you must take under consideration where the users hands will be placed on the device they are using.
When we’re talking about consistency of an application we most often refer to its appearance. Elements feel out of place, buttons don’t have the same design, window differ from each other, scroll bars seem weird and etc.
Inconsistencies in design are easy to spot. However, this focus on how things look is misguided.
Often, when it comes to usability, appearance doesn’t matter all that much. The point isn’t to make all the elements look exactly the same. They just need to be immediately recognizable for what they are.
For example, it is generally accepted that a button with red colors expresses denial of a certain action. This means that if you decide to make the accept button red, the majority will mistake it for a cancel button.
This is due to the fact that people have already grown accustomed to the way certain elements look in applications and they tend to apply that knowledge into other apps, making it hard for designers to implement something different than usual.
The more a user interface element looks like something users already know, the more they will expect it to work like the thing they already know.
~The gearbox symbol is widely used as a button for settings. So changing its functionality to something entirely unrelated guarantees a decent amount of complaints from angry users.
If you really must create a version of a commonly used interface element
that behaves differently, make sure that it looks different enough so that people won’t form false expectations. The last thing you would want is to frustrate your users by creating an element that doesn’t fit the behavioral model of a common, similar-looking element.
Usually when we design an app, we try to do it in such a way that even the least brightest of people can use it without being infuriated. For this reason we try to make our user experience as friendly as possible. If a certain action might yield unpleasant results the application should at least warn the user and ask for confirmation.
A well known example would be when we try to close a certain text file after we have made some changes to it but have not saved it. Nowadays of course most applications have been created in such a way that as soon as a change is made the file is saved automatically. Before, however, the application would show a message notifying us that we have not saved the file and asking us to confirm whether we want to proceed with exiting. And on many occasions this exact notification can be the reason why you didn’t have to spend the next couple of hours redoing your work.
But let’s be honest here, how many times has it happened that you just clicked on a notification button on random without reading it.
Warnings are great for shifting the blame to the users — after all, they
should have read the warning, right? They are not the best way, however, for
Fortunately, there is a better solution.
The undo button. The one button that can prevent headaches.
Instead of forcing people to deal with constant warnings, undo offers a
simple, transparent solution.
The possibility of reverting an action is a great feature indeed but often we do several unwanted actions at once and want to go back to the beginning state. For this reason it’s best if the undo is multilevel, allowing the users to undo more than just the most recent action.
There are some situations, however, where implementing undo is impossible due to technical reasons.
You can’t let the user undo sending an email — once it’s sent, it’s out of your control.
Similarly, while you can delete a tweet once it’s sent and unpublish a blog post once it’s published, but that’s not quite the same as preventing the action altogether.
One solution to this is to delay the action and allow the user to undo
it temporarily. Instead of sending the mail right away, show an undo
button for a few seconds. If the user undoes the action, don’t send the
mail. Otherwise, remove the undo button and send the mail.
So keep in mind that if it is not technically possible for you to offer undo, at least delay the potentially dangerous action so that people can prevent it from
happening even after issuing the command.