This problem stems from the problem area Flexible user interfaces in the main problem area Utilizing screen space.

Background

On PDAs without keyboard, a common solution for entering text is to show a software keyboard on the bottom of the screen where the user can enter text using the stylus. The area in which the keyboard is shown may already be used by the application. This means that the application have less room for its “normal” interaction.

Problem

The main problem when designing a user interface that should be able to handle that the software keyboard comes and goes is how to resize the dialogs. Resizing may just imply adding/adjusting a scroll bar, but often some other adjustments are needed to avoid some parts of the dialogs becoming invisible.

The severity of this problem is depending on the type/style of the user interface. If the UI only contains an arbitrary text, adding or adjusting the scrollbar is a sufficient solution. A forms-based UI may be much more difficult to resize. The same may be the case for a more visual presentation, depending on whether the visualization is tailored for the screen size or not. Handling tab folders and buttons that are placed on the bottom of the screen is also a challenge.

The design patterns presented in this problem focus on forms based UIs, because it is mainly for this type of UIs that this problem occurs.

Solutions approaches

A buffer solution (see design patterns below) may also be used with two or more large UI controls sharing the amount of size reduction to be applied. Generalized, this solution ends up as dynamic resizing of the controls in the UI. This may be done using two different approaches. The first is to decide a resizing rule for each window and apply that as tailored code for each window. The second is to have a general layout adjustment algorithm doing it for all windows.

Design patterns

Add or adjust scroll bars

The most obvious and most simple solution to this problem is to add or adjust scroll bars when the keyboard appears, as illustrated in fig. 1 below. The other solutions presented below are solutions where the need for adding scroll bars are removed or reduced.

Fig. 1. Adding scroll bar when keyboard is shown

Let the keyboard cover part of the UI

How “bad” this solution is depends on what is placed on the part of the screen that will be covered by the keyboard, as illustrated in fig. 2 below. If this part is occupied by output fields, the solution may work fine as long as the keyboard is removed when not needed. If this part of the screen contains important input fields or tab folders the solution is useless.

Fig. 2. Keyboard covers part of UI

Only use the part of the screen that will not be covered by the keyboard

In practice, what this solution does is to reduce the size of the screen. This solution may be OK for dialog boxes as illustrated in fig. 3 below, but is seldom practical for normal windows.

Fig. 3. Dialog box which leaves room for keyboard

Use one large UI control as a buffer

By this we mean that when the keyboard is added, one of the controls is reduced vertically to be just as much smaller as the size of the keyboard, as illustrated with the calendar control in fig. 4 below. General controls that may be used for this are primarily list boxes and multi line text boxes.

Fig. 4. Calendar control that shrinks when keyboard is added

Keyboard as part of layout

Instead of using a built-in software keyboard that the application have to adjust to, it is also possible to have an application specific keyboard that is designed to be part of the layout, as illustrated in fig. 5 below.

Fig. 5. Keyboard as part of layout of an application