Find an alternative to tooltips for touch interfaces

[Continuities]

ADR relies heavily on :hover tooltips for delivering information. This obviously doesn't work on touch interfaces. This is the final hurdle to making ADR fully mobile-friendly.

[AndySky21]

What if a :focus state is used together with :hover? in order to enable this, all we need is a tabindex attribute on things with tooltips, e.g. in room, outside and world. Then elements become "interactive" and can be focused either with tab navigation, or with touch. Tabindex number could be set according to the active panel (i.e. all focusable elements on Room have tabindex=1, Outside: tabindex=2 and so on). This means that tab order will entirely depend on tree order, so no issue with reordered stuff or non-linear disposition. Unfortunately I don't play ADR on mobile devices, so even if I can work it out, I can't test it then.

[Continuities]

The issue here is less technical, and more design. The question isn't "how do we open the tooltips?" it's "how do we convey the same information without tooltips?" Pure touch interfaces lack the ability to focus on an element without activating it (like hovering the mouse without clicking). Thus, showing contextual information based on interaction isn't really possible in the same way.

On Wed, May 20, 2015 at 2:05 PM Andrea Rendine notifications@github.com wrote:

What if a :focus state is used together with :hover? in order to enable this, all we need is a tabindex attribute on things with tooltips, e.g. in room, outside and world. Then elements become "interactive" and can be focused either with tab navigation, or with touch.

— Reply to this email directly or view it on GitHub https://github.com/doublespeakgames/adarkroom/issues/12#issuecomment-103976353 .

[AndySky21]

You mean that focusable elements cannot be focused with touch unless they have an activation behavior? Really? ...wow.

[groteworld]

How about high-jacking the tooltip for mobile and displaying it in a confirm, modal, something?

On Wed, May 20, 2015 at 2:09 PM, Andrea Rendine notifications@github.com wrote:

You mean that focusable elements cannot be focused with touch unless they have an activation behavior? Really?

...wow.

Reply to this email directly or view it on GitHub: https://github.com/doublespeakgames/adarkroom/issues/12#issuecomment-103977633

[groteworld]

NOTE: I don't love it because it isn't consistent with the  web game, but it is an easier fix.

On Wed, May 20, 2015 at 2:09 PM, Andrea Rendine notifications@github.com wrote:

You mean that focusable elements cannot be focused with touch unless they have an activation behavior? Really?

...wow.

Reply to this email directly or view it on GitHub: https://github.com/doublespeakgames/adarkroom/issues/12#issuecomment-103977633

[AndySky21]

I'm testing it with an emulator, so not completely sure if it works, but.. Touch interface with simple <div tabindex="1"> elements works, in the sense that it allows application of :focus state. IMHO all we need is to use tabindex and change CSS so that :hover tooltips also appear on :focus.

[AndySky21]

I'll submit a very small experiment with room. See if it works, when you can.

[AndySky21]

393 done. It's just for room stores, actually.

For buttons, I have an idea but it will take some days. Button > touch: tooltip appears, no activation behavior. Below the tooltips, there could be a control with the proper name (e.g. Build, Buy, Craft) that actually activates said control. A 2-step activation. Luckily, in ADR there are no real "buttons" but elements with an onClick action, and this can be played with.

[Continuities]

Yeah, if you do that then a touch will also trigger a focus which will allow the tooltip to open on touch. The problem that I was trying to articulate was that touching a button to focus it would also click the button, so there's no way to open the tooltip without taking an action.

The two-step is basically how Amir solved the problem in the iOS port. I don't really like it, but there may not be another way.

On Wed, May 20, 2015 at 2:42 PM Andrea Rendine notifications@github.com wrote:

393 https://github.com/doublespeakgames/adarkroom/pull/393 done. It's

just for room stores, actually. For buttons, I have an idea but it will take some days. Button > touch: tooltip appears, no activation behavior. Below the tooltips, there could be a control with the proper name (e.g. Build, Buy, Craft) that actually activates said control. A 2-step activation.

— Reply to this email directly or view it on GitHub https://github.com/doublespeakgames/adarkroom/issues/12#issuecomment-103990833 .

[AndySky21]

Either a 2-step, or (if at all possible) a timed touch. On focus the tooltip appears, while if the button is touched for, say, 3 seconds, the action is triggered. This will allow users to speed the interaction (basically skipping 1 passage) when the tooltip is repetitive (e.g weapons cost)

[Continuities]

So a long-press to activate any buttons? I don't think I've seen any other webpage/app that behaves like that, so it's unlikely that it'd be discoverable. I guarantee that we'd be inundated with "the buttons don't work!" bug reports.

On Wed, May 20, 2015 at 3:42 PM Andrea Rendine notifications@github.com wrote:

Either a 2-step, or (if at all possible) a timed touch. On focus the tooltip appears, while if the button is touched for, say, 3 seconds, the action is triggered. This will allow users to speed the interaction (basically skipping 1 passage) when the tooltip is repetitive (e.g weapons cost)

— Reply to this email directly or view it on GitHub https://github.com/doublespeakgames/adarkroom/issues/12#issuecomment-104010593 .

[AndySky21]

hmm I suppose it's true, the worst part in interfaces is to make users understand how they work. Some players are discovering ADR tooltips just now... I only have to refine last commits, then I could try. I hope that my last pull requests are correct.

[wmassingham]

You could also add something on the button to convey that it consumes items. Either a little icon like with Font Awesome, or Unicode chararacters like 🌳 (which requires a compatible font) (edit: github converted it to an emoji), but that's bringing some imagery into an otherwise purely textual game.

Or, in the style of games like Nethack, use a character to represent items like enemies currently are. So for example, the button to go into a cave might say Explore -1i, i representing a torch. (And to communicate that i = torch you could put it on the inventory too.)

Or just go the direct route and make buttons bigger and put -1 torch right on the button, but then buttons that require multiple types of items could get really big, though that's less a problem for mobile.

[Continuities]

The suggestion to add touch-specific content directly into the buttons got me thinking. What if we added a "view cost" indicator to buttons that have costs. Tapping the indicator would open the hover overlay, while tapping the button proper would attempt to purchase. Best of both worlds?

On Tue, Jun 2, 2015 at 11:38 AM Webster Massingham notifications@github.com wrote:

You could also add something on the button to convey that it consumes items. Either a little icon like with Font Awesome http://fortawesome.github.io/Font-Awesome/, or Unicode chararacters like 🌳 (which requires a compatible font), but that's bringing some imagery into an otherwise purely textual game.

Or, in the style of games like Nethack, use a character to represent items like enemies currently are. So for example, the button to go into a cave might say Explore -1i, i representing a torch. (And to communicate that i = torch you could put it on the inventory too.)

Or just go the direct route and make buttons bigger and put -1 torch right on the button, but then buttons that require multiple types of items could get really big, though that's less a problem for mobile.

— Reply to this email directly or view it on GitHub https://github.com/doublespeakgames/adarkroom/issues/12#issuecomment-107993935 .

[wmassingham]

I feel like that would have the issue of potential mis-clicks (build when you want to see cost).

I made some mockups of my three suggestions, and the confirmation screen: https://moqups.com/wmassingham@gmail.com/9lffui2l

I don't like two-step solutions, because it just feels clunky to me, especially when it's not that dangerous.

[Continuities]

Yeah, I'm not a fan of two-step either. #3 would probably work in a more mobile-centric view with vertical scrolling. Man, now I wanna do a full responsive overhaul...

On Tue, Jun 2, 2015 at 12:27 PM Webster Massingham notifications@github.com wrote:

I feel like that would have the issue of potential mis-clicks (build when you want to see cost).

I made some mockups of my three suggestions, and the confirmation screen: https://moqups.com/wmassingham@gmail.com/9lffui2l

I don't like two-step solutions, because it just feels clunky to me, especially when it's not that dangerous.

— Reply to this email directly or view it on GitHub https://github.com/doublespeakgames/adarkroom/issues/12#issuecomment-108006539 .

[groteworld]

It will need it to properly fit on a phone

What if a third  ( or fourth) of the width on the right side of a button was sectioned off for info?

On Tue, Jun 2, 2015 at 12:36 PM, Michael Townsend notifications@github.com wrote:

Yeah, I'm not a fan of two-step either. #3 would probably work in a more mobile-centric view with vertical scrolling. Man, now I wanna do a full responsive overhaul... On Tue, Jun 2, 2015 at 12:27 PM Webster Massingham notifications@github.com wrote:

I feel like that would have the issue of potential mis-clicks (build when you want to see cost).

I made some mockups of my three suggestions, and the confirmation screen: https://moqups.com/wmassingham@gmail.com/9lffui2l

I don't like two-step solutions, because it just feels clunky to me, especially when it's not that dangerous.

— Reply to this email directly or view it on GitHub https://github.com/doublespeakgames/adarkroom/issues/12#issuecomment-108006539 .

---

Reply to this email directly or view it on GitHub: https://github.com/doublespeakgames/adarkroom/issues/12#issuecomment-108008587