Free-form Apps
Free-form apps can put the important elements of the user interface anyplace on the screen. Hybrid apps are the same as grid-based apps but you may want your keyguard to expose parts of the keyguard that you can’t by exposing an entire message/command bar or a set of buttons. On the other hand you may have a unusual tablet case that doesn’t have a standard rectangular opening and need to change the outline of the keyguard to make it fit properly. All of these things are possible using OpenSCAD and telling keyguard.scad exactly where and how big to cut holes. It’s also the way that you can engrave text on the top or bottom surfaces of the keyguard to personalize it or mark it with a serial number.
We begin with a description of how to create a keyguard for a free-form app but almost all of that information applies to hybrid keyguards as well.
What is a Free-form App?
AAC apps often organize their content into grids – but there are some apps that take an entirely different approach. One example is the AACORN AAC app from AACORN. As you watch the video below, note that there are times when objects in the user interface are arranged in a grid but that is not the basic way the app is used to generate speech:
https://www.youtube.com/watch?v=wXucFujbsG8
At the core of the AACORN AAC app is a “word tree” which has a center button and is surrounded by 5, 6, or 7 buttons (depending on how you count them). To the left of the tree are seven shortcut buttons that can be used to start the tree. At the top of the app screen is a large bar that displays the phrase or sentence as it is built. None of these things are laid out in a grid so creating a keyguard for this app will require complete flexibility around where the openings in the keyguard appear, how large those openings are, and how the openings are shaped.
Static Modes of Usage
Before you can start the process, there are some practical issues that have to be addressed. Grid-based AAC apps tend to be very static in their layout – meaning all the objects in the user interface tend to stay where they are and stay the same size from the moment you launch the app until you close the app. Non-grid-based apps can behave very differently. Objects can move around the screen and the overall layout can alternate between non-grid-based and grid-based depending on which objects you touch. Since a keyguard is a rigid device and since it can be difficult to swap one keyguard for another (either because it is mounted tightly to the tablet or because it would require intervention by another person), you should determine if there are ways to use the AAC app in a mode where the screen layout doesn’t change.
For example, while the AACORN AAC app described in the video above seems to be very fluid in its layout, there are two ways you can effectively use the app that wouldn’t require removing and replacing one keyguard with another that had a different layout.
Mode 1: Word Tree
“Word Tree” mode is the distinguishing capability of the AACORN AAC app. In this mode, the user builds phrases and sentences dynamically by interacting with the six or so objects of the Word Tree:
One more object important to interacting with the tree, but not included in the image, is located to the right at the end of the green line. It is used to bring the tree back to its previous form. The button with the “+” on it is used to add a new word to the category. Since that requires a new screen layout, the “+” button is not included in this usage mode.
These 6 or so elements don’t change size, location, or shape as the phrase is built.
The tree has to be “seeded” with a word or category of words. That action can be accomplished by choosing one of the shortcut objects to the left of the tree on the same screen:
The up and down chevrons are used to navigate through the 21 shortcut choices.
These shortcut objects also don’t change location, size, or shape as the user builds their sentence.
Finally, there are two other screen objects that display the sentence as it is built:
And a message bubble that causes the app to speak the whole phrase/sentence:
All other screen elements take the user away from this screen and should be covered by the keyguard to prevent them from being touched accidentally.
An appropriate keyguard to support this mode of use might look like this:
In order to ensure that this mode will work, a sufficient number and variety of shortcuts must be set up that will support initiating a useful tree for most settings the user might find him or herself in.
Mode 2: Favorites List
The AACORN AAC app supports the creation and storage of a large list of canned phrases and sentences. These are called “Favorites”. The Favorites screen looks like this:
The user of the app simply taps on a row of words to have the app speak the entire row. There is a slider to the right of the rows that is used to scroll through the list. At any point, four rows of “favorites” can be displayed. This approach allows for fast delivery of speech (because it is pre-constructed) but there is no support for ordering the favorites or quickly finding an appropriate response except by scrolling. The four lines of favorites and the slider are the only screen objects necessary to utilize this communication mode of the app. All other objects on the screen are irrelevant or navigate away from this screen.
An appropriate keyguard to support this mode of use might look like this:
Unfortunately, these apps rarely consider their use with keyguards when they are designed and critical screen objects are placed very close to each other. That makes it difficult to put a physical divider, like a keyguard rail, between them without the rail being very thin, flexible, and fragile. In the above example, you may be able to address this problem by covering the written words a relying only on the images.
Once you’ve settled on a procedure for using the app that results in a relatively static screen layout, it’s time to start specifying the location, size, and shape of each opening in the keyguard. There are, no doubt, many ways to collect this information but I’d suggest starting with a screenshot of your app. Identify, and number each important element of the screen you’re targeting:
The following videos will take you through the process of creating a free-form keyguard.
First we’ll take a look at the app to see if there’s a way to use the app effectively – without needing to swap keyguards constantly because the screen layout is changing:
Second, we’ll gather information about the screen objects we need to access. We can take our measurements (in pixels) from a screenshot:
Or we can measure directly (in millimeters) from the running app:
Third, we’ll open up keyguard.scad in OpenSCAD and two of the .txt files in Notepad++ – and begin to enter the data we collected.
The following video talks about using a file called “data.scad”. The program has since changed to use one file: “openings_and_additions.txt” is used to make cuts and engrave text in the screen area of your keyguard. It can use measurements whose units are either pixels or millimeters and you can specify whether the measurements were taken from the upper-left or lower-left of the screen opening. Measurements, for cuts in the case opening region, must be in millimeters and must be taken from the lower-left corner of the case opening. It’s the file you’d use to make the keyguard fit in a case that doesn’t have a rectangular opening.
Fourth, we’ll test the layouts before printing the full keyguard. One way to do that is by printing the first few layers and comparing that to the app:
Another is to compare the image from OpenSCAD to your screenshot.
Fifth, we’ll go back to OpenSCAD and add any wall slopes before saving the design as an STL and printing it.
Sixth, we’ll test the printed keyguard, just to be sure we didn’t mess up.