处理控制远程机器人的应用程序,在该应用程序中,按下按钮与实际发生的操作之间可能存在显着延迟.此外,由于网络不可靠等原因,命令有可能无法成功到达目标接收者.此外,还有一些变量在发挥作用,其变化不是即时的.例如,指令速度和当前速度都有一个变量; 更改指令速度不会立即使当前速度与该值匹配.
问题是,如何让应用程序反映远程机器人报告的当前状态,以及向用户确认应用程序理解了他的命令,但系统尚未收到来自机器人的通知已被承认？(弹出窗口是绝对禁止的.)
已经讨论过的一些想法:
按下命令按钮时,启动计时器一段合理的秒数,并在此期间禁用该按钮.不要直接更新相应的标签,而是等待机器人的响应.(例如,如果按下速度+按钮,右侧是显示当前速度的文本标签,请不要立即更改标签,而是等待机器人的响应).一旦发生此响应,或计时器到期,请重新启用该按钮.
优点:页面上不需要额外的控件小部件.标签始终反映机器人的当前状态.
缺点:如果您想连续发送两个速度更新,则必须等到第一次收到并确认.会感到迟钝和反应迟钝.
拥有一个用户可以查看的日志,该日志显示用户已采取的所有操作的文本表示,已加上时间戳,并且历史记录清晰可见.可以根据用户偏好进行颜色编码.
优点:用户立即反馈他的命令被理解,因为它出现在日志中
缺点:不解决如何处理按钮(尤其是单选按钮)行为的问题.
有没有人有在为行动和响应之间存在显着延迟的环境构建UI的经验？我会很感激任何和所有的输入.
听起来您需要向用户传达以下信息：
\n\n机器人属性的当前状态或值。
机器人正在寻求的目标（即接收到的）值。
用户发送给机器人的命令值。
每个命令的状态（待处理、已接收、已实现、超时）。
还有其他一些考虑因素：
\n\n连续或离散反馈。是否有机器人持续实时反馈当前值？或者是离散反馈，即机器人仅在达到目标后才发送当前值？显然，连续对用户来说更好，因为它允许用户区分机器人缓慢和被卡住，但如果你没有它，你就找到了一种没有它的生活方式。
同步或异步命令发送。如果命令是同步发送的（即，直到收到最后一个命令才发送新命令），则用户可能需要一种方法来 (a) 强制发出下一个命令，而无需等待上一个命令的答复（如果回复丢失），以及 (b) 如果在命令创建和发送之间条件发生变化，则取消排队的命令。
Robot with or without conflict resolution. Does the robot have the logic to look ahead in the list of commands it has received and resolved conflicting commands? For example, if it\xe2\x80\x99s at a stop and its received-commands queue includes a command to go 5 m/s followed by a command to go 2 m/s, is it smart enough to delete the 5 m/s command? Or will it first attempt to accelerate to 5 m/s then 2 m/s, possibly resulting in an overshoot? Will it wait until it achieves 5 m/s before it even \xe2\x80\x9clooks at\xe2\x80\x9d the 2 m/s command? A lack of conflict resolution complicates your UI because the users may have to track all commands sent to understand why the robot is behaving like it is.
Integrated Information with Position-coding Controls
\n\nLet\xe2\x80\x99s assume that the robot has conflict resolution and asynchronous command-sending. Rather than have separate controls for commanded, targeted and current values, I recommend you integrate them all in a single control to make it easy for the user to compare current, target, and commanded values, and see discrepancies. Perhaps the best way to do this is by representing values by positions in the window. Such position-coding of values is unmatched in showing the relations among things. There are two standard GUI controls, radio buttons and sliders, that accomplish such position coding. However, you\xe2\x80\x99ll have to augment them to fulfill for your purposes. The best usability could require custom-made position-coding controls where you schematically represent the robot and maybe the environment, and allow the user to control it through direct manipulation. However, I'm assuming you need a simple-to-develop implementation, and a well-laid-out combination of sliders and radio buttons may get you pretty close to this ideal.
\n\nUse radio buttons for setting a categorical value and a slider for setting a numeric value. The slider may include a text box to allow the user to fine-tune the value. You augment each of these controls so that they show the commanded, target, and current values at the same time. The \xe2\x80\x9cusual\xe2\x80\x9d indicator (the dot for the radio button and the handle for the slider) represents the commanded value while separate graphic pointers indicates the current and target values. Discriminate the current from the target by making the current more prominent. I\xe2\x80\x99d design them such that they merge into a single pointer when they are at the same value in order to minimize clutter for the usual state of things. If your users are untrained on the system you may want to include text labels on the pointers (\xe2\x80\x9ccurrent,\xe2\x80\x9d and \xe2\x80\x9ctarget\xe2\x80\x9d when target is different than current).
\n\nUsing these position-coding controls makes it easy for the user to compare current, target, and commanded values and see discrepancies. The status is implicit in the relative positions of the indicators. When the target pointer moves to the commanded position, the user knows the command was received. When current pointer is at the target, the robot has achieved the commanded value. This is especially good for continuous feedback of numeric values because the users can not only see the difference between the current and target value on a slider, they can estimate how long it will take for it achieve the target by seeing how fast the pointer is closing on the target. For the radio buttons, you can include \xe2\x80\x9cX% Done\xe2\x80\x9d text by the Target pointer to indicate when the target will be achieved (if this information is available).
\n\nFor the most responsive UI, changing a value of a slider or radio buttons should send an immediate command. There is no \xe2\x80\x9cApply\xe2\x80\x9d button. Users can re-send a commanded value at any time by re-clicking on the appropriate slider position or radio button. I think you'll find this is a natural human tendency anyway when confronted with an apparently unresponsive control (consider elevator buttons).
\n\nThe descrepency between the target pointer and commanded indicator may be too subtle to signal a lack of reception of a commmand if responses are commonly slow (over a few seconds, such that user attention has likely shifted elsewhere). If that is the case, you may want to include a modeless alert after a time-out period that almost certainly indicates the command was lost in transmission. A modeless alert may include a text annunciator beside the control and/or graphically highlighting the commanded-target descrepancy. Depending on criticality, you may want to use a audible alert like a beep or animation to speed capturing user attention. The modeless alert disappears automatically when the target value matches the commanded value for whatever reason.
\n\nSeparate Controls for Commanded and Current
\n\nIf sliders and radio buttons take too much space for your purposes (or have other issues), you can go with separate non-position-coding controls for commanded and current values, as implied by your Disable Buttons design. However, overall, this is a more challenging design with more issues to resolve.
\n\nI would favor field controls like text boxes, check boxes, and dropdown menus, rather than command buttons so that the commanded value is clearly shown. Continuous numeric attributes may include spinner buttons with the text box if it doesn\xe2\x80\x99t end up clogging the queue with incremental commands. As with the above option, changing a value sends an immediate command.
\n\nYou\xe2\x80\x99re right to be concerned about the using a timer and disabling. In addition to the problem of making the system sluggish, it means you gray out the commanded state. That can make it hard to read, and also requires some mental gymnastics by the user to interpret (\xe2\x80\x9cit\xe2\x80\x99s unavailable, so that means I already selected it\xe2\x80\x9d). The interpretation can also be ambiguous because often disabled means Not Applicable (e.g., the Speed control is disabled because the robot has lowered stabilizers for fixed-base operation).
\n\nThe solution is to use some other graphic feedback than disabling. I\xe2\x80\x99d stay away from color coding. Color coding tends to be arbitrary and thus confusing (e.g., does red mean queued or timed-out?). This may be one of the (rare) good places to use animation since animation is intuitive for representing an on-going process. A flashing or throbbing border (or other feature) for the commanded-value control can indicate a sent command is awaiting reply. A flashing/throbbing border for the current-value control indicates the command is received and the robot is seeking the target value. If animation would be distracting in this situation (like it is for most other situations), then consider a dashed border (versus solid) to indicate awaiting reply or seeking target; dashed suggests a tentative or transitory state.
\n\nThe target value and status are implied by what is animated. If the commanded-value border is animated, the value inside is a pending \xe2\x80\x93the reply is yet to be received. If the current border alone is animated, the value inside the commanded control is the target value. If both borders are animated, then the robot is seeking one (unspecified) target value, while another is pending. If you think it\xe2\x80\x99s problematic to leave the target unspecified in such circumstances, then you may need three controls to discriminate commanded, target, and current. However, if this is an edge case, it may be better to display the target value on mouse-over of current value control or with a drop-down button.
\n\nIf feedback is continuous, you can also update the current value of numeric attributes at regular increments (about every 200 to 500 ms) so this animation provides an additional feedback of the robot seeking the target. For any attribute, if it takes 10-15 seconds or more for the robot to reach common targets and the robot has conflict resolution, you may want to also display a progress bar within or beside the current attribute control so the user can judge when the robot will achieve the target value.
\n\n要重新发送命令，用户始终可以重新选择一个值，或者在焦点位于命令控件上时按 Enter 键。对于某些控件（例如复选框）来说，\xe2\x80\x99s 有点奇怪和尴尬，因此我\xe2\x80\x99d 还考虑在命令超时时在控件附近出现一个无模式通知（而不是弹出窗口）回答。该通知包括一个用于重新发送命令的按钮。
\n\n如果您的用户未经系统培训，您可能需要在动画下包含多余的文本（例如，等待回复时的 \xe2\x80\x9cSending\xe2\x80\x9d 和 \xe2\x80\x9cSeeking\xe2\x80\ x9d（当向目标值移动时）。
\n\n日志表
\n\n如果命令是同步发送的和/或机器人缺乏冲突解决方案，那么日志记录方法可能是最好的。这样，用户可以跟踪发送命令或机器人接收的命令的命令队列，以预测机器人的行为。但是，我不会将\xe2\x80\x99 设为只读文本框，而是将其设为可操作的表格。虽然表默认按时间戳排序，但属性、命令值、状态（待处理、查找、已实现、超时）将有单独的可排序字段。如果反馈是连续的，则状态应指示实现目标值的进度（例如百分比或进度条）。
\n\n如果存在同步命令发送，则用户可以编辑待处理命令的命令值或强制前进、移动或删除待处理命令。在任何情况下，都可以复制并重新插入命令，以便随时重新发送任何命令。甚至可能提供一种方法来保存选定的命令并稍后检索和插入它们\xe2\x80\x93现在你有了宏功能。
\n\n如果机器人往往特别暴躁（经常失去通信、响应缓慢），那么您可能希望在用于创建命令和查看当前值的控件旁边放置此日志表。应设置控件以使用户清楚地了解离散命令的创建。对于古怪的计算机到机器人界面，虚假命令的成本很高，因此每个命令都应该经过精心策划和深思熟虑。这可能意味着一组字段控件，如文本框和下拉列表，用于设置各种属性的值，以及一个为这些值生成命令的按钮。是的，这很尴尬，但是 \xe2\x80\x99 准确地表示了与机器人的通信链路。
\n\n或者，如果队列通常几乎为空，那么您可能希望在单独的窗口中提供此表，以便专家解决机器人行为问题。通常情况下，用户会使用我上面给出的其他两个选项之一。
\n