Adobe insights about creating, delivering and monetizing digital content across platforms and devices

Post navigation

Mobile Development: screen orientation and custom keyboards

I first started to create mobile applications last year once I got my hands on early builds of AIR 2.5 for Android. Since then I’ve built a number of mobile applications and I’ve talked to people smarter than me about mobile development.

Trust me, if you are like me, a developer with background in web/desktop applications, than this transition is not that easy. The “canvas” you have on mobile devices is much smaller, and the touch input user interface introduces a whole new universe.

So I thought I should share my experience by starting a series of articles. And hopefully I can get feedback from you, because as said, I’m not a user experience ninja. I’m just a developer.

In this first article of the series, I want to cover two topics: screen orientation and custom keyboards.

Screen Orientation

As if we didn’t already have enough complexity on mobile devices (different screen sizes and densities) on smartphones and tablets you have a feature called screen orientation. Basically, a user can hold a device in a portrait or landscape orientation. Adobe AIR provides support for this feature; you can code your application to account for screen orientation changes.

And this is great! Right? If some users prefer to work with your application in portrait mode and others in landscape, you can make them all happy by supporting both use cases.

Let’s stop for a bit and take a look at this feature in action. The screenshots are taken on my Android phone. In the picture below you can see the default soft keyboard pulled out when you want to type an URL in the browser. Obviously, what we have here is a landscape orientation.

The picture below shows the same application as the one before, but this time the device is held in portrait mode.

After I used this application in both orientations, this is what I thought about the pros and cons:

The soft keyboard takes a lot of space when is displayed. Thus you will see more of your application UI if the device is held in portrait rather than than landscape.

The bigger the device gets, the harder it is to type with both hands when holding the device in landscape. Indeed, if you’re not a basketball player, you will find it harder to type fast on a tablet when in landscape compared to portrait mode.

Custom Keyboards

All modern mobile OSes have built-in support for soft keyboards (on screen keyboard). Depending on the OS flavor you might have different keyboards, slightly optimized for a specific task (email/Internet, generic text, and so on).

All the Calculator applications I’ve seen running on these devices have a custom keyboard. The next picture is a screenshot of my Android phone running the default Calculator application.

Why does the Calculator use a custom keyboard rather than the standard soft keyboard? The answer in this case is obvious: because it has only the keys that are used by the application, this custom keyboard is much more optimized than the standard keyboard. The standard Android numeric keyboard has about 30 keys and the Calculator one has 16. Because of this difference, you not only get bigger keys but you don’t get noise (keys that are of no use in the Calculator context).

Below you can see a custom keyboard I created for an application that helps you to split the restaurant bill.

Conclusions

In conclusion, although people are used to changing the device orientation, you might want to reconsider this for your application and design your application for either landscape mode or portrait mode, but not both. Although this might seemed like a bit drastic, I do think that sometimes it could make sense.

For example, an email reader app if used in landscape mode on a tablet gives readers two panels at the same time: a panel displaying the messages and one displaying the content of the current selected email. You don’t even have to force your users to use one orientation though. In the example above, when the user wants to use the device in portrait mode you can hide the messages list panel.

Second, you should always ask yourself if your application can benefit from having a custom keyboard instead of the built-in keyboard.

This was my first post from the series. In the next posts I will go deeper on how to create custom keyboards, how to deal with screen orientation, and how to adapt your layout to resolution just to name a few.