英文文献翻译2699774886.docx

英文文献翻译2699774886.docx

《英文文献翻译2699774886.docx》由会员分享，可在线阅读，更多相关《英文文献翻译2699774886.docx（31页珍藏版）》请在冰点文库上搜索。

英文文献翻译2699774886

杭州电子科技大学

毕业设计（论文）外文文献翻译

毕业设计（论文）题目

智能可视化通讯产品工业设计

翻译

（1）题目

移动应用的用户界面设计模式

翻译

（2）题目

探索老年人的手机界面设计

学院

计算机学院

专业

数字媒体技术

姓名

项珍珍

班级

08052511

学号

08054109

指导教师

张峻

移动应用的用户界面设计模式

ErikG.Nilsson

SINTEFICT,Postboks124,Blindern,N-0314Oslo,Norway–egn@sintef.no

摘要：

在本文中，我们目前针对移动应用的用户界面设计模式的集合。

在收集的模式是分成的问题，进一步分为三个主要问题领域的地区设置。

经过预先发送这个问题的结构，我们目前在一些细节上发现了一些模式。

然后，我们目前从一些有关的研究结果验证模式集合。

该验证表明，两种模式的集合和个人模式和混合背景的可用性专业人士的相关有用。

最后，我们讨论了使用记录设计知识，相关的工作和今后的研究的一个模式格式的利弊。

介绍

在本影和FLAMINCO项目中，我们已经开发了一套设计准则，以帮助发展中国家更多的用户友好的应用程序在移动设备（掌上电脑/智能手机），如何解决移动设备的用户界面设计时出现的各种问题给予实际的意见。

这些准则设计的主要部分是（参见文献[5]）（模式集合http:

//www.sintef.no/flaminco）的移动应用程序的用户界面设计模式的集合。

每个问题提出了关于设计模式的格式（参见文献[4]）。

模式集合在处理问题的“来源”是本影和FLAMINCO项目的重新要求引出的阶段，并实践光学经验，在开发和利用项目的合作伙伴之间的移动应用中发现的问题。

主要问题领域

设计模式的指导方针是按照给定的结构在模式集合中提出来的。

在顶层，他们被分成三个主要的问题领域。

在这三个主要问题的每2个问题里，少数问题领域是被定义的。

在每个这些问题的地方，一部分问题是不确定的。

如表1所示，在表列出了一些确定的26个问题，与他们连接问题领域（用户界面设计模式）。

表1用户界面设计模式和问题领域的连接

主要问题领域

问题区域

个人问题/界面设计模式

屏幕空间的利用

一般的屏幕空间

提出元素列表

原则和机制的分组信息

机制包装信息

用户界面的灵活应用

处理对话框当软件键盘显示/隐藏

支持肖像和风景模式之间切换

不同屏幕尺寸设备的用户界面

互动机制

处理输入

输入文字的机制

输入数字数据的机制

多态模式输入

不使用麦粒肿LUS

不使用LUS的应用程序交互

在不使用键盘的情况下检索数据库数据

大型物体设计

准则

自动产生的标准特点

结合品牌，美学，和屏幕空间

难以了解的方面

在同步过程中的用户交互

长期业务的用户交互

背景

在没有键盘的PDA，一个共同的解决办法是输入文字显示软件键盘上，用户可以在使用EN-TER文本手写笔在屏幕的底部。

这个区域可能已经被应用程序使用，从而减少其“正常”的互动空间。

问题

主要的问题是如何调整对话框以避免部分对话框暗藏。

这个问题主要取决于用户界面的类型和风格。

以UI为基础的形式是最有挑战性的，而对于含有任意添加或调整滚动条的文本或视觉演示的UI通常是足够的的。

处理选项卡上的文件夹和被放置在屏幕底部的按钮也是一个挑战。

解决方案

当键盘出现时，最简单的方法是调整或添加滚动条。

在这个前提下给出的其他解决方案都是需要通过添加，减少或删除滚动条的方法来解决。

在某些情况下它是可以让键盘覆盖部分UI。

这个方案不好的一面是他依赖于被键盘挡住的部分屏幕。

如果这个部分在被输出领域占用，只要键盘不被使用，这个解决方案是可以精确执行的。

如果这个屏幕的一部分包含了重要的输入栏位或选项卡上的文件夹，此时，这个解决方案是不起作用的。

另一种简单的，但很少非常实用的解决方案是只使用不被键盘覆盖的一部分屏幕。

在实现过程中，这个方案主要是减少屏幕的大小，并且比较适合对话框而不是windows系统。

一个更先进，但仍然相当容易实现的解决方案是使用的一个大的UI控件作为缓冲区。

当键盘增加一个时，其中一个空间就会急剧减少使之调整并与键盘尺寸一样小。

可使用的控件主要是列表框和多文本框。

另一种相当简单的解决方案有两个变种的用户界面，一个是使用所有的屏幕空间，一个是使腾出空间给键盘。

主要劣势是当用户界面的变化时，用户可能会混淆，为此而增加了工作量。

两个或两个以上的大型UI控件通过共享大量减少的尺寸用于缓冲池的解决方案使之应用。

通常来说，这个解决方案在UI中的控件的动态调整大小。

这可能是使用两种不同的方法来完成。

首先是决定为每个窗口的大小调整规则和申请，每个窗口定制的代码。

二是所有的Windows有一个总体布局增加调整的算法。

验证

2007年在一天半的人机交互国际会议里展示了所有模式的教程。

在本教程中，提出了结构模式集合，所有的模式是在一个非常简短的的水平。

然而，在26个里面，有12是提出了更多的细节。

在演示过程中，参与折填写了一份问卷。

他们给主要问题领域的相关性和实用性，以及对未来使用模式集合的期望值打分。

在从1（最低）到6（最高）范围里对相关性，实用性和希望值打分。

在29个参与教程问卷调查的参与者里，是年龄为25~50的男性，大多数为30岁左右。

一大部分来自亚洲，其余是欧洲和美国的。

大多数是大师级别的，其余是本科和博士学历的。

教育背景的不同区别于技术和非技术的不同。

UI开发范围从0到12年，大多数人只有5年及以下的经验。

开发范围从0到6年的移动解决方案的经验，多数有2年以下经验。

结论

主要问题领域的分数显示可利用屏幕的空间的相关系数的平均值为5.3，互动机制为5.4，设计的最大值为4.9。

分数模式集合，如显示平均得分5.0的相关性，以及实用性和未来使用4.5模式的集合。

所有这些成绩验证模式的集合，解决有关问题，并就如何解决这些问题的有益和实用的意见。

在提出更详细的个人模式的分数，分数各不相同位，但仍然相当高。

下面图1显示为12模式的相关性和实用性的平均分数，降分数的相关性进行排序。

图1针对性和实用性的平均分数

至于这种模式集合，相关的平均分数高于实用性相应的分数。

这并不奇怪，因为它是通常更容易同意与一个比一个建议的解决方案问题描述。

虽然所有，但平均实用性分数上规模的上半部分，模式的实用性分数最低，得分之间的相关性和实用性的分数的不同差异，最高的模式，为进一步开展工作的候选人。

它也可能注意到，相关分析显示，在12个问题中有7个的针对性和实用性的分数在0.01水平，在其他5个里面有2个在0.05的水平。

此外，模式的集合相关性和实用性的分数维持在0.01水平。

用户使用模式的文件格式和设计知识

所选择的图案格式是在许多方面非常适合文件的用户界面设计方面的知识，因为它抓住了问题的重要方面。

此外，由于设计模式可能会在不同的抽象层次，他们可以被用来描述不同的“大小”的问题。

此外，划分成定义良好的问题的数量有限的问题领域，使得它可以处理单独设置一个管理的问题。

最后，有一个模式的集合，使人们有可能结合起来，刚才提到的“分而治之”的原则，具有良好的整体结构。

我们不得不使用的模式格式的最大挑战是连接之间的问题和解决方案。

很多时候，这是很多很多的连接。

提出了相同或非常相似的解决了一些问题，要么会导致大量的交叉引用或大量的重复。

我们选择使用交叉引用，正在收集到的其他模式进行（参见文献[2]）。

目前，我们正在考虑重组模式的集合，使每个图案代表一个解决方案或一个问题和一个解决方案中的一个独特的组合。

这两种方法将减少交叉引用的需要，但都将增加模式的数量，从而使之更难以得到一个模式的集合的概述。

相关工作

有一个模式的集合，甚至在网络上的模式的集合，见（参见文献[1]）等收藏品的评估。

也有几个收藏，如设计模式的Wiki和小弹簧的移动用户界面设计模式，为移动用户界面模式。

后者与我们的两个主要问题领域的重叠，但组织问题，而我们的集合，这个集合是由解决方案的组织。

（参见文献[8]）的模式，虽然在注重移动的互动，在其范围内更广泛的比我们的集合，只有两个用户界面模式。

（参见文献[2][3]）提出了设计模式的普适计算的集合，是相当大的，但有一个与模式，在一个更高的抽象层次和或比我们的模式解决方案的建议设置全面更广泛的范围。

结论和未来计划的工作

在本文中，我们已经介绍了移动应用的用户界面设计模式的结构化集合。

作为索引的结构是有价值的，它提供了全面的概述为移动用户界面设计问题。

已通过验证的模式集合使用教程问卷。

此验证表明，无论是个人模式评估和整个山坳选择相关的和有用的与会者认为，很可能，他们将在今后的工作中使用集合。

它还确定了需要更多的工作模式。

最后，我们已经讨论了使用记录设计知识的一个模式的集合的利弊。

主要职业能力分为结构设置一个管理的问题，主要是相同的解决方案可能适用于一些问题，引起了很多模式之间的交叉引用。

收集不断改进和加强，例如：

在多模态交互领域和使用背景（参见文献[7]）。

致谢：

本文是基于工作是由挪威研究理事会，并在这些项目的行业合作伙伴资助的本影和FLAMINCO项目的支持。

我还要感谢我的同学JanHeim贡献设计验证和分析结果以及所用的问卷。

参考文献

[1]DengJetal（2005）ManagingUIpatterncollections.InProceedingsofthe6thACMSIGCHINewZealandchapter'sinternationalconferenceonComputer-humaninteraction

[2]DuyneDK&LandayJA（2004）DesignPatterns,Coursedocumentation

[3]LandayJA&BorrielloG（2003）DesignPatternsforUbiquitousComputing.InIEEECom-puterAugust2003

[4]GammaE,HelmR,JohnsonR,andlissidesJ（1995）DesignPatterns–ElementsofReusableObject-OrientedSoftware.Addison-Wesley

[5]NilssonEG（2005）Designguidelinesformobileapplications.SINTEFReportSTF90A06003,ISBN82-14-03820-0

[6]NilssonEG（2007）Designpatternsforuserinterfacesonmobileequipment.Tutorialdocumentation,HCIInternational

[7]NilssonEG,FlochJ,etal.（2006）Model-baseduserinterfaceadaptation.Computers&Graphics30（5）:

692–701

[8]RothJ（2002）PatternsofMobileInteraction.PersonalandUbiquitousComputing,Volume6,Issue4（September2002）

DesignPatternsforUserInterfaceforMobileApplications

ErikG.Nilsson

SINTEFICT,Postboks124,Blindern,N-0314Oslo,Norway–egn@sintef.no

AbstractInthispaperwepresentacollectionofuserinterfacedesignpatternsformobileapplications.Thepatternsinthecollectionaregroupedintoasetofproblemareasthatarefurthergroupedintothreemainproblemareas.Afterpre-sentingthisproblemstructurewepresentoneofthepatternsinsomedetail.Thenwepresentsomerelevantfindingsfromavalidationofthepatternscollection.Thisvalidationshowsthatboththepatternscollectionandtheindividualpatternsarerelevantandusefulforusabilityprofessionalswithamixedbackground.Fi-nally,wediscussprosandconsofusingapatternsformatfordocumentingdesignknowledge,relatedworkandfutureresearch.

Introduction

IntheUMBRAandFLAMINCOprojects,wehavedevelopedasetofdesignguidelinestoaiddevelopingmoreuserfriendlyapplicationsonmobiledevices（PDAs/SmartPhones）,givingpracticaladvicesforhowtosolvevariousproblemsthatarisewhendesigninguserinterfacesonmobiledevices.Themainpartofthesedesignguidelinesisacollectionofuserinterfacedesignpatternsformobileapplications[5]（thepatternscollectionisavailableathttp:

//www.sintef.no/flaminco）.Eachproblemispresentedonadesignpatternformat[4].The“sources”fortheproblemsaddressedinthepatternscollectionareproblemsidentifiedinthere-quirementselicitationphaseoftheUMBRAandFLAMINCOprojects,andprac-ticalexperienceindevelopingandusingmobileapplicationsamongtheprojectpartners.

Mainproblemareas

Thedesignguidelinespresentedinthepatternscollectionfollowagivenstructure.Onthetoplevel,theyaregroupedintothreemainproblemareas.Withineachof2thesethreemainproblemareas,asmallnumberofproblemareasaredefined.Withineachoftheseproblemareas,anumberofproblemsareidentified.InTable1below,someofthe26identifiedproblems（UIdesignpatterns）withtheircon-nectiontoproblemareasarelisted.Abriefversionoftheprobleminboldfontispresentedinthenextsection.

Table1.UIdesignpatternsandtheirconnectiontoproblemareas

Mainprobl.area

Problemarea

Individualproblems/UIdesignPatterns

Utilizingscreenspace

Screenspaceingeneral

Presentingelementsinlists

Principlesandmechanismsforgroupinginformation

Mechanismsforpackinginformation

Flexibleuserin-terfaces

HandlingdialogswhenSWkeyboardisshown/hidden

Supportingswitchingbetweenportraitandlandscapemode

UIsthatshouldrunonequipmentwithdifferentscreensize

Interactionmechanisms

Handlinginput

Mechanismsforenteringtext

Mechanismsforenteringnumericaldata

Multimodalinput

Notusingthesty-lus

Interactingwithapplicationswithoutusingstylus

Retrievingdatafromadatabasewithoutusingkeyboard

Designatlarge

Guidelines

Standardfeaturesinanautomaticallygeneratedprototype

Combiningbranding,aesthetics,andscreenspace

“Difficulttoun-derstand”

Userinteractionduringsynchronization

Userinteractionduringlong-lastingoperations

Handlingdialogswhensoftwarekeyboardisshownandhidden

Background.OnPDAswithoutkeyboard,acommonsolutionforenteringtextistoshowasoftwarekeyboardonthebottomofthescreenwheretheusercanen-tertextusingthestylus.Thisareamayalreadybeusedbytheapplication,thusleavinglessroomforits“normal”interaction.

Problem.Themainproblemishowtoresizethedialogstoavoidsomepartsofthedialogsbecominginvisible.Theseverityofthisproblemdependsonthetype/styleoftheuserinterface.Itismostchallengingforforms-basedUIs,whileforUIscontainingarbitrarytextorvisualpresentationsaddingoradjustingascrollbarisusuallysufficient.Handlingtabfoldersandbuttonsthatareplacedonthebottomofthescreenisalsoachallenge.

Solutions.Themostobviousandmostsimplesolutiontothisproblemistoaddoradjustscrollbarswhenthekeyboardappears.Theothersolutionspre-sentedbelowaresolutionswheretheneedforaddingscrollbarsareremovedorreduced.

InsomecasesitisOKlettingthekeyboardcoverpartoftheUI.How“bad”thissolutionisdependsonwhatisplacedonthepartofthescreenthatwillbecoveredbythekeyboard.Ifthispartisoccupiedbyoutputfields,thesolutionmayworkfineaslongasthekeyboardisremovedwhennotneeded.Ifthispartofthescreencontainsimportantinputfieldsortabfoldersthesolutionisuseless.

Anothersimple,butseldomverypracticalsolutionistojustusethepartofthescreenthatwillnotbecoveredbythekeyboard.Inpractice,whatthissolutiondoesisreducingthesizeofthescreen.ThissolutionmaybeOKfordialogboxes,butisseldompracticalfornormalwindows.

Amoreadvanced,butstillfairlyeasilyimplementeds