Like the iPhone, the iPad has only one primary button on the front of the device and a few buttons on the sides (for volume and on/off). The logistics of a kiosk mean people shouldn’t be allowed to randomly quit the app so you have to disable the iPad buttons by jailbreaking—and installing the appropriate software—or by disabling them physically (by covering them up). For physical barriers, there are a number of existing products such as the nice looking Beyond Kiosks, the more portable iBracket or simple DIY projects like this wooden kiosk stand. I’m not sure how the wooden kiosk stand would hold up to abuse but, hardware aside, it comes down to the software problems.

To run successfully as a kiosk, the kiosk app needs to be the only app running on the device without the ability to exit the app in any way (at least without removing the iPad from its enclosure). The iPad doesn’t offer an easy way to force an app to stay open but you can be sneaky and do things like launching the app again whenever it happens to close:

-(void)applicationWillTerminate:(UIApplication *)application {
    [application openURL:[NSURL URLWithString:@"mykioskapp://"]];
}

Note: Doing this would probably get an app rejected from the App Store.

Care must also be taken not to include any way for a user to accidentally jump into another application, such as the web browser or the email app. If someone gets out of the kiosk application they’ll probably be confused but, more importantly, they’ll be stuck with no way to get back because the only buttons that would return them to the kiosk application have been disabled or covered up.

The other software problem is dealing with the Apple App Store submission process. Running in a kiosk could initially be great since a kiosk app probably isn’t going to be distributed through the app store. Instead, it will be easily loaded on each kiosk directly. Both a development distribution or an over-the-air Ad-Hoc distribution would work but each come with their own problems. Anyone who has dealt with Ad-Hoc or development distributions knows that the certificate process isn’t fun and just when you think you have it sorted out, the provisioning profiles on the devices expire and you have to repeat the process. It would be great to bypass the burden of the Apple App Store rules and regulations but to do so someone will need to be on-site to update the app on a regular (monthly) basis as the development or Ad-Hoc distributions expire or the app itself needs updates.

The idea of an iPad kiosk is obviously possible and there are a few existing companies already using it for things such as ticket sales or product information. If I get any further into the project I’ll post some updates and let you know how it goes.

One of the biggest hurdles with UiTextInput is that you don’t get the benefit of the great UI work that Apple has put in their core iPhone text inputs. There’s no text selection, magnification loops, copy/paste or any of those other things we take for granted when we use the default inputs. If you want advanced editing features you have to implement them all yourself—and it’s a lot harder than it looks.

Text selection, for example, is something that you’re probably familiar with if you’ve used an iPhone or iPad but have you ever stopped to actually look what’s going on? The subtleties of the touch interaction are very intuitive but may not be what you expect when you think about it. For example, here are few things you may not have noticed when editing text in something like the default notepad.

• When you quickly single tap, the carat is placed in the text where you tapped but it’s position is based on word boundaries. A mouse click in a word processor places the carat at the point where you clicked but a tap in iPhone OS places it in front of or after the word, depending on which end of the word was nearest the tap.

• Holding on a word will reveal a magnifying loop that gives you fine grained control over the selection. This is the only way you can place the carat within a word.

• The select/select all/paste menu will appear if you long-tap. As a result it will always appear after the loop is shown but could also appear if you touch and release just before the loop shows (of course you’ll be selecting and pasting on a word boundary in the latter case).

• The “select” option in the menu always starts by selecting a full word. Which word depends on where the carat is placed. If the carat is in a word then that word will be selected. If the carat is at the beginning of a word, between the space and the first letter, then the word following the carat is selected. If the carat is at the end of a word, before the following space, then the word preceding the carat is selected.

• Double tapping a word will immediately select it. If you hold and drag on the second tap you can select a larger range based on where you drag. Interestingly, the range selection also has a magnifying loop—but with a different shape—so you can have fine grained control at the end of the selection.

These are just a few of the subtle interactions that most iPhone users just do without thinking about. If you’re going to implement your own UITextInput be sure to closely look at the existing text inputs and how you typically interact with them as you’ll need to implement yours the way users will expect it to work.

Designing a great app isn’t a simple task. Jacob Nielsen recently asserted that “the mobile user experience is still miserable.” Extracting user insights from testing is a challenge. People have difficulty telling you what they want; they usually only know it when they see it. But developers don’t have to tackle user research alone. Interaction designers are trained to find relevant user groups, talk to customers and read between the lines. They understand how real-world context affects an application’s design.

It takes a lot of leg work, but your efforts to understand user needs will be rewarded. The forefront of mobile technology is an exciting place to be.