Master-master / detail approach? (a.k.a, how to approach summarized data)

Question

Great day to everyone.

I'm trying to design an application that is basically a to-do list, which of course provides some level of master-detail: a list of tasks and the detail for each task.

Now, the extra feature that this application will provide will be a graph that displays dependencies between all tasks. And here's the challenge: since this generated graph is useful as a master view of the general list, it should be displayed as well.

So, I have two sections: a master overview, a master list (with add / remove capabilities) and a detail view.

How can these be designed so that it flows a naturally usable way?

This is what I have so far, which is not close to something that makes real sense to me.

^{download bmml source – Wireframes created with Balsamiq Mockups}

What is the proper approach to this master-master-detail need? Or maybe there's no such thing as master-master-detail?

Update: After Izhaki's feedback I put together a second iteration where the upper panel is what actually gets displayed all the time: the list and the graph overview. The details panel gets hidden or shown if necessary to edit detail, so thanks to that it has become a more common master-details approach.

^{download bmml source}

Answer 1

It goes likes this.

First, distinguish between the data and its view. In the case of the task list, you have one set of data, and two views to display it - if the data changes, both views need updating.

Then, consider these three popular IA concepts (I'm using my favourite terms, but mention other terms as well):

• Unique component - a component (typically a page) that only appears once in the system. For example, a privacy policy page.
• Listing component (aka catalog, records, items, gallery) - a component that lists a collection of similar items. These typically involve a template and the entries are read from a database. For instance, a page on a site listing all men T-shirts.
• Record component (aka item, product) - a component that shows a single record out of many. Typically a template page which populate the data of a single database record (and possibly its associations). For example, a page on a site showing a particular T-shirt.

Now in your case, you have a single set of data (the tasks) which has two views (the list and the graph), both are a form of listing component. This is common - like a travel information app that shows nearby stations both in a list form, and in a map form.

Then you also have a record component (a task), which is viewed by the task details panel.

I think what is glaring about the current design, is that you have chosen to create the following visual hierarchy:

• Left pane
  • Tasks (list view).
• Right pane
  • Tasks (graph view).
  • Task details.

Where it seems highly reasonable to employ the following structure.

• Left pane
  • Tasks (list view).
  • Tasks (graph view).
• Right pane
  • Task details.

In other words, move the graph you to the right (where the list view is) to take advantage of gestalt law of proximity.

If it is important for users to see both views at the same time, you should split the left panel to top and bottom parts. If it isn't, you can put each in a tab.

Also consider how important for users it is to permanently see the task details panel. Possibly you can show extra details on a popover box upon hover, and only show the form itself upon double click?