Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Improve user experience following the field collection example for single paragraph type. The goal is to deprecate Field Collection module. All possible changes and improvements are open for discussion.
Proposed resolution
- Change "Add User" to simply "Add or Add another item.
- Possibly, remove Type: User and use simply "User" instead if it is the single type.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | Screen Shot 2017-06-13 at 6.57.02 PM.png | 88.6 KB | hanoii |
| #10 | UnlimitedMultipleFields.png | 71.83 KB | Ginovski |
| #10 | MobileUnlimitedMultipleFields.png | 27.3 KB | Ginovski |
| #10 | UnlimitedSingleTypeAndField.png | 81.47 KB | Ginovski |
| #10 | MobileUnlimitedSingleTypeAndField.png | 28.37 KB | Ginovski |
Comments
Comment #2
Ginovski CreditAttribution: Ginovski at MD Systems GmbH commentedProviding screenshot of comparison between the field collection and single paragraph type, both with 2 fields (email and user)
The differences are:
1. The field collection has 1 value field by default, the paragraph has none (has to click to add a paragraph)
2. The field collection add button is with different title (goes for the global approach - "Add another item", instead of specific approach that paragraphs uses - Add @type)
3. The placement of the remove button.
I propose we can fix the 1. point, and add a value field by default on paragraphs.
Comment #3
miro_dietikerCan you please provide the same screenshots for a mobile screen width use case?
Comment #4
Ginovski CreditAttribution: Ginovski at MD Systems GmbH commentedOk, so uploading screenshots for 6 cases:
1. Mobile multiple fields
2. Mobile unlimited single field
3. Mobile limited single field
4. Multiple fields
5. Unlimited single field
6. Limited single field
Suggested issues:
1. Remove "Type: Paragraph type" label for limited/unlimited single field.
2. Add default paragraph type for all cases (because it is single paragraph type).
Comment #5
miro_dietikerRemoving of "Type:" is already proposed by some different issue. However i was not happy about that mixing.
Changing to generic "Add" feels like a step back to me. But OK, if this is only about single paragraph type UX, we could consider it.
More importantly, the had the idea to remove the paragraph type label completely if there is only one possible paragraph type.
The remaining problem is then that the Remove button is eating the first line.
I don't really understand what is so ugly with Paragraphs. We might want to hear some more voices from Field Collection users first before implementing anything.
Comment #6
miro_dietikerIf this issue wants to be parent from its current child, then it needs to be META and include the child scope too, providing overview.
I propose to create another META issue. Related issues need a lot of love and updates.
Comment #7
miro_dietikerComment #8
drobnjak CreditAttribution: drobnjak at MD Systems GmbH commentedComment #9
miro_dietikerOK, we have an updated version already after commits. Let's update these screens here with the new "X" remove button so we have exact examples of what we compare.
Comment #10
Ginovski CreditAttribution: Ginovski at MD Systems GmbH commented8 cases:
1.1. Mobile Limited Single Field
1.2. Limited Single Field
2.1. Mobile Unlimited Single Field
2.2. Unlimited Single Field
3.1. Mobile Unlimited Single Type and Field
3.2. Unlimited Single Type and Field
4.1 Mobile Unlimited Multiple Fields
4.2. Unlimited Multiple Fields
Comment #11
Ginovski CreditAttribution: Ginovski at MD Systems GmbH commentedComment #12
miro_dietikerMost importantly i realise that the "Remove" X is not well positioned when it is all alone on the right. It has too much horizontal space.
I also feel that this X is a tiny bit too small, since it's about closing a whole widget, not just a small item.. But that needs much more detail work.
Also the "Show row weight" starts to get annoying...
More related activity here #2831838: Improve remove button X or in child issues before doing anything else.
I'm postponing more actions for further comparision on more UI improvements that are on our roadmap.
Comment #13
miro_dietikerAnd linking to the Roadmap. :-)
Comment #14
hanoiiI wanted to tried paragraph specially as a field collection alternative.
Namely, I want one field that really is a collection of other fields and that I can add to other content types, but those fields have to be on every content type, exactly like a field collection.
So I installed paragraphs, created one paragraphs type, added enabled that paragraph and added a field to a content type.
The behavior is kind of there, but a few odd things I noticed out of the box.
- Remove button: why would I want to remove a single type paragraph field, and if I want, should be optional
- Field label of the paragraph field is not displayed, I'd like it to be
- The paragraph type is displayed, I rather don't have that and it's also styled oddly. (This I know I can hid in css, just wondering if default is correct)
See screenshot.
Comment #15
miro_dietikerWe auto-add a single-type paragraph field by default. You can disable that.
I only see an option to drop the "Remove" button, if the field is required and cardinality is 1.
The paragraph type is output as non-emphasized to avoid to compete with the regular field labels. We had once a prefix "Type:" but it was cluttering the UI and didn't help. How are you missing the "field title" here? All fields have a label - we recently decided to remove the first field label if the paragraph type has a single field only. If you look at Material Design, they do grouping in a similar way with less emphasis than the regular field labels.
There's a lot we can improve for the advanced use cases and we have proposals for those.
Please provide examples for better styling, if you have an idea.
Still keeping this postponed as the refactoring of the "Remove" / "..." button didn't happen yet.