7

My company is building an on-line map which displays moving objects (vehicles) and static objects (bus stops).

When the user hovers over an item, a tooltip with additional info about all the objects beneath the cursor appears.

enter image description here

Since the vehicles are moving, the objects beneath the cursor can change dynamically. The UX issue at hand is: how should the tooltip react?

  1. Change with the set of objects beneath the mouse pointer. Usability issue: Users might not have time to read all the information they are interested in before it disappears.
  2. Don't change the tooltip, until the mouse is moved. Usability issue: The tooltip might become inconsistent to what the mouse is actually hovering over.
  3. Use a timeout during which the tooltip is stable. Usability issue: Timeouts are always inappropriate for some users/use cases.

An added issue is the underlying data displayed in the tooltip might also change dynamically. The deviation (delay w/ regard to schedule) of a bus might change, it might finish its current trip and start a new one, etc. Considering options 2 and 3, should the tooltip keep these values up-to-date or just show the snapshot from when the mouse initially triggered the tooltip?

My gut feeling is to go with option 3 with dynamically updating data in the tooltip, but have not found real evidence from research or even anecdotal evidence to go one way or the other.

Edit: Many answers suggest we should drop tooltips in favor of a properties window that shows information for a vehicle the user has clicked/selected.

We already can do that in our UI, but in my opinion this is not an appropriate substitute for a tooltip. Clicking is not as effortless as hovering and also, it carries a different intent (i.e. that the user wants to use the selected object in some way), where as hovering is more "just look, don't touch" and less involved.

This is what selecting a vehicle in our UI looks like:

enter image description here

However, if many objects overlap at the point of click, the user has to click a second time to resolve the overlap and pick the vehicle she is interested in

enter image description here enter image description here

I don't mind one or two click for selecting the exact vehicle if the user starts to perform a sequence of commands using that vehicle. However, a well made tooltip allows us to have a lightweight interaction for just glancing at the information very effortlessly.

I'm hoping this puts things in contexts and motivates why we would very much want a usable hovering interaction.

Improve this question
4
  • In my opinion, there is no reason this should be an on-hover tooltip. It unnecessarily makes it unusable on touchscreens, for instance. I would say make a bus selectable, and have an info area appear when a bus is selected. Unless there is some other reason this HAS to be a tooltip, don't use a tooltip.
    – Dan
    Aug 11, 2015 at 14:14
  • 1
    Currently, > 99% of users will work with this map in a desktop environment, so it would not be appropriate to drop interactions that are specific to mouse & keyboard. Hovering over an object to obtain more information about that object is a well-known, time-tested interaction pattern. Clicking on an object that you want more information about is possible in our interface, but I do not like to waste user clicks, when she just wants to quickly glance at the information. Also, when clicking you have to resolve overlapping objects, which becomes a second click from a list of possible objects.
    – Chris
    Aug 12, 2015 at 7:42
  • Suit yourself of course! However I will point out that while 99% of usage isn't a touchscreen right now, looking at touchscreens as completely unimportant is shortsighted. Also, overlapping objects are also an issue with hover, not just clicking. On fact, I would imagine overlapping objects are even less easy to select with hover. Hover may be time-tested and well-known but that does not make it the best choice inherently. You also argue that hovering is easier for some reason, but I would argue clicking is since you don't have to maintain mouse position, and won't activate it accidentally.
    – Dan
    Aug 12, 2015 at 17:33
  • I didn't want to come across as dismissive of touch. It's absolutely important to us, but in my opinion goes far beyond the scope of this question. My rationale for hovering being a more lightweight form of interaction is the following: It requires one less click, and since the tooltip may display all info of overlapping objects (to a degree of course), it will even save a second click. Also it does not change the state of the UI, namely the current selection that the user may not want to modify just to glance at a different object.
    – Chris
    Aug 13, 2015 at 12:39

8 Answers 8

Reset to default
2

Interesting problem.

Since you are using a tooltip, I am assuming that there is no need to have multiple tooltips visible simultaneously. If this is needed, a tooltip is not the right control.

So my answers concentrates on not having the requirement of multiple tooltips at once.

I was asking myself: why would a user want to see this popup? Probably because he/she is interested in more detailed information on the object. He/she wants to "inspect" the object.

Then how about not moving the object any more once the user is hovering above it? Instead, move the map beneath the object. Once the user hovers off the object, revert to the original behaviour.

Improve this answer
7
  • However, what if there are multiple movable objects (buses) under the cursor and they move in different directions? You would not be able to move the map to follow both. Not having a tooltip and instead a static popup in the corner of the screen is a good idea since a tooltip could hide the bus if its route falls under the tooltip.
    – Amer
    Aug 11, 2015 at 9:43
  • That's why I am clearly stating the my answer is only applicable if there is only 1 tooltip. The problem of having multiple objects in close proximity (or even overlapping) is a different one, unrelated on the tooltip behaviour. Using a static popup in the corner does not solve that issue either. Your last argument is actually the worst since in fact the opposite is true. A tooltip can never hide the object it refers to. Not in any case. It is the static popup you are suggesting that will obscure objects.
    – Bart Gijssens
    Aug 11, 2015 at 10:50
  • Ah I believe you mean to say your answer is only applicable if we want to track one movable object. Because as you can see in the screenshot, multiple data sets are shown in the same tooltip, two stations and one bus. Had there been two buses, we would have seen two rows, one for each bus. Taking this into consideration, multiple tooltips were not considered by the question, all data under the current cursor would be fit into a single tooltip. Second, I do not think we should consider having the user constantly move their cursor to follow a moving object, which leaves us with a static tooltip.
    – Amer
    Aug 11, 2015 at 11:24
  • The tooltip in this case can hide one of the objects it refers to because it is linked to the cursor and not the object, it can refer to a static object plus a movable object at the same time. As the question states "...about all the objects beneath the cursor..."
    – Amer
    Aug 11, 2015 at 11:29
  • That makes no sense. There may be many busses, but the tooltip only refers to 1 bus, and the tooltip will always show only 1 row. That's my assumption.
    – Bart Gijssens
    Aug 11, 2015 at 13:00
1

First Two Options are Untenable

First option implements there could be minimal time for the user to read, which you have no control over. Even worse, (s)he would need to move the cursor to display the data properly. The second option is bad because of inconsistency. Moreover the mousemove event triggers way to often.

Conceptional Problem and Solution

I think it is already a design issue to display these information on hover. All your problems could be solved by using a click event and a fixed position for the tooltip. However, if you really want to stick to this logic you should use the third option. Moreover I would suggest a modified version of your third solution.

  1. Display the tooltip at a fixed positon (top left or top right corner) and change visiablity if another tooltip is opened or tooltip is closed manually.
  2. Display the tooltip on the mouse position (fixed) and start a fade effect on mouseleave. The tooltip can still be next to the icon and the hover area covers the icon, too. This way the user can still control how long he wants to read the tooltip. Still give the option to close it manually.

Notice the problem for option 2 is what happens if you hover many objects within a short period of time, and probably the same object multiple times.

If you have multiple objects hovered at the same time (I still suggest to limit the number somehow) you could highlight the selected ones and show multiple tooltips with a reference (e.g. same color).

Improve this answer
6
  • I dislike the idea of the tooltip appearing at the position of the mouse cursor instead of the object it refers to. Image multiple busses in the streets. If not made clear to which object the tooltip refers it will lead to errors.
    – Bart Gijssens
    Aug 11, 2015 at 10:53
  • I see another problem with your approach: when will the tooltip appear? When you hover above the bus, right? When will the tooltip disappear? When you hover off the tooltip, right? In that case you will be forced to show the tolltip on top of the bus initially. I'm not sure that would be ideal. Check the tooltip behaviour in your favorite OS. You will see that the tooltip NEVER appears above the object, and never underneath the mouse cursor. There is a reason for that.
    – Bart Gijssens
    Aug 11, 2015 at 11:01
  • I edited my answer with a solution for both of your problems. The selected objects should be highlighted and referenced in the tooltip (e.g. with a color). The tooltip can appear next to the cursor while the hover area still covers the icon, just some minor css.
    – oshell
    Aug 11, 2015 at 11:36
  • Mind we are not implementing yet. CSS or not, hard or easy is not relevant at this point in time. We are merely looking at the UX side of the story. Color coding and textual references are in my opinion less clear than the simple approach of showing 1 tooltip in close proximity to the object it describes.
    – Bart Gijssens
    Aug 11, 2015 at 13:03
  • I also mentioned that limiting the number of tooltips is neccessary, I agree that color references can become confusing with too many elements. Changing the behaviour of the map movement would probably result in confused users too.
    – oshell
    Aug 11, 2015 at 13:15
1

A few changes to my answer in light of the OP's clarifications; they would like a light weight tooltip to give information at a glance and this tooltip would remain at the cursor.

The tooltip is showing two types of information.

  1. Set of objects
  2. Some additional data with respect to an object

Static objects by definition will not move, so showing the set of static objects under the cursor is a non-issue.

Moving objects pose one of the problems of the OP, which is a moving object could move away from under the cursor while the user is looking at its information. This is the first problem

The other problem the OP is facing is the additional data associated with the objects, whether static or moving. Though in the screenshots the OP does not show additional data next to static objects, the problem and solution of the additional data is the same regardless of mobility of the object. This is the second problem

Objects Moving From Under the Cursor

I propose that when hovering over objects, all objects under the cursor are highlighted and/or have their icon size increased slightly to visually tie the data to be shown in the tooltip with the objects on the map. If a moving object moves from under the cursor, do not unhighlight / revert size of the icon and do not remove its row from the tooltip.

Consideration: Objects Moving Under the Cursor

You can consider adding a moving object to the tooltip (and highlighting it) if it comes under the cursor. Though this can potentially lead to a really huge tooltip if the user leaves their cursor on a busy location for a long time.

While maybe not a normal use case, we should probably still deal with it. We can set a limit of objects and start removing those objects which are no longer under the cursor.

Additional Object Data Updating

In the OP's screenshot, the moving objects have additional data which is quite important. Seeing out dated information by keeping this data static will harm the user. So this data must be updated at regular intervals, say five seconds.

This solution ensures that a user is not scrambling after a moving object by keeping the moving object's row intact in the tooltip while the cursor has not been moved. Also it makes sure that the data the user is seeing is not out of date.

Improve this answer
1

I totally understand your dilemma. Despite the UX challenges, info on hover is an intuitive, expected, and convenient UI for the user. As long as it doesn't break ;-)

Use a slight delay before triggering the info (200-300ms). If things are moving so quickly that this isn't feasible, then neither is the hover box. Once activated, the hover box should remain visible until

  1. The user moves the cursor a given distance away from the info or object. An unmoved cursor should not trigger this.
  2. The object passes out of view (thus the connection can't be reasonably maintained).

The info is presumably worth reading, so you don't want it to move which brings us to the issue of being disconnected from the object of concern. For this, you can use a simple connector, as illustrated below. The object moves as it chooses, the info stays in it's initial position, and the connector keeps the relationship alive.

Map image with map item and info box connected by a line

Improve this answer
1
  • I really dig your previz!
    – Chris
    Aug 14, 2015 at 6:50
0

A static tooltip that has a dynamic arrow or line (or some other form of indication) linking it to the object it relates to. The tooltip remains in place but as the object moves, the indication moves with it so that it always stays linked to the tooltip.

However this would require the tooltip to remain active when the cursor is no longer over the object to prevent the need for the user to track it with the cursor. Otherwise the trigger for a tooltip could be a click rather than a hover.

Improve this answer
0

If tooltips are problematic, how about not using them?

Tooltips are good when you're displaying small blurbs of info contextually next to the object of interest. In your case though, the info to display is a fair amount and it's also important to show updates of items on the map below. So we should consider other ways of displaying info...

A details pane may be a better solution

Highlight the selected item, then slide open a details pane on the side.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Notes: This assumes you're dealing with an interface with large enough screen real estate to display both map and details at the same time. But if you're on a mobile device, tooltip idea wouldn't work very well anyways.

Improve this answer
1
  • We also have a detail pane, that shows the properties of selected objects. However, for the user to determine in a lightweight way to figure out which objects she is currently hovering over, we'd very much like to keep a tooltip.
    – Chris
    Aug 12, 2015 at 7:36
0

One idea could be to lock the position of the bus and instead move the map around the bus when hovering on the bus dot. This way the position of the tooltip can be static.

Improve this answer
1
  • The mouse cursor may "hit" multiple busses, so the tooltip may display data for several busses (as in the screenshot it lists two stops and one vehicle). On another note we have a tracking feature in the application, but that should not snap onto a bus just by hovering over it.
    – Chris
    Aug 12, 2015 at 14:13
0

IMO this is not a tooltip but a floating properties panel, because it's not intended for a quick glance to a single info piece but to present the user a set of related data.
This is not wrong, it's only different. I find it's helpful to characterize issues before attacking them.
I would display the updated data in a fixed position, and would bind the moving bus to the fixed pane with a dinamically updated connector.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.