【正文】 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. The buffer solution 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. Validation The patterns collection was presented at a half day tutorial at the HCI International conference in 2021 [6]. At the tutorial, the structure of the patterns collection was presented, and all patterns were presented at a very brief level. Then, 12 of the 26 patterns were presented in more detail. During the presentation, the participants filled in a questionnaire. They scored the relevance of the main problem areas, the relevance and usefulness of each of the presented patterns, and finall