Skip to main content

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

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

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex