I have four lists, they are claims, deviations, tasks and costs

  • A claim can have deviations and tasks as children
  • A deviation can be, but does not have to be, a child of a claim
  • A deviation can have tasks and costs as children
  • Tasks and costs can not have children

So a possible scenario could be:

Claim 1
 - Deviation 1.1
  - Task 1.1.1
  - Task 1.1.2
  - Cost 1.1.1
 - Deviation 1.2
  - Task 1.2.1
  - Cost 1.2.1
  - Cost 1.2.2
 - Task 1.1
 - Task 1.22

Deviation 1
 - Task 1.1
 - Cost 1.1

Keep in mind that I can not display my data in a tree view like this, for two reasons

  • There are no 'folder' type items, they are all objects with different attributes
  • I want to give the user as much information as possible without too much clicking

At the moment I am using two grids, one grid to display all claims, the other grid to display all deviations

Example claim/Deviation grid

Title           | Description    | Created by    | Department   | Customer    | product   | Order number   | Status
example claim..  lorem ipsum d..  John Doe        Economics      local fact..  0582B       012345678        In progress
another claim..  lorem ipsum d..  Jane Doe        Quality Depa.. local fact..  0722F       011234678        Done
last test clai.  lorem ipsum d..  Bond, James..   IT-Departmen.. local fact..  0222B       011253438        Declined

So I have two of these, they do not share the same attributes, except for title, created by and status, so I can't have claims and deviations in the same grid. The deviation grid is positioned below the claims grid, since claims will be more in focus.

Now to the complicated part, if I select an item in the claims grid, the deviations gird will be filtered, so that only children to the selected claim is shown.

After claim is selected, we can choose to open it to see additional information, this is where I display tasks for that claim.

The same goes for deviations, if we select and open one, we can see its tasks and costs.

So my problem is that I am having serious doubts about this, with two grids on the same page it feels like a lot of clutter, and I'm not sure that filtering the deviation grid after a claim is selected is the way to go, it feels too complicated.

Also, in order to see tasks and costs one has to open a second window, say a user is searching for a specific task, but can't remember what claim/deviation it was in..

Question, how can I display these four lists in an understandable way?

If none of this makes sense, I will try to elaborate

1 Answer 1


I'd suggest showing the children of a claim and the children's children in a detail table (tree-like structure).

All the 'dangling' children (those without a parent) could be displayed in a secondary grid. The secondary grid could be displayed / hidden depending on an item that can be toggled (like a a checkbox). Again, this would make the first grid the user's primary focus as well as allowing the user to see any parent less children (ie. dangling elements).

Remember that filtering (or any other sort of functionality) should only be used on relevant fields and in an intuitive way.

I previously mentioned that some good actions to use in a grid for filtering purposes are these:

  • Filtering: Where you let a user write a textual input that filters the column of which the function exists in.
  • Grouping: Allows a user to group a grid depending on the header of which is dragged and dropped (direct manipulation preferably) into a field.
  • Sorting: Allows a user to click a header to sort the grid depending on the column's values (Ascending or Descending).

enter image description here

The reason I'd go on with a such approach is because I think it would be more user-friendly as it could be quite intimidating for a not-too-experienced user to be faced with two grids that have no apparent relation.

Here is an example of how to use a detail table. Keep in mind that I don't know what stack you are using, so it's just a proof of concept so that you get a visual representation of what I am suggesting. I'm sure that your stack has something similar you can use.


Just saw you have a requirement where you cannot use a tree-like structure (which basically a detailstable is). Why? Is it due to bad database-design? If so, could that be changed?

  • I was thinking about a tree structure where you only see the title of each object, then has to open it to see the rest of the information. A 'mater detail' grid could work, but my fear is that it's a lot of data, could get messy fast, but if I strip the grid to only the most relavant data, then maybe
    – sch
    Commented Oct 10, 2016 at 12:23
  • Well I doubt it would be less stressful for a user than having to see two grids that display different data. If I understand it correctly you are already showing ALL the data, but in two individual grids. This way you'd at least hide one grid worth of information in the primary grid's detailtable. OR you could have the ID (Title) set as a linkbutton of some sort to send the user to a different page with all the Id's details. That's probably less friendly than a detail table, but it would do the trick.
    – geostocker
    Commented Oct 10, 2016 at 12:26
  • The reason why I felt I had to use two grid is that not all deviations are a child of a claim, so if I have to expand claims to see deviations, some deviations will get lost (those without a parent).. maybe one grid, and a 'select' box somewhere, where the user selects what they want to work with claim/deviation, then have that to be a detailed grid
    – sch
    Commented Oct 10, 2016 at 12:31
  • 1
    Ah, missed that. Didn't see that you needed a way of displaying 'danging' children too. If that's the case then I'd suggest adding some checkbox or something the user can toggle to display / hide the second grid. It might also be advisory to get the data ONLY when the box has been checked.
    – geostocker
    Commented Oct 10, 2016 at 12:34
  • yeah, that makes sense, will look into some filtering possibilities
    – sch
    Commented Oct 10, 2016 at 12:38

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.