3

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.

mockup

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.

mockup

download bmml source

  • Not directly related to your question, but consider only showing the delete button in edit mode. Providing an extra guard and interaction step to prevent slips. Assuming that it's always there when you edit (or create) a task, there's no problem it not being visible on the main screen - users should be able to recall that they have seen it before in edit mode. – Izhaki May 17 '14 at 22:58
  • @Izhaki Great tip! Thanks, I thought that would create discoverability issues, but if it's included the first time, then maybe it is not that bad. – Alpha May 18 '14 at 0:44
  • Yeah. Delete-within-edit does not really follow common thinking because the two operations are clearly distinct ones. But the delete-within-edit is such a popular pattern in so many applications (notably that's how apple do it on the iPhone), that even if users don't see the delete button in edit mode many of them will guess it right. On that note, when creating a new entity, I actually think that a button labelled 'delete' is better that one labelled 'cancel'. – Izhaki May 18 '14 at 1:18
  • And although I'm pretty much certain you already have this in mind, adding task times would allow you to perform critical path analysis, which would be a super-neat feature. – Izhaki May 18 '14 at 1:24
  • @Izhaki On its way ;) – Alpha May 18 '14 at 1:33
4

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?

  • I loved this answer for providing me the thought process necessary to make the right calls. Thanks! It was important that users see both the list and the graph, and details are not as important, so I started with the concept of left: list, right: graph (note: the graph requires some big real state). However, the edit view would have to eventually be somewhere, so I went with the right panel since it's where I could take some space without hiding too much, but this lead me to what I have. Where did I go wrong? – Alpha May 18 '14 at 0:53
  • (Sorry for the double comment) I've been rethinking on what you mentioned and maybe its not that important for users to see the table and the graph at the same time, as long as both provide the same functionality (even if it is in different ways). I'll play with that thought in mind. Thanks! – Alpha May 18 '14 at 0:59
  • 1
    I can only guess, but given the highlighted item on the list, which also shows as a highlighted circle on the graph, I'd argue that it is very important to see both. I can easily see myself explore the graph by clicking on the list, or by clicking on the circles on the graph to see the related task. Quite an amazing concept in my view, and a highly attractive one. – Izhaki May 18 '14 at 1:07

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.