it-swarm.cn

两步操作和按钮约定

我们的Web应用程序具有三种不同的操作,操作如下:

  1. 向用户显示一个弹出窗口,其中选择了不同的设置。
  2. 用户可以单击标有操作(例如:“合并”)或“取消”的按钮。
  3. 如果用户前进,则应用程序将处理操作,这可能需要一些时间,并且会显示另一个弹出窗口,其中概述了将会发生的情况。此时,操作尚未提交,用户可以选择继续或取消。

这是我们的三个操作不一致的地方。在一种情况下,选择继续/取消,在另一种情况下则选择完成/取消,最后我们得到最终确定/取消

其中哪一个最好?有更好的选择吗?如果是这样,是否有任何支持的论点?

3
carrier

我通常会尽量避免使用此类通用按钮标签,并且要尽可能具体。您的标签让我感到非常“数据库化”,并让我想起了程序员为非常抽象的领域设计的工具(例如数据库编辑器)。

有关更多讨论,请参见有关“确定/取消”按钮定位的相关问题:

确定/是否在左侧/右侧取消?

在我的回答中,我链接到 Jakob Nielsen对“确定/取消”按钮的研究 ,他指出:

命名按钮以说明其功能通常比使用通用标签(例如“确定”)更好。明确的标签用作“及时帮助”,使用户更有信心选择正确的操作。

例如,一些示例:

另外,您可以考虑省略替代方案。在某些情况下,这可能是有道理的。我认为,如果用户要做出重大承诺,例如购买某些东西或涉及大量数据的CRUD操作,则可以选择“取消”选项。

但是对于一些简单的事情(例如发推文),尤其是在提交操作之后可以轻松进行回滚的情况下,可以忽略显式的“取消”按钮,因为通常不继续执行不会提交任何内容。

一个很好的例子是StackExchange的注释表单,它只有一个“添加注释”按钮,无法隐藏或取消表单。不想添加评论?不要点击“添加评论”!

10
Rahul

听起来像向导。这是一个例子:

  1. 用户启动合并功能
  2. 出现一个弹出窗口,标题为合并
    它包含命令的设置,以及Next >Cancel按钮。
  3. 用户更改设置并单击Next >
    应用程序会稍等片刻。
  4. 向导的下一页出现。它具有FinishCancel按钮。
    如果用户单击Finish,则操作完成; Cancel取消整个操作。

另一种方法是使其成为一个步骤的过程,但允许撤消。取决于操作,这可能会或可能不会。

  1. 用户启动合并功能
  2. 出现一个弹出窗口,其中包含命令设置以及MergeCancel按钮。
  3. 用户更改设置,然后单击Merge
    应用程序将处理该操作片刻并完成操作。
  4. 屏幕显示操作结果,并包含一个Undo按钮。如果用户单击Undo,则操作将还原。
3
Bennett McElwee

我想提出两点:

1)如果实际的合并过程是在第二个屏幕(带有摘要)之后启动的,则“合并”按钮应位于第二个屏幕上。这使我说,在第一个按钮上,按钮应该说“ Preview Merge results”之类的内容,因为这是用户在他/她开始的流程中将获得的下一个结果。

2)这是一种令人毛骨悚然的建议,但在第一个屏幕上具有三个按钮也许会有些道理:“预览合并”,“取消”和“不预览合并”。这将为知道他/她将要做什么并且不想等待统计信息然后承诺其决定的用户节省一些时间。只是个主意...

0
Jüri

如果您在单击“合并”之后未真正执行“合并”,则不应将其称为“合并”。

通常在多阶段表单中使用的是“继续/提交”约定。继续表示您必须继续进行下一阶段,但这并不意味着您已经做出了一些承诺。

对于在线商店,结帐通常需要用户通过一些表格进行操作,并提供地址和付款明细。直到他们最终可以确认订单的页面上使用的是“下订单”或“承诺购买”按钮。

我将使用“预览合并”或“继续”按钮,然后在他们提交的页面上使用“执行合并”或“提交”按钮。

0
Nick Bedford