>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #1905364. --> Reported by: [joachim](https://www.drupal.org/user/107701) >>> <p>I'm afraid that the UX for adding and manipulating fields for groups is pretty bad -- sorry!</p> <p>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.</p> <p>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!)</p> <p>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.</p> <p>So we'd have a main admin 'Group types' page that looks like this:</p> <p><img src="http://drupal.org/files/OG%20UI%20proposal%20-%20admin%20list.png" alt="OG UI proposal - admin list.png"></p> <p>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.</p> <p>Here's the form for editing a single group:</p> <p><img src="http://drupal.org/files/OG%20UI%20proposal%20-%20edit.png" alt="OG UI proposal - edit.png"></p> <p>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.</p> <p>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*.</p> <p>Anyway, I thought I'd get the ball rolling and get people's feedback on this. Any other pitfalls I haven't spotted?</p>