图形用户界面设计-多表单vs模拟MDI(选项卡)vs页面控制

从程序员的角度来看,页面控制解决方案很快就失控了。一个表单上的代码和组件可能太多。(最初这个问题被标记为delphi,所以我从那里开始。)

从用户的角度来看,“打开新窗口”范式常常令人困惑。我们人们倾向于认为我们能够同时处理多任务,处理许多打开的窗口和任务,但事实并非如此(我们的任务像计算机一样在丢失时间的情况下切换,增加了准确性的损失)。

显然,这取决于应用程序的类型。但我倾向于用Chrome和火狐在其最新版本中展示的一个范例:

• 在不同的选项卡中保留不同的窗体
• 允许用户将选项卡分离到自己的窗体中(通过拖放百分比固定和取消固定)
• 添加良好的导航方式

我也实现了类似SDI的东西作为应用程序的主屏幕。看看“Outlook样式”。导航、对象列表、不同窗格中的对象详细信息、一些附加窗格(如驾驶舱)。然后为某些任务(一些模式,一些非模式)打开一个新的窗口/窗体,但使用时间很短。在编写电子邮件后,它将被发送并关闭窗口。但是,如果我能做到这一点,我有可能在同一时间处理多封电子邮件。

看看这个问题。如果它具有仪表板字符,则采用“Outlook样式”等。如果用户是广泛分布的、异构的、不懂计算机的人群,请使用选项卡上的SDI或表单。如果你为程序员写作,你可能会选择多种形式,仅仅是因为我们倾向于认为我们可以处理它。它适用于多个屏幕(希望如此)。

在我看来,MDI是最糟糕的选择。我最讨厌的事情莫过于调整一堆窗户的大小,或者贴上瓷砖等等。

选项卡也很糟糕,尤其是当您有多行选项卡时(或者如果您有一行但仍有多个选项卡不适合使用,并且必须使用一些时髦的滚动条或“更多”按钮)。

我宁愿看到程序员思考这个问题,并根据我作为用户所做的事情向我展示我需要看到的东西。在程序中实现不同的用户界面作为用户控件(而不是离散形式),然后根据当前上下文显示或隐藏它们是一种可行的方法。

如果为每个选项卡内容使用框架,则选项卡式表单是一个好主意。这样可以避免在一个表单单元中获取过多的代码。试着用谷歌Chrome做同样的事情。我个人创建了一个菜单,其中的选项实际上是框架,只有当用户请求时才加载,所以永远不会有很多选项卡可见,除非用户需要它们全部打开。