accounts: Redesign! #17604
Replies: 2 comments 3 replies
-
Hi @garrett, I'm really liking the new Account page functionality in Cockpit 282. Regarding the three colors that are shown for different groups, I don't see any where that we present information to the user regarding what the colors represent, which might limit the usefulness of the colors. Would it be possible to somehow communicate to the user what the colors represent? Perhaps a tool tip when hovering over the color or something like that? |
Beta Was this translation helpful? Give feedback.
-
Details pagesHere's what I have as a work-in-progress for details pages. AccountsEdit account would present a modal that's extremely similar to the "Create account" modal dialog that is basically the same, but with a different title "Edit account" and has all the values prefilled. The dropdown menu kebab would have all the not extremely common settings, such as "Set expirations", View user processes", "Log user out", "Lock account", and "Delete account". Basically the same as the account menu above, but without "View user details" and "Edit user" as you're viewing the details at the moment and "Edit user" is a button. GroupsThis has a checkbox right now... but a first pass wouldn't have that. When selected, it would allow a bulk remove. That's not mocked up yet. The kebab would have "Remove user from group". The add user to group action would pop up a modal dialog that has a UI to add a user. Ideally, it would let you add multiple in one go. What I'm thinking of is something I don't have a mockup of yet, but it would basically be a modal with a filterable list of users. The list would have a checkbox in front of the user name, and it would also contain the display name too. |
Beta Was this translation helpful? Give feedback.
-
Accounts page redesign
Cockpit's Accounts page has been around since the start of Cockpit and we've wanted to extend it to better support groups and provide many additional features. The current iteration of the page wouldn't easily support some of these features without a bit of reworking.
Since this is a large project, not everything is done yet, but I wanted to share what I have mostly "finished" for the first iteration. (Everything can still change, of course.)
Taking inspiration from this past year's Cockpit-Podman redesign, which has some similar constraints (images related to containers is similar to groups compared to accounts, where the primary focuses are containers and users — both of which can get very long — but images and groups are still of secondary importance, but shouldn't get in the way), I've used similar patterns when redesigning the Accounts page.
Main accounts page
Groups: Collapsed
I've switched the display of accounts from cards to a list, so we can show more information about each account (notably the last active and assicated groups) as well as make it easier to filter and sort the list.
By default, groups would be collapsed with a preview of the most important ones and a count of how many users are in each. Important groups would be administrator (sometimes called "wheel" on some distributions) and groups with several users. The sorting order would be: Admin access, then groups with users. Groups without users would not be shown when collapsed.
Groups: Expanded
By default, groups is collapsed to preserve space, as the primary use of the page is to view and edit accounts.
When the Groups section is expanded all groups are shown and each group has more information than the "label" chip (when in collapsed mode). Groups have the same color with a blip as they do in the collapsed mode "labels". I've purposefully picked only a few colors, for easier distinction between types of groups:
Each group would have the label color, the group name (in some cases, such as "wheel", a more friendly name would be shown first), the group ID, the number of users in the group, and the accounts. Having the # of users in the group allows for it to be easily sorted. Even in sorts, admin groups would be shown first, then groups with users, and finally groups without users. A secondary sorting would be alphabetical.
By default, it would sort alphabetical, but with admin groups first.
Accounts & groups menus
Accounts can have a menu with related actions on the list itself. Some of these would be implemented on the first pass of the implementation, and others might (or might not) come shortly after.
Process section of the menu:
Destructive section of the menu:
The groups menu is pretty simple: Edit and delete.
Create account
The create account dialog gets an overhaul as well.
Create account: Collapsed (default)
By default, we're not adding anything new versus what we already have, except for extending the groups section to support all groups (instead of selected ones). It would use an autocomplete selector and add groups as "label" components. Additionally, we'd ad an expand disclosure link.
The home (based on the username), shell, and ID will be set to default values when this is collapsed. Many users don't care and are happy enough with the defaults.
Create account: Expanded
When expanded, the default values will be prefilled, making them editable.
After a user is created with the customization section expanded, this will be remembered in localstorage, so the next time around (using the same browser), the last expanded state will be re-used. This is because someone who cares about setting custom values once will probably care about it later too.
Coming soon
Not all of the design is finished. I wanted to share what I could earlier than later. We're going to iterate, so the implementation may change in areas.
Account details page
Account details will mainly be the same, but with the groups being overhauled, to match the create account dialog.
If we do have user-specific process listing (as talked about above, on the user list's user menu), we'll want to add something here, either inline (similar to the metrics page, filtered to a specific user) or a link to a user-specific subpage with that information.
Group details page
New to the redesign would be a group details page. It would be pretty basic, with a way to rename the group and a way to manage members of the group.
It would likely use a widget that would show current users and allow someone to add more. The users should mainly be identified by the user name, but it should also show the full name of the user too.
Perhaps we'd use a dual list selector, although it doesn't support showing details and it prioritizes the unselected items before the selected ones... so it might not be the best fit for our use.
Conclusion
What do you think? We will to adjust this based on feedback and during development.
Beta Was this translation helpful? Give feedback.
All reactions