RFC: Design of Admin Project Management Dashboard

[zspencer]

First pass at wireframes for the admin dashboard for project management. Simple approve/reject flow with a toast that says "Yo, you did this thing" and an Audit Log that tracks the history.

I decided to put the archive and public projects on separate pages from the pending projects, but I would be fine putting them all on the same page for now, or even doing a table. More important than the layout is the interaction model that asks for reasons from admins whenever they do a project management action.

Thoughts? @bhaibel @emdashbuck @jtu0 @atav1k @jalcine

[coveralls]

Coverage remained the same at 100.0% when pulling 4fdafef228eb7893577991e098c1b60d708917bc on zs-initial-design-of-admin-interface into 927781e13855f3eb5cd2bb9b6b6f4c30d05fa11d on primary.

[bhaibel]

I like the interaction model.

I find putting the projects in a grid hard to read. I think I would prefer it if we defined a project "block" that included the workflow buttons (like the one you have here, but more horizontal-y) and then had those repeat vertically.

I like the idea of putting pending and inactive projects on separate pages. I'm not convinced we need a separate admin area given that. I would like us not to reflexively include an admin area, in part because Rails projects often struggle with view code sharing questions when they take a persona-focused rather than a resource-focused approach to slicing up pages. I'd like to know more about why you think the benefits of a separate admin area for this project outweigh the costs.

I'm not 100% on putting designs in the repo proper instead of in stories, because I'm worried it will make them seem set in stone rather than throwaway artifacts -- what value do you think that practice gives us?

[zspencer]

re: Grid, yeah I think we'll want a table instead.

Re: Why an admin area: My basic thinking is threefold:

1. Administration and moderation are likely to be very important chunks as independently hosted community oriented nourish instances pop up. Moderators are going to have a very different set of motivations/interaction desires than supporters or creators, (for instance, table of projects vs cards of projects) and keeping those motivations/desires/actions separate will mean we don't have to code around them in the creator/supporter focused site (and vice versa).
2. By separating Admin stuff out, we have a pretty safe place for new contributors to make first commits, that is most likely to line up with their interests. I.e. Instance Host Frida wants a feature to bulk block IP addresses. If Frida wants, they can add the feature in without friction for maintaining creator/supporter focused usability and design guidelines.
3. Security. Every admin page inherits from an AdminController, so we can safeguard it all without additional work. This isn't to say we won't/can't/shouldn't add moderation-like links throughout the site (i.e. "Hide this comment" or "Disable this project" on the regular site for people with the permissions necessary to take those actions), but centralizing the Zone of Ultimate Power seems like a positive move.

Re: Designs in Repo - Unfortunately, github's Issues/Milestones is absolutely terrible for collaborating on design. We could do a shared dropbox or Google Drive or look into Invision or something, but I figured instead of adding the overhead of maintaining yet-another-file-repository we can store it in Git until it becomes cumbersome. In my experience, having design docs (and other documentation, such as contribution guidelines, etc) right next to the code actually improves changeability of the documentation, since it's under version control and right next to where people are doing the work. That experience may not be universal, and I'm happy to not include the current design work in the git repo especially as Real Designers ramp up and start doing that work instead of me.

[bhaibel]

Fair enough about designs in repo, let's just leave them there and see how this evolves.

I see what you're saying about having a separate admin area, and I agree with your goals for it, but I'm not convinced that it will get us there. Sorry to wall of text after a few days, I knew that what you were saying was logical but pinging me WRONGGGG and it took me a little while to figure out how to articulate it. Here are some places I don't quite agree with your assumptions:

1. Why would admins prefer tables where supporters would prefer a grid? Like, I see the underlying motivation there as a way of "getting more stuff in" in a readable fashion, but tables aren't magic; horizontal scanning of text is difficult for both supporters and moderators because horizontal scanning of text is difficult for humans generally. I think that adding moderation buttons as something that's a normal part of the project summary module that only admins/moderators see is likely to be a more usable design, maybe something like this, and will require fewer views to be maintained period.

2. I guess I'd rather use a component library to make it easy to add "pretty" features to the "normal" UI whether they're user-facing, moderator facing, or instance-owner facing? And I also think that we don't need to have a separate admin area to make the BlockedIPAddressesController (or, more to the point, the PendingProjectsController) admin-only, and can use human judgement to let it be ok for PRs against admin-only views be a little less "designed" than supporter-facing views.

3. I understand where you're coming from with the security argument, but IME as soon as you start adding "moderation links" to everyone-facing views you run into the security problems you're trying to avoid anyway, and trying to maintain an admin area AND moderation links encourages either human error (changing n - 1 places where security logic's maintained) or backflips in the service of DRYness. I think I'd rather we solve the moderation-links problem well and run with that strategy hard; that way we'll have a strong set of exemplars for new contributors to look at. I've had good success with exposing "available actions" a given user can take at a policy and/or presenter level (or, in one org, even at the model level -- I can see you wincing from DC, but it worked well for that culture). That way, the view and controller layers can loop over or do includes? on that action collection. It's concise, robust, and -- super importantly given this project's goals -- copypasta-friendly. This strategy tends to also push security policies further towards the business-logic layers of the application rather than the controller level, which has security benefits once we start surfacing APIs, doing anything interesting with async processing, etc.

Like, I'm not totally against having an admin-only area, but I do see it as a premature optimization right now and would rather we see how far we can get with controller proliferation & business-logic-level policies before we go the separate-admin-area route.

[zspencer]

I'm going to refresh this later today with the horizontal layout you provided, unless you want to do that. LMK if you decide to do so so we don't duplicate effort @bhaibel.

[bhaibel]

You can grab that, I certainly have enough things to do. Sorry I didn't submit it as an additional PR or whatever and make it easier for you -- I'm still getting used to Balsalmiq again

[bhaibel]

@zspencer do you want to refresh your wireframes or do you want to just close this out because all the ideas are contained in the PR?

[zspencer]

Let's leave it open until the flash and email stuff is taken care of, then just close it. No need to merge once the entire thing's been implemented.