Alternatives to tooltips in tablets?
I understand this question has been discussed a couple of times on the site. However, it seems not to be getting the answer or inspiration I am looking for. BTW, my background is a programmer in case I sound too silly.
So let's say we have a web application. The question is, how to convey info that we don't want filling up the screen all the time and yet needs to be available when desired. Hover text was good for that, but only works well when there's a mouse involved. Now we need to support this web application to run reasonably well on a couple of targeted tablets-browser combination (including iPad, Andriod Samsung and more).
To throw a wrench in, sometimes the elements are not only "hover-enabled" to display additional dynamic content, but also clickable to trigger a primary action(such as going to another page). The real estate is very limited, so adding an "info" icon is not an option. The fact that the tooltip content is dynamic also rules out the option of "graph legend".
Here is a concrete user case.
In below screen, there is a calender widget with very limited real estate. The way it works with a mouse is: 1) when mouse-over "11/24/2014", hover text will tell it is thanksgiving and other info.
2) when end user clicks any specific date cell, end user will be navigate to another page.
It works fine with a mouse, but not "touch". What we are hoping for "touch" is:
1) Same codebase, runs well in major browsers in both desktop and major tablets
2) Preserve existing functionality (supplemental info for each date cell, and clickable event on each date cell)
The question becomes, Hypothetically, if we had designed these screens with tablets in mind, what might we have done differently so that we didn't even rely on hover text? Might we have done something that works the same for both touch and mouse? It does not have to be "hover to bring up tooltip", then what options do we have?
EDIT: add another user case that no extra real estate For example, many of the column values can have hover-up to provide supplemental info.
Welcome to UX.SE; No hover with touch interaction - that's a given. I feel the question is too broad because any solution will have to be specific to the actual problem it comes to solve. That's what UX is about. A general solution such as "Have a mode via a toggle button with which a tap reveals some help or additional information" would only work for some cases, not others. So I think had you provided a real use case (with user needs, mockups and problem-specific information) you'd get much better answers.
Thanks for your comments. I am hoping that the example (see the calendar widget image) serves as a real user case? user needs to know the additional info for each date in the calendar cell, which was exposed as "hover" with a mouse. Each date has to be "clickable" to navigate to a new page. We need to preserve this capability. And the real estate is limited since this calendar widget is only part of the page. Please advise if there is more info I should provide, or I should phrase my user case differently?
In the case of a calendar - using the (desktop) date-picker already means you are not using the right pattern for touch. Date picking on the iPhone, for example, uses a slot-machine style. Unlike the desktop version, you first choose the date, then press 'select'. This allows exposing additional information (like showing 'thanksgiving') before the user made a selection. So that's how things should work on mobile. I still don't feel that answers the question title though.
Um.This is not for iphone, only for TABLETS. We are hoping to have our web application run well on some major tablets. And it does except a couple of issues. How to deal with hover up is one of this. I am going to send a screenshot to describe the issue more clearly soon
Just edit my original question hoping to make the problem can be more specific. Thanks
I'd argue you can't treat mouse and touch based devices as one - if you're trying to create a catch-all design, one platform will have to suffer (obviously depending on the actual design, but this applies to any application with tooltips). From a usability perspective you should tailor the design to the device it'll run on, or simply accept you can't get it right on all.
Some of the issues here is that you're trying to convert something that currently exists and was designed for one type of device into something that works on totally different form-factors. You're going to have to make some awkward compromises as a result. Whereas if you were to start from scratch you could make these decisions in advance and not have to suffer as much compromise at a later date. But hindsight is a wonderful thing.
@JonW I totally agree. What happens is that, this web application has been live for a number of years (before touch screen is even invented). Now as tablets are getting so popular, the requirement is to make this web app work on tablets. It already does work pretty well most of the time, except hover-up tooltips and a couple of other stuff. I understand there might not be a good answer, and I am just trying to explore possibilities. Thanks so much for your input. I also edited my original post to add another concrete user case
You haven't gotten a satisfying answer because there is no satisfying answer. You are trying to make an application built with desktops in mind work well on a touch screen without changing your basic design, which is not possible.
On a desktop, you have multiple ways to trigger actions on something (click and mouse over), while on a touch screen you (basically) only have one--tapping. There is no way around this limitation.
If you must use the same design for both platforms, you should start by creating a good design for touch screens, and then adapting it to desktop. This will be much easier, because the touch screen interface is the more restrictive of the two. Most touch screen interfaces can simply be used on a desktop without modification (even if they are not ideal for the environment). Right now, you are trying the reverse, and this is bound to have unsatisfying results.
Besides the mouse-over problem, your design has other potential problems on touch, like controls that will be too small to use.
Given that a calendar is one of the basic apps available on every single touch screen device, you should really just look at how these calendars work and emulate them. Not only will it save you from having to re-invent a solution to this problem, it will also result in a design that is more familiar to the user.
I agree everything you said, particularly starting with designing for touch. Now in reality this web application has been live for a number of years (before touch screen is even invented). Now as tablets are getting so popular, the requirement is to make this web app work on tablets (not smart phones, so controls being too small is not much an issue due to bigger size of tablet screens). It already does work pretty most of the time, except hover-up tooltips. The screenshot I gave happen to have calender controls. and there are other scenarios that is not calendar. Any other thoughts?
@riceball, you could make the calendar a lot bigger (there is a lot of blank space around it in the screenshot, and other elements could be moved or reduced in size) and display the first part of the event name in each day box.
I agree that the calendar widget can be bigger. When you say "display the first part of the event name in each day box" -- do you mean "having the supplemental info" in the date cell? Can you elaborate a little bit more? Also I added another screenshot (Edit in bold in my original post) where there is really no extra blank space. I understand there might not be a good answer, and am just trying to explore possibilities. Appreciate your insights so very much.
@riceball, I focused on the one case you originally mentioned, showing extra info on the calendar. I meant the tooltip info. I don't think there is a general solution to this, you would have to design a work-around for each context.
You are absolutely right. Thanks for the inspiration on my first user case. Now I am thinking about enlarging this calendar widget, then adding "!" or "?" icon to dates that do have supplemental info. This way it could work out on both desktop and tablets (borrowing from below softserv's idea). What do you think?
@riceball, adding something like `!` is probably the best general solution to providing tool-tip information. But you risk having things too small to be usable, even on tablets.
I recently had a project with a similar challenge. I was charged with rebuilding an application that relied heavily on hover text for help. With the updates focus on tablet and devices I had to figure out a new way to present this information. As a result, I relied on a lot of tap to expand interaction.
After looking at your example. I am very glad the application didn't have a calendar. I'm incorporating a mock-up of a basic interaction. You see the content moves to accommodate the space and closes when not needed.
You could also overlap or cover content. My client felt it was important for the content to remain visible, but if that's not the issue an overlap would be just fine.
I know you didn't want to rewrite any code. I confess someone else built the final product, so I can't say how much code had to be rewritten, but it was built and all the interactions work just fine on tablet and desktop.
I don't think there are any good approaches that would require no changes to the site. I suppose you could consider a "touch and hold" option for more info (some phones do this), but that is far from a universal approach. I personally wouldn't do that, but just playing devil's advocate lol
If I were in this situation, I would see what could be done about adding a small icon next to these items: for example, put a "?" or a "i" icon next to the tool in question. With a mouse, the user could hover over this icon to see the tooltip. With a tablet, the user would click on that icon to see the tooltip. In the latter case, it might more sense to set up the tooltips so that they also have an option to close them manually. This keeps it contextual and on-demand.
Anything else that comes to mind for me would require far more work and doesn't seem feasible given your constraints.
adding "?" or "i" may work out in some cases, but not sure if everywhere -- some pages may have an ocean of "?" or "!" icons. For example, In my 2nd user case (in bold Edit that I added this morning), real estate is very limited for this data table, then many cells in this data table do have hover-up to display supplemental info on demand. Any thoughts? Also I am very curious to hear what else that comes to your mind? As you can see, I am in brainstorming stage, and any ideas are very welcome
Why not use a single tap to bring up a hover dialog that shows the informational tooltip. Eg., Thankgiving. In the same dialog, present a way to close the dialog, and also a link/button that takes them to the detail page. Basically, you are forcing the user to view the tooltip by default on the first tap. Then, the next tap brings them to the page they were originally looking for.
This seems like a needless delay. If I'm understanding you correctly, you're suggesting that you should delay the user from doing what she wants by providing supplemental information that she may not care about in place of the intended action. Is that correct?
Yeah, forcing the user to see the tooltip content *every time* even when they've seen it hundreds of times before isn't really ideal. How often do you re-check a tooltip on an item after you've already seen it once before?
You might want to see what Google Material Design Guidelines say about Touch UI tooltips.
Looks like it is triggered by a touch and hold. Then, when the user releases, it completes the desired action. That seems like a good way to handle it.
Here's what I consider a best solution and both Apple and Google agree.
Press the control (widget, whatever) If you wish to select the control, just click it.. no wasted time If you wish a tool tip, hold it and after 200ms the tooltip will be displayed until the touch is released. repeat
This is a close relation to the desktop action since tooltips don't usually pop up until the mouse cursor has been over the control for a short time.
I guess how people are supposed to know is from familiarity with touch devices.