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.I'm afraid that the UX for adding and manipulating fields for groups is pretty bad -- sorry!
Part of the problem stems from the fact that there is a big gap between the way a site builder conceptualizes this task and the way the Drupal architecture accomplishes it. Put more simply, on the one hand the site builder thinks 'My group is made up of Group nodes, Article nodes, and Tag terms, with Normal membership type', but there is no actual 'definition' of a that in Drupal, just a lot of fields on different entities.
Hence we have an architecture-first UI, which doesn't work well at all. (Anecdotally: myself and other developers were completely baffled by it at first, and if I hadn't been shown it I'm not sure I would have figured out what I was meant to do to make something a group!)
What I think we have to do is fake up the concept of 'a group type' in the UI, even if that doesn't exist materially in Drupal.
So we'd have a main admin 'Group types' page that looks like this:
This would need to go investigating fields to determine how they all fit together. In the example, it's found that there is a 'group' field on 'group' nodes, and that the 'group content' field on 'article' nodes points to this: hence they form part of the same group definition. Likewise, it's looked at the group membership fields on users to figure out which membership types apply.
Here's the form for editing a single group:
The group entity type can't be changed -- that would bring the whole thing crashing down (!!). If we allow removal of group content entity types, we probably need a confirm form.
It occurs to me that complications arise when, say, we have two group types, say node types A and B, and article nodes have a group content field that refers to *both*. That would be... interesting to deal with, as deleting the article node from group A doesn't mean deleting the field, because it does double duty, but rather changing its target bundle settings... *sigh*.
Anyway, I thought I'd get the ball rolling and get people's feedback on this. Any other pitfalls I haven't spotted?
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | og-field_type_context-1905364-7061900.patch | 1.58 KB | othermachines |
| #6 | 1905364-og-field-name-5.patch | 8.87 KB | amitaibu |
| #5 | og-settings.png | 50.68 KB | amitaibu |
| OG UI proposal - edit.png | 52.8 KB | joachim | |
| OG UI proposal - admin list.png | 46.12 KB | joachim | |
Comments
Comment #1
amitaibu> I'm afraid that the UX for adding and manipulating fields for groups is pretty bad -- sorry!
No need to be sorry, the UX sucks :/
Let's try also the UX team, maybe they can have a look in OG and give some feedback as-well.
Comment #2
othermachines CreditAttribution: othermachines commented@joachim
That's some good work you've done there. One thing that jumps out is that we've lost any reference to fields altogether. Do you think this might create a roadblock for those who require further customization (and might be new to OG)? Since there are a lot of reasons why a site builder might need to edit these fields directly, I wonder if there is some way we can maintain the simplicity of what you have here without completely disguising the architecture. Or is that a pitfall others can live with? Anyway, I'll think on it and post here if I have any ideas.
Comment #3
joachim CreditAttribution: joachim commentedYou can always add fields manually in the fields admin for the relevant entities.
And we could add help text to this group edit form to explain that this creates fields, and give links to the admin page to allow further customization.
Comment #4
amitaibuFor now, I've started working on allowing adding multiple group audience fields via og field settings page, by allowing to enter a field name.
Comment #5
amitaibuThis page still deserves love, but the following patch makes it easier to add multiple group-audience fields.
As bonus it also changes via Ajax the description per selected field type, so it's easier to know which kind of field you attach.
Comment #6
amitaibuOh, and the patch...
Comment #7
amitaibuI've committed the patch in #6. Marking as needs-review, as some more love should be given to that page.
Comment #8
othermachines CreditAttribution: othermachines commented@Amitaibu -
I just downloaded your changes. This is a step, for sure. Not being allowed to add multiple fields was the big thing that was missing from this page, functionally. I didn't encounter any errors.
I agree with @joachim that this page needs a major overhaul, but if we're only tweaking for now: can we move the field description and field name into a wrapper with the "Fields" select? Maybe just move everything inside field_info_wrapper? This won't make a difference on some interfaces, but on mine (Rubik) the wrappers offer some visual context. Otherwise it isn't clear they have much to do with each other.
Question: It's my understanding that, traditionally, certain fields can only be added to groups, and others to group content. Is it now true that you can add any field to any type? I didn't go through them all but I tried a couple that I would have expected to generate a validation error and didn't get one. Or maybe I am imagining things!
Thnx -
Comment #9
amitaibu> Maybe just move everything inside field_info_wrapper?
I agree - Patch please :)
> Is it now true that you can add any field to any type?
Yes, because a group can also be a group-content (think subgroups).
Comment #10
othermachines CreditAttribution: othermachines commentedYou got it.
Comment #11
amitaibuCommitted, thanks. Back to needs-work.