How can I identify usage of hardware vs soft keyboard in a hybrid tablet?

Question

Problem:

I have a small group of roughly 90 users which is extremely important, so when one or two of these business customers desire the UI changed in their web app, they usually get development resources dedicated. However, it's important for us to understand exactly how the application is being used by the group as a whole because this group tends to have strong personal views on how their UI should look and they all use the app differently. I'm having the most trouble with identification of their usage of hardware vs soft keyboard. Optimally I'm looking for an answer as simple as, "use the new Window.TabletMode == true!" I don't think that simple answer exists.

Research:

• SO question Detect virtual keyboard vs. hardware keyboard is the only significantly similar question I see but it focuses half of its time on using a JavaScript keyboard to replace the soft keyboard, so the answers talk about how to make the keyboard specific to numbers, dates etc. Additionally, he's looking for cross-browser solutions where I need only IE11+ support. Finally, I can depend on the hardware keyboard being docked and a specific brand (Dell). Finally, I can depend upon Windows/IE11, so there could be other avenues of approach compared to this 3-year-old question. My use of a hybrid tablet also makes the approaches of capability checks useless since I already knwo all the capabilities (touch, etc) are already available on the device.
• I could check the Registry for the UI setting, but I really need to stick to JavaScript or something similar.
• Android has undocumented but known events which indicate showing and hiding of the keyboard. However, none of the users will be using Android.
• IE should receive a WM_SETTINGCHANGE message when the change occurs, but I'm unable to determine if this is made available to a JavaScript API. I'm thinking it would be a message far more specific (if any), so I can't find anything with this search term and JavaScript.

Code:

From W3Schools,

The window.orientation property returns 0 for portrait and 90 or -90 for landscape view.

Combined with window.innerHeight, I could use something like...

var portrait;

$(window).on("orientationchange",function(event){
  if (event.orientation == 0)
  {
     portrait = true;
  } 
  else //if not, it's landscape
  {
    portrait = false;
  }
});

Then I would use window.innerHeight in combination with the value of portrait to determine if the width to height ratio looks like I have a keyboard open. This approach really might work in fullscreen considering my fairly narrow constraints, but what if the browser isn't fullscreen? I'm sure there are plenty of other reasons to not write a hacky ratio calculation for this. Additionally, my greatest desire would, of course, be to do this with any browser and any screen size.

These things I can handle: I'd need to set variables on the loading of the document and work out a way to determine when the typing becomes relevant. I might need to check for some browser capabilities. Perhaps I'd increment counters for typing with and without a hardware keyboard. Once I hit a certain number (let's say 5 keystrokes), I'd send a POST request to my data tracking endpoint to let it know that session 12345 used the soft keyboard (or hard keyboard). Afterwards, I'd unsubscribe from the event handler. However I work this part is of less concern because I don't think I'll get stuck on anything, but I didn't want anyone to spend time on beautification or development of a huge example.

Environment:

• Hardware should all be Dell tablet/laptop hybrids (specific model TBD) with IE11+. I hate to make something IE specific, but if it runs on IE11+, it's totally acceptable.
• I should be able to pull in any sort of JavaScript libraries suggested, but keep in mind that JQuery 2.2 and Knockout 2.1 are already present, so little "weight" is added for a solution with JQuery usage.
• I probably can't get approval to write an application that uses ActiveX or some other heavy handed customized approach that would require installation of a local application because my company has roughly 50,000 users, and a deployment like that for 90 users would be overly complex to maintain.
• The screen sizes should all be 11 inches, but I'd be sad to resort to using specific size and resolution because an answer like that would be extremely limited in application for me or future readers.

Impact for Readers:

I'm seeing a move away from Ipads in the medical kiosk / EMR space because Ipads limit a lot of the UI choices in favor of a cohesive experience. Physicians especially will often get attention of high ranking IT leaders if they desire a very specific UI change. Microsoft has tended to allow a lot of non-standard intervention and (more recently) more standard types of intervention in how the browser works. I think a lot of this movement is going to Windows tablets for this reason and also for the reason that many medical groups are heavy on .NET development capability.

Answer 1

Bottom Line: You can't get exactly what you want. With IE11 you actually have a couple other challenges. You can't simply use the Fullscreen API with promise = element.requestFullscreen() because IE will request permission from the user first, and the API lets you check for capability but not state. Also, multiple fullscreen applications can share the desktop in Windows 8 and 8.1, which is a bit counterintuitive.

However, if you can count on the web app probably being fullscreen, your "hackish" JavaScript solution probably is the best answer. Get the initial dimensions when the document loads and compare during key presses. As a side note, keep in mind that the user might not be using the software keypad just because he or she isn't in the dock. The user still needs to explicitly open the software keyboard.

If you had said "Android only", it would be an easy solution, but you already demonstrated you knew that in your question. If you wanted to use a desktop app, there is some MSDN documentation on a hardware token here but again you specified that this wouldn't be simple enough.