Posted: April 26th, 2009 | Author: Adrian | Filed under: Good practices, VS | Tags: actions, buttons, links, submit | 3 Comments »
When dealing with webpages, some usability experts say we should use links when the user is gonna get on a different page and buttons when the user makes an action.
I don’t really care. I don’t care because users don’t care.
Let’s get things a little further, what’s a button? Does it have to have borders? Different color?
Is a icon followed by a link really a link or a button? I see those things like buttons, others see it like “fancy links” or “descriptive links” or “visual links”.
One thing i agree with, though: forms should have “hard to miss” primary action button, you cannot put a link there mainly because it will not be a “primary action”, there are other links on a page so the weight of a “submit link” won’t be so different.
Posted: April 17th, 2009 | Author: Adrian | Filed under: Good practices | Tags: quotes | No Comments »
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Antoine de Saint Exupéry
Posted: April 13th, 2009 | Author: Adrian | Filed under: Good practices, Patterns | Tags: ajax, edit, inline | No Comments »
Since the AJAX and web 2.0 madness a new edit option appeared on the web (used for many years in desktop software though): “edit in place” or “inline editing”. It’s basically used to edit a thing and one thing only, a “one field form” if you like.
It’s not for computer naive users and it’s better to avoid it for simple applications if it’s not really obvious how to use it.
There are two distinct parts of this action: triggering the apparition of the field and the submitting of the action.
Triggering the field can be done in a few ways:
- holding the mouse cursor on the text to be edited (the same as the desktop way) – simple but not obvious, you can’t know about this feature without reading the help or a proper training. (For example see the IPB (invision power board)). I don’t recommend this method for the web, it’s not intuitive enough.
- clicking the text – hovering the text, the background of the text becomes yellow – a convention that nowadays seems to mean “click me, something will happen”. Used by Yahoo, Google, WordPress etc it’s a convention that is becoming a standard. Though it’s better than the previous one, it can be done better.
- right click on element shows a menu with edit/rename option. Again, the user is not used to right click on things on the web, maybe on pictures to download them but that’s about it. Cool but not usable enough. See the Google Docs example:
- just showing an edit button is the best solution i ever saw, straight forward. If the aesthetics don’t allow that, show the edit button/link only when hovering, but keep the yellow background on the text all the time. WordPress admin does a good job with the post slug editing:
The field must appear in the same place the text is before triggering the edit. Jenifer Tidwell says in her book “Designing Interfaces” that the field must be set only as a border on the text to be edited, the position/font/color of the text should not be changed. Although it’s a very good point, it’s hardly possible to achieve this technically when working with dynamic text and user generated content.
Some people choose to select all the text inside (like in windows explorer) to make the text replacing faster, but it’s very easy to delete the text and many users won’t know how to recover from this (it’s important that on click outside the field the action is canceled and the initial text restored).
Submitting the form is easy, either you insert a “save” button, or let the user hit “enter” (IPB for example). I prefer and recommend the first one, but make sure it works with “enter” too. A very good idea is to provide a “Cancel” button, it gives the user self confidence.
UPDATE: a few examples on quince.