31 Days of Windows 8 for HTML5 | Day #15: The On-Screen Keyboard
31 Days of Windows 8 for HTML5 | Day #15: The On-Screen Keyboard
Join the DZone community and get the full member experience.Join For Free
Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.
This article is Day #15 in a series called 31 Days of Windows 8. Each of the articles in this series will be published for both HTML5/JS and XAML/C#. You can find additional resources, downloads, and source code on our website.
Today we are going to take a look at the on-screen keyboard in Windows 8. Microsoft does not seem to make a distinction in naming between the keyboard that appears when you tap your finger on a input control and the one that can be found in the Ease of Access Center. We are going to focus today on the keyboard that looks like this:
The Ease of Access On-Screen Keyboard, on the other hand, is a tool designed for making a computer easier to use for those that may not be able to use a keyboard at all. It can be found by opening the Ease of Access center on your machine…
And clicking the “Start On-Screen Keyboard” option. You will discover a keyboard that looks like this, instead:
The primary focus of this keyboard is to allow a user to completely use Windows without having a keyboard attached to their computer. It’s not customizable, and doesn’t respond to any of the code we are going to write in this article. This keyboard is also one of the only windows that can be placed over the Start Screen. Check this out:
OK, so I’ve spent the first few paragraphs of this article talking about a keyboard that is NOT the focus of this article. Why? There are two reasons:
- If you are using a non-touch device when you work through this article (or on your own app and want to use the features of the regular touch keyboard), you’ll find that mouse clicks don’t launch the touch keyboard on your machine. So you’ll search the web looking for a solution to make it show up.
- As you search around the web looking for more information about manipulating the on-screen keyboard in Windows 8, you’re going to get plenty of articles on the Ease of Access one, which is likely not what you wanted. If you do find an appropriate article about how to turn on the touch keyboard, it’s likely this one, because I wasn’t able to find any way to make this work.
The primary reason for this is because this is one of the few times that Windows 8 makes a distinction between a mouse click and and finger tap. If you mouse click on a input box, Windows 8 assumes you are using a real keyboard, even if you’re using a touch-enabled machine. A finger-tap, however, will produce that keyboard we’re going to talk about today.
To save you some frustration, when developing your application that will take advantage of the on-screen keyboard, use the simulator if you’re not working on a touch machine. It allows you to simulate “taps” with your mouse. Here’s where you set it:
OK, now that we’ve gotten all that out of the way, let’s get this actual article started.
Using the On-Screen Keyboard
First, let’s take a look at the default states of the on-screen keyboard that the user can navigate to any time the keyboard is open. We saw the standard QWERTY view earlier:
But there are several more. When we build an application, our primary focus, above all else, should be to make the tasks a user needs to accomplish as easy as possible. (That IS on the top of your mind, right?) To that end, the on-screen keyboard can be manipulated to make that happen. Our input element has had this notion of a type now for some time. With HTML5 we had a number of new types introduced such as datetime, email and more. This type attribute will activate the the appropriate keyboard for the task at hand. If type is not specified, the normal keyboard will be displayed. Here’s what the code looks like:
<input type="number" value="1234" />
You will find, as you start playing with the type attribute, that there are a large number of types, actually 23. Now these of these 23 input types they are not all applicable in changing the keyboard. For example a datetime type isn’t going to provide you a different keyboard other than the standards keyboard. Let’s look at how these input types might change the keyboard layout.
Standard Keyboard Layout
<input type="color" value="color"/> <input type="date" value="date"/> <input type="datetime" value="datetime"/> <input type="datetime-local" value="datetime-local"/> <input type="month" value="month"/> <input type="text" value="text"/> <input type="time" value="time"/> <input type="week" value="week"/>
<input type="search" value="search"/>
Enter key changes to Search.
<input type="email" value="email"/>
Added “@” and “.com” buttons, smaller space bar
<input type="url" value="url"/>
Added “/” and “.com” buttons, smaller space bar, Go key ( as enter )
<input type="number" value="1234567890"/> <input type="tel" value="111-111-1111"/>
<input type="password" value="password"/>
Added the Hide keypress button
- type=”file” brings up the file picker
- type=”hidden” hides it, what else
- type= [“radio”] or [“range”] or [“reset”] or [“submit”] brings up a native looking control
In addition to our types, it’s important to understand the other options our users can navigate to at any time when the keyboard is on the user’s screen. Here they are:
Symbols (a second set of symbols after the set shown with the Number keyboard)
Split Keyboard (a user choice, this keyboard is optimized for thumb typing)
Inking Keyboard (this keyboard does handwriting recognition)
Obviously, this is a huge set of input points for us as developers, and by providing the right keyboard for the job will make your app more useful to your users.
On last point, you can’t launch the on-screen keyboard via code at all. In fact, setting the focus on a input control won’t do anything but make the cursor blink. It specifically requires a tap event (not a mouse click) to occur on the input box before the on-screen keyboard will appear. (This is the same reason why you should use the Simulator when debugging this type of functionality in your apps.)
Today, we’ve covered off on the variety of keyboards that are available to our users. We can leverage input types to show the right keyboard at the right time. In addition, we learned that there are 30 entire pages of Emoji characters to use as well. (If it’s not obvious, we benefit greatly from writing these articles as well!)
If you would like to see a working application that uses all of the input types, click the download icon below:
Tomorrow, we are going to dive into using Context Menus to gather data, both in our application, as well as from buttons in our AppBar control. See you then!
Published at DZone with permission of Clark Sell , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.