工業(yè)設計手機界面設計中英文對照外文翻譯文獻

外文文獻翻譯移動應用的用戶界面設計模式摘要：在本文中，我們目前針對移動應用的用戶界面設計模式的集合。在收集的模式是分成的問題，進一步分為三個主要問題領域的地區(qū)設置。經過預先發(fā)送這個問題的結構，我們目前在一些細節(jié)上發(fā)現(xiàn)了一些模式。然后，我們目前從一些有關的研究結果驗證模式集合。該驗證表明，兩種模式的集合和個人模式和混合背景的可用性專業(yè)人士的相關有用。最后，我們討論了使用記錄設計知識，相關的工作和今后的研究的一個模式格式的利弊。介紹在本影和FLAMINCO項目中，我們已經開發(fā)了一套設計準則，以幫助發(fā)展中國家更多的用戶友好的應用程序在移動設備（掌上電腦/智能手機），如何解決移動設備的用戶界面設計時出現(xiàn)的各種問題給予實際的意見。這些準則設計的主要部分是的移動應用程序的用戶界面設計模式的集合。每個問題提出了關于設計模式的格式(參見文獻[4])。模式集合在處理問題的“來源”是本影和FLAMINCO項目的重新要求引出的階段，并實踐光學經驗，在開發(fā)和利用項目的合作伙伴之間的移動應用中發(fā)現(xiàn)的問題。主要問題領域設計模式的指導方針是按照給定的結構在模式集合中提出來的。在頂層，他們被分成三個主要的問題領域。在這三個主要問題的每2個問題里，少數(shù)問題領域是被定義的。在每個這些問題的地方，一部分問題是不確定的。如表1所示，在表列出了一些確定的26個問題，與他們連接問題領域（用戶界面設計模式）。表1用戶界面設計模式和問題領域的連接主要問題領域問題區(qū)域個人問題/界面設計模式屏幕空間的利用一般的屏幕空間提出元素列表原則和機制的分組信息機制包裝信息用戶界面的靈活應用處理對話框當軟件鍵盤顯示/隱藏支持肖像和風景模式之間切換不同屏幕尺寸設備的用戶界面互動機制處理輸入輸入文字的機制輸入數(shù)字數(shù)據(jù)的機制多態(tài)模式輸入不使用麥粒腫LUS不使用LUS的應用程序交互在不使用鍵盤的情況下檢索數(shù)據(jù)庫數(shù)據(jù)大型物體設計準則自動產生的標準特點結合品牌，美學，和屏幕空間難以了解的方面在同步過程中的用戶交互長期業(yè)務的用戶交互背景在沒有鍵盤的PDA，一個共同的解決辦法是輸入文字顯示軟件鍵盤上，用戶可以在使用EN-TER文本手寫筆在屏幕的底部。這個區(qū)域可能已經被應用程序使用，從而減少其“正?！钡幕涌臻g。問題主要的問題是如何調整對話框以避免部分對話框暗藏。這個問題主要取決于用戶界面的類型和風格。以UI為基礎的形式是最有挑戰(zhàn)性的，而對于含有任意添加或調整滾動條的文本或視覺演示的UI通常是足夠的的。處理選項卡上的文件夾和被放置在屏幕底部的按鈕也是一個挑戰(zhàn)。解決方案當鍵盤出現(xiàn)時，最簡單的方法是調整或添加滾動條。在這個前提下給出的其他解決方案都是需要通過添加，減少或刪除滾動條的方法來解決。在某些情況下它是可以讓鍵盤覆蓋部分UI。這個方案不好的一面是他依賴于被鍵盤擋住的部分屏幕。如果這個部分在被輸出領域占用，只要鍵盤不被使用，這個解決方案是可以精確執(zhí)行的。如果這個屏幕的一部分包含了重要的輸入欄位或選項卡上的文件夾，此時，這個解決方案是不起作用的。另一種簡單的，但很少非常實用的解決方案是只使用不被鍵盤覆蓋的一部分屏幕。在實現(xiàn)過程中，這個方案主要是減少屏幕的大小，并且比較適合對話框而不是windows系統(tǒng)。一個更先進，但仍然相當容易實現(xiàn)的解決方案是使用的一個大的UI控件作為緩沖區(qū)。當鍵盤增加一個時，其中一個空間就會急劇減少使之調整并與鍵盤尺寸一樣小?？墒褂玫目丶饕橇斜砜蚝投辔谋究?。另一種相當簡單的解決方案有兩個變種的用戶界面，一個是使用所有的屏幕空間，一個是使騰出空間給鍵盤。主要劣勢是當用戶界面的變化時，用戶可能會混淆，為此而增加了工作量。兩個或兩個以上的大型UI控件通過共享大量減少的尺寸用于緩沖池的解決方案使之應用。通常來說，這個解決方案在UI中的控件的動態(tài)調整大小。這可能是使用兩種不同的方法來完成。首先是決定為每個窗口的大小調整規(guī)則和申請，每個窗口定制的代碼。二是所有的Windows有一個總體布局增加調整的算法。驗證2007年在一天半的人機交互國際會議里展示了所有模式的教程。在本教程中，提出了結構模式集合，所有的模式是在一個非常簡短的的水平。然而，在26個里面，有12是提出了更多的細節(jié)。在演示過程中，參與折填寫了一份問卷。他們給主要問題領域的相關性和實用性，以及對未來使用模式集合的期望值打分。在從1（最低）到6（最高）范圍里對相關性，實用性和希望值打分。在29個參與教程問卷調查的參與者里，是年齡為25~50的男性，大多數(shù)為30歲左右。一大部分來自亞洲，其余是歐洲和美國的。大多數(shù)是大師級別的，其余是本科和博士學歷的。教育背景的不同區(qū)別于技術和非技術的不同。UI開發(fā)范圍從0到12年，大多數(shù)人只有5年及以下的經驗。開發(fā)范圍從0到6年的移動解決方案的經驗，多數(shù)有2年以下經驗。結論主要問題領域的分數(shù)顯示可利用屏幕的空間的相關系數(shù)的平均值為5.3，互動機制為5.4，設計的最大值為4.9。分數(shù)模式集合，如顯示平均得分5.0的相關性，以及實用性和未來使用4.5模式的集合。所有這些成績驗證模式的集合，解決有關問題，并就如何解決這些問題的有益和實用的意見。在提出更詳細的個人模式的分數(shù)，分數(shù)各不相同位，但仍然相當高。下面圖1顯示為12模式的相關性和實用性的平均分數(shù)，降分數(shù)的相關性進行排序。

圖1針對性和實用性的平均分數(shù)至于這種模式集合，相關的平均分數(shù)高于實用性相應的分數(shù)。這并不奇怪，因為它是通常更容易同意與一個比一個建議的解決方案問題描述。雖然所有，但平均實用性分數(shù)上規(guī)模的上半部分，模式的實用性分數(shù)最低，得分之間的相關性和實用性的分數(shù)的不同差異，最高的模式，為進一步開展工作的候選人。它也可能注意到，相關分析顯示，在12個問題中有7個的針對性和實用性的分數(shù)在0.01水平，在其他5個里面有2個在0.05的水平。此外，模式的集合相關性和實用性的分數(shù)維持在0.01水平。用戶使用模式的文件格式和設計知識所選擇的圖案格式是在許多方面非常適合文件的用戶界面設計方面的知識，因為它抓住了問題的重要方面。此外，由于設計模式可能會在不同的抽象層次，他們可以被用來描述不同的“大小”的問題。此外，劃分成定義良好的問題的數(shù)量有限的問題領域，使得它可以處理單獨設置一個管理的問題。最后，有一個模式的集合，使人們有可能結合起來，剛才提到的“分而治之”的原則，具有良好的整體結構。我們不得不使用的模式格式的最大挑戰(zhàn)是連接之間的問題和解決方案。很多時候，這是很多很多的連接。提出了相同或非常相似的解決了一些問題，要么會導致大量的交叉引用或大量的重復。我們選擇使用交叉引用，正在收集到的其他模式進行(參見文獻[2])。目前，我們正在考慮重組模式的集合，使每個圖案代表一個解決方案或一個問題和一個解決方案中的一個獨特的組合。這兩種方法將減少交叉引用的需要，但都將增加模式的數(shù)量，從而使之更難以得到一個模式的集合的概述。相關工作有一個模式的集合，甚至在網絡上的模式的集合，見(參見文獻[1])等收藏品的評估。也有幾個收藏，如設計模式的Wiki和小彈簧的移動用戶界面設計模式，為移動用戶界面模式。后者與我們的兩個主要問題領域的重疊，但組織問題，而我們的集合，這個集合是由解決方案的組織。(參見文獻[8])的模式，雖然在注重移動的互動，在其范圍內更廣泛的比我們的集合，只有兩個用戶界面模式。(參見文獻[2][3])提出了設計模式的普適計算的集合，是相當大的，但有一個與模式，在一個更高的抽象層次和或比我們的模式解決方案的建議設置全面更廣泛的范圍。結論和未來計劃的工作在本文中，我們已經介紹了移動應用的用戶界面設計模式的結構化集合。作為索引的結構是有價值的，它提供了全面的概述為移動用戶界面設計問題。已通過驗證的模式集合使用教程問卷。此驗證表明，無論是個人模式評估和整個山坳選擇相關的和有用的與會者認為，很可能，他們將在今后的工作中使用集合。它還確定了需要更多的工作模式。最后，我們已經討論了使用記錄設計知識的一個模式的集合的利弊。主要職業(yè)能力分為結構設置一個管理的問題，主要是相同的解決方案可能適用于一些問題，引起了很多模式之間的交叉引用。收集不斷改進和加強，例如：在多模態(tài)交互領域和使用背景(參見文獻[7])。致謝：本文是基于工作是由挪威研究理事會，并在這些項目的行業(yè)合作伙伴資助的本影和FLAMINCO項目的支持。我還要感謝我的同學JanHeim貢獻設計驗證和分析結果以及所用的問卷。參考文獻DengJetal(2005)ManagingUIpatterncollections.InProceedingsofthe6thACMSIGCHINewZealandchapter'sinternationalconferenceonComputer-humaninteractionDuyneDK&LandayJA(2004)DesignPatterns,CoursedocumentationLandayJA&BorrielloG(2003)DesignPatternsforUbiquitousComputing.InIEEECom-puterAugust2003GammaE,HelmR,JohnsonR,andlissidesJ(1995)DesignPatterns–ElementsofReusableObject-OrientedSoftware.Addison-WesleyNilssonEG(2005)Designguidelinesformobileapplications.SINTEFReportSTF90A06003,ISBN82-14-03820-0NilssonEG(2007)Designpatternsforuserinterfacesonmobileequipment.Tutorialdocumentation,HCIInternationalNilssonEG,FlochJ,etal.(2006)Model-baseduserinterfaceadaptation.Computers&Graphics30(5):692–701RothJ(2002)PatternsofMobileInteraction.PersonalandUbiquitousComputing,Volume6,Issue4(September2002)DesignPatternsforUserInterfaceforMobileApplicationsAbstractInthispaperwepresentacollectionofuserinterfacedesignpatternsformobileapplications.Thepatternsinthecollectionaregroupedintoasetofproblemareasthatarefurthergroupedintothreemainproblemareas.Afterpre-sentingthisproblemstructurewepresentoneofthepatternsinsomedetail.Thenwepresentsomerelevantfindingsfromavalidationofthepatternscollection.Thisvalidationshowsthatboththepatternscollectionandtheindividualpatternsarerelevantandusefulforusabilityprofessionalswithamixedbackground.Fi-nally,wediscussprosandconsofusingapatternsformatfordocumentingdesignknowledge,relatedworkandfutureresearch.IntroductionIntheUMBRAandFLAMINCOprojects,wehavedevelopedasetofdesignguidelinestoaiddevelopingmoreuserfriendlyapplicationsonmobiledevices(PDAs/SmartPhones),givingpracticaladvicesforhowtosolvevariousproblemsthatarisewhendesigninguserinterfacesonmobiledevices.Themainpartofthesedesignguidelinesisacollectionofuserinterfacedesignpatternsformobileapplications[5].Eachproblemispresentedonadesignpatternformat[4].The“sources”fortheproblemsaddressedinthepatternscollectionareproblemsidentifiedinthere-quirementselicitationphaseoftheUMBRAandFLAMINCOprojects,andprac-ticalexperienceindevelopingandusingmobileapplicationsamongtheprojectpartners.MainproblemareasThedesignguidelinespresentedinthepatternscollectionfollowagivenstructure.Onthetoplevel,theyaregroupedintothreemainproblemareas.Withineachof2thesethreemainproblemareas,asmallnumberofproblemareasaredefined.Withineachoftheseproblemareas,anumberofproblemsareidentified.InTable1below,someofthe26identifiedproblems(UIdesignpatterns)withtheircon-nectiontoproblemareasarelisted.Abriefversionoftheprobleminboldfontispresentedinthenextsection.Table1.UIdesignpatternsandtheirconnectiontoproblemareasMainprobl.areaProblemareaIndividualproblems/UIdesignPatternsUtilizingscreenspaceScreenspaceingeneralPresentingelementsinlistsPrinciplesandmechanismsforgroupinginformationMechanismsforpackinginformationFlexibleuserin-terfacesHandlingdialogswhenSWkeyboardisshown/hiddenSupportingswitchingbetweenportraitandlandscapemodeUIsthatshouldrunonequipmentwithdifferentscreensizeInteractionmechanismsHandlinginputMechanismsforenteringtextMechanismsforenteringnumericaldataMultimodalinputNotusingthesty-lusInteractingwithapplicationswithoutusingstylusRetrievingdatafromadatabasewithoutusingkeyboardDesignatlargeGuidelinesStandardfeaturesinanautomaticallygeneratedprototypeCombiningbranding,aesthetics,andscreenspace“Difficulttoun-derstand”UserinteractionduringsynchronizationUserinteractionduringlong-lastingoperationsHandlingdialogswhensoftwarekeyboardisshownandhiddenBackground.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,butstillfairlyeasilyimplementedsolutionistouseonelargeUIcontrolasabuffer.Bythiswemeanthatwhenthekeyboardisadded,oneofthecontrolsisreducedverticallytobejustasmuchsmallerasthesizeofthekeyboard.Controlsthatmaybeusedforthisareprimarilylistboxesandmultilinetextboxes.YetanotherfairlysimplesolutionishavingtwovariantsoftheUI,onethatusesallthescreenspaceandonethatmakesroomforthekeyboard.Themaindis-advantagewiththesolutionis–inadditiontoaddeddevelopmentwork–thattheusermaybeconfusedwhentheUIchanges.ThebuffersolutionmayalsobeusedwithtwoormorelargeUIcontrolsshar-ingtheamountofsizereductiontobeapplied.Generalized,thissolutionendsupasdynamicresizingofthecontrolsintheUI.Thismaybedoneusingtwodiffer-entapproaches.Thefirstistodecidearesizingruleforeachwindowandapplythatastailoredcodeforeachwindow.Thesecondistohaveagenerallayoutad-justmentalgorithmdoingitforallwindows.ValidationThepatternscollectionwaspresentedatahalfdaytutorialattheHCIInternationalconferencein2007[6].Atthetutorial,thestructureofthepatternscollectionwaspresented,andallpatternswerepresentedataverybrieflevel.Then,12ofthe26patternswerepresentedinmoredetail.Duringthepresentation,theparticipantsfilledinaquestionnaire.Theyscoredtherelevanceofthemainproblemareas,therelevanceandusefulnessofeachofthepresentedpatterns,andfinallytherele-vanceandusefulnessofthepatternscollectionandsuchaswellastheirexpecta-tionsforfutureuseofthepatternscollection.Relevance,usefulnessandfutureusewerescoredonascalefrom1(lowest)to6(highest).29oftheparticipantsatthetutorialhandedinthequestionnaire.Therewasasmallmajorityofmale,agevariedfrom25to50,mostbeingaround30yearsold.AmajorityhadtheirorigininAsia,therestcomingfromEuropeandAmerica.Themajorityhasaneducationonmasterlevel,therestsplitamongundergradu-atesandPhDholders.Theeducationalbackgroundwasequallysplitbetweentechnicalandnon-technical.UIdevelopmentexperiencevariedfrom0to12years,4themajorityhaving5yearsorlessexperience.Experienceindevelopingmobilesolutionsvariedfrom0to6years,themajorityhaving2yearsorlessexperience.ResultsScoresonthemainproblemareasshowanaveragescoreonrelevanceof5.3forUtilizingscreenspace,on5.4forInteractionmechanisms,and4.9forDesignatlarge.Scoresonthepatternscollectionassuchshowanaveragescoreonrele-vanceof5.0,andonbothusefulnessandfutureuseofthepatternscollectionof4.5.Allthesescoresverifythatthepatternscollectionbothaddressesrelevantproblemsandgivesusefulandpracticaladvicesonhowtosolvetheseproblems.Lookingatthescoresfortheindividualpatternsthatwerepresentedinmoredetail,thescoresvaryabit,butarestillfairlyhigh.Figure1belowshowstheaveragescoresforrelevanceandusefulnessforthe12patterns,sorteddescendingonscoresforrelevance.Fig.1.AveragescoresforrelevanceandusefulnessAsforthepatternscollectionassuch,theaveragescoresforrelevancearehigherthanthecorrespondingscoresforusefulness.Thisisnotsurprising,asitisusuallyeasiertoagreewithaproblemdescriptionthanaproposedsolution.Al-thoughallbutoneoftheaverageusefulnessscoresareonthetophalfofthescale,thepatternswheretheusefulnessscoresarelowest,andthepatternswherethedif-ferencebetweenrelevancescoreandusefulnessscoresarehighest,arecandidatesforfurtherwork.Itmayalsobenotedthatcorrelationanalysesshowthatthescoresforrelevanceandusefulnesscorrelatesonthe0.01levelfor7ofthe125problems,andonthe0.05levelfor2oftheother5.Also,thescoresforrelevanceandusefulnessforthepatternscollectionassuchcorrelatesonthe0.01level.UsingpatternsformattodocumentdesignknowledgeThechosenpatternsformatisinmanywayswellsuitedtodocumentuserinterfacedesignknowledge,asitcapturestheessentialaspectsofaproblem.Also,asde-signpatternsmaybeondifferentabstractionlevelstheycanbeusedtodescribeproblemsofdifferent“sizes”.Furthermore,dividingaproblemfieldintoalimitednumberofwelldefinedproblemsmakesitpossibletohandleasetofmanageableproblemsseparately.Finally,havingapatternscollectionmakesitpossibletocombinethejustmentioned“divideandrule”principlewithhavinganoverallstructure.Thebiggestchallengewehadusingthepatternsformatistheconnectionbe-tweenproblemsandsolutions.Veryoftenthisisamanytomanyconnection.Pre-sentingthesameorverysimilarsolutionstoanumberofproblems,eithercausesalotofcross-referencesorlargeamountsofrepetition.Wechosetousecross-references,asisbeingdoneinotherpatternscollections[2].Currentlywearecon-sideringrestructuringthepatternscollectionsothateachpatternrepresentseitheronesolutionorauniquecombinationofoneproblemandonesolution.Boththeseapproacheswillreducetheneedforcross-referencing,butbothwillincreasethenumberofpatterns,thusmakingitmoredifficulttogetanoverviewofthepat-ternscollection.RelatedworkThereareanumberofpatternscollectionsandevencollectionsofpatternscollec-tionsontheweb,seealso[1]foranassessmentofsuchcollections.Therearealsoafewcollectionsofpatternsformobileuserinterfaces,likeTheDesignPatternWikiandLittleSpringsmobileUIdesignpatterns.Thelatteroverlapswithtwoofourmainproblemareas,butwhileourcollectionisorganizedbyproblems,thiscollectionisorganizedbysolutions.Thepatternspresentedin[8],althoughfocus-ingonmobileinteraction,aremuchwiderinitsscopethanourcollection,withonlytwouserinterfacepatterns.[2&3]presentadesignpatternscollectionforubiquitouscomputingthatisfairlylarge,buthasabroaderscopewithpatternsthatareonahigherabstractionleveland/orarelesscomprehensiveinthesuggestedsetofsolutionsthanourpatterns.ConclusionsandfutureworkInthispaperwehavepresentedastructuredcollectionofuserinterfacedesignpatternsformobileapplications.ThestructureisvaluableasanindexanditgivesacomprehensiveoverviewofdesignproblemsformobileUIs.Thepatternscollectionhasbeenvalidatedusingaquestionnaireatatutorial.Thisvalidationshowsthatboththeindividualpatternsassessedandthewholecol-lectionwereperceivedasrelevantandusefulbytheparticipants,andthatitislikelythattheywillusethecollectioninfuturework.Italsoidentifi