Groups

[flavour]

Wireframes:
https://sites.google.com/sahanafoundation.org/wacopdesign/groups
https://sites.google.com/sahanafoundation.org/wacopdesign/groups/group

A lot of discussion happened here as they were being introduced here 1st (impossibly):
#21

Starting a new thread for discussion of the feature now that we have the core model defined & HTML for the browse page (some of which is working now) and the profile page (a lot of complexity here, and still in raw dummy mode, will start that by hiding everything which isn't working & start getting bits working)

[flavour]

@devinbalkind:
1st Question:

• Admins...can there be more than 1 or just 1 for each Group?
  (Model-wise I will allow more than 1, as we're already making use of the core model in another usecase although without per-forum admins there...just will keep it flexible, so this is a UI issue & ability to have a faster query in the Virtual Field for the Admin column)

Your wireframes suggest just a single Admin per Group.

I am thinking that Admin should be an attribute of membership...as all Admins would be Members right?
Although if you have just 1 for the Group, then it probably shouldn't appear like that to the Users.

[flavour]

@devinbalkind:
The wireframe has 3 different action buttons...which I can work out when should show:
Join = Public Group which the user is not a member of
Leave = Group which the user is a member of
Request Invite = Private Group which the user is not a member of

ok, so these are clear & we'll only ever have 1 (not a problem to have more technically anyway, other than screen real-estate)

My question comes that therefore the bottom Group is a Private group which we're not a member of which by definition "Anyone else can see that the forum exists but not its members or posts". But the wireframe shows the Admin & the # of Members...is that OK?

[flavour]

@devinbalkind: Can a user Request Invite to a Secret Group if they know the URL?

[flavour]

@devinbalkind: The Groups Profile page dummy HTML has sections for 'Bookmarked Events' and 'Bookmarked Incidents' however Bookmarks are links between individual Users & Events/Incidents NOT Groups <> Events/Incidents so this doesn't make sense to me.

[flavour]

The Tasks section...is this completely unfiltered? Or do we need now to be able to link Tasks to Groups?

[flavour]

How are the Group details edited?
e.g. I mistakenly left my 'private' test group as public...the UI as-defined here doesn't allow me to rectify this mistake

[flavour]

This design also suggests that Updates are linked to Groups somehow (The # Updates in the top-right & the fact that we show an Updates dataList, which presumably should be filtered somehow).
So...how is this done?
(A) We add a link table for Updates <> Forums & so this is a field we add to the form on other screens ?(hidden/auto-filled if update added on this page)
i.e. just like the current links to Incidents & Resources
(B) All Updates which are created by Members of this Group?
(C) All Updates which relate to Events/Incidents which have been Bookmarked by this Group? (Of course, this isn't yet possible as Bookmarks are currently Users<>Events/Incidents not Groups <> Events/Incidents)

[devinbalkind]

1. Yes, there can be multiple admins per group and yes admins should always be group members.
2. Yes, for a Private Group it's okay to display the admin and # of members.
3. No, a user can't request an invite to a Secret Group.
4. "Bookmarked Events" is the wrong name. It should be "Shared Events" and "Shared Incidents". Users can share both to a group. The Share icon in the designs is supposed to provide the user a list of groups they're a member of and to which they can share events/incidents/updates/posts. When an incident/event is shared, it should work like Bookmarks, where the feed of that incident/event is displayed within the group.
5. Yes, we need to link tasks to groups.
6. To edit basic group information, we should have an edit button only visible to admins. Clicking that button can bring the user to a new page or popup to make edits. Whichever is easier.
7. Updates should flow into the Group both via A and C. Updates can be posted to a group from the group page. They can also be shared with the group via the Share icon on individual Update posts - no matter what event or incident they're part of. And they can come in via Incidents and Events shared to the group. Does that make sense?

Thanks!!

[flavour]

Yes, there can be multiple admins per group and yes admins should always be group members.
Yes, for a Private Group it's okay to display the admin and # of members.
No, a user can't request an invite to a Secret Group.

Cool, all these are complete then

"Bookmarked Events" is the wrong name. It should be "Shared Events" and "Shared Incidents". Users can share both to a group. The Share icon in the designs is supposed to provide the user a list of groups they're a member of and to which they can share events/incidents/updates/posts.

OK...this makes sense.
The Icon is visible for Updates, but obviously had nothing to be wired up to before
The Icon was hidden for Events/Incidents since there wasn't anything to wire it up to yet

Now that we have Groups, I can add the link tables, the methods to do the linking & wire these to the UI.
Do we need the ability to Unshare? (like for removing bookmarks)

When an incident/event is shared, it should work like Bookmarks, where the feed of that incident/event is displayed within the group.

Like for the Dashboard, OK, so we can use the same approach.

Yes, we need to link tasks to groups.

ok...how is this done?
(A) We can assign Tasks to Groups
(B) Separate link...simple version is extra field in the form, more complex version (but fits the rest of the UX) is to have a 'Share' icon on the Tasks...I think we need the latter as most users won't be able to Edit Tasks but will still want to share them...

To edit basic group information, we should have an edit button only visible to admins.

ok, so let's look at where to place it & how to style it.

It seems that Events have no such button yet either, so we should do the same there.
Incidents have a Pencil in their action toolbar: http://prntscr.com/h6uf5i

Events just have 1 icon visible (bookmark) but this is also where the commented share icon is so adding a Pencil there makes sense:
http://prntscr.com/h6uhy4

So I guess we should add a Pencil icon in the same place for Groups then: http://prntscr.com/h6uibx
Will be the only icon, but at least is consistent with Events, if not Incidents.

Clicking that button can bring the user to a new page or popup to make edits. Whichever is easier.

New page is easier as then we don't need to refresh the original page, but I think a Popup is more consistent/better UX....for now at least we'll just have this refresh the whole page on popup close, but can get fancier to just refresh the relevant elements later if we get time (unlikely I feel)

Updates should flow into the Group both via A and C. Updates can be posted to a group from the group page. They can also be shared with the group via the Share icon on individual Update posts - no matter what event or incident they're part of. And they can come in via Incidents and Events shared to the group. Does that make sense?

Yes...so 1 remaining question here: If we create an Update from pages other than the Group, should we include Groups in the form, or can they only do it via the Share icon after creation?
I have mixed feelings about this...the form is already very busy so am wary of adding clutter, but it also seems clunky to have to wait until after the post is submitted to be able to Share it.
Well, for now I'll focus on all the other parts and this can be revisited to add this extra option later if needs be.

[flavour]

The Share icon in the designs is supposed to provide the user a list of groups they're a member of

is there a Design for this?

Options I can envisage:
(A) Clicking the share icon opens a Dropdown list of the Groups user is a member of.
User can select the relevant group & the action is committed via n AJAX call (with notification of success).
Variant: the dropdown list has checkboxes next to the items.
I like this option best. We can prepopulate the c hexkboxes based on whether already Shared & then this can also be used to Unshare (if we allow that...and then who can do this? Only original sharer or any Member?)

(B) Open a Popup with a form with a Multiselect dropdown of the list of groups that the user is a member of. User selects the relevant Group(s) & then clicks Save to commit the Sharing & close the Popup

[flavour]

ok, so the Event toolbar with Share unhidden & adding Edit (& Delete) Icons looks like this:
http://prntscr.com/h6urvw

Seems odd to have the text label for 'Share Event' but not the other Icons...should this be moved to popover for consistency?

(Yes, Edit & Delete only show if the user has the relevant permissions)

[devinbalkind]

Great work Fran. Here are my comments.

Do we need the ability to Unshare? (like for removing bookmarks)

Yes, lets have an "Unshare" method.

Yes, we need to link tasks to groups.

ok...how is this done?
(A) We can assign Tasks to Groups
(B) Separate link...simple version is extra field in the form, more complex version (but fits the rest of the UX) is to have a 'Share' icon on the Tasks...I think we need the latter as most users won't be able to Edit Tasks but will still want to share them...

Yes both A and B please. I think creating tasks should follow the post/update convention:

• Create it within a Group and its associated with that group via a hidden field.
• Create it via Dashboard or Tasks pages and pick the group in the create form - default to no group.
• Share it with the icon into a group.

ok, so the Event toolbar with Share unhidden & adding Edit (& Delete) Icons looks like this:
http://prntscr.com/h6urvw

Seems odd to have the text label for 'Share Event' but not the other Icons...should this be moved to popover for consistency?

Yes let's just use icons with popover text for all the event buttons.

New page is easier as then we don't need to refresh the original page, but I think a Popup is more consistent/better UX....for now at least we'll just have this refresh the whole page on popup close, but can get fancier to just refresh the relevant elements later if we get time (unlikely I feel)

Sounds good.

Yes...so 1 remaining question here: If we create an Update from pages other than the Group, should we include Groups in the form, or can they only do it via the Share icon after creation?
I have mixed feelings about this...the form is already very busy so am wary of adding clutter, but it also seems clunky to have to wait until after the post is submitted to be able to Share it.

I think we can leave Groups off the Update form. Tasks will almost always be associated with a group when they're created by a user while updates will not be.

The Share icon in the designs is supposed to provide the user a list of groups they're a member of

As for the Share modal/dropdown, I agree A sounds best. There is no design for it. I can try to get one made if you want. I think only the user who shares the item with the group should be able to unshare it.

[flavour]

ok, Events can now be Shared (Demo updated)
Now to do the other resources (Incidents/Updates/Tasks) which should be quicker since some elements can be fully reused & others just minor tweaking.

Notes:

• I allow Admin to unshare even if they weren't the person doing the sharing

• I find it confusing that we see Event updates shared to a Forum only if the Update isn't also linked to an Incident (same for the Dashboard). I think we should remove this restriction. If we can't then we should at least make it clearer in the Event Updates page which Incident the Update relates to ...actually this should be done anyway (currently this isn't included in the card at all, but is only visible if the user has Edit rights & then Edits the Update!

[devinbalkind]

I agree that all updates associated with the Event or it's Incidents should be displayed and that we should include a link back to the Updates incident and/or event in the card display. @dhornbein can you and Katie make sure Fran has a design that meets this need? If I recall correctly, we might already have this design somewhere..?

[flavour]

I agree that all updates associated with the Event or it's Incidents should be displayed

Actioned.

I have also allowed sharing of Tasks via Create/Update forms when not in Group Profile, done automatically if it is.
I have also enabled a Menu item for Groups, since they're now becoming useful...let me know if should be moved.

Remaining Actions:

• Wire up the Share icon for Updates (should be straightforward)

• Share Icon for Tasks
  Not sure where this latter would go...currently there is no Task Profile page or anything....we're going to a raw Eden page on Open right now which is inconsistent (& menus start showing when open in Groups view, but see little point in polishing that right now unless this is the correct place to go?)

PS Currently there is no visibility for Tasks as to which Incident they relate to unless opened (just like Updates)...should I enable a list_field for that?

PPS I hid the Flag / Make Public Icons from Updates & the Flag from Incidents since they currently do nothing

[flavour]

Wire up the Share icon for Updates

Actioned. I see that for Update Cards & the Incident, then the Share Icon now has a Blue backgound which is probably undesirable...I guess this is a Foundation default for dropdowns or something, but I'll leave to @dhornbein to resolve.

[devinbalkind]

Great work Fran.

PS Currently there is no visibility for Tasks as to which Incident they relate to unless opened (just like Updates)...should I enable a list_field for that?

Yes please.

PPS I hid the Flag / Make Public Icons from Updates & the Flag from Incidents since they currently do nothing

Great

Thanks!

[devinbalkind]

And yes, I think it's fine for the tasks to link to the conventional page format for now. Those pages are functionality enough. We'll see if we need to go deeper once we get into QA/testing.

Thanks again.

[flavour]

Currently there is no visibility for Tasks as to which Incident they relate to unless opened (just like Updates)...should I enable a list_field for that?
Yes please.

Actioned

I think it's fine for the tasks to link to the conventional page format for now.

ok, added a share icon (in the footer currently) & hid the menu & ensured that editing a task from Group takes you back to the Group afterwards.

The only remaining thing is the fancy Filter on the Updates page, which I am leaving for now.

[devinbalkind]

Fran. Do you need anything from @dhornbein or I to keep moving forward?

[flavour]

Un less you can think of something I'm missing, as I said in the last update:

The only remaining thing is the fancy Filter on the Updates page, which I am leaving for now.

So is this fancy filter urgent?

[flavour]

ok, so I have made progress with the Fancy Filter (Demo server updated)

Question:

• How is this supposed to work? Before this filter was added, we already displayed all Updates linked to Shared Events/Incidents...so should we remove that unless the relevant Event/Incident is checked?
  Should we have all of these checked by default & so the user can uncheck some if they wish to narrow?

Known Issues:

• 'Stop Sharing' works, but isn't done by AJAX yet so user gets a nasty screen ;)
• 'Stop notifications' does nothing yet
  (I see that actually the Notifications part was another chunk that is still outstanding, so will look at that next)

[flavour]

Notification Settings:

• The 'Daily Digest' will take a chunk of work, so will put aside for now, so we can hide that part completely (but when we do come back to it should it be a radio either/or or a checkbox to allow both, but then also neither, which is a bit confusing.)
• Similarly, the SMS/Email allows neither...is this the way to switch off completely? I suggest moving the Channel above Notification Frequency once we have daily digests & hence we restore the frequency section (Channel is more critical as decides whether on/off...well actually both do right now...as I say seems confusing.)
• Should we be smart & only show the SMS option if the user has registered a mobile phone # ? Seems sensible to me.

[flavour]

@devinbalkind

What exactly do they get notified about if they set that? This is Group-wide, so they get notified about:

• Any new Update matching the group_filter (i.e. shared directly or linked to Event/Incident which is Shared)
• Any modified Update matching the Group filter?
• Any new Task shared to the Group?
• Any modified Task shared to the Group?
• Any member changes?
• Any new Event/Incident shared to the Group?

If an Event/Incident is shared to the Group which already has Updates attached to it, should the user get all of these backlog Updates as notifications?

[devinbalkind]

Re: Fancy Filters

Should we have all of these checked by default & so the user can uncheck some if they wish to narrow?

Yes

Re: Notification Settings
Let's simplify. Top can be "Receive Email" checkbox. We can eliminate SMS option for now.
Frequency can be a radio so they only pick one.

Re:Notifications

Any new Update matching the group_filter (i.e. shared directly or linked to Event/Incident which is Shared)

Yes

Any modified Update matching the Group filter?

No

Any new Task shared to the Group?

Yes

Any modified Task shared to the Group?

Yes

Any member changes?

No

Any new Event/Incident shared to the Group?

Yes

If an Event/Incident is shared to the Group which already has Updates attached to it, should the user get all of these backlog Updates as notifications?

No just a link to the Event/Incident. They can click to learn more from there.

Is it easier for you to write these notifications or should I take a stab at it?

Thanks so much.

[flavour]

Is it easier for you to write these notifications or should I take a stab at it?

If you have some text you want to write then please do :)

[flavour]

Should we have all of these checked by default & so the user can uncheck some if they wish to narrow?

Actually that wouldn't work...it's right the way it is...all that is working now on the server, so ready to start tackling Notifications

[flavour]

@devinbalkind: The Notifications Settings UI is now all visible & working, so can be reviewed.
I am now going to work on the actual Notifications themselves, so if you wanted to feed in how you want them to look, now would be a good time.

[flavour]

Possibility I missed previously:

• Any new Task linked to Incident which is Shared?