【正文】 based user interface adaptation. Computers amp。s international conference on Computer human interaction [2] Duyne D K amp。 Graphics 30(5): 692–701 [8] Roth J (2021) Patterns of Mobile Interaction. Personal and Ubiquitous Computing, Volume 6, Issue 4 (September 2021) Design Patterns for User Interface for Mobile Applications Erik G. Nilsson SINTEF ICT, Postboks 124, Blindern, N0314 Oslo, Norway – Abstract In this paper we present a collection of user interface design patterns for mobile applications. The patterns in the collection are grouped into a set of problem areas that are further grouped into three main problem areas. After presenting this problem structure we present one of the patterns in some detail. Then we present some relevant findings from a validation of the patterns collection. This validation shows that both the patterns collection and the individual patterns are relevant and useful for usability professionals with a mixed background. Finally, we discuss pros and cons of using a patterns format for documenting design knowledge, related work and future research. Introduction In the UMBRA and FLAMINCO projects, we have developed a set of design guidelines to aid developing more user friendly applications on mobile devices (PDAs/SmartPhones), giving practical advices for how to solve various problems that arise when designing user interfaces on mobile devices. The main part of these design guidelines is a collection of user interface design patterns for mobile applications [5] (the patterns collection is available at Each problem is presented on a design pattern format [4]. The “sources” for the problems addressed in the patterns collection are problems identified in the requirements elicitation phase of the UMBRA and FLAMINCO projects, and practical experience in developing and using mobile applications among the project partners. Main problem areas The design guidelines presented in the patterns collection follow a given structure. On the top level, they are grouped into three main problem areas. Within each of 2 these three main problem areas, a small number of problem areas are defined. Within each of these problem areas, a number of problems are identified. In Table 1 below, some of the 26 identified problems (UI design patterns) with their connection to problem areas are listed. A brief version of the problem in bold font is presented in the next section. Table 1. UI design patterns and their connection to problem areas Main probl. area Problem area Individual problems / UI design Patterns Utilizing screen space Screen space in general Presenting elements in lists Principles and mechanisms for grouping information Mechanisms for packing information Flexible user interfaces Handling dialogs when SW keyboard is shown/hidden Supporting switching between portrait and landscape mode UIs that should run on equipment with different screen size Interaction mechanisms Handling input Mechanisms for entering text Mechanisms for entering numerical data Multi modal input Not using the stylus Interacting with applications without using stylus Retrieving data from a database without using keyboard Design at large Guidelines Standard features in an automatically generated prototype Combining branding, aesthetics, and screen space “Difficult to understand” User interaction during synchronization User interaction during longlasting operations Handling dialogs when software keyboard is shown and hidden Background. On PDAs without keyboard, a mon 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. This area may already be used by the application, thus leaving less room for its “normal” interaction. Problem. The main problem is how to resize the dialogs to avoid some parts of the dialogs being invisible. The severity of this problem depends on the type/style of the user interface. It is most challenging for formsbased UIs, while for UIs containing arbitrary text or visual presentations adding or adjusting a scrollbar is usually sufficient. Handling tab folders and buttons that are placed on the bottom of the screen is also a challenge. Solutions. The most obvious and most simple solution to this problem is to add or adjust scroll bars when the keyboard appears. The other solutions presented below are solutions where the need for adding scroll bars are removed or reduced. In some cases it is OK letting 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. 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. Another simple, but seldom very practical solution is to just use the part of the screen that will not be covered by the keyboard. In practice, what this solution does is reducing the size of the screen. This solution may be OK for dialog boxes, but is seldom practical for normal windows. A more advanced, but still fairly easily implemented solution is to 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. Controls that may be used for this are primarily list boxes and multi line text boxes. Yet another fairly simple solution is having two variants of the UI, one that uses all the screen space and one that makes room for the keyboard. The main disadvantage with the solution is – in addition to added development work – that the user may be confused when the UI changes.