In #2642810: UX improvements for nested paragraphs we have explored how to increase the usability of nested paras.

One significant difficulty is understanding what the Add buttons relate to. In that issue we added a labelling to give the name of the paras field the Add button would add to. However, we did not implement a visual clue to the relationship.

I suggest that the Add button area gets some white space beneath it, so that the Add buttons more clearly relate to what is above them, (which they are would be close to) than what is below them (which they would be separated from by some white space).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jonathanjfshaw created an issue. See original summary.

johnchque’s picture

IMHO I think that the space height is Ok, we all know that the buttons are by default below the forms, also, the indentation makes clear that the button is used for the widget above it. In terms of UI design I think we should keep it like that since it looks well organized and the space below the button can take away the the beauty of the design.

jonathanshaw’s picture

"we all know that the buttons are by default below the forms".

On Drupal, Add buttons often go above what they add to. Submit buttons go below forms, but add buttons in a context like this? Not at all clear what the user would expect.

You are right about the indentation helping, and the horizontal lines. I just thinking they're maybe not enough.

I actually find it prettier with more whitespace, not uglier. See what you think:

miro_dietiker’s picture

On Drupal, Add buttons often go above what they add to.

Please point me at such an example.

Not sure how much space adds real beauty. Note that also the add button below still relates to ALL paragraphs above. Too much spacing makes things fall apart.

jonathanshaw’s picture

On Drupal, Add buttons often go above what they add to.
Please point me at such an example.

admin/content
admin/people
admin/structure/menu

It's obviously not a perfect analogy, but goes to show that user's expectations on this are uncertain.

I don't mean to argue for it on aesthetic grounds saying it is prettier; rather I'm suggesting it on grounds of clarity, and questioning the objection that it is uglier.

miro_dietiker’s picture

That's a pretty different situation.

Those kinds of add buttons are on an overview page with an add task that leads to a creation form. Yeah that's a common pattern.
See the UX pattern described here: https://www.drupal.org/node/1089894
For these cases, the recommendation is to only have one action per page.

But it has nothing to do with editing a piece of content and adding a new element such a field instance. In these cases the action button are always below the previews data items.

yoroy’s picture

Issue tags: +Usability
miro_dietiker’s picture

On the paragraphs sprint we discussed the addition of a Drag handle in front of the add button.
#2737863: [META] Allow to add a paragraph between any item

Thus, a new paragraph can be added at a specific position beside or before any other paragraph.
This step might shift some aspects of indentation / spacing of the add button.

tassilogroeper’s picture

Issue tags: +DevDaysMilan
tassilogroeper’s picture

talked with @yongt9412 directly. We came to the solution in order to fix this problem we need to:

- refactor the split button rendering as proposed in issue #2742021: Implement ParagraphsDropDownButton render element to a twig template
- to style the "add new" button in the footer and the other buttons in the header (delete, collapse) it is important to wrap them correctly via css classes
- this can be done before #2742021 has started. but this follow up needs to consider, dependencies (Wrapper, prefix, split buttons, suffix) created in this issue here

so here is the supposed html structure

emmet:
.paragraphs-actions-wrapper.footer>(.prefix+.dropbutton-wrapper+.suffix)

html

<div class="paragraphs-actions-wrapper footer">
  <div class="prefix"></div>
  <div class="dropbutton-wrapper"></div>
  <div class="suffix"></div>
</div>

The important parts here:
- we need a wrapper (paragraphs-actions-wrapper, just a supposed name)
- a modifier (footer or header) to position the button left in the footer and right in the header (remove, collapse). You could also use left|right classes, but those would not take into account padding and other positioning needs