938723 - Sketch, then build in code, the "View Group as Curator" screen

Status: VERIFIED FIXED

(Participation Infrastructure :: Phonebook, defect)

Description

[Justin Crawford [:hoosteeno] [:jcrawford]]

Attachment: curated_group_view_as_curator.png

In bug 936570 we discuss this at length.

When a curator views a group they are the curator of, they should have the option to...
1. edit the group
2. view and accept members who have requested membership

#1 is covered by bug 938680. 

#2 is unspecified so far. 

I attach a sketch for how the "View group as curator" screen might answer #2. Other sketches are welcome (please attach to this bug). Once we have a sketch that folks like, let's build it in code.

Note: The attached sketch is not a layout or design guide; it roughly depicts the interface elements we could add to support the "view and accept members" feature.

Comment 1

[William Reynolds [:williamr]]

I like the elements in this sketch a lot. Three thoughts:

- In the membership filter, I think it would be helpful to display the number of people in each of those membership states. Using the mockup in comment 0, those labels would say: All (3), Members only (2), Requesting membership (1)'. This allows curators to tell at a glance how many people are in each membership state, and it appears to be a common practice on others sites. Not needed for V1.

- I think it would be valuable for a curator to be able to deny someone's request for group membership. This seems to be a common pattern on other sites, and it will make it easier for the group curator to maintain the list of people 'Requesting membership' so that list doesn't grow to a large number. A simple implementation would be to add a Decline button next to the Accept button. I don't think this is a requirement for V1 since it isn't needed for a curator to maintain a group, though it would be useful.

- We may want an easier way for curators to accept (or deny) membership requests in bulk. Some curated groups will have hundreds of members (ex: summit2013 or sf-monument) and it would be time consuming for a curator to accept them individually. A common pattern for processing bulk requests is to have a table where each row represents a person who has requested membership and a check box. There is then an action dropdown to accept (or deny) the people in the rows that have been checked. Again, I don't think this is needed for V1, but it would be useful for curators of really large groups in the future.

Comment 2

[William Reynolds [:williamr]]

Attachment: accept or decline mockup

Here's a quick mockup that shows what having accept and decline buttons could look like.

Also, I moved the button to be below the username, so that the button does not overlap with the person's username.

Comment 3

[Dan Poirier [:dpoirier]]

This is looking nice.

When I saw the word "All" in the Filter choices, my first impression was that it would display all members, and the hidden choices would display some subset of the members. It didn't occur to me that All might mean members plus non-members who want to join.

I think if instead of a dropdown, this was a stack of radio buttons (kind of like the filters in the Django admin), it'd have been immediately obvious to me what this control was doing. That's just the first solution that occurs to me, there are probably plenty of other options.

Comment 4

[William Reynolds [:williamr]]

Attachment: Curator view for membership requests mockup

(In reply to Dan Poirier [:dpoirier] from comment #3)
> This is looking nice.
> 
> When I saw the word "All" in the Filter choices, my first impression was
> that it would display all members, and the hidden choices would display some
> subset of the members. It didn't occur to me that All might mean members
> plus non-members who want to join.

I had a similar first impression. I assumed that "All" referred to accepted members. After reading the other choices, I realized "All" included accepted members and those who are waiting to have their membership request accepted. It may help to reorder this filter choices to something like: Members, Requesting Membership, All. 


> I think if instead of a dropdown, this was a stack of radio buttons (kind of
> like the filters in the Django admin), it'd have been immediately obvious to
> me what this control was doing. That's just the first solution that occurs
> to me, there are probably plenty of other options.

I was also thinking of this. I made a quick mockup to show an approach with tabs, which are effectively radio buttons.

This mockup also includes a sketch with a table view for a curator to bulk triage membership requests. Wanted to offer a visual as a follow up to comment 1.

Comment 5

[William Reynolds [:williamr]]

Attachment: Curator view for membership requests.png

Updated mockup that has the 'select all' checkbox.

Comment 6

[Justin Crawford [:hoosteeno] [:jcrawford]]

William, I like all of your suggestions. I tend to agree with you that these features are not required in V1, so we might not want to get get too committed to the interfaces showing them in detail. But now is the time to advocate to the contrary!

WRT the actual interface -- where the buttons are, whether we use radio or dropdown or tabs -- I suggest  we ask :wbowling to offer an expert's opinion.

There is one feature we did specify for V1 that should be added to these: Remove Member. I imagine this sits in the same place as accept/deny on every user card. I think it ought to have a confirmation popup.

Comment 7

[Wray Bowling [:wbowling]]

Filters are IMO best done with checkboxes. In a nutshell:

[x] Members + [x] Requests = "All"

Because as soon as you have a C option, the "All" is possibly too generic and/or the combinations unavailable multiply. 

example: As Tabs, let's assume one day we introduce "Admins":

[Members] [Requests] [Admins] [All]
- Admins and Members (not possible)
- Admins and Requests (not possible)

To make an "All" button is completely reasonable, but I would make it do nothing more than refresh the page with all the checkboxes filled in.

Comment 8

[William Reynolds [:williamr]]

(In reply to Justin Crawford [:hoosteeno] from comment #6)
> William, I like all of your suggestions. I tend to agree with you that these
> features are not required in V1, so we might not want to get get too
> committed to the interfaces showing them in detail. But now is the time to
> advocate to the contrary!

The one feature I would advocate for V1 is the ability for the curator to accept/decline requests in bulk, since it will make it easier for curators to manage groups. If we don't do it in V1, I suggest we build these feature shortly after V1.

> WRT the actual interface -- where the buttons are, whether we use radio or
> dropdown or tabs -- I suggest  we ask :wbowling to offer an expert's opinion.

+1. I'm sure wbowling will turn these features and ideas into a great interface.

> There is one feature we did specify for V1 that should be added to these:
> Remove Member. I imagine this sits in the same place as accept/deny on every
> user card. I think it ought to have a confirmation popup.

Agreed with including this Remove Member feature for V1.

(In reply to Wray Bowling [:wbowling] from comment #7)
> Filters are IMO best done with checkboxes. In a nutshell:
> 
> [x] Members + [x] Requests = "All"
> 
> Because as soon as you have a C option, the "All" is possibly too generic
> and/or the combinations unavailable multiply.

Yes, I like this a lot. As you mentioned, it allows for all combinations to be filtered and it's more future proof if we add more membership states (like Admins).

Comment 9

[Wray Bowling [:wbowling]]

Attachment: 8 - Members vs Requests.svg

Multiple filters are enabled as checkboxes. An "All" button has turned all of those filters on. Below the Filter row, three users appear. One is await acceptance from the curator. The second is a member. Both users have an "x" button hovering above their card.

Comment 10

[Dan Poirier [:dpoirier]]

In general, my expectation when I click an X in the corner of a window is that it'll just make the window go away, not change data. So I think I'd rather have an explicit Reject action of some sort.

Comment 11

[Wray Bowling [:wbowling]]

Attachment: request-accept-decline vs member-remove.jpg

There was some reasoning behind my original sketch but there are other ways to handle this sort of interface. I talked over these options with Dan. Here are all the options explained. (changes from my svg are drawn in dark blue)

A. A small circle-X button in the top right corner of the user's card that both declines requests and removes members. In the case of removing the member from the group, a confirm popup asks if the curator is sure. This option will yield the fewest problems with translated text. The "remove" as a small X is widely accepted as a way to close or delete things. To make the action more obvious for a first-time-clicker, the popup can ease any further confusion without the verb needing to be written on every single card even after the user has learned what the button is for.

B. The small circle-X button is moved inside of the status to make the purpose of the button more obvious. This might feel cramped and users sometimes upon seeing an (x) inside of a small area like this don't immediately recognize that it is something they can click on. It loses the "most popular way to depict removing something" advantage of option A. Upon clicking the (x) to remove membership, there are two different expectations a user may have. 1: That the user who was previously a member is now in the "requesting" category again. or 2. That removing their membership would require that user to request membership again. A curator user that expects either situation 1 or 2 if presented with the opposite of their expectation, will complain, or at least experience a violation of their expectations. Read more about that here: https://en.wikipedia.org/wiki/Expectancy_violations_theory

C. The circle-x button is replaced with a verb button that explicitly defines the action. This will put any doubts to rest about what the buttons do before any user clicks on them for the first time, but in all subsequent clicks, they may feel that they no longer need that verbosity.

I was in favor of option A because it communicates to the user "you will make this box go away" Options B and C may also be good choices though. I'm interested to hear what you all think.

Comment 12

[William Reynolds [:williamr]]

To recap our IRC discussion, several folks favor Option A from comment 11. Two suggestions:
- Have a tiny X on the card with a hint on rollover. "Remove user from group"
- For approving members, use the flow shown in comment 9. In the corner of the card it would say "requested" and clicking on "requested" would change their status to accepted.

Comment 13

[Wray Bowling [:wbowling]]

Pull request: https://github.com/mozilla/mozillians/pull/748

Comment 14

[Wray Bowling [:wbowling]]

That last pull request was merged. I think this bug is done.

Comment 15

[Rebecca Billings [:rbillings]]

Verified all in comment 12- members are automatically added, group curator can remove or click 'requested' to fully join.

Comment 16

[Matt Brandt [:mbrandt]]

Bumping to verified per comment 15 - curated groups has been merged to master and has landed on stage. lgtm