The best way to show several related tables

Question

I have three or four connected tables, and I really wonder what's the best way to lay them out in a page?

One table is for Roles. Second table is for Users. Each role might have several users and user should be able to edit them. Also user might want to do it from users' table side, which means editing each user's roles. Each role has some permissions on some items! So the third table will be permissions. Users table and Roles table both can have their separate permissions, therefore it's useful to show effective permissions that one user will have from his or her own permissions, in addition to the roles that he or she is a member of.

Roles might be around 20, Users should be around 10 but it's very good to be able to show more, and finally permissions will have around 30 items.

I'm using Kendo UI and I'm able to show Tabs or Panels, or use Trees instead of tables, but I'm looking for cleanest way.

Answer 1

Welcome to the site, 67172!

There's one conventional pattern showing relations involving tables, which is usually called master-detail. This is restricted to a single list of items and details for the selected item (which might be a table again). Obviously, this is too simple for your case. You'll need to be creative yourself.

My first question is about the target users: 3 or 4 interacting tables on one screen is heavy lifting (both in terms of design as well as in terms of use). It will only work for professionals who are very aware of the objects and their relations - otherwise, they will not be able to interpret your design. Also, I'd do this only if they regularly use this UI, i.e., if they can build up expertise. If these two conditions are not met, I'd try to break the design down into simpler tasks, e.g. role definition, user-role association, permission assignment, etc. and create specialized, simpler UIs for each.

If you go for the complex design, the tricky part are the merged permssions, I think. My first idea is the following:

• The recurring pattern is that you have two sets of objects which are related: roles and users, roles and permissions, users and permissions.
• You could show each of these three associations using two tables for the two sets of objects, where a selection in one table highlights (not: selects) the associated entries in the other table.
• Each table must allow (single) selection of an entry as well as associating it with an entry selected elsewhere.

So you would have a table of roles linked with the users and with the role permissions table, a users table linked to the roles and the user permissions table, and two tables for role permissions and user permissions. Each table has a single-selection capability as well as a multi-association capability (e.g., a checkbox column).

If the user wants to see all users with a role, he selects a role (single selection in role table), and the associated role permissions as well as the associated users are highlighted (e.g., by checkboxes in these two other tables).

If the user wants to add a user to the role, he checks the association checkbox in the users table.

If the user wants to see all roles of a user, he selects the user, which will deselect the role, and set the association checkboxes in the roles list accordingly.

Some issues that need to be fixed with this idea:

• If a role is selected, a set of users are associated. There is no useful way to show which permissions are associated with these users. Similar if a user is selected: Many roles are associated, and role permissions cannot be shown.
• There are separate lists for role and user permissions. That does not fit the user model of permissions.
• If there are many items in any list, there's not enough room to show all the associated ones (because that means every selection rearranges them, creating confusion).

Other design approaches are

• A hierarchical table which lists associated items as descendants - this creates many double entries, and is tedious to interact with (expand/collapse).
• A graphical visualization - avoids double entries, because different paths can lead to the same item, but quickly get crowded for strongly connected networks.