We are working in web app where we have parent records that have multiple attributes that have many-to-one attribute values tied to them. We are attempting to list these parent records in a grid control and then want to be able to show the child records that are tied to these attributes that have these many to one attributes. Can anyone give some advice on how best to handle this and possibly point me to some examples?

Let me try to give an example here to better explain this. Let's you have a list of margarine products and the parent product is Imperial margarine which comes in different packages sizes and has more than one ingredient. So both the package sizes of the Imperial margarine and the ingredients within the margarine would be many to one - to the Imperial margarine parent. So if I wanted to display and store all the margarine products I sell in a hierarchy grid, the parent grid would contain all the different margarine brands (i.e Imperial, Country Crock, Blue Bonnet, etc.) with attributes related to the parent product (manufacturer, nutrition facts, etc) in that parent row. Then these many to one attributes like package size (with a list of it's attributes (package size details, retail price, inventory, etc), ingredients, etc need to somehow show in child rows. One way I was thinking of possibly doing this is if you clicked the parent you would see each of the many-to-one attributes as direct child's and then clicking on those nodes, would show their rows of records (i.e. package sizes of margarine).

Do people think that would work, any other ways people think this could be done?

  • 2
    Welcome to Stack.UX! Check out the faq and tour pages to learn more about getting the most out of this community. Your question is vague and hard to answer right now. Do you have an example of what you're thinking of implementing?
    – elemjay19
    Jun 1, 2013 at 4:32
  • 1
    Norabora, thanks for the welcome and comment. I added an example above to give some more detail on this. I hope that helps.
    – wilbev
    Jun 1, 2013 at 16:16

1 Answer 1


This sounds a programmer's approach to designing a UI. You've clearly thought very hard about your objects and their relations, mapping it out in your head in a kind of UML style. This is a good way for a programming team to work and communicate, because it lets you map out all the edge cases and suggests a good database schema. Unfortunately, it doesn't make for good UX.

To design a good UI, you have to think from the user's perspective. Start with who they are, what they want to do, and then start thinking about the interface. Only when you have that information can you start worrying about the layers behind the interface.

So in your example, the question is not what interface is good for these object relations? There's no answer to that kind of question. The question should be who are my users and what do they want to do? Are they middle aged women shopping for margarine on-line? Are they the product managers of a margarine conglomerate, maintaining their product database? Are they FDA inspectors, checking for mislabeled products? There are a thousand different use cases for this kind of database, and each requires a different approach.

To give some sense of an answer let me elaborate on these cases.

  • If you're catering to online shoppers, you want to let people browse and search. There's no need to focus that much on giving an overview of all products, focus on the product page. Think about information hierarchy: what's the information that all user's care about (price, name, availability) and what's the information that only some people care about (allergy info, ingredients, nutritional information). Design a visual hierarchy to match these priorities. Let people click from page to page, and focus on not overloading them with information in complicated diagrams.

  • Let's say your users are maintaining the company's official product catalog. Now we care about data integrity. The quality of the information is mof primary concern. The users will be faced with this application every day, so you can sacrifice some UI friendliness to make them more productive, and to remove any risk of data corruption. You need accountability, so all edits should be logged and tied to the user. The overview is important here, so users can see at a glance what information is missing.

  • Finally, let's say (for the sake of argument) that the FDA is checking all information provided by margarine manufacturers for anomalies. The data is there, and it's read-only. No need to worry about editing, and again, we can sacrifice friendliness. Ninety-nine percent of the records will be uninteresting, what we need is a clever way to filter through the information deluge. Give them the tools to hunt for the outliers.

So the take home message is that you don't start from your object model. In fact, if you have your object model before the UI, there's an issue with your process. You should have got to know your users a long time ago. Find out who they are and what they want. Map out these use cases and prototype an elegant UI. Once you have that, you can start the software engineering and modeling. And of course, test whatever you have, even if it's just a sketch in a notebook.

  • Thanks Peter, alot of good suggestions here. We definitely already know who the user base is and the object model is still adaptable to how we feel is best so we wanted to try to get the UI roughed up first. Your second use case is probably the closest to our scenario, only 2-4 people will be using this admin area of the application and basically just having a CRUD area to add and review these entities. Really our biggest dilemma is how to deal with with the multiple many-to-one's in a grid.
    – wilbev
    Jun 2, 2013 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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