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:
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.