I have a system with four objects in it. They are projects, documents, tasks, and people.

A project has children and they are tasks, documents and people which in turn are siblings.

But the problem arises because some use cases mean that sometimes tasks become children of documents. Imagine a big floor plan where there are multiple broken pipes and each broken pipe is a different task.

I have a wireframe that deals with the first use case easily enough ie when tasks, docs, and people are all children of the project and it looks like this:

enter image description here

But how do I adapt my interface so that when use cases dictate that tasks are children of a document it doesn't mess everything up. I'm thinking breaking the implied relationship of the top navigation would be a good start....

  • Does each document have its own view? If so, I can imagine a list of its related tasks appearing on that page. – Matt Obee Sep 22 '14 at 15:33
  • 1
    there will be a listing page with all the documents of that project and then a detail view where the document is listed along with related attributes (such as tasks). So, I see what you're getting at and I agree. Maybe its a terminology thing eg say 'tasks associated with this document' so you still imply the heirarchy – colmcq Sep 22 '14 at 15:36
  • Yes, that sounds perfectly reasonable. If it were me I'd show related documents when looking at a task and related tasks when looking at a document. – Matt Obee Sep 22 '14 at 15:38

The comments suggest excellent ways to approach this. In terms of real-world commercial and open-source products, Atlassian's Jira product resolves this problem by giving relationships names (in Jira each direction of the relationship can have a separate name), and graph databases like Neo4j approach this problem even down at the data layer. In your case the UX can model the precise relationships you described.

A project's UX can literally list items with the "child" relationship:

  • tasks, documents, people

A document can list items with the "child" relationship:

  • tasks

...as well as items with the "sibling" relationship:

  • tasks, documents, people

...and of course the "parent" relationship:

  • project


An example document could be depicted as:

Document D1


  • Task T1

  • Task T2


  • Document D2

  • Person P1

  • Person P2


  • Project Proj1

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.