Create system for displaying and hiding based on permissions

[AbhiAgarwal]

Depending on a person's role!

[grungerabbit]

How close are we to being able to configure these? @maxdumas

The intranet IA I worked on in June (and never showed anyone oops) is this: http://jsfiddle.net/grungerabbit/5wtwvqjm/4/

I've thought about this more too. I think if it's not massive overhead, we should design the landing page as if it were a phone homescreen. Make an interaction to allow people to drag and drop those "cards" along a grid, and reorder them to taste. My reasoning is - each person in our club does subtly different roles, even within the same initiative. Just to take infra as an example, Abhi needs to see API keys more than I do. I need to add projects more than Max. and so on.

I spent a long time trying to order these tasks for different roles. Now, after sitting on it, I think the best solution is to let each person configure it themselves. This has the added side effect of people having "ownership" of their Intranet.sexy... since we're building Intranet for the team. (Also, this structure would make this version of the landing page more resilient as peoples' roles change.)

Thoughts on technical overhead? I admit this sounds nice mainly because I don't have to build it. 😅

I know we have many other priorities. Just cutting down the number of cards, as outlined in the IA, would help a lot!

[grungerabbit]

ps Trello's starred boards section does what I'm describing extremely well. It also shows the 2nd strategy we could consider, which is simply alphabetizing the cards

[grungerabbit]

tldr; remove cards according to IA and person's roles -> alphabetize cards -> crazy homescreen drag and drop config time

[ethanresnick]

Until now, I've interpreted this issue as being about better reflecting what the user is strictly able to do, rather than personalizing/prioritizing based on what they might want to do. As part of this, we'd inevitably cover the first step of @grungerabbit's plan (i.e. removing a card from the home screen if the user doesn't have any permissions, as already enforced by the API, for that resource type). But I've also imagined this capability extending beyond the home screen/cards. For example, if the user can list presenters but doesn't have permission to delete one, the "Delete" button on the presenter screens should be hidden/disabled. Or, if the user can see API Keys but not create one, the "Add" button in that home screen card should be hidden/disabled, even if the card remains.

Basically, I was imagining was a series of mechanical changes, managed by some general angular service that views use to check for a permission before rendering a UI element. If there user has permission, the element is shown; if not, the template hides/disables it. This would be independent of/wouldn't yet go into any tech@nyu-specific logic about which roles should see what and in what order.

I think a more-mechanical system like I described above should be implemented as a starting point, which is consistent with @grungerabbit's plan's first step. I just wanted to spec out the above since the original issue didn't give much description, and we all may have been imagining different things.

About the other steps @grungerabbit proposed (e.g. drag and drop or role-based ordering)... I'm really not sure. Ordering the cards more intuitively—whether that's alphabetically and/or chunking them into smaller groups, or allowing user drag & drop—gives better UX than leaving them ordered in the quasi-random way they're ordered now. The question is just how much design + dev effort do we want to put into getting that improvement.

To answer that, it's worth taking into account that the current homepage's organization around resource-type-based cards is fundamentally flawed, imo, because it focuses too much on the database's perspective rather than the user's perspective.

For example, a marketing team member has a task like "create facebook events for those that don't have them". We should help that person by showing them on the homepage a list of just the events that need facebook events, with a one-click option on each event for copying that event's full body text to their clipboard, and a one field form for pasting in the facebook URL once it exists. That would be a good homepage UX...not making them use an "Events" card to list all events, then configure some filters to find those that need facebooking, then go to the long event edit form, copy all the text field-by-field to create the body while switching windows, etc. And I think there are analogous tasks for most people on the board, for which the design could really help the user do a specific task quickly rather than just presenting them with a database table browser.

The problem is that we don't know what these tasks are yet, and identifying/designing for them all would take an absurd amount of time and a lot of experimentation (as prior attempts have revealed). Therefore, we're gonna be stuck with the CRUD browser in some form, as suboptimal as it is, for a while. Presumably, what'll happen is that we'll gradually add custom-designed flows on the "hot paths" for particular user groups, as we identify + prioritize their specific tasks. But, even once some dedicated flows exist, we'll still need the CRUD for unanticipated/still undesigned tasks.

So, basically, we're talking about spending design + dev resources to marginally improve (through better ordering) a system (the cards) that's fundamentally broken—and yet is going to be with us for quite a while.

My hunch is that drag and drop would be too much work for the benefit. Maybe the client side would be relatively easy to handle (I have no idea—that's a @maxdumas question) but then there's the question of where to store the user's preferred ordering. I really don't want to put that data into the API, since it's so clearly intranet-specific. But that would mean we'd need a new database/API server just to send this intranet-specific data to the client. Ick.

I also trust Cheryl that a purely role-based approach might not be adequate, given the different roles people play within the same team, or stable enough as people change roles.

So, imo, that leaves the best option as alphabetical order + trying to chunk the cards into smaller groups. IIRC, we already spent some time trying to chunk them earlier. What ever happened with that?