936570 - Design user interaction for "Curated Groups"

Status: VERIFIED FIXED

(Participation Infrastructure :: Phonebook, defect)

Description

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

We've developed a fairly complete specification for V1 of the curated groups feature[0]. We need a draft of the various interactions this feature implies. The interaction design could be in rough code mockups or in flowchart form. The goal of the interaction design is to explain what new pages or page elements we'll need to build to support this feature. It should be rough, not polished; we will iterate on it. I think I've called out the critical interactions/questions below, but as you build this you may encounter others. Let's talk about it here.

1) A user can input information about a new curated group the user is creating.
* Questions:
  ** How does the user get to this feature?
* Inputs: 
  ** Group name
  ** Submit
* Error states: 
  ** "Group already exists, please choose a different name."
  ** "Your group must have a name."

2) A curated group owner can submit changes to a curated group.
* Questions:
  ** How does the group owner get to this feature?
* Inputs: 
  ** group name (required)
  ** more info URL (text)
  ** group overview (textarea with character limit: 500 chars)
  ** irc channel (text)
* Error states: 
  ** "Group already exists, please choose a different name."
  ** "Your group must have a name."

3) A curated group owner can manage the membership of a group.
* Questions:
  ** How does the group owner get to this feature?
  ** How does this feature relate to already existing group membership view screens?
* Actions:
  ** See all users who have requested to be admitted
  ** Accept a user who has requested to be admitted
  ** Remove a member from the group

[0] https://mozillians.etherpad.mozilla.org/curated-group-specs

Comment 1

[Wray Bowling [:wbowling]]

Attachment: 1 - edit button.svg

Here I have simply conjoined the "join/joined" button with the "edit" button if the user has permissions to edit.

Comment 2

[Wray Bowling [:wbowling]]

Attachment: 2 - make admin.svg

Here you can see a "make admin" button on a user's card so admins can make admins out of other users.

(there is an edge case here: not letting the last remaining admin relinquish their admin status)

Comment 3

[Wray Bowling [:wbowling]]

Attachment: 3 - profile display.svg

Here you can see a user's profile with groups they are admins of visualized as a single-character crown next to the name of the group.

Comment 4

[Wray Bowling [:wbowling]]

Attachment: 4 - form validation.svg

A few different ways we can go about making form validation. Whatever is already in place to show validation is probably fine to keep as it is one of the most bewilderingly re-invented wheels. Visualized on the lower half is a standard HTML5 form validation pop-up.

A quick demo was made here: http://jsbin.com/oLIJUFO/2/edit

Comment 5

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

(In reply to Wray Bowling [:wbowling] from comment #1)
> Created attachment 830499 [details]
> 1 - edit button.svg
> 
> Here I have simply conjoined the "join/joined" button with the "edit" button
> if the user has permissions to edit.

To clarify, the "edit" button would be on the group view screen (e.g. https://mozillians.org/en-US/group/summit2013/). This answers the question in comment 0 #2. And the sketch here depicts the editing interface, which resembles profile edit screen. 

Upon review, I realize: In the featureset of V1, an owner of a curated group cannot leave the group, and cannot join the group. An owner of a group can only edit it. So for an owner, we can simply replace the join button with the edit button.

Comment 6

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

(In reply to Wray Bowling [:wbowling] from comment #2)
> Created attachment 830500 [details]
> 2 - make admin.svg
> 
> Here you can see a "make admin" button on a user's card so admins can make
> admins out of other users.

V1 doesn't include this feature. The features in V1 are entirely described by the spec linked in comment 0. I suggest we use the user card element from this mockup to explain how a user would be /added as a member/, not /added as an admin/. If we do that it makes perfect sense, I think, and it begins to address comment 0 #3. 

Comment 0 #3 also requires that we show a curator a list all the users who have requested to join. :wbowling, can you suggest how we'd get to that feature? Is it a filter on the group view screen visible only to admins? Is it a different screen? Etc.

Comment 7

[Wray Bowling [:wbowling]]

Good point on swapping out "join/joined" for JUST "edit" if the user is the admin.

And as you noted in IRC, 2-make admin.svg shows more than one admin which is not a V1 feature. so i'll rethink that one.

Comment 8

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

(In reply to Wray Bowling [:wbowling] from comment #3)
> Created attachment 830501 [details]
> 3 - profile display.svg
> 
> Here you can see a user's profile with groups they are admins of visualized
> as a single-character crown next to the name of the group.

I like this a lot!

Comment 9

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

These are a great start. I think we still need to address a couple points from comment 0:

> 1) A user can input information about a new curated group the user is
> creating.
> * Questions:
>   ** How does the user get to this feature?

i.e. "How does the user start the process of creating a new curated group?"

> 3) A curated group owner can manage the membership of a group.
> * Actions:
>   ** See all users who have requested to be admitted
>   ** Accept a user who has requested to be admitted
>   ** Remove a member from the group

We know how "accept a user" will work, from comment 2. We still need to figure out how to see the filtered list and how to remove a member. Does removing a member have a confirmation dialog?

> 
> [0] https://mozillians.etherpad.mozilla.org/curated-group-specs

Comment 10

[Wray Bowling [:wbowling]]

Attachment: 5 - Create Button.svg

A "Create" Button on the Groups listing page.

Comment 11

[Wray Bowling [:wbowling]]

The simplest solution in the end felt like the best. Just a big fat "create group" button right there on the groups listing page. It was a pretty universal convention. I was looking at meetup, facebook, and vimeo (I'm rather partial to Vimeo's design decisions)

Comment 12

[Wray Bowling [:wbowling]]

To sum up the long IRC chat from today:

Curated groups are different from regular groups.

Regular Groups:
- anyone can join
- anyone can leave
- group is deleted when there are no users and garbage collection comes around

Curated groups:
- users can only join if invited
- regular users can leave
- curators can only leave if they hand off their curator-ship to someone else
- curators can delete the group and it removes all users from it

Comment 13

[Dan Poirier [:dpoirier]]

So we have:

- Regular groups
- Curated groups
  - Functional areas
- System groups

(I put functional areas under curated groups because both have owners.)

Is that right?

Comment 14

[Wray Bowling [:wbowling]]

Attachment: 6 - CRUD permissions.svg

My present understanding of the ins/outs of Curated Groups organized by the classic CRUD permissions.

Yes, admins are omnipotent. I wanted to keep it curated-group-related though.

Comment 15

[Wray Bowling [:wbowling]]

Attachment: 7 - Curated vs Open.svg

Yesterday's conversation was long. What I got from it: It did sound like it would be okay to flatten curated groups in to groups as long as the interface and permissions between a zero-admin group and more-than-zero-admin group are handled appropriately.

Here's the first half of that interaction: creating a group and having the option to leave it open. An open group would be the same as creating a new group tag in your profile.

Comment 16

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

(In reply to Wray Bowling [:wbowling] from comment #14)
> Created attachment 831502 [details]
> 6 - CRUD permissions.svg
> 
> My present understanding of the ins/outs of Curated Groups organized by the
> classic CRUD permissions.

In V1, as currently conceived:
* curators cannot update curator. only admins can update existing curator field.
* curators cannot leave their curated group. 
* curators cannot delete groups. only admins can delete groups.
* admins have exclusive access to some fields

Comment 17

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

(In reply to Dan Poirier [:dpoirier] from comment #13)
> So we have:
> 
> - Regular groups
> - Curated groups
>   - Functional areas
> - System groups
> 
> (I put functional areas under curated groups because both have owners.)
> 
> Is that right?

We have one kind of group that has various orthogonal flags:
* members can leave the group, or not
* members can join freely, or by request, or not
* group is visible in search/browse/profile edit, or not
* group is a functional area (which means it gets functional area strings in UI), or not

A group can also have a curator and some meta data, or not. 

In the UI, we will have UI cues that distinguish...
* groups that have curators from groups that do not (having a curator means the group gets a big info box like this one https://mozillians.org/en-US/group/summit2013/, whereas not having a curator looks like https://mozillians.org/en-US/group/a-misrable-little-pile-of-secrets/)
* groups that are flagged as functional areas from groups that are not (being a functional area means the curator is called a "steward" and the group is called a "functional area" instead of a "group")

Comment 18

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

This work has spun off 3 bugs where we should focus our UI for the moment. I think this one is done.

bug 938674
bug 938695
bug 938723

Comment 19

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

Since the bugs in comment 18 are resolved, this one is definitely verifiable.