绿果用户体验完善(2)–对话框,究竟是要还是不要?
“如果我们把网站想像成一所房子,每个窗口是一个单独的房间。房子本身用主窗口来表达,每个房间都是一个文档窗口或对话框。在现实生活中,我们不会为房子添加房间;除非它有一个其他房间无法满足的意图。同样,我们也不应该随意为程序添加窗口;除非它有现有窗口不能或者不应该满足的特殊意图。”
因为需要有某种用途,所以我们才会去专门添加一个房间;同理,因为网站页面上的架构无法满足交互的需要,我们才会考虑使用浮在页面上的对话框来完成交互行为。
在通讯录组件中,查看列表中好友的详细信息是采用鼠标移到好友头像上弹出对话框显示,如果需要修改好友的信息,则是需要点击对话框中的按钮,然后会弹出一个新的对话框来执行操作。
从程序架构的角度来看,这样的设计并没有什么不合理的地方。对应每一个功能,各自用一个对话框去实现它,也为用户创造了直观的对话方式。
现在,我们换一种角度,从用户使用通讯录的体验来看,这是怎样的一个过程:进入通讯录,查看联系人,修改资料,保存。然后可以发送名片或者继续查看下一个联系人。
这当中,用户对一个具体联系人的操作其实是一个连续的动作,拥有一条完整的任务线。在完成了查看联系人这个任务后,用户可以选择是发送联系人的名片还是继续查看其他联系人,这就是另外一条任务线了。
如果我们把通讯录比作一所房子,那么第一个动作就应该是在同一个房间里发生,而当用户需要执行其他任务时,才应该出现新的房间。因为从用户的角度来看,无论是查看还是修改某个联系人的资料,都是对一个联系人执行操作的功能,它们应该是一个整体,不可以被分割开来。
那么这里应该如何设计呢?51job在个人用户资料这里就为我们提供了一个很好的启示。
查看资料的页面
修改资料的页面
查看和修改功能放在同一个页面完成。当用户修改完资料以后,点击“保存简历”,完成了本次查看、修改、保存的操作;而系统也生成一个新的结果页向用户展示。
尽管相比于跳转到新页面来实现交互,对话框已经相当前进了一步,但是想要能保持用户整个操作流程的流畅体验,还视需要我们更进一步去斟酌。通过研究用户目标这种方式,我们自然能找到程序应有的表现形式,而不会简单地把每种功能都设置成对话框。而用户执行正常事件序列之外的功能时,我们就应该为用户提供对话框来实现,而不应该继续保留在页面上。
因为需要有某种用途,所以我们才会去专门添加一个房间;同理,因为网站页面上的架构无法满足交互的需要,我们才会考虑使用浮在页面上的对话框来完成交互行为。
在通讯录组件中,查看列表中好友的详细信息是采用鼠标移到好友头像上弹出对话框显示,如果需要修改好友的信息,则是需要点击对话框中的按钮,然后会弹出一个新的对话框来执行操作。
从程序架构的角度来看,这样的设计并没有什么不合理的地方。对应每一个功能,各自用一个对话框去实现它,也为用户创造了直观的对话方式。
现在,我们换一种角度,从用户使用通讯录的体验来看,这是怎样的一个过程:进入通讯录,查看联系人,修改资料,保存。然后可以发送名片或者继续查看下一个联系人。
这当中,用户对一个具体联系人的操作其实是一个连续的动作,拥有一条完整的任务线。在完成了查看联系人这个任务后,用户可以选择是发送联系人的名片还是继续查看其他联系人,这就是另外一条任务线了。
如果我们把通讯录比作一所房子,那么第一个动作就应该是在同一个房间里发生,而当用户需要执行其他任务时,才应该出现新的房间。因为从用户的角度来看,无论是查看还是修改某个联系人的资料,都是对一个联系人执行操作的功能,它们应该是一个整体,不可以被分割开来。
![]() |
那么这里应该如何设计呢?51job在个人用户资料这里就为我们提供了一个很好的启示。
![]() |
查看资料的页面
![]() |
修改资料的页面
查看和修改功能放在同一个页面完成。当用户修改完资料以后,点击“保存简历”,完成了本次查看、修改、保存的操作;而系统也生成一个新的结果页向用户展示。
尽管相比于跳转到新页面来实现交互,对话框已经相当前进了一步,但是想要能保持用户整个操作流程的流畅体验,还视需要我们更进一步去斟酌。通过研究用户目标这种方式,我们自然能找到程序应有的表现形式,而不会简单地把每种功能都设置成对话框。而用户执行正常事件序列之外的功能时,我们就应该为用户提供对话框来实现,而不应该继续保留在页面上。
还没人转发这篇日记