改进主 - 细节界面的设计 [英] Improve design for master-detail interface
问题描述
介绍和相关信息
我正在编写应用程序，将有关合同的数据写入数据库。它与银行软件类似。
合同是非常复杂的数据，所以让我描述一下它的结构：
它有基本信息，用一组基本控件（按钮，复选框，文本框等）表示。
合约可能会也可能不会根据附件有额外的复杂数据描述它。
合同可能会或可能不会有额外的复杂数据描述它，鉴于特别报道。
附件和报告与原始合同具有完全相同的特征。它们具有相同的按钮，文本框等。合同与这两者之间的唯一区别在于，合同有2个额外的文本框，当然，附件和报告是合同的一部分。
之前在此寻求帮助，并在线研究后，我决定使用master-detail界面来保留空间。这样，用户既可以添加新数据，也可以编辑/删除/搜索/打印等现有数据。
我努力解决这个问题
为了呈现如此庞大的数据，我决定使用标签控件。这个解决方案减少了占用空间的数量。
为了显示现有数据，我决定使用树视图控制，原因如下：
- 它可以将合约呈现为根节点。
- 如果合同有附件或/和报告，它们可以显示为子节点。
此处 [当用户输入合同/附件/报告时，^ 是标签控件的草图。
第二个标签对合同/附件/报告具有相同的控制。第一个选项卡为Contract提供额外的2个控件，但是对于Annex和Report都是相同的。在模型中我展示了第一个合同标签，以便为这篇文章的读者提供参考点。
以下是针对以下情况的树视图草图：
- 合同没有附件或报告 [ ^ ]
- 合同有2个附件 [ ^ ]
- 合同有2份报告 [ ^ ]
- 合同附件和报告 [ ^ ]
在这里 [ ^ ]是我所拥有的草图弄明白所以远。
进入新/编辑现有数据的机制：
如前所述，treeview代表数据库中的现有数据。
如果用户想要编辑合同/附件/报告，他会检查所需的节点和新闻<按钮。这会将所选节点加载到选项卡控件中完成编辑后，用户可以通过按>保存编辑内容。保存按钮和更改。
如果用户想要向合同添加新的附件/报告，他可以通过将现有合同加载到标签控件（通过按< ;按钮）然后按新附件或新报告按钮（这些按钮将在合同加载后立即启用进入标签控件）。完成输入附件/报告数据后，用户必须按保存按钮才能添加新条目。
按添加新合同新合同按钮 - >选项卡控件被重置并清除。用户完成输入数据后，必须按保存按钮将合同添加到数据库中。合同将显示在树视图控件中。
用户可以通过按取消按钮中止编辑/新输入。
如果用户想删除/打印合同/附件/报告，可以通过检查所需节点并按相应按钮来完成。
至于搜索选项，按该按钮将启动一个对话框，用户将在该对话框中配置搜索条件。 Treeview将重新填充搜索结果。
问题
我相信我的总体想法很好 - >使用选项卡控件输入数据，使用树视图显示现有条目。我对通过<编辑合同/附件/报告的解决方案感到满意。和>纽扣。在我看来，打印，删除和搜索功能也正确实施。
但是，在我看来，添加新条目 - 即合同/附件/报告 - 效率低下。当用户将现有合同加载到选项卡控件并尝试添加新附件/报告时，情况也是如此。
我相信我的设计非常笨拙且效率低下，这是我缺乏经验的结果。
问题
- 如何为新/现有合同添加新的附件/报告改进机制？
- 有没有更好的方法实施新合同的输入，而不是添加特殊按钮（也许我可以在标签中添加特殊标签，例如+用于此目的）？
- 如果你有更好的解决方案来实现这种类型的主 - 细节界面我也会考虑它。
如果需要进一步的信息，请发表评论，我会更新我的帖子有相关信息。
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.
推荐答案
我建议考虑一个替代设计：每个合同都由一个单独的tre代表视图。所有附件和报告以及其他向下钻取视图都由视图的某些子节点表示。如果选择详细信息节点，则必须在树视图右侧使用一些（面板）（在西方文化中，树视图显示在左侧，并且与每个节点相关的详细信息在右侧;在从右到左的写作文化，可能是相反的。）
然后你决定哪个部分信息可以在树节点上（显然，信息很少） ）哪个部分在右侧面板上。最后，您可以深入了解最精细的细节。
此设计可同时解决您的许多问题。首先，没有选项，只是存在或不存在一些树节点。此外，右侧面板上的视图可能是多态的。它可能是不同的视图，具体取决于树节点中存储的数据对象的类型。
-SA
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
这篇关于改进主 - 细节界面的设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
