+972 52-548-6969
The right UI metaphor
After some discussion about whatever a tree is the correct UI to show the use for my permissions issue, I decided to see if there is another way to handle that.
This is not the way the UI looks like, obviously, but it should give you an indication about how it works. Gray check mark means that something below this level is checked, a check mark means that it has permission on this node. Note that I can have permission on a node, and permission on sub nodes, and it has different meanings. If I have a permission on a node I have cascading permission to all its children, but a child may be associated with multiply parents (and not always at the same level of the tree, sigh).
In this case, we have Baron that has permission to schedule work for the Tel Aviv's help desk stuff. He also has permissions to schedule work to John & Barbara, no matter in what capacity.
It other words, even thought Baron can assign work to Jet, he can only do so when Jet works for the Tel Aviv Help Desk, he cannot assign Jet to work in the Pesky Programmers role. He can do that to John & Barbara (assuming he has the rights to do assign work on the Pesky Programmers department, of course, which is another tree.
The idea is that you can assign detailed permissions to any parts of the tree that you are interested in. There is another screen that allows you to find the hierarchy of objects if you are really interested (not shown here).
Naturally, permissions are many to many, the tree is many to many and I have a headache just try to figure it out. Just to point out, this is done on a web application, and the complexity is that the real tree has about two thousands entries at the lowest level (and ~7 at the top most level), so you need to get data lazily from the server, but, you also need to display the grayed check box, so the user will know that a child node is marked, that was the main difficulty, actually.
So, I am open for ideas about how to design this better.
Comments
Well...
Since the permission tree is not really a tree but rather a dag (because objects can appear under multiple parents, and I'm just guessing there can be no cycles, but that sounds right), the tree metaphor is a bit tricky. It is not immediately apparent that Baron has permissions to assign stuff to John and Barbara wherever they are, since in the tree they're shown under HelpDesk and Night Shift. I know there are tri-states, but a naive user might not understand that.
In this case I'd propose something more akin to windows' own permission handling: you start with a blank sheet of permissions, and you add objects to it (you can add them from a tree/dag view or via a search, it doesn't matter). The end result is that you see a FLAT list of objects to which you have permissions, using their "true name" instead of their tree hierarchy (I'm presuming each object has a "true name" that identifies it regardless of its parents, for example "John Smith" or "Tel Aviv HelpDesk". That doesn't have to be the same as the display name; for example the display name of "Tel Aviv's HelpDesk" is simply "Help Desk", which is how it is shown in the tree under Tel Aviv".
For example, your own example would look like this:
Grant permissions to [Schedule Work] to [Baron]
to:
Tel Aviv HelpDesk (IT->Tel Aviv->Help Desk)
John Smith
Barbara Mars
[Add to list...] [Remove]
This way the permissions are evident: Baron has permission to anything in the Tel Aviv HelpDesk, and to John and Barbara wherever they are.
This can work if the object's "true name" is a better representative of it than its hierarchy, so one can understand what an object is simply from looking at its true name (for example, a true name approach won't work if it's a GUID or a SID). If your objects are identified by their position in the tree, BUT they can have multiple parents, you have an entity problem.
It seems to me like some of your entities are position-based (like Tel Aviv's HelpDesk which has a single parent - Tel Aviv, which identifies it) and others are not (like people who can have multiple "parents"). In that case maybe it's wiser to separate the two, and show tree paths or a tree view for position-based entities and true names for "roaming" entities.
Huh?
To test the "child or grandchild checked" part (for the greyed checkbox on a parent node), something like a Modified Preorder Tree Traversal structure might be your best bet. That would allow you to fetch a subtree (or in this case, just the "checked" status of a node in a subtree) efficiently in one sql statement. There's a fairly decent article on it here:
http://www.sitepoint.com/article/hierarchical-data-database/2
If you have already solved the greyed-checkbox part of the problem in another way, though, I'd love to hear how you accomplished that.
Avish has some very good points here. Your data isn't strictly hierarchical so using a tree is going to be awkward.
Moreover, your permission rules are actually much more set-like. You are granting permission to Baron to have authority over some set, however that set is defined. Here it sounds like you have sets defined across at least two different hierarchies: one of people and one of places. There's no way to combine these things into one nice-looking tree without producing some wacky and confusing combinatorial explosion.
Using a tree will also prevent you from ever defining "DENY" type rules.
So I'm with Avish on this. Use a list of objects and of object aggregates (like user groups and such). You can resolve Avish's "true name" issue by ensuring that each of your objects has some intelligible canonical name including its relationship to other objects of its natural type. The names can be enriched with additional properties to make them clearer. So "Tel Aviv" becomes "Office: Tel Aviv" and "HelpDesk" becomes "Department: HelpDesk in Tel Aviv" and "Barbara" becomes "Employee: Barbara (currently working in Help Desk in Tel Aviv)". Making names unambiguous is strictly a presentation issue (assuming you already have stable identifiers) and there are many creative ways of accomplishing it.
I would do this using an explorer view
On the right you'd have a tree view of the Where (Tel-Aviv, Help desk etc.)
When you select a node you get a grid where you can see the people that have permissions
and columns for each of the permissions they have (assign work, manage whatever)
This view should visually separate people who have been specifically assigned at this node, inherited permissions (to allow overrides) and overrides - this can be done with Icons, colors, sections or a combination of those.
Also from a permission management point of view if might be easier to define profiles and roles and then assign people to them rather then the way it is depicted here - people change all the time but profiles and roles are more stable - but, that's a much deeper issue of course.
It sounds like you are looking for a "multi-axial tree" data structure. I've worked with similar sized and hierarchies (multiple parents per child). Other than using a 3D view that let's you navigate around (with WPF or Java applets you can do this) you can see examples that others have done for dictionary management if you download the sample MedDRA browser here: http://www.meddramsso.com/MSSOWeb/meddra/browser.htm, but we never liked that. Instead we ended up breaking the tree up. When you select a child, the possible parents are listed above in a combo box, there is a "primary" parent in our dataset, so that made it easier, then the user would switch axis by changing parent. For our dataset, there was always an initial search that would find a child node to start, then build the hierarchy down in the normal tree structure, and have the parents listed above as mentioned.
HTH
Avish is doing it the "right" way. To developer a tree makes sense, we "see" the data like that. But even for me as a developer its hard to get what you are trying to do. I had to read Avish commen to fully get it :)
Using trees are usually a bad idea for most big data structures, I only recomend it for file structures (and thats because most user are finally used to that) and very light structures, no more the 2-3 in depth. For bigger structures you have to devide it in smaller chunks that makes sense to the average user.
Don't get me wrong, I have been through the tree creation myself and for us it usually do work. But seeing users scratch their head and give up, change your views.
Comment preview