内嵌工具栏的可用性

发布于 2024-09-08 10:46:37 字数 685 浏览 6 评论 0原文

我有一个可以修改、保存和删除的实体,因此它在窗口顶部有一个工具栏,您可以按其中一个操作按钮,这是合适的。可以提交父实体。

但是,该实体还具有可以修改、保存和删除的子实体。可用性最佳实践是在父实体屏幕上显示子实体网格,然后打开一个包含子实体值(可以保存、删除等)的新窗口,或者我可以为这些子实体提供另一个工具栏。每个子实体都可以提交。

例如(内联):

//

[父实体]

|--------------------工具栏 ------------------ --|

[新建子实体] [保存] [删除] [提交]

|--------------------------------工具栏 ---------------- ----|

[父实体字段]

[子实体网格]

|--------------------子实体工具栏 ------------------ --|

[保存] [删除] [提交]

|--------------------子实体工具栏-------------------- -|

[子实体字段]

//

您可以从网格中选择一个子实体来设置子实体字段。

我目前将子实体作为单独的窗口,但我讨厌有多个弹出窗口。有关于可用的弹出窗口数量的指南吗?

谢谢

I have an entity that can be modified, saved and deleted and so it would be fitting that it would have a toolbar at the top of the window that you can press one of those action buttons. The parent entity can be submitted.

However, this entity also has child entities that can be modified, saved and deleted. Is it usability best practice to have a grid of the child entities on the parent entity screen and then open a new window with the child entity values (that can be saved, deleted, etc), or can I have another toolbar for those child entities. Each child entity can be submitted.

For example (inline):

//

[Parent Entity]

|------------------Toolbar --------------------|

[New Child Entity] [Save] [Delete] [Submit]

|------------------Toolbar --------------------|

[Parent Entity fields]

[Child Entities Grid]

|------------------Child entity Toolbar --------------------|

[Save] [Delete] [Submit]

|------------------Child entity Toolbar --------------------|

[Child Entity fields]

//

You would select a child entity from the grid which would set the Child Entity fields.

I currently have the child entity as a separate window, but am loathe to have multiple popups. Is there a guide to how many popups are usable?

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

你在看孤独的风景 2024-09-15 10:46:37

一般来说,最好的平衡是将父实体和子实体的网格放在同一页面上,并为父网格和子网格进行就地编辑。顶部的单个菜单/工具栏适用于两个网格。对于主从关系,这是相当常见的做法,例如您为应用程序描述的那样。例如,Windows 资源管理器和 Microsoft Outlook 使用它。

“保存”命令保存自上次保存以来的任何更改,无论是创建、修改或删除父项、子项或混合项。删除删除当前选择的任何内容——一个或多个父项、一个或多个子项,甚至属性中选定的文本(例如,文本框内容)。新建命令(或创建或插入)为任何具有焦点的网格创建一个新的默认实体。这种设计为用户提供了:

  • 一组简单的命令 - 例如,无需区分“提交”和“保存”。一键式“只需保存”保证。

  • 最小的混乱和最少的冗余工具栏,允许用户通过最少的滚动或其他操作来查看和操作尽可能多的数据对象。

    最小的混乱和最少的冗余工具

  • 最小的导航工作和学习开销 - 无需学习单独的窗口(您正确想要避免的多个弹出窗口)或父实体和子实体的命令。

  • 没有任何模式会降低灵活性、扰乱用户的流程或流程,甚至强制破坏他们的工作(例如,由于与另一个过时对象的关键冲突,他们无法提交新对象,但它们可以删除过时的对象,因为它们处于创建新对象的模式)。

主要缺点是用户可能会混淆工具栏命令当前适用的对象。您不希望他们认为自己正在删除子级,而实际上是在删除父级(及其所有子级)。为了避免这种情况,您需要使用适当的图形设计来:

  • 明确选择的内容:整个父级、整个子级或实体内的属性。一次只能选择一件事情。保持一致,通常对整个选定内容使用相同颜色的反相视频(亮对暗),并避免对其他内容使用反相视频。考虑使用网格的当前记录标记或“对象控件”来区分选择实体(整个网格的行)从行内的属性。

  • 区分活动父级和选定父级。活动父级是与您在子网格中显示的任何内容相关联的父级。总是只有一位活跃的父母。选定的父级是用户为某些操作(例如删除)而明确选择的父级(例如,通过单击对象控件或当前记录标记)。可能有也可能没有选定的父母。可能有多个选定的父项(例如,通过 Shift 键或 Control 键单击)。通常,活动父级具有比选定父级更微妙的图形。简单的当前记录标记(例如,左边距中的箭头)可能就足够了。查看 Windows 资源管理器(其中文件夹是父级,文件是子级)等文件管理器,了解区分活动和选定的其他想法。

  • 可能会使用动态工具栏控件标签来备份这些图形。当父网格处于活动状态时,使用“删除[父类名称]”标记“删除”,当子网格处于活动状态时也是如此。如果空间不允许这么多文本,请使用工具提示。

  • 包括一种方法来清楚地指示当前网格(这主要用于指示 New 将创建哪些实体)。网格或网格标题周围的增强边框可能就足够了。否则,强调网格标题(类似于对活动窗口所做的那样)也可能很好。

  • 提供撤消功能。如果用户在想要孩子的时候不小心吹走了父母,那么轻轻一按就可以扭转损害。无论如何,所有丰富的应用程序都应该具有撤消功能。如有必要,还可以包含删除父级或子级的警告(而不是删除实体属性的某些文本)。

Generally, the best balance is to have the grids of parent and child entities on the same page, with edit-in-place for both parent and child grids. A single menu/toolbar at the top applies to both grids. This is fairly common practice with master-detail relations, such as you describe for your app. For example it’s used by Windows Explorer and Microsoft Outlook.

The Save command saves any changes since the last save, whether it be creation, modification, or deletion of parents, children, or a mix. Delete deletes whatever is currently selected –one or more parents, one or more children, or even selected text within an attribute (e.g., text box contents). The New command (or Create or Insert) creates a new default entity for whatever grid has focus. This design provides the users with:

  • Single simple set of commands –there’s no need to distinguish Submit from Save, for example. There’s one-click “just save it” assurance.

  • Minimal clutter and fewest redundant toolbars, allowing users to see and manipulate as many data objects as possible with minimal scrolling or other manipulations.

  • Minimal navigation effort and learning overhead –no need to learn separate windows (the multiple popups you rightly want to avoid) or commands for parent and child entities.

  • No modes that can reduce flexibility, disrupt the user’s flow or train of throught, or even force the destruction of their work (e.g., they can’t submit a new object because of a key violation with another obsolete object, but they can delete the obsolete object because they’re in a mode for creating a new object).

The primary disadvantage is the potential for users to confuse what object(s) the toolbar commands currently apply towards. You don’t want them thinking they’re deleting a child when they are in fact deleting the parent (along with all its children). To avoid this, you need use appropriate graphic design to:

  • Make clear exactly what is selected: an entire parent, entire child, or attribute within an entity. Only one thing should appear selected at a time. Be consistent, generally using the same colored reverse-video (light on dark) for the entire selected content, and avoid using reverse-video for anything else. Consider using a grid’s current record marker or “object control” to distinguish selecting an entity (entire row of a grid) from an attribute within the row.

  • Distinguish between the active parent and a selected parent. The active parent is the one associated with whatever you’re showing in the child grid. There is always exactly one active parent. A selected parent is one explicitly chosen by the user (e.g., by clicking the object control or current record marker) for some action such as Delete. There may or may not be a selected parent. There may be multiple selected parents (e.g., by shift- or control- clicking). Generally the active parent has a more subtle graphics than a selected parent. A simple current record marker (e.g., an arrow in the left margin) may be sufficient. Look at file managers such as Windows Explorer (where the folders are the parent and the files are the children) for other ideas for distinguishing active from selected.

  • Possibly back up these graphics with dynamic toolbar control labels. When the parent is grid active, label Delete with “Delete [Parent Class Name]” and likewise when the child grid is active. Use tool tips if space does not allow this much text.

  • Include a means to clearly indicate the current grid (this is primarily needed for signaling what entities New will create). An enhanced border around the grid or the grid title may be sufficient. Otherwise accentuating the grid title (similar to that done for active windows) may also be good.

  • Provide Undo. If the user does accidentally blow away a parent when a child is intended, then one click should reverse the damage. All rich apps should have undo anyway. If necessary, also include a warning for deleting parent or child (as opposed to deleting some text of an entity attribute).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文