consolidate tabs and filters in groups directory

[JonathanReeve]

Remove all filters, and replace them with these tabs:

Logged out:

Forums | Committees | Members' Groups 

Logged in:

My Groups | Forums | Committees | Members' Groups 

"Forums" will be divisions and discussion groups. "Committees" will be committees, and "Members' Groups" will be everything else.

A related task will be to consolidate and rename divisions and discussion groups to "forums."

We will lose some functionality with this:

1. The ability (mostly for group admins and super-admins) to easily find hidden groups.
2. The ability to find the groups with the most members, by sorting by "most members"
3. The ability to find the newest groups
4. The ability to sort groups alphabetically

But I don't think the loss of (1) is too bad--group admins can find their groups in their "My Groups" tab. The loss of (2) isn't too bad, either, since actual membership size isn't effectively that important, compared to a group's activity. (3) can be solved by featuring new groups in a kind of carousel, and (4) isn't necessary, in my opinion.

We should probably keep this as an MLA-only modification, and not package it for upstream.

[JonathanReeve]

I mocked up what this might look like, with a centered primary/secondary tab nav:

[JonathanReeve]

I think this restructuring will require these sub-tasks:

1. [x] Point each tab to a new URL, e.g. /groups/my-groups/, /groups/forums/, /groups/committees/, /groups/members-groups/
2. [ ] Hook AJAX calls to click events on these tabs, so that clicking a tab filters the group directory appropriately.
3. [ ] Handle the above URLs, so that navigating to /groups/forums, for instance, will load the group directory and filter appropriately

Alternatively, I could just listen to GET requests on the group directory, and change the URLs to something like /groups?filter=forums. This would be easier, but less pretty.

[chriszarate]

I think we have to go with easier but less-pretty URLs. For one, the hierarchy of /groups/[facet-name]/ conflicts with BP's hierarchy (/groups/[group-name]/) and could lead to trouble—perhaps not with these URLs, but in future facets.

[JonathanReeve]

Oh, right. There is an "illegal group names" function somewhere, I think, that rejects certain reserved group names, but even with that, it's probably better not to interfere with this hierarchy. I'll just do the GET queries, then. I'll break this one out into the two sub-tasks.