1

I have to anonymize this substantially, so forgive the abstraction, but here is the debate.

There is an interface in which you can create an object. This object has several attributes, as well as sub-objects. The sub-objects are what I'm dealing with.

You can add as many sub-objects to an object as you want. You can have zero or 1000, but the realistic range is 1-5.

The sub-objects have a couple of their own attributes. Some of these might be changed once set, but the sub-object title will basically never be changed. Nevertheless, the option to change it must be there.

Deleting a sub-object will be rare except when you accidentally create a new one. A sub-object with entered data will almost never be deleted, and it is decidedly an edge case.

On the page for the main object, you can view its attributes and sub-objects. The sub-objects can be expanded or collapsed.

In order to edit the sub-object title, you must have the sub-object expanded, in which case you'll see an edit icon next to the title. Clicking that icon will turn it into an editable field. Unfocusing from the field makes it revert to fixed text.

When the field is editable, a trash icon appears for the sub-object. When you click the icon, there will be a prompt to confirm you want to delete the sub-object.

In short, this means that, in order to even see the trash icon, you must click once or twice (depending on if the object is expanded). In order to delete, you must make two or three clicks.

That's a lot of clicks, but this is an edge case and I do not want to clutter up the UI with a button that will almost never be used.

Is this the correct solution? If not, what is?

enter image description here

1 Answer 1

3

The user that needs to delete a sub-object, however rare a case, has an intention to delete, not edit. They will probably eventually find the Delete button by entering into the Edit state (because that's all they can do), but it's extra cognitive load for them to have to remember that Delete can only be accessed via Edit.

You're sensing a tension between two usablity heuristics - Aesthetic and Minimalist Design (which you're opting for, here), and Recognition Over Recall (making the user remember where the Delete button is, vs. just showing it to them).

But using the right number of clicks is also part of good minimalist design. So, I think you should honor your user's intention to delete, and move the Trash icon to the screen where you show the Edit icon. Two icons isn't too many, and it'll save the user a step.

8
  • That's a fair point but technically it's not two buttons, it would be three because the minimize caret would be there.
    – JClaussFTW
    Nov 10 at 20:35
  • I am considering putting both edit and delete into a meatballs button, but the only appropriate place for that is on the far right side which means I'd need to rethink the location of expand/collapse.
    – JClaussFTW
    Nov 10 at 20:36
  • You might do a meatball action menu on the left, and expander icon on the right. Could the menu show while the item is collapsed? I know it's a change from the current state.
    – Izquierdo
    Nov 10 at 21:15
  • I'd like to avoid the menu while the item is collapsed. Is there any precedent for meatball menus going on the left? I'm sure there are but I'm blanking.
    – JClaussFTW
    Nov 10 at 21:21
  • I'm thinking of the kebab menu, which is vertical and can be placed on the left. What's the reason why you'd want friction in allowing the user to edit or delete? Do they need to review all information before taking action?
    – Izquierdo
    Nov 10 at 22:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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