Following is the data that needs to be displayed, to which the user can make changes or add new entries.

For capturing a contract, there is a set of documents that is maintained and for each document there can be one or more clauses that can be attached.

The current UI shows the documents listing in a grid and the clause listing in another grid below. On selecting a row in the documents grid for a document, the relevant clauses get listed in the grid for clauses.

The grid for Documents, captures/displays the basic details of the document like Name, applicable date, etc.

The grid for Clauses, captures/displays the code, description, follow-up action, etc.

What is the best pattern that is available to display and capture inputs as described in the many-to-many relationship above ?

  • What would be the primary point of entry? Would the users always search for the clause corresponding with a document? Or could they search the other way around. Not that you should provide all the options to the user. But a single point of entry makes things and decisions a lot easier... Commented Aug 29, 2012 at 12:01
  • Currently the point of entry is selecting the relevant document. This is done by selecting a row in the document grid. Once the user selects the row, the relevant clause details are fetched and displayed in the Clause detail grid. The user can then edit the Clause detail grid to add/remove/modify the clauses. To complete the answer, the user cannot search the other way around. It is always Select Document ID first for the user.
    – Pratik
    Commented Aug 29, 2012 at 12:46
  • 2
    Can you be a bit more specific about what you are missing? You've described the system fairly well so it doesn't seem like you have a problem.
    – Sam Hasler
    Commented Aug 29, 2012 at 14:34
  • @Sam Hasler - We do have a system in place. But we have observed that a lot of users struggle with this pattern initially. The cause and effect is not that evident, mainly because the Document Details grid displays the list of all the documents and on selecting a particular row, the clauses for that document are displayed. Wanted to know whether there are better patterns that have been used or can we have a column in the Document details grid, which has a button like "Show Clause", which renders the pattern more affordance.
    – Pratik
    Commented Aug 30, 2012 at 6:16
  • 1
    Can you provide a screenshot? Its hard to visualize text
    – Mervin
    Commented Sep 7, 2012 at 18:21

2 Answers 2


I would do the following:


download bmml source – Wireframes created with Balsamiq Mockups

Selecting a clause differs from selecting a document, since a clause could be viewed as an attribute of a document. Thus selecting a clause, marks all the documents where it's attached. This way we see which documents that should be sent to customers and act on it.

Selecting a document, you get a callout which shows the clauses attached to that specific document - since we're interested what we should do with that document and not all the clauses available.

This is what I can come up with with given information in the question.

Good luck

  • 1
    I like this idea, but I would have done it slightly differently. I'd have had it so selecting a document highlighted the clauses just the same way as selecting clauses highlights documents. The highlighting would then just mean "this is related", since what the relationship is is clear from the context. I would make the selection indication very distinct from the highlighting, but otherwise this is exactly what I would have suggested. Commented Oct 19, 2012 at 23:03

It seems to me it's not a many-to-many relationship, but rather, a one-to-many relationship with a so-called flyweight, that is, a clause can be "reused" for other documents as well.

You can try to do list inlays: instead of having two separate grids, you could pack them into each other. Nested grids, subgrids, these are their implementation names.

(In the jQuery example, go to Hierarchy -> Load subgrid data only once)

This would bring a clear hierarchy to the document-clause relationship. On the other hand, it makes it hard for you to perform bulk actions, like, "add this clause to all documents", but as you said, you only display the clauses of a given document, where this fits well.

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.