Improve design for master-detail interface

Question

0.00/5 (No votes)

See more:

INTRODUCTION AND RELEVANT INFORMATION

I am programming application that writes data about contracts into database. It is similar to banking software.

Contract is very complex data, so let me describe its structure:

It has basic info that is represented with a set of basic controls ( button, checkbox, textbox etc ).

Contract may or may not have additional complex data that describes it, in view of an annex.
Contract may or may not have additional complex data that describes it, in view of a special report.

Annex and Report have exactly the same characteristics like the original contract. They have same buttons, textboxes and so on. The only difference between Contract and these two is the fact that Contract has 2 extra textboxes, and of course, that Annex and Report are part of a Contract.

After asking for help here previously, and researching online I have decided to use master-detail interface to preserve space. That way user can both add new data or edit/delete/search/print/etc existing one.

MY EFFORTS TO SOLVE THIS

In order to present such enormous amount of data I have decided to use tab control. This solution halved the amount of occupied space.

For displaying existing data, I have decided to use treeview control because of following :
- It can present contract as a root node.
- If contract has anexes or/and reports, they can be shown as child nodes.

Here[^] is the sketch of tab control when user enters contract/annex/report.

Second tab has same controls for Contract/Annex/Report. First tab has extra 2 controls for Contract, but is the same for both Annex and Report. In the mockup I have shown first tab for Contract in order to provide point of reference for the readers of this post.

Here are the sketches of treeview for following cases:
- Contract has no annexes or reports[^]
- Contract has 2 annexes[^]
- Contract has 2 reports[^]
- Contract has annexes and reports[^]

Here[^] is the sketch of what I have "figured out" so far.

MECHANICS FOR ENTERING NEW / EDITING EXISTING DATA:

As said before, treeview represents existing data in database.

If user wants to edit contract/annex/report, he checks desired node and presss < button. This loads selected node into tab control. When finished with editing, user saves edits by pressing > button and changes are saved.

If user wants to add new annex/report to the contract, he can do so by loading existing contract into tab control ( by pressing < button ) and then pressing New Annex or New Report button ( these buttons will become enabled as soon as contract gets loaded into tab control ). Once finished with entering data for annex/report user must press save button in order to add the new entry.

New contract is added by pressing New Contract button -> tab control gets reset and cleared. Once user finishes entering data he must press save button to add the contract into database. Contract will be shown in treeview control.

User can abort editing/new entry by pressing cancel button.

If user wants to delete/print contract/annex/report, it can be done by checking desired node and pressing corresponding button.

As for search option, pressing that button will launch a dialog box where user will configure search criteria. Treeview will be repopulated with search results.

PROBLEMS

I believe my general idea is good -> use tab control for entering data, and treeview for showing existing entries. I am also satisfied with the solution for editing contract/annex/report via < and > buttons. Printing, deleting and search functions are also properly implemented in my opinion.

However, adding new entry - be that contract/annex/report - is inefficient in my opinion. The same goes for the case when user loads existing contract into tab control and tries to add new annex/report.

I believe my design is very "clumsy" and inefficient, which is the result of my inexperience.

QUESTIONS

- How can I improve "mechanics" for adding new annex/report to the new/existing contract?

- Is there a better way to implement entering of new contract, than adding special button to it ( maybe I could add special tab in the tab cont, like + for this purpose)?

- If you have better solution for implementing this type of master-detail interface I will consider it as well.

If further info is required leave a comment and I will update my post with relevant information.

Posted 30-Dec-14 12:30pm

AlwaysLearningNewStuff

Add a Solution

1 solution

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2014-12-30T17:13:00

Solution 1

I would advise to consider an alternative design: each contract is represented by a separate tree view. All annexes and reports, and other "drill-down" views are represented by some child nodes of the view. If you select the "detail" node, you have to use some are (panel) on the right of the tree view (in Western culture, the tree view is shown on left, and the detail related to each node are on right; in right-to-left writing cultures, it could be the opposite).

Then you decides which part information could be on a tree node (apparently, very little of information) and which part is on the right panel. Ultimately, you can drill-down to the finest level of detail.

This design solves a number of your problems at the same time. First, there are no "options", just presence or absence of some tree nodes. Also, the view on the right panel could be polymorphic. It could be different view depending on the type of the data object stored in the tree node.

—SA

Posted 30-Dec-14 17:13pm

Sergey Alexandrovich Kryukov

Comments

AlwaysLearningNewStuff 31-Dec-14 11:53am

Thank you for answering. I have a little doubt if I understood you correct.

What you suggest is to move treeview to the left ( I agree with you on this one ) and use it to represent one contract with its annexes/reports if they exist. Then user could click on the contract/annex/report node and load it into tab control for editing. Tab control would be adjusted according to the selected node ( polymorphism, as you said ). I agree with this approach as well.

My follow up questions are these:

How would I present the list of existing contracts to the user, so he can choose one?
Should I use combobox, and if yes, where should I put it?

What about adding new contract, where should I put that button ( or any other control you would suggest )?

How should user add new annex/report to the existing/new contract?

To sum it up, my problem is generally based on layout design.

I hope this makes sense to you. If I need to further clarify please leave a comment.

In case we don't "speak" soon, I wish you happy New Year and marry Christmas ( I assume you are Orthodox Christian ).

Best regards Mr.Kryukov.

Sergey Alexandrovich Kryukov 31-Dec-14 13:47pm

The list of existing contracts was outside of out discussion. I perceived your problem as the problem of showing just one contract. I did not know what a single window represent; it could be just one contract. But if this is a set of contract, it depends on your design. The list of contracts is in the same relational to the context I just described, as the relational between the tree and right panel: master-detail.

It's just that your contract list could be something more complex than the list: you might need to perform the query to get the subset of contract (time range, keyword, tags, and so on), the query results could be shown in some control, and when you select a contract, the tree view is fully repopulated, and so on, as I explained above.

Here, there can be option. This subset of contract can be represented in different controls. It could be list view, etc. but, especially if you really have the query, this list could be simply the top level of your tree nodes of the same tree. Each top-level node could represent a single contract, and all deeper nodes — all I described above.

Happy New Year, best wishes!

—SA

AlwaysLearningNewStuff 31-Dec-14 16:05pm

I did not know what a single window represent; I apologize for confusion.

I just wanted to show existing contracts into treeview, the same way you advised me to do for single one. I must be able to somehow edit those existing data. That would be the role of the buttons in the middle of the window.

That seems to be my problem -> to organize buttons for new contract and other stuff into coherent group.

When you get the time and if you want, you could carefully read my post again and try to help.

As always I will try to handle this on my own.

Best regards.

Sergey Alexandrovich Kryukov 31-Dec-14 16:18pm

Nothing to apologize about. I think I describe the choice when you represent the set of contracts in the same tree view. What's wrong with that?
—SA

AlwaysLearningNewStuff 31-Dec-14 16:51pm

I just don't understand fully what you said.

I will try to formulate a meaningful question after giving your comment thorough thought...

Sergey Alexandrovich Kryukov 31-Dec-14 18:23pm

I'll gladly clarify or confirm things if you tell me what where your concerns are.
—SA

AlwaysLearningNewStuff 31-Dec-14 18:48pm

Mr.Kryukov, look at the answer on the link below, it is almost what I need:

http://ux.stackexchange.com/questions/70312/improve-design-for-master-detail-interface

With a few tweaks here and there, and adding DELETE option answer omitted, I think it could be great solution to my problem. Also, image is worth 1000 words, so that sketch can help you realize where my confusion lies.

Best regards and thank you sincerely for your readiness to wholeheartedly help.

Sergey Alexandrovich Kryukov 31-Dec-14 18:57pm

Well, looks not bad. I would say that your own idea of having Annex #1 and Annex #2 (and everything like that, report #1 and #2, and so on) checked or unchecked redundant. What will you do it, by some reason, later you would need to introduce Annex #3? So, instead, you should make it possible to add some number of annex nodes, as well as other extendable nodes. You can always limit it to 2 nodes now and change it later.
—SA

AlwaysLearningNewStuff 31-Dec-14 19:13pm

What will you do it, by some reason, later you would need to introduce Annex #3?

Well, that is what New Annex and other corresponding buttons are for -> they add annex #3/report #3 to the contract.

Checkboxes were "solution" for a problem answerer pointed out in his post.

I hope I understood you well ( no offense, but your English is little confusing in that last comment ).

Anyway, the answerer on that site transformed your advice into image. I see no reason not to oficialy accept your answer, just give me time to deal with that missing DELETE option he forgot to add.

Best regards!

AlwaysLearningNewStuff 31-Dec-14 20:19pm

I think everything will work out fine with the design from that site. As said before, he transformed your words into image. I have officially accepted your answer and voted 5.

If you have any suggestions for improvement please feel free to point them out.

Best regards.

Sergey Alexandrovich Kryukov 31-Dec-14 21:00pm

Great. I thought you can see the bigger picture better, just because this is your project, and glad to hear about it.
Happy New Year!
—SA

Improve design for master-detail interface

1 solution

Solution 1

Add your solution here

Preview 0

Improve design for master-detail interface

1 solution

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us