3

What is the best way to indicate edit-in-place functionality on a list view in a responsive web application? This is an in-browser application designed for mobile (not a native mobile app), so cross-platform compatibility should be kept in mind.

The page current looks like this (header and navigation not shown):

enter image description here

Apart from viewing the list of employees, the primary actions to be taken from this screen are calling and texting. The Edit action isn't a primary action so given the amount of screen real-estate, I think that showing the pencils is too cluttered.

Unfortunately there's no hover option for mobile. Here are some examples in the wild:

  • On Android, editing a contact requires you to navigate to the contact view first then tapping the edit button on the action bar. This makes sense as there are many contact details.
  • For the Alarm Clock application on Android, long-pressing on the alarm will bring up a modal menu with Edit Alarm and Delete Alarm. The Edit alarm button takes you to a new screen, again logical because there's numerous fields. There's also a mass-delete option that brings up checkboxes beside all of the alarms you wish to delete.
  • On iOS, I believe editing is done by tapping on the item which brings you to a new screen, while deleting is done either by left-swiping and tapping the minus icon, or on the edit screen by tapping the red Delete button (I don't have an iOS device handy at the moment to check)

Since there are such few fields (first name, last name, title, phone, and a checkbox indicating whether the phone has texting), transitioning to a new view or opening a modal seems overkill. The edit functionality expands the item (row) to a form with Update, Delete, and Cancel buttons. I've thought about several options:

  1. Tap on the list item to expand the item as described above. I'm not sure about the affordance of this option.
  2. Keep the edit buttons
  3. Use a vertical ellipses to the right of the Call button that opens a flyout menu with two options: Edit and Delete.

So what do you guys think?

  • What about an > that brings the Edit and Delete options like iOS does? – Carbon Jul 3 '14 at 12:32
4

I'd go for:

Option 3: Use a vertical ellipses to the right of the Call button that opens a flyout menu with two options: Edit and Delete.

Mainly because this option is the one least likely to result in accidental deletes or unintentional entry to edit mode, but also because these are less common secondary actions but which still need to be discoverable.

But I'd also leave a clear space between the call button and the vertical ellipsis so that it's distant from the most common primary actions - again to avoid mis-tapping.

  • 2
    This option is also good because it'll last longer. You can add more options to the overflow menu if they are needed in the future. I'm seeing this 6 months later on the homepage for some reason, but my initial reaction is that in-place-editing seems weird to me; I'd expect an edit modal that shows me more information about the person than the data that happens to show in the table. – Kip Dec 16 '14 at 23:20
1

I think there are three big rules that must be taken in to account when identifying the best view/edit paradigm:

  1. I want the information to be easy to read (Summary/Print view without edit clutter)
  2. I want to prevent unwanted mistakes on important data
  3. I want to quickly and easily edit the information

The UX solution for View/Edit may be different depending on which of the three above is the highest priority, as there is always a balance between easy editing and preventing screw ups. Some say it is better to make it difficult for users to edit data to prevent them from making mistakes. However, if a user has been given the permissions to edit the data in the first place, you must presume that said user has the intelligence and expertise to be entrusted with making changes to that data: Making something difficult to do is never a proper UX solution.

I personally like the technique used where the information is presented in a "View" state until a user hovers over an input. Then, an input bounding box is revealed, which shows the user that the information is editable. ON click, the cursor is placed inside the input, allowing the user to modify or enter data. Lastly, when the user exits focus and leaves the page, a confirmation message is presented showing the user the change that was made, allowing them to confirm or delete the change(s).

This solves all three big rules, while sacrificing none of them: The data is easy to view/read. The data is easy to edit (onfocus/onclick) and unwarranted changes are prevented (confirmation message).

Edit per feedback below... yes this is a web-only solution and doesn't work for mobile.

  • Interesting points, but the technique isn't exactly applicable to mobile as users can't hover over things on a mobile device. – rink.attendant.6 Dec 15 '14 at 17:35
0

How about a simple "Employees - tap to edit" header and table items that instantly go into edit mode when clicked ?

The reasoning is the following :

  1. this is explicit
  2. it keeps short and will not result in overcrowding the interface and
  3. UI trends are such that most displayed elements now offer some sort of interactivity so it is likely that users will try or at least be comfortable clicking on the table items and discover that they instantly go into edit mode, i.e. consistently with the suggested header.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.