毕业设计论文 外文文献翻译 移动应用的用户界面设计模式 中英文对照.doc

1、外文文献翻译移动应用的用户界面设计模式Erik G. Nilsson SINTEF ICT, Postboks 124, Blindern, N-0314 Oslo, Norway egnsintef.no摘要：在本文中，我们目前针对移动应用的用户界面设计模式的集合。在收集的模式是分成的问题，进一步分为三个主要问题领域的地区设置。经过预先发送这个问题的结构，我们目前在一些细节上发现了一些模式。然后，我们目前从一些有关的研究结果验证模式集合。该验证表明，两种模式的集合和个人模式和混合背景的可用性专业人士的相关有用。最后，我们讨论了使用记录设计知识，相关的工作和今后的研究的一个模式格式的利弊。介绍

2、在本影和FLAMINCO项目中，我们已经开发了一套设计准则，以帮助发展中国家更多的用户友好的应用程序在移动设备（掌上电脑/智能手机），如何解决移动设备的用户界面设计时出现的各种问题给予实际的意见。这些准则设计的主要部分是(参见文献5)(模式集合http:/www.sintef.no/flaminco)的移动应用程序的用户界面设计模式的集合。每个问题提出了关于设计模式的格式(参见文献4)。模式集合在处理问题的“来源”是本影和FLAMINCO项目的重新要求引出的阶段，并实践光学经验，在开发和利用项目的合作伙伴之间的移动应用中发现的问题。主要问题领域设计模式的指导方针是按照给定的结构在模式集合中提出

3、来的。在顶层，他们被分成三个主要的问题领域。在这三个主要问题的每2个问题里，少数问题领域是被定义的。在每个这些问题的地方，一部分问题是不确定的。 如表1所示，在表列出了一些确定的26个问题，与他们连接问题领域（用户界面设计模式）。表1 用户界面设计模式和问题领域的连接表格要显示出来主要问题领域问题区域 个人问题 /界面设计模式 屏幕空间的利用一般的屏幕空间 提出元素列表原则和机制的分组信息机制包装信息用户界面的灵活应用处理对话框当软件键盘显示/隐藏支持肖像和风景模式之间切换不同屏幕尺寸设备的用户界面 互动机制 处理输入输入文字的机制输入数字数据的机制多态模式输入 不使用麦粒肿LUS不使用LUS

4、的应用程序交互在不使用键盘的情况下检索数据库数据 大型物体设计 准则自动产生的标准特点结合品牌，美学，和屏幕空间 难以了解的方面在同步过程中的用户交互长期业务的用户交互背景在没有键盘的PDA，一个共同的解决办法是输入文字显示软件键盘上，用户可以在使用EN- TER文本手写笔在屏幕的底部。这个区域可能已经被应用程序使用，从而减少其“正常”的互动空间。问题主要的问题是如何调整对话框以避免部分对话框暗藏。这个问题主要取决于用户界面的类型和风格。以UI为基础的形式是最有挑战性的，而对于含有任意添加或调整滚动条的文本或视觉演示的UI通常是足够的的。处理选项卡上的文件夹和被放置在屏幕底部的按钮也是一个挑战

5、。解决方案当键盘出现时，最简单的方法是调整或添加滚动条。在这个前提下给出的其他解决方案都是需要通过添加，减少或删除滚动条的方法来解决。在某些情况下它是可以让键盘覆盖部分UI。这个方案不好的一面是他依赖于被键盘挡住的部分屏幕。如果这个部分在被输出领域占用，只要键盘不被使用，这个解决方案是可以精确执行的。如果这个屏幕的一部分包含了重要的输入栏位或选项卡上的文件夹，此时，这个解决方案是不起作用的。另一种简单的，但很少非常实用的解决方案是只使用不被键盘覆盖的一部分屏幕。在实现过程中，这个方案主要是减少屏幕的大小，并且比较适合对话框而不是windows系统。一个更先进，但仍然相当容易实现的解决方案是使用

6、的一个大的UI控件作为缓冲区。当键盘增加一个时，其中一个空间就会急剧减少使之调整并与键盘尺寸一样小。可使用的控件主要是列表框和多文本框。另一种相当简单的解决方案有两个变种的用户界面，一个是使用所有的屏幕空间，一个是使腾出空间给键盘。主要劣势是当用户界面的变化时，用户可能会混淆，为此而增加了工作量。两个或两个以上的大型UI控件通过共享大量减少的尺寸用于缓冲池的解决方案使之应用。通常来说，这个解决方案在UI中的控件的动态调整大小。这可能是使用两种不同的方法来完成。首先是决定为每个窗口的大小调整规则和申请，每个窗口定制的代码。二是所有的Windows有一个总体布局增加调整的算法。验证2007年在一天

7、半的人机交互国际会议里展示了所有模式的教程。在本教程中，提出了结构模式集合，所有的模式是在一个非常简短的的水平。然而，在26个里面，有12是提出了更多的细节。在演示过程中，参与折填写了一份问卷。他们给主要问题领域的相关性和实用性，以及对未来使用模式集合的期望值打分。在从1（最低）到6（最高）范围里对相关性，实用性和希望值打分。在29个参与教程问卷调查的参与者里，是年龄为2550的男性，大多数为30岁左右。一大部分来自亚洲，其余是欧洲和美国的。大多数是大师级别的，其余是本科和博士学历的。教育背景的不同区别于技术和非技术的不同。UI开发范围从0到12年，大多数人只有5年及以下的经验。开发范围从0到

8、6年的移动解决方案的经验，多数有2年以下经验。结论主要问题领域的分数显示可利用屏幕的空间的相关系数的平均值为5.3，互动机制为5.4，设计的最大值为4.9。分数模式集合，如显示平均得分5.0的相关性，以及实用性和未来使用4.5模式的集合。所有这些成绩验证模式的集合，解决有关问题，并就如何解决这些问题的有益和实用的意见。在提出更详细的个人模式的分数，分数各不相同位，但仍然相当高。下面图1显示为12模式的相关性和实用性的平均分数，降分数的相关性进行排序。图1 针对性和实用性的平均分数至于这种模式集合，相关的平均分数高于实用性相应的分数。这并不奇怪，因为它是通常更容易同意与一个比一个建议的解决方案问

9、题描述。虽然所有，但平均实用性分数上规模的上半部分，模式的实用性分数最低，得分之间的相关性和实用性的分数的不同差异，最高的模式，为进一步开展工作的候选人。它也可能注意到，相关分析显示，在12个问题中有7个的针对性和实用性的分数在0.01水平，在其他5个里面有2个在0.05的水平。此外，模式的集合相关性和实用性的分数维持在0.01水平。用户使用模式的文件格式和设计知识所选择的图案格式是在许多方面非常适合文件的用户界面设计方面的知识，因为它抓住了问题的重要方面。此外，由于设计模式可能会在不同的抽象层次，他们可以被用来描述不同的“大小”的问题。此外，划分成定义良好的问题的数量有限的问题领域，使得它可

10、以处理单独设置一个管理的问题。最后，有一个模式的集合，使人们有可能结合起来，刚才提到的“分而治之”的原则，具有良好的整体结构。我们不得不使用的模式格式的最大挑战是连接之间的问题和解决方案。很多时候，这是很多很多的连接。 提出了相同或非常相似的解决了一些问题，要么会导致大量的交叉引用或大量的重复。我们选择使用交叉引用，正在收集到的其他模式进行(参见文献2)。目前，我们正在考虑重组模式的集合，使每个图案代表一个解决方案或一个问题和一个解决方案中的一个独特的组合。这两种方法将减少交叉引用的需要，但都将增加模式的数量，从而使之更难以得到一个模式的集合的概述。相关工作有一个模式的集合，甚至在网络上的模式

11、的集合，见(参见文献1)等收藏品的评估。也有几个收藏，如设计模式的Wiki和小弹簧的移动用户界面设计模式，为移动用户界面模式。后者与我们的两个主要问题领域的重叠，但组织问题，而我们的集合，这个集合是由解决方案的组织。(参见文献8)的模式，虽然在注重移动的互动，在其范围内更广泛的比我们的集合，只有两个用户界面模式。(参见文献23)提出了设计模式的普适计算的集合，是相当大的，但有一个与模式，在一个更高的抽象层次和或比我们的模式解决方案的建议设置全面更广泛的范围。结论和未来计划的工作在本文中，我们已经介绍了移动应用的用户界面设计模式的结构化集合。作为索引的结构是有价值的，它提供了全面的概述为移动用户

12、界面设计问题。已通过验证的模式集合使用教程问卷。此验证表明，无论是个人模式评估和整个山坳选择相关的和有用的与会者认为，很可能，他们将在今后的工作中使用集合。它还确定了需要更多的工作模式。最后，我们已经讨论了使用记录设计知识的一个模式的集合的利弊。主要职业能力分为结构设置一个管理的问题，主要是相同的解决方案可能适用于一些问题，引起了很多模式之间的交叉引用。收集不断改进和加强，例如：在多模态交互领域和使用背景(参见文献7)。致谢：本文是基于工作是由挪威研究理事会，并在这些项目的行业合作伙伴资助的本影和FLAMINCO项目的支持。我还要感谢我的同学Jan Heim贡献设计验证和分析结果以及所用的问卷

13、。参考文献1 Deng J et al (2005) Managing UI pattern collections. In Proceedings of the 6th ACM SIGCHI New Zealand chapters international conference on Computer- human interaction 2 Duyne D K & Landay J A (2004) Design Patterns, Course documentation 3 Landay J A & Borriello G (2003) Design Patterns for Ub

14、iquitous Computing. In IEEE Com-puter August 2003 4 Gamma E, Helm R, Johnson R, and lissides J (1995) Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley 5 Nilsson E G (2005) Design guidelines for mobile applications. SINTEF Report STF90 A06003, ISBN 82-14-03820-0 6 Nilsson

15、 E G (2007) Design patterns for user interfaces on mobile equipment. Tutorial documentation, HCI International 7 Nilsson E G, Floch J, et al. (2006) Model-based user interface adaptation. Computers & Graphics 30(5): 692701 8 Roth J (2002) Patterns of Mobile Interaction. Personal and Ubiquitous Compu

16、ting, Volume 6, Issue 4 (September 2002) Design Patterns for User Interface for Mobile Applications Erik G. NilssonSINTEF ICT, Postboks 124, Blindern, N-0314 Oslo, Norway egnsintef.noAbstract In this paper we present a collection of user interface design patterns for mobile applications. The pattern

17、s in the collection are grouped into a set of problem areas that are further grouped into three main problem areas. After pre-senting 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 valida

18、tion shows that both the patterns collection and the individual patterns are relevant and useful for usability professionals with a mixed background. Fi-nally, we discuss pros and cons of using a patterns format for documenting design knowledge, related work and future research. Introduction In the

19、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 t

20、hese design guidelines is a collection of user interface design patterns for mobile applications 5 (the patterns collection is available at http:/www.sintef.no/flaminco). Each problem is presented on a design pattern format 4. The “sources” for the problems addressed in the patterns collection are p

21、roblems identified in the re-quirements elicitation phase of the UMBRA and FLAMINCO projects, and prac-tical 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 t

22、he 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 pattern

23、s) with their con-nection 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 s

24、pace in general Presenting elements in lists Principles and mechanisms for grouping information Mechanisms for packing information Flexible user in-terfaces Handling dialogs when SW keyboard is shown/hidden Supporting switching between portrait and landscape mode UIs that should run on equipment wit

25、h different screen size Interaction mechanisms Handling input Mechanisms for entering text Mechanisms for entering numerical data Multi modal input Not using the sty-lus Interacting with applications without using stylus Retrieving data from a database without using keyboard Design at large Guidelin

26、es Standard features in an automatically generated prototype Combining branding, aesthetics, and screen space “Difficult to un-derstand” User interaction during synchronization User interaction during long-lasting operations Handling dialogs when software keyboard is shown and hidden Background. On

27、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 en-ter 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 h

28、ow to resize the dialogs to avoid some parts of the dialogs becoming invisible. The severity of this problem depends on the type/style of the user interface. It is most challenging for forms-based UIs, while for UIs containing arbitrary text or visual presentations adding or adjusting a scrollbar is

29、 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 pre-sented below are solutions wh

30、ere 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 m

31、ay 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 pr

32、actice, 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 i

33、s 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 an

34、d one that makes room for the keyboard. The main dis-advantage 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 shar-ing the amount of size reduction to be applied. Ge

35、neralized, this solution ends up as dynamic resizing of the controls in the UI. This may be done using two differ-ent 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 ad-justment algorithm doing

36、 it for all windows. Validation The patterns collection was presented at a half day tutorial at the HCI International conference in 2007 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

37、 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 finally the rele-vance and usefulness of the patterns collection and such as well a

38、s their expecta-tions for future use of the patterns collection. Relevance, usefulness and future use were scored on a scale from 1 (lowest) to 6 (highest). 29 of the participants at the tutorial handed in the questionnaire. There was a small majority of male, age varied from 25 to 50, most being ar

39、ound 30 years old. A majority had their origin in Asia, the rest coming from Europe and America. The majority has an education on master level, the rest split among undergradu-ates and PhD holders. The educational background was equally split between technical and non-technical. UI development exper

40、ience varied from 0 to 12 years, 4 the majority having 5 years or less experience. Experience in developing mobile solutions varied from 0 to 6 years, the majority having 2 years or less experience. Results Scores on the main problem areas show an average score on relevance of 5.3 for Utilizing scre

41、en space, on 5.4 for Interaction mechanisms, and 4.9 for Design at large. Scores on the patterns collection as such show an average score on rele-vance of 5.0, and on both usefulness and future use of the patterns collection of 4.5. All these scores verify that the patterns collection both addresses

42、 relevant problems and gives useful and practical advices on how to solve these problems. Looking at the scores for the individual patterns that were presented in more detail, the scores vary a bit, but are still fairly high. Figure 1 below shows the average scores for relevance and usefulness for t

43、he 12 patterns, sorted descending on scores for relevance. Fig. 1. Average scores for relevance and usefulness As for the patterns collection as such, the average scores for relevance are higher than the corresponding scores for usefulness. This is not surprising, as it is usually easier to agree wi

44、th a problem description than a proposed solution. Al-though all but one of the average usefulness scores are on the top half of the scale, the patterns where the usefulness scores are lowest, and the patterns where the dif-ference between relevance score and usefulness scores are highest, are candi

45、dates for further work. It may also be noted that correlation analyses show that the scores for relevance and usefulness correlates on the 0.01 level for 7 of the 12 5 problems, and on the 0.05 level for 2 of the other 5. Also, the scores for relevance and usefulness for the patterns collection as s

46、uch correlates on the 0.01 level. Using patterns format to document design knowledge The chosen patterns format is in many ways well suited to document user interface design knowledge, as it captures the essential aspects of a problem. Also, as de-sign patterns may be on different abstraction levels

47、 they can be used to describe problems of different “sizes”. Furthermore, dividing a problem field into a limited number of well defined problems makes it possible to handle a set of manageable problems separately. Finally, having a patterns collection makes it possible to combine the just mentioned

48、 “divide and rule” principle with having an overall structure. The biggest challenge we had using the patterns format is the connection be-tween problems and solutions. Very often this is a many to many connection. Pre-senting the same or very similar solutions to a number of problems, either causes a lot of cross-references or large amounts of repetition. We chose to use cross-references, as is being done in other patterns collections 2. Currently we are con-sidering restructuring the patterns collection so that each pattern rep