工业设计手机界面设计中英文对照外文翻译文献Word格式文档下载.docx

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

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

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

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

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

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

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

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

9、ki和小弹簧的移动用户界面设计模式，为移动用户界面模式。后者与我们的两个主要问题领域的重叠，但组织问题，而我们的集合，这个集合是由解决方案的组织。（参见文献8）的模式，虽然在注重移动的互动，在其范围内更广泛的比我们的集合，只有两个用户界面模式。（参见文献23）提出了设计模式的普适计算的集合，是相当大的，但有一个与模式，在一个更高的抽象层次和或比我们的模式解决方案的建议设置全面更广泛的范围。结论和未来计划的工作在本文中，我们已经介绍了移动应用的用户界面设计模式的结构化集合。作为索引的结构是有价值的，它提供了全面的概述为移动用户界面设计问题。已通过验证的模式集合使用教程问卷。此验证表明，无论是个人

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

11、 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 Ubiquitous Computing. In IEEE Com-put

12、er 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 E G （2007） Design patterns for use

13、r 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 Computing, Volume 6, Issue 4 （September

14、2002） Design Patterns for User Interface for Mobile Applications 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. Af

15、ter 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 validation shows that both the patterns collection and the individual patterns are relevant and useful for usability profess

16、ionals 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 UMBRA and FLAMINCO projects, we have developed a set of design guidelines to aid developing more user friendly applica

17、tions 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 . Each problem is p

18、resented on a design pattern format 4. The “sources” for the problems addressed in the patterns collection are problems 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 partne

19、rs. 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 are

20、as, a number of problems are identified. In Table 1 below, some of the 26 identified problems （UI design patterns） 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 prob

21、lem 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 in-terfaces Handling dialogs when SW keyboa

22、rd 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 sty-lus Interacting with a

23、pplications 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 un-derstand” User interaction during synchronization User intera

24、ction during long-lasting operations Handling dialogs when software keyboard is shown and hidden 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 en-ter text using the stylus. This area may already

25、 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 becoming invisible. The severity of this problem depends on the type/style of the user interface. It is most challenging for for

26、ms-based 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

27、is to add or adjust scroll bars when the keyboard appears. The other solutions pre-sented 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 pa

28、rt 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 seld

29、om 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

30、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 dis-advantage with the s