I am trying to design an interface to do two things:
- Create Items and Objects
- Create links between Items and Objects (in a many-to-many association)
An Item is a simple attribute that must be applied to at least one (and possibly all) Objects.
An Object is an auto-numbered container that contains at least one item. Objects are split up into auto-numbered sub-objects in a nested association.
I have designed a form similar to the mockup below to allow for creation of Items and Objects side-by-side:
download bmml source – Wireframes created with Balsamiq Mockups
This form works quite smoothly for the particular use-case of my application. Where I run into difficulties is in editing associations between Items and Objects.
My feeling is that it should be possible to edit the association while staying on this screen. I would imagine that it would run something like this:
- User clicks an Item.
- Text to the effect of "Add Item Name to Objects ->" appears under the item
- The other Items fade and clicking them is disabled
- The "Add Object" buttons are disabled
- Each Object link is replaced with a checkbox
- The user clicks a "done" button placed... maybe next to the edited Item
This would work vice-versa when clicking on an Object.
This seems like it would work nicely because it is taking advantage of the fact that all of the entities needed already exist on the screen. Also it is nice for the user to have an overview of all Items and Objects (particularly for my application's use-case).
However, I am worried that by adding an extra mode into an already complicated form it will confuse users.
Do you have any suggestions for preventing the mode-shift from becoming confusing?
Alternatively, can you think of strong arguments for extracting this mode out into a separate "edit association" screen or dialog for the selected Item/Object?
Answer
As I said in my comment, you should add some more information to make it a clearer.
As a general concept, many-to-many relationships bumps into some problems.
It is technically solved by adding a mediator object (or a junction table/cross-reference table/join table), and this might be an approach to find suitable solutions. Take a look at this example from http://sourcemaking.com/design_patterns/mediator:
The main problem here is that the mediator thing is usually an abstract thing. Not easy to name it and not easy to describe it. But it's there.
Sometimes it's a real world item, like if you have a bunch of products and a bunch of customers - you'd like them to be connected in a list of orders.
But what if you have a lot of books and a lot of readers. How should you name this connection? The answer isn't clear. If your a library, you could name it "loans" (please correct my English if this is not the correct term). If your Amazon, you can name it "sales". But if you're maintaining a "books I've read" list for your local book club, then I'm not sure...
You should spend some time figuring this out. Really! That is important to the users of the product (and it is an important aspect of the maintainability of your product. Use proper names in your code and in your database).
So... A proper advise really depends on what your items really are and the relationship between them and the task the user is performing when creating and connecting them.
Sorry that this turned out to be a long comment instead of an answer ;-)
No comments:
Post a Comment