Grow your CSS skills. Land your dream job.

UI Pattern Ideas: List with Functions

Published by Chris Coyier

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.

Hover Functionality

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.

Edit Mode

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.

Drag Functionality

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.

Single-Click 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.

Double-Click Functionality

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.

Omnipresent Functionality

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!


  1. Congratulations, Jay! Really deserved. You made it simple and functional.
    I wish I had more time to play with this, and I hope Chris will continue with UI Pattern Ideas. This is a really nice thing.

  2. sliver37
    Permalink to comment#

    It’s awesome to see how differently each person approaches things, congratulations to Jay and everyone who got a mention in this article.

  3. Jonathan
    Permalink to comment#

    Argh, too bad I started so late :)
    Congrats to Jay.

    Apple UI – The way of the ninja…

    And thanks Chris for mentioning my entry :)

    Greetings from Germany,

  4. Permalink to comment#

    Congrats, Jay.

    Interesting to see how each and every one has different approach to the same problem

  5. Congratulations Jay on the best list with functions UI. LT

  6. Jim
    Permalink to comment#

    This Group Project is a great idea. I hope you throw some more out from time to time, Chris.

    Well done Jay, intuitive and looks good.

  7. Patrick Bruckner
    Permalink to comment#

    Congrats Jay. Also think he brougth the best solutions…

  8. Pawan
    Permalink to comment#

    This is good… please carry more of such ui pattern projects.

  9. Bram Cordie
    Permalink to comment#

    “…Edit Mode, which is what I consider the most successful pattern.”

    I don’t really think Edit mode should be declared the big winner. There are two obvious reasons why this pattern fails.

    1.When you have a big list the user will have to scroll through the list when looking for the item he needs. Now when he has found the desired item he suddenly decides he want to edit/delete it. What he has to do now is scroll all the way up to the unlock button, unlock, search for the item he wanted AGAIN delete it and lock.
    Ok no biggy, just make the unlock button fixed and prevent it from scrolling with the list. But now you have this Edit button bloating your screen

    2.You are still repeating all the icons.
    The challenge explicitly says “…repeating icons are bad…”. The only thing you did is hide it with yet another button you have to scroll/repeat.

    Sorry for all the hating but this doesn’t make sense to me.

    I don’t have my blog set up yet so is there a place where we can further discuss the different patterns or a specific pattern. I still have some technical problems getting my pattern working like it should and could use some advice.

    To avoid any confusion about how my dial pattern works please view it in Firefox and please change the description. Now it says “Clicking certain positions opens a “dial”” this is only true when confirming a delete. When selecting an option you just drag in the right direction. The dragging instead of clicking really makes it feel more natural and doesn’t require excessive clicking like the awesome edit mode. If you use browser other than firefox, it can really mess up the dial experience.

    • DED
      Permalink to comment#

      Bram, those are very good observations. I especially was concerned with the first one : this pattern requires too much scrolling or knowing beforehand what you want to do. I think though for your second point, he does hide the icons when they are not needed so comes close to the spects.

      To add to your analysis, I would like to point out to people that even without issues these are technically not design patterns: they are candidate design patterns. I realize many will say that these are designs and they are patterns. But, in the field the phrase “design pattern” has a tight definition. To qualify for a design pattern a solution must be used over time and prove to be useful. The solution cannot just appear to be useful, or seem correct. The point behind design patterns is that there are always many viable solutions, but some of them have negative effects. See Christopher Alexander’s books for more on the history behind the idea.

    • #1 can be solved with a overlaid fixed element (holding the edit function) that scrolls down with the user, either “hovering” over the list as the user scrolls down, or as a long bar along the list to activate editing on a mobile interface.

      #2 Repeating icons are bad if the user is initially presented to such a list without any forethought. If they click edit then they are expecting something to happen and there needs to be an obvious reaction (i.e. icons/text which clearly relate to editing something). I don’t see any other option that would explain the changed functionality of the list as quickly.

      Jays wins not necessarily because it was totally original (like your dial) or fulfilled every requirement but that it was most successful in the number one rule of UI design “Don’t make me think.”

      By the way, if you plan to use that dial in a future design, I wouldn’t put “Yes” on the same side the user clicks the “Delete” icon, I can imagine some people accidentally deleting names like that.

    • Bram Cordie
      Permalink to comment#

      1. I don’t want a big edit button floating around on my screen all the time. Especially on a mobile device where my screen real estate is already limited.

      2. If the user wants to interact with something he will click it. This is when you present him all the things he can do with the thing he clicked. Repeating all the icons even in edit mode is completely useless. In this case we have a list of items which all share the same functionality. Once I know what I can do with one of the items, I’ll assume the other items have the same functionality.
      If you want to take this even further you could add separate functionality for every item. And change the options on the fly when the users request interaction with it.

      About the delete confirmation: I considered switching the yes and no but I don’t want to slow down the user when he has to delete a bunch of items consecutively. You’d be racing your mouse from left to right all the time. The chance that you accidentally click, hold, drag left release and click again is very small. People that are used to double clicking won’t have a problem with this because I check if the gesture deviates enough from the original click before the actual dialing starts.

    • DED
      Permalink to comment#

      Actual all mode enhanced interfaces carry a cognitive cost with them, so it does ‘make you think’ because you have to remember what mode you are in. Jay’s design helps by having the icons only in editing mode. But, don’t be fooled that this design is finished as far as user experience is concerned.

  10. Permalink to comment#

    Congrats Jay. Well deserved. Some nice stuff you made. :)

  11. Marcelo
    Permalink to comment#

    Congrats Jay!!!

  12. Permalink to comment#

    Congratulations Jay. I love that you did this contest as it lets UX Designers and other see various ideation on how to solve for a problem. It also reenforces innovation.

    Great job guys!

  13. Permalink to comment#

    Cool idea for a “competition” and it’s an interesting read and congrats to Jay Salvat for excellent solutions. I just want to put in my 50 cents:

    Touch device applications use touch and hold to edit all the time, so that’s becoming a common and very useful way to edit things *on touch screens*. It’s especially helpful because you don’t have to give up any screen real estate.

    Furthermore, clicking to edit is also annoying on touch screens since when you’re trying to scroll by dragging, for instance, the little menu popping out would be annoying (even though it disappears once the device realizes you weren’t clicking)

    However, just like right clicking has been around on computers (desktops) for a long time without ever becoming helpful on the web, in the same way a click+hold action will never be succinct on desktops.

    Another thing.

    I would say the behavior/UI you create should depend entirely on what kind of a “thing” you’re editing in the first place and what it’s purpose/weight is in the application.

    In most cases you should be able to edit the item both from the list and from the page you access when you’ve clicked it. You should also be able to delete many items at a time, because when you have to delete 7 items and have to press and hold or click an icon and then probably confirm the action 7 times, it’s quite possible to go mad. (It also causes more stress on your servers).

    I think the edit mode is a great suggestion, but it does take up more space and it might also be weird in an environment where the list becomes very long and you have to find the edit mode button first. Also, should it be on the top or at the bottom?

    There’s also one aspect that some of the examples didn’t cover which is that as applications progress and you add more functionality, you will probably need more actions than edit and delete, so where will you put those?

    This is becoming a bit long for a comment, so I’ll write a blog post on this and even give my suggestion (heck, it’s an interesting exercise) and let you know.

    Anyways, great post. You’ve got a new RSS subscriber and I’ll be looking out for more of these :-)

    • Bram Cordie
      Permalink to comment#

      “There’s also one aspect that some of the examples didn’t cover which is that as applications progress and you add more functionality, you will probably need more actions than edit and delete, so where will you put those?”

      I’m planning on making my dialer more flexible by having the option to add actions. Each with their own icon and dial-tab.
      For example when you add a 4th action the 270 degrees the dial covers would be divided by 4 instead of 3 to determine the dial-tab size.
      This would involve some maths with radials to figure out mouse position when selecting an action which I still have to figure out.

    • Permalink to comment#

      about click-and-hold: Google Chrome does that with its history button. (Click to go back, hold to view history.)

      It’s the only thing I *hate* about Chrome.

    • Bram Cordie
      Permalink to comment#

      In Chrome the click-and-hold on the history button doesn’t work that well because you have to hold and scroll the list with your mouse.
      Not every user has the same mouse sensitivity so it’s hard to fine tune this click-and-hold behaviour. For example a user with his mouse sensitivity set very low won’t be able to scroll all the way down because he reaches the end of his desk by the time he gets to the 5th element.

      Click-and-hold can work on a desktop environment when used in the right way.
      You can do this by allowing the user to be sloppy with his gestures when handling the click-and-hold. this is why the chrome history example fails, the user has to be very precise when holding down his mouse and selecting the desired item in the list.
      I managed to circumvent this for my dial by using the direction the user is moving when holding down instead of where he is hovering his mouse exactly. This allows the user to just flick his mouse in the right direction, west, north, or east to select an action.

  14. Nice work! Thanks for the fun project Chris :)

  15. Great post ;) Thank you very much..

  16. Permalink to comment#

    Yay! Congrats Jay. I was just glad to participate. I learn so much from everyone. :D

    I’m so using what I learned for future projects.

    This was awesome Chris. Please have more. ( Even without prizes! :D )

  17. Permalink to comment#

    What event fires when you Press & Hold on a touch device?

    Can touch devices detect a double-tap?

    Can :active be used in place of hover on a touch device? What if you press+hold a link for 2 seconds instead of clicking it selects the element and makes it :active? Could you then have your suckerfish menus tweaked to work with :active instead of hover.

    These ideas again make me want some sort of :click pseudo element which in turn makes me want a full-blown yet limited subset of proper javascript specialized for manipulating the .style objects.

  18. Permalink to comment#

    Hi, unfortunately I did’nt know about this contest. I want to mention that I created an datatable based on your editable invoce example. Initially all textboxes have a style that make them look like labels and when you click somo of those inputs they change the style to look like textboxes (Just like you did). Thanks

  19. Permalink to comment#

    And on a related note, False simplicity from Usabilitypost talks about how icons are not always the answer (and takes TweetDeck as an example).

    Oh, and congrats to the winner!

    (P.S. Chris, this problem reminds me a bit of your front page… You use jQuery to “cancel out” a few repeating elements)

  20. Bram Cordie
    Permalink to comment#

    Dialer v0.3 erratic behaviour in Chrome is now fixed. Safari still doesn’t prevent the text selecting like it should.

  21. Oh I like the post, very easy to flick down and skim. I have always liked the ideas of patterns as they are based on user actions rather than design ideas. Sometimes it is nice to be obvious when constructing a UI. At Web Courses Bangkok we always try and teach that simplicity is key but sometimes it takes guts to make it that simple…and a load of Jquery :)

  22. Permalink to comment#

    Congrats Jay :)

  23. Permalink to comment#

    Congratulations to Jay!

  24. Permalink to comment#

    Congratulations Jay, nice work :) Works pretty sweet :)

  25. “Double click” doesnt quite work on mobile devices, does it? I got mad tapping away on my iPhone.

  26. I’m late to the party now, but here’s interesting avoidance of repeating elements:

    If you hover over any of the items in the navigation, you see the connection to “type” right away because it changes color to red. While this type of “smart design” probably can’t apply just anywhere it certainly will be interesting to some.

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".