I'm designing a settings GUI component which requires the user to select items from an assortment. These items have conflicts and dependencies between them, so selecting an item might restrict you from selecting another and/or is only available if another item is selected.
I'm displaying the items in a check list, but this isn't mandatory.
 Java project  C# project  C project  Object Oriented utilities  Java Enterprise Edition components (JEEc)  Server modules
With the following conditions:
C projectconflict with each other (only 0 or 1 of these can be selected).
Object Oriented utilitiesrequires
C# projectto be selected.
Java projectto be selected.
Server modulesconflicts with
C project(can be selected even if no
___ projectis selected).
Thoughts about the List component
The problem with using a list GUI component is that it's not clear what the relations are between the items. Here are my thoughts of what can be done:
- Gray out (and disable) any items which conflict when a selection is made. Ex.: selecting
C projectdisables everything else.
- Auto-select any required item if it's the only choice. Ex.: selecting
Combining points 1 and 2, selecting
JEEc will also disable
C# project and
C project. If there are multiple choices for a requirement then with some decent logic it's possible to disable anything which conflicts with all of them. Ex.: selecting
Object Oriented utilities will disable
However, this can be quite confusing. Selecting one item can suddenly gray out and select multiple other items out of nowhere. A description panel on the side can list conflicts and dependencies to alleviate some of the surprise.
Thoughts about the Tree component
I though about trying a tree component, something like this:
 Java project  Object Oriented utilities  Java Enterprise Edition components (JEEc)  C# project  Object Oriented utilities  C project  Server modules
The main problem is that not all conflicts can be shown. In the top level, only the first 3 conflict which each other, and the last one conflicts only with the 3rd. This structure also requires to duplicate items for requirements (
Object Oriented utilities appears under 2 items).
I think that while a tree is easier to work with visually, it fails to pass important information to the user.
In practice, the relations won't be too complicated, but it can be something like
(Requires 1 AND 2) OR (Requires 1 AND 3). The intended audience is programmers, so assume a fitting technical capability.
What would be a good UX design for this component?