[IxDA Discuss] Graphical methods for displaying time elapsed

[dnp607]

>
> OK, I can understand that you might not be able to implement this  
> advice, but I'll point out that a working IxD practitioner needs to  
> learn the art of diplomatically pushing back when the client hasn't  
> provided enough information to properly characterize the  
> overarching goals of the project. If the client is insisting on a  
> generic solution that could lead to a bad (and possibly dangerous)  
> user experience, it's _your responsibility_ to find that out before  
> the trouble starts.
>

I appreciate your diplomacy Will, and apologies again for my imposed  
constraints of secrecy. I think you've done a fine job given these  
constraints, so I'll get right to that!

> First, I would consider whether we could entirely eliminate the  
> 'good alarms'. Do we really need to see a signal indicating that  
> all is going well? "Hey, you're still breathing and have a pulse!!"  
> Looking at it another way, can we reduce the complexity of the real- 
> time presentation by using the implicit assumption that "no signal"  
> == "state is good"?
>

This is on point - I think there is little need to indicate "green",  
repeatedly. It's really anything other than "everything is OK" that  
should take up screen space. I've been worried that users need so see  
that *something* is happening, but this can be communicated in a  
simpler and less real-estate consuming way.

> Using this model, the primary presentation could show only 'Bad'  
> and 'Worse' events in a timeline, with an option to also show the  
> 'Good' events if the user switched modes.
>

A log window seems appealing here - it can be referenced later, and  
for my purposes, need not take priority of user's focus over critical  
information.

> Second, remember that you should never use only one sensory  
> modality to convey important information. Color alone is not  
> enough. For your event timeline, you _can_ use just color, because  
> those events are now history. However, you're describing a  
> situation in which the user must assess the _current_ level of  
> 'badness'; therefore, you should also provide a strong, immediately  
> distinguishable signal of the current state.
>

Yes, good input, and we do have this item under control through both  
shape and very conservative/researched use of blinking.

>
> I recommend three main elements:
>
> - Current-state indicator, as described above, to guide immediate  
> user response to correct for bad states. Always visible, and  
> prominently placed in the UI layout.
> - Scrolling timeline of the events of the past 30 minutes,  
> displayed in 30 1-minute blocks; square or rectangular blocks would  
> work. Add some sort of hashmarks to visually separate the timeline  
> into 5-minute segments. If you can have two adjacent signals of the  
> same level of severity, you'll need to indicate the boundaries  
> between two adjacent events of the same category. Here I'd  
> recommend a black line extending above and below the boundaries of  
> the main timeline. You might also arrange this as a series of six 5- 
> minute rows, with a clear indication of sequence, from newest to  
> oldest.
>
> - Some method of selecting a given event and thus revealing the  
> important details of that event - for example, start time,  
> duration, type of event, source of error (e.g, '1201: 1206 -  
> Navigation error - Yaw rate > 12 degree/sec').
>
> For an alternative method of dealing with a timeline of events, see  
> the Google Finance method of calling out important events  in a  
> timeline (Example: http://finance.google.com/finance?q=aapl). They  
> add flag markers to high-importance events, with links to detailed  
> reports (news stories). They also offer less detailed callouts of  
> the data at any point in the timeline when the mouse is moved  
> across the timeline itself (watch top right corner of chart area  
> while mousing across chart). Not simple to implement, but doable,  
> and worth the effort for understanding complex data displays.
>

Excellent feedback.

>
> Might be a bit hard to display/access all the events in a 30-minute  
> pie chart if space is limited and/or the number of events is much  
> above 20 AND the selection method is something other than keyboard  
> commands. I don't have a link to the research, but I've seen a  
> number of usability studies that show most people display less fine- 
> motor accuracy moving a mouse cursor in a circle or arc than they  
> do when moving a mouse in a horizontal or vertical line.

There is the added issue of interpreting positions on a circular  
display to a standard wall clock. I found research done on radar  
displays that pointed this out. I'm proposing many options, but am  
personally biased against a circular UI element without clear need.

Regards,
-Dan

-------------------------------------------------------------
Dan Peknik * NASA Ames Research Center
         San Jose State University, ID HF/E
-------------------------------------------------------------