PowerApps for the Fat-Fingered

My first memory of seeing a touchscreen goes back to a scene from the movie Die Hard (1988). Shortly before the bad guys appear, Bruce Willis as NYPD Detective John McClane finds himself at Nakatomi Plaza, a partly under-construction building where all the high-rise action would later unfold. At the lobby of the building, he exclaims “Cute toy!” as he tries out a touch-enabled kiosk.

Early touchscreens were definitely for the fat-fingered. — Die Hard (1988) / 20th Century Fox

Old touchscreens die hard

Functionally, the Nakatomi Plaza Directory was no different from information kiosks found in modern-day shopping malls. In this future we live in, however, handheld devices are the mainstream facilitators of touch input. Unlike the Nakatomi Plaza Directory, these contemporary devices are not designed to accommodate “fat fingers.”

Just because the cramped QWERTY-layout keys and buttons sliding up to occupy the bottom half of a palm-sized screen are mainstream does not mean they are universally accepted or preferred. Ensuring accessibility across input functions is a key (no pun intended) objective in any serious user experience design.

A fat-fingered PowerApps demo; see below for download details

There are other reasons why fat fingers will live on. There are professions and groups of users that operate with ruggedised gear, rely on in-your-face signs, and have very little appreciation for fine print and other subtleties. I once did a PowerApps project where the number-one design goal put forward by the client was support for fat-fingered operation. Reason: Their field operators carry around ruggedised Android devices for data entry at various locations, often under suboptimal lighting and climate conditions. The client specifically wanted to NOT see the built-in device keyboard pop up when entering scientific data into their mobile app; it would simply slow everyone down and raise their blood pressure.

Influenced by this guiding principle, most form fields in the project were engineered to accept either a numeric value or a selection from predefined choices. While designing a solution to the given requirements and specifications, my thinking evolved as follows:

1. To suppress the built-in device keyboard completely, turn textboxes into buttons that look and behave like textboxes. These textbox-looking buttons store values from user input as dynamic labels. [This was actually an afterthought, but deserves to be the foremost consideration.]
2. For number fields, provide big fat number buttons that collectively look like a numeric keypad. For choice fields, use galleries with adjustable widths and heights as opposed to placing native dropdown controls. After all, customising the appearance of controls is what PowerApps does best.
3. Wait, fat-fingered is the polar opposite of overcrowded. Struggling to find screen real estate for a numeric keypad between or below individual fields does not amount to much of an improvement over the built-in device keyboard. Same with galleries that do not provide sufficient padding between rows of choices. Lateral thinking is required for true fat-fingered operation…
4. Go big. Think outside the form. Why not use an entire screen for a keypad? Tapping a numeric field in a form switches to a screen that has a fat finger-friendly keypad. Upon entering a value into this dedicated keypad screen, the app swiftly takes the user back to the form, with the originating numeric field now neatly populated.
5. Likewise, use an entire screen for a scrollable gallery of choices. When a selection has been made, the app takes the user back to the form. PowerApps can easily pass data between screens. Use global variables, screen navigation parameters, or both.
6. But hold on — what if the form has dozens of numeric fields and equally many choice fields? What if the app has multiple such forms? It does not make economic sense to build hundreds of dedicated keypad and gallery screens, each one wired to a single field. The answer is a single generic re-usable keypad screen and a single generic re-usable gallery screen that work on any numeric or choice field. Even if an app has a thousand such fields, the total number of additional screens required to facilitate fat-fingered operation remains at two. Very doable.

There are, of course, various nuances to take care of when coming up with a robust generic design. For starters, not all numeric fields behave equally. Some expect digits below the decimal point while others accept whole numbers only. Other characteristics that impact validation and formatting of numeric data include negative numbers, minimum-maximum range, maximum number of digits, use of thousand separators, placement of commas and dots, and use of leading zeros.

For both numeric and choice fields, the user should have an option to “skip” the data entry or selection if the field they are looking at is optional by definition. Provisions for these things ultimately drive the quality and level of finesse across your app. But again, very doable once you know what you want to achieve.

The essence of a generic design

What I would like to document here is how the plumbing is done across screens to facilitate key concepts.

First, a generic keypad screen for numeric fields:

A design for a re-usable numeric keypad

• The OnSelect event of a numeric field does two things: first, it specifies the various behavioural parameters for the generic keypad screen; for example, whether to allow whole numbers only, the maximum number of digits, etc. Although you can create multiple global variables for each of the parameters, it is handy to have a single, resettable collection variable with multiple keys in it, using the ClearCollect function. When done, the OnSelect event navigates the user to the generic keypad screen for data entry.
• The generic keypad screen adapts the presentation and behaviours of its keypad to the parameters specified by the originating field. For example, if digits below the decimal point are expected, the keypad enables a button that enters a dot (.). Key-presses of the keypad buttons (0 to 9) assemble a number that will be passed back to the originating field upon save. In fact, all it needs to do is update the collection variable created earlier. One of the keys in the collection stores the number the user just punched in.
• The user is brought back to the screen containing the originating numeric field. The OnVisible event of the screen examines the collection variable designed for numeric fields, extracts fresh user input, and populates the originating field with it. When done, it clears out the same collection variable to prevent any unintended use of the last user input by other unrelated numeric fields.

This is how numeric fields are taken care of. Next, a generic gallery screen for choice fields works in similar fashion (see below). There is, however, one key difference: the originating field must also pass the actual choices for the user to select from. These choices are usually stored in some data source, object, or array. Because the one-size-fits-all generic gallery screen is, well, generic, it cannot look up arbitrarily structured data sources, objects, or arrays associated with different choice fields.

Instead, each choice field must “flatten down” its choice set into a single bar/comma/semicolon-delimited string using the Concat function. The generic gallery screen on the receiving end picks this up and unpacks the raw choice-string into a set of items displayed in its gallery using a mix of ClearCollect, Split, First, and RemoveIf functions. As the user makes a selection, the selected choice is passed back to the originating field.

A design for a re-usable gallery of choices

Suggested enhancements for the touch-savvy

As with all things in PowerApps, there is always room for further tweaks and enhancements. Here are a few:

• Dynamic screen titles. The generic keypad screen and the generic gallery screen can have dynamic titles to better inform the user what they are doing. Simply create another parameter passed on to each generic input screen.
• Preventing screen flickers. Switching between screens that have adaptive rendering may result in an unintended flickering effect. To prevent this, create an opaque rectangle over an entire screen and set its Visible property to the negation of a boolean variable that changes from false to true at the very end of the screen’s OnVisible event.
• Simulating a wizard with automatic sequential tapping of fields. This may save your impatient users a lot of taps when there are multiple related or dependent numeric and choice fields in a form. Instead of getting the user to tap into every single individual field that brings up a generic keypad or gallery, automate the taps in a predefined sequence so that the user goes through a wizard-like experience after which they will see a completed form for review. An example of this is a form with “Day” (numeric), “Month” (choice), and “Year” (numeric) fields. On first load of the form, the user gets to enter a day, select a month, and enter a year in an unbroken sequence as opposed to a continuous manual back-and-forth between the form screen and the generic input screens. To achieve this, place a series of If blocks and Select function calls inside the OnVisible event of the form screen. For this tweak to work, however, each numeric or choice field included in the tap sequence needs to have been implemented as a button that looks like a textbox.