When you add a username to the field “Add owners” in group settings, the username then appears with an X next to it (see screenshot below). This conveys the impression that when I click “save” to save the group settings, the user(s) I just added will in fact be added to the group. Unfortunately, this is not the case. The added users are only saved if you click the “+ Add” button below and then click save. I think this is misleading and could be improved so that either the “+ Add” button click is not necessary at all or it is made more evident that the button has to be clicked before saving. But even here I see room for improvement.
In the field for adding members to the group right below is, the UX is slightly more intuitive: as long as there is no new member to be added, the “+ Add Members” button is greyed out. Once you enter a user name it becomes active and the attentive admin will notice that change and guess that “maybe I have to click “Add Members” before I save.”
Taken together these two issues make a third issue, namely that of inconsistency. Adding owners and adding members is almost the same thing (from a user perspective) so why should the UX be so different? (Note also that for adding members, there is no “enter username” hint)
And while I’m at it, it might be useful to add a hint whether owners are automatically members (i.e. owner = privileged member) or whether owner and member are two entirely distinct categories. I suppose that the latter is true, but it could be mentioned right in the rgoup settings where the question is likely to come up.
It happened again the other day. I wanted to add a user to a group and ended up adding him a a group owner. Luckily I realized the mistake after less than 24 hours…
So my plan here is to shift most of the members/owners management away from the admin page into the group page. The group tab in the admin page will only be used to create groups and fill in basic information. I’ve already added the ability to remove a member on the group page and will be adding the following features soon:
Allow admins to add/remove groups owners on the group page.
Allow group owners to add new users directly on the group page.
Allow group owners to filter for users on the members page making it to easier to carry out admin actions for a particular member. I personally think this is crucial for large groups where our current solution makes it really hard to find a group member as you’ll have to tab through multiple pages of users sorted by id.
Awesome! I updated and the new group pages look fantabulous. You’ve made tremendous progress here. Nice work!
Really enjoying the power of the groups listing page with filters etc. Wonderful. My team will be very happy.
Some small noticings:
When looking at the group profile, the group name is highlighted with a strong warning that the name is already taken. Not sure that message is needed.
Maybe the group name should not even be editable here, since it’s a matter of sitewide concern and doesn’t need to be quite so easy to change. How about a link to group admin , like on user profiles? Or greyed out/uneditable for those without privs, with a notice to contact an admin about changing admni settings?
members page on vertical menu, when managing the group, only allows adding members and not managing/removing them. Maybe remove this and instead just add a + ADD MEMBER link to the member list accessed via horizontal members menu? Could be a popup or a link to this page.
any chance we’ will see ASSIGNED and TAGS on groups messages menu?
edit: and a small typo, I think - should be “closed groups” not “close groups” on the groups listing page.
The groups tab under the admin pages is going to be removed once we feel like we’ve gotten into a decent state with the new groups pages. The name input field will only appear for an admin user. As a group owner, the edits that you can make to a group is still limited.
I actually started off with a modal to add members but after I implemented it, I realized modals are really bad design wise since that is no direct way to link to it.
Hmm probably not at this moment since it is way easier to just visit your assigned messages from the dropdown menu.
And…the admin group pages are gone! Everything that you used to be able to do on the admin group pages can now be done on /groups or /groups/<group name>.
Why, when it makes life more difficult for admins? If you really think there are too many tabs, I’d suggest hiding the ones you rarely need (API, Plugins, Backups) behind “More” or “Other” or something like that.
Well, maybe I’m using discourse differently than other admins but for me the admin page is the central hub from where I basically start all my admin activity (excluding moderation activity, of course, which happens “front stage”) and I find it helpful that I can find/access everything from there.
(Not fully true though)
To create categories, I have to navigate to the categories page, which is two clicks away from the admin page, plus a click on the categories sandwhich menu, plus a click to create a new category. If I want to edit an existing category, it’s even more complicated than that (though there may be shortcuts if the category in question happens to be on the “Latest” page or if it is in the hamburger menu). So what I’m saying about groups basically also applies to categories.
So if the group button disappears, I’ll have a couple of extra clicks compared to now. But it’s not additional physical energy, also mental energy because - at least in my mental model of the discourse UI - the section in the hamburger menu that has the link to the groups page is dedicated to the user facing side (because users have the same menu section) so when my mind is in admin mode, I don’t really “see” that part of the menu, if you know what I mean. Having to access the group admin page through the groups link in the hamburger menu (that’s the idea, right?) will force me to look at that part of the menu.
One could argue: you’ll get used to it, and it’s probably true (after setting up three discourse instances, I eventually got used to having to go to the categories page to create categories), but I’d still say it’s incoherent to not have all admin (important) stuff easily accessible from the admin page. I agree that removing noise and clutter is important, but only if it makes things easier for the user, which means that the removed information should be redundant or irrelevant. If the information removed now has to be in the user’s head instead, it’s usually not easier for the user.
Note that I do see the point in moving the actual group admin page under groups rather than admin, all I’m saying is there should be a short cut from the admin page.
I hope this clarifies at least my problems with the change. If anyone has a better mental model of the discourse UI, I’d be curious to understand it.
If you are not on the admin page, you’ll just have to open the hamburger menu and go to groups. IMO, opening the hamburger menu is not a significant overhead that it justifys a link in the admin nav that does the same thing as link in the dropdown. That is also only one extra click and not a couple…
[
I would argue that once your mind adjust to the fact that everything group related is done on the groups pages, you won’t not see/remember the groups link in the hamburger menu when you mind is in “groups admin mode”
