进度消息 - 用户体验
当显示进度条时，您是否显示通用消息，例如：
- “正在工作”
- “正在加载”“正在进行”
- 或者
额外的编码工作是否值得通过更精细的消息带来的用户体验改进，例如
- “正在加载案例 2，共 5 个
- ”加载团队”
- “保存 POL10283”
另外，如果您编码粒度消息，您是否从它们所属的对象控制这些消息，或者从对象加载到的更广泛的视图/模块控制这些消息？
标记
When displaying progress bars do you display generic messages, such as:
- "Working"
- "Loading"
- "In Progress"
Or is the additional coding effort worth the user experience improvements resulting from more granular messages, such as
- "Loading Case 2 of 5"
- "Loading Teams"
- "Saving POL10283"
ALso, If you code granular messages, do you control these from teh objects to which they pertain, or to a wider view / module into which the objects are loading?
Mark
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您的消息让用户了解任务完成之前还剩多少时间，那么它会显着提高可用性。
因此，“正在处理 5 项中的第 2 项”之类的内容肯定比“正在处理”要好。
我还建议避免进度条，而不是一直运行到结束，然后简单地一次又一次地开始。那只是为了戏弄用户。感觉就像：“一分钟内就能完成。好吧，也许再过一分钟。再过一分钟”。
It makes a significant improvement in usability if you message gives the user an idea of how much time left until the task if finished.
So something like "Processing item 2 of 5" is definitely better than just "Processing".
I also recommend to avoid progress bars than run up until then end then simply start again and again and again. That's only for teasing users. It feels like: "It'll be done in a minute. Well, maybe in one more minute. In a minute more".
如果这是一个您不知道长度的任务（没有计数或循环计数），那么一般消息或信息特定步骤就可以了，但我确实倾向于尝试完成的百分比或“案例 2 of 5” 。
这可以更好地指示正在执行的实际任务。
If it is a task that you do not know the length of (No counts or loops to count) then a generic message or info ion the specific step is fine, but I do tend to try the percentage completed or "Case 2 of 5".
This gives a better indication of the actual task being performed.
评估“价值”是相当困难的。作为一名用户，我真的很想知道发生了什么。因此我倾向于尝试实现这样的细节。
我会将视图与实际处理细节（可能涉及视图确实不应该知道的对象）分离，并在我的模型中使用一种通知板。有趣的事件可以发布在那里，视图可以拾取它们。
Evaluating the "worth" is pretty difficult. Speaking as a user, I really like to know what's happening. Hence I tend to try to implement such detail.
I would decouple View from the actual processing detail (which may involve objects that the View really shouldn't know about) and use a kind of NoticeBoard in my model. Interesting events can be posted there, and the view can pick them up.
从第二个选项中获得的反馈对于追踪不可预见的错误非常宝贵。就选择哪个选项而言，我会选择第二个，因为它使我能够为更广泛的视图提供一个单独的线程。因此，如果对象加载失败，至少我有一个通用机制来应对问题。
The feedback you get from the second option can be invaluable in tracking down unforseen bugs. In terms of which option to choose I would go for the second as it enables me to give the wider view a seperate thread. So, if the objects fail loading at least I have a general purpose mechanism to react to the problem.
(1) 我相信一般来说，用户会更喜欢更精细的消息。
但是，您需要进行更详细的任务分析。你需要问：每项任务对他们来说有多重要，任务中的每一步对他们有多重要？
“加载案例 2（共 5 个）”
“正在加载团队”
“保存 POL10283”
等在化工厂等中很好。
但在一个简单的应用程序中，它们可能没那么重要。
(2)关于问题2，我同意上面djna的观点。消息应该位于（业务/域）对象中。他们的调用者/客户端（通常是控制器或视图/演示）应该从对象中获取它们。
(1) I believe users would prefer more granular messages, in general.
However, you need to do a more detailed task analysis. You need to ask: How important is each task to them, each step in a task to them?
"Loading Case 2 of 5"
"Loading Teams"
"Saving POL10283"
etc are fine in a chemical plant etc.
But in a simple app, they may not be that important.
(2) Concerning Question 2, I agree with djna above. The messages should be in the (business/domain) object. Their caller/client (usually controller or view/presentation) should get them from the objects.