Last week I asked people to participate in a group design project on a specific design pattern: a list with functions. The premise was:
The design pattern we are going to tackle is a list with functions. Think of a list of five names. The primary function of this list is to click the names. The secondary function of the list is that the list needs to be manageable. There needs to be some kind of functionality to edit and delete each list item.
The response was amazing. Tons of you submitted ideas. I only have the one prize, so I will be picking a winner at the end, but I also want to cover all the interesting ideas.
Not every single submitted idea is shown below. There were a number of solutions which I felt failed the original intent. If clicking the name is what was required to get to a point where you could edit/delete, that’s an unsuccessful attempt. Edit/delete are secondary functions, not to overtake the primary function.
I quoted a Zeldman tweet in the opening article that said that functionality that only reveals itself on hover fails. He was referring to mobile devices, which don’t have mouse cursors but instead rely on touch. Those mobile devices don’t have hover states, so if the functionality is hover-only, users will not be able to access that functionality. It’s hard to guarantee an interface is desktop-only with devices like the iPad being nearly fully web capable. That’s not so say “never use hover”, but it is to say that there should be some kind of fallback that doesn’t require hover for mobile.
Example by Sean. The fact that one function has a label and the other doesn’t is a bit strange, as well as the placement.
Example by cancel bubble. This also has rudimentary mobile browser detection which changes the functionality to be omnipresent.
Example by kil. While I don’t think the styling is successful, it brings up the point of intentionally separating by proximity the functionality of edit and delete.
Example by Austin Knight.
Example by Pete.
I’m thinking having a toggle for turning the list into “Edit Mode” is the most successful base for this design pattern. No repeated icons, no reliance on hover, no instructions required.
Example by Jay Salvat. At it’s most basic.
Similar example from Red.
Example by Jonathan. iPhone style.
Example by Baylor Rae
Example by RSBomber.
Kirk Strobeck created a PDF describing an interface which is essentially a list with three different modes.
Mass Edit Mode
Mass Edit Mode differs from Edit Mode in that when the Edit Mode is enabled, all list items immediately become editable. This may be useful in specialized situations, but I would think in most situations this would feel uncomfortable for a user (putting items they are satisfied with into an editing mode when they are trying to edit something else feels unsettling).
Example by Justin.
Example by Red.
Example by Josh Brown.
Example by Raymond Torres.
Dragging is doable on either the web or mobile, although the technology to get it done is quite different.
Example by Bart. Drag left to edit, right to delete.
Example by Greg.
Miles Harrison created a Flickr set which shows how you might turn drag functionality on its head by dragging functionality onto the list items rather than dragging the list items to functionality.
Example by Alexandre Kilian. Variation on the starter idea that I provided, just uses a click to reveal the functionalities rather than hover.
Example by r3dsc0rpi0n. Click right on the list item for the primary function, click outside of it, but within its box, to edit.
Example by Damien. Kind of a combination between click and omnipresent. Slidedown from the top when edit is clicked revealing area to make edit.
Example by Hayden K.
I think that the inherit problem with exposing functionality on double-click is that it’s rarely used on the web and so requires instructions on how to use it. Something this simple should require instructions or any learning curve (however short) for a user.
Example by Jason. Edit in a modal popup.
Example by Justin Lee. Justin brings up the point of saving/aborting. The intuitive keys are Return and Escape, but the absence of any proof those work is a bit unsettling.
Example by Jay Salvat
Example by Jay Salvat. Double click slides in a pane for editing.
Example by Jay Salvat.
If done perfectly, omnipresent functionality should be able to work here. I specifically mentioned how a slew of repeated icons can be visually overwhelming and should generally be avoided. So “perfectly” means good placement and keeping the clutter down.
Example by Boba. Icons are placed out of the way and faded until hovered. I removed the default image borders for the screenshot.
Example by Dave Blencowe. I think this is an example of omnipresent functionality getting visually overwhelming.
Example by Marcelo. This isn’t exactly what I think of as “omnipresent”, but putting this here for lack of better classification. The checkbox is interesting, but too invasive to the primary functionality.
Example by Kevin Sweeney.
Example by Cory. Cory’s simple idea was to make omnipresent for mobile, and use hover for desktop with essentially the same design.
Example by Graham Ramsey.
Example by Bram Cordie. Clicking certain positions opens a “dial” from which you can choose other functionality. The dial is pretty cool and I could see it being nice in touchscreen environments, so long as it’s use was natural and required no instruction.
Example by Stephen Gerstacker. Click-and-hold to get the functionality to show up. It works, but it’s definitely not discoverable and would require instruction.
I’m going to give the crown to Jay Salvat. Jay created a variety of polished examples including the first submitted example of Edit Mode, which is what I consider the most successful pattern. Congrats Jay!