0

I've recently been noticing a pattern, in editors where you can create collections of objects (for example, in the editor for a multiple choice question when creating the possible answers), where adding a new item is done through clicking on a "ghost" editor for that object, which turns into a fully-usabe, real editor upon the creation of the object.

For example, in Google Forms, adding a choice to a question looks like this:

enter image description here

Comparing it to a more traditional "Add" button, like in this case: enter image description here

Are there any advantages in using this pattern vs the more traditional "Add" button? Does it lead to better predictability/understanding or to a lower interaction cost?

Does it depend on the complexity of the controls that are generating upon creating the object? For example, in Google Forms it's just a one-line input with two buttons on the right, so it's pretty "lightweight" to the eye; in the second example, there's a taller editor, so maybe it wouldn't be suitable in that case?

2
  • 1
    One quick thing I see is that the Google Form allows the user to create a new option by typing Enter. That could be a problem in the rich text editor example, where users might need a hard line break. Also problematic when there are two inputs, side-by-side. Commented Jul 20, 2022 at 22:27
  • Agreed. But what about just the click interaction (i.e. The addition of a new item happens when you click on the "ghost")? Would that lead to an advantage over the add button? Does it just look nicer? Commented Jul 21, 2022 at 12:17

1 Answer 1

1

It's good UX to anticipate the user's next desired behavior.

When you click (or press Enter) to fill in a new answer to a multiple choice question, there's a 50/50 chance your next behavior will be to set another answer. Teeing that up for simple interactions saves the user time and clicks, especially if they're setting up a form with 50 questions and 5 options for each question. (If the user doesn't need the system-added option, they merely move on - no data loss, so no confirmation needed - and the extra option goes away.)

When might you need an Add button?

  • In heavier component groups that might cause a visual distraction and interfere with the user's ability to stay focused (I would guess that's the case in your example).
  • When there's not a 50/50 chance that the next action will be to add another item, but the user might want to add another item and needs the chocie.
5
  • Given that, for my app (second gif), the "50/50 change" condition does apply, do you feel it might be worth it to kind of simplify the input group in order to better accommodate such a style? For example, make the rich text editor a little less tall by default, and only show the editor buttons when focused, maybe also hide the drag handle unless hovering like Forms does. Also, does this pattern have a name that I can research to find out more? I wasn't able to find anything on it other than the Forms example in practice. Commented Jul 21, 2022 at 14:22
  • Another option is that you could show the next row automatically and visually subordinate the components (show them in a disabled state) until the user clicks into them. Not sure of the name of this pattern, sorry! Commented Jul 21, 2022 at 14:50
  • Not 100% sure I understand what you mean. Would it look something like this? drive.google.com/file/d/1DqAyRUEwyqcZB1e5QihQh1mW4DVDhG-Q/… Commented Jul 21, 2022 at 14:58
  • That's the idea. Commented Jul 21, 2022 at 16:03
  • Gotcha. I'm just wondering, how is that different from the Forms example? I kind of identified the two patterns as the same one. Maybe the difference is that Forms clearly labels the ghost input as an action ("Add choice") whereas in the example I just posted the ghost looks exactly like the normal input, minus the opacity/disabled state? Commented Jul 21, 2022 at 16:23

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.