Problem/Motivation
Currently there are usecases where we list system/build-in elements(say configuration entity) and custom elements on a single page. For example
User roles page has build-in roles anonymous & authenticated and any custom role(s) added by user.
Proposed resolution
As @webchick proposed at #2119903-25: Show locked date formats in the UI, we can follow what we got in views UI or something similar. Here is a typical outcome:
Current roles UI:
proposed roles UI:
Current date format UI:
proposed date format UI:
Remaining tasks
Discuss the design
User interface changes
Yes, it will change few pages with the scenarios mentioned above.
API changes
N/A
Comment | File | Size | Author |
---|---|---|---|
#10 | Roles D8.png | 20.81 KB | alexrayu |
#10 | 2280055-unify-locked-unlocked-user-roles-10.patch | 3.12 KB | alexrayu |
#6 | roles.png | 38 KB | alexrayu |
#6 | 2280055-group-roles-by-origin-6.patch | 2.05 KB | alexrayu |
#5 | icn-lock-9x12.png | 1.04 KB | alexrayu |
Comments
Comment #1
vijaycs85Comment #2
alexrayu CreditAttribution: alexrayu commentedSome ideas. "Locked" may be misleading, sounding as if these permissions can;t be changed. maybe, 'system' VS 'custom'?
I must admit, I am not happy with any of the 3 options below. but maybe we can use them as a start for making this really UX friendly.
Comment #3
vijaycs85Seems like I didn't explain the page proper. here is another try...
Comment #4
alexrayu CreditAttribution: alexrayu commentedThanks for clarifying vijaycs85. Probably, the approach needs to be at least two-fold:
Given we want to call them 'locked'. When I first saw the 'locked' user roles, I thought I was going mad trying to understand, what had I done to 'lock' them and how to unlock :D Would it make sense to call them 'system' vs 'custom'? I think 'locked' and 'unlocked' is also fine, if we indicate it well. This is where those designs I posted come it. We can do it with text, with color, with icon (opening a small explanation popup), a combination of these.
Comment #5
alexrayu CreditAttribution: alexrayu commentedComment #6
alexrayu CreditAttribution: alexrayu commentedVijay, Please see this patch for the Roles list. Don't look at the style yet - its very rough. Just want to see if I understood you correctly.
There are a few things that are concerning here, especially the element wights.
Comment #7
vijaycs85thanks for the patch @alexrayu. it looks great.
yeah, I was wondering why we need weight for roles. we can check with @moshe_work or @davidstrauss (user module maintainers) if there a use case. otherwise, we can get ride of them. for this patch point of view what we have in screenshot looks good.
However, we need to unify this UI approach for other pages as well. Not sure if this something we can easily get done by views?
Comment #9
alexrayu CreditAttribution: alexrayu commentedThe tests are failing because they will need to be changed if they are to go along this patch. However, I never really intended this patch for review. I don't really like what it does. The weights are ending up in different tables, which is plain wrong. I included this patch to start a conversation on what needs to be done and how.
Comment #10
alexrayu CreditAttribution: alexrayu commentedOk, here's a simple patch that does it without messing the row weights.
Comment #12
Bojhan CreditAttribution: Bojhan commentedSo I am not really sure about this, we are trying to resolve a problem that is very widespread and solved in multiple ways. And the interesting part is that it rarely comes up in any user testing we have done so far. So I am not even sure if it is a significant problem for users.
I'd be keen on taking a step back and looking at all of the parts this touches and actually validate whether the solution works. If we do it wrong, we might end up making loads of interfaces hard to understand. The whole two table approach is far from ideal.
Comment #13
alexrayu CreditAttribution: alexrayu commented@Bojhan: From what I understood, our ideas, including two tables, will need to rest until better times, if what we need to do is to bring interface to accord with #2119903: Show locked date formats in the UI. In that case, we have a single table, but have (locked) text appended to the labels of locked elements.