I am trying to design an interface to do two things:

  1. Create Items and Objects
  2. 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:

  1. User clicks an Item.
  2. Text to the effect of "Add Item Name to Objects ->" appears under the item
  3. The other Items fade and clicking them is disabled
  4. The "Add Object" buttons are disabled
  5. Each Object link is replaced with a checkbox
  6. 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?

  • 1
    Could you elaborate what items and objects really are? It's a big difference between creating songs/playlist vs infants/parents vs tags/categories. Also, if you could describe the actual task and the context/workflow in which this screen appears. Modes are generally a bad thing, and it should definitely be avoided as a single step in a larger task. Commented Apr 18, 2012 at 7:51

1 Answer 1


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:

enter image description here enter image description here enter image description here

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.
enter image description here

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 ;-)

  • 1
    Can you point to an example of a UI actually implementing the editing of a mediator table/grid? Thanks
    – Dvir Adler
    Commented Dec 23, 2012 at 7:23
  • @DvirAdler: The thing is that the mediator table is usually irrelevant for the end user. In the library example, you would either "select a book" and have a look at the history of this book (all the borrowers), or you would "select a borrower" and have a look at the history of his loans (all the books). Showing the mediator mediator table would be like a "log of transactions" where you dump out a list of "events" - i.e. a table with "Date|Borrower|Book". I'll see of I can come up with any example of this. :-) Commented Dec 23, 2012 at 13:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.