Tuesday, April 10, 2012

Detect whether browser has keyboard/arrow keys in web page


I have a full-screen game in HTML+JavaScript, which uses the arrow keys as primary controls. This cannot be used on keyboardless Android devices (I haven't tested on iOS), and even if the soft keyboard had arrow keys it would take up unnecessary space. Therefore, I have added onscreen control buttons. However, the buttons are unnecessary (and absurdly large) on desktop browsers, so I would like them to not pop up unless they are needed.



What heuristics can I use to decide whether they are needed — that is, whether it is impossible or awkward for the user to input arrow-key events — other than recognizing specific User-Agents (which is straightforward, but not future-proof)?



I will of course allow the user to hide/show the buttons; I am looking for useful heuristics for choosing the default setting.


Source: Tips4all

9 comments:

  1. No need for any user-agent sniffing, config options or any kind of guessing. Just do this:


    Have a title screen which says "press to continue".
    On click or key press, hide touch controls and start game.
    On touch, show touch controls and start game.


    You never even needed to mention the option to the user and you auto-detected their preferred control perfectly.

    ReplyDelete
  2. Use feature detection with Modernizr: http://www.modernizr.com/docs/#touch

    While this is not a reliable way to check if the user has a keyboard it is definitely reliable to see if the browser is capable of touch.

    ReplyDelete
  3. You can check the user agent for android, iphone etc. . .

    http://www.hand-interactive.com/resources/detect-mobile-javascript.htm

    ReplyDelete
  4. If you have only arrows (left/right/up/down) you might consider adding touch-events inside the game field? This would not take up space obviously as it is layered on top of the game, so it could be 'always on'.


    A computer user would not even know it is there, though he/she could use them to play your game with a mouse I guess.
    The touch-device user on the other hand can much more easily use the "areas" (mid top, mid left, mid bottom and mid right for instance) because of .. well.. touching instead of using a mouse.


    This might need some explaining, as you probably would not want the points to be visible to the user, but it feels like a valid option.

    Even if you have 4 buttons and a 'fire', you could do this, for instance by adding a 'middle' section.

    ReplyDelete
  5. look for touch specific events such as touchstart or gesturestart and show the onscreen controls if detected.

    http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html

    I am not sure if the system-info api has been implemented by any browsers:
    http://www.w3.org/TR/system-info-api/

    ReplyDelete
  6. rather than displaying the on-screen keyboard by default, add a button to toggle the display of the on-screen keyboard.

    It might also be prudent to give the on-screen keyboard the ability to be resized.

    Edit to answer question:

    Keyboard should be hidden by default if most of your users are going to be on a computer,

    Visible by default if most of your users are going to be on a mobile device.

    ReplyDelete
  7. Instead of trying to guess, make it a config option for the user to choose.

    ReplyDelete
  8. Check if the device supports touch events with the Touch object. If not, it's a desktop browser. This is the most literal way to determine if you need touch controls.

    function hasTouch() {
    return (typeof Touch == "object");
    };


    Demo: http://jsfiddle.net/ThinkingStiff/5DCeH/

    ReplyDelete
  9. You could use javascript to find out the height of the windows view port and then us an if statement saying:

    if ($(window).height() <= "960")) {
    //Your code to display keyboard controls
    //P.S. 960 is height of iPhone 4+ screen
    }


    Edit: Left out ) at end of $(window).height() <= "960"

    ReplyDelete