文章目录[隐藏]
本文由Mail.Ru公司的员工Yury Vetrov讨论的关于移动Web框架设计的案例研究，将从设计流程的转变过程讨论，即从经典原型→设计→模型→HTML实现方法，为每个产品设计实现基于框架的现代而高效的方法。
在2012年代中期,我们推出的手机网站mail . ru的新闻，这是基于设计和技术平台的第一个项目,我们内部称之为“引导类固醇。 “现在我们有9个产品建立在这个框架上，将来也会越来越多。
上述产品设计依次为:汽车、货币、健康、高科技、星座,孩子,夫人,新闻、天气、体育、电视。
这种方法有几个好处:
- 视觉风格、交互设计原则和信息架构是统一的。 设计和生产一批视觉类似、工作原理相仿的产品利于用户。对于品牌建设也非常好,因为可形成统一产品线。
- 推出新产品和重新现有设计变得更容易。 框架有所有必要的UI控件,模式和组件。 它还可以帮助我们快速建立新的设计。
- 容易控制大量的产品项目当他们都以同样的方式设计，而不是去关注一百个独立的项目,你只需要控制核心准则。
- 现代设计过程意味着我们正在设计的代码而不是为每个屏幕设计经典原型→模型→HTML→实现方法,若是那样将会产生很多不必要的工件。
- 任何有效的产品决策会产生累积效应。 例如,我们可以增加体育网站上翻页长度,然后这些增强功能适用于所有其他产品。
- 从每两年重新设计到不断更新设计。 大型设计都需要花费很多的时间和精力,通常会因此失去很多细微改进。
总的来说,这种方法已经成为我们的用户体验战略的一个重要部分。 最重要的事情是对我们的框架来说它也已成为一种实现统一的技术。 我们多次试图统一我们的设计规范,UI工具包、模式库等,但并没有作为长期的解决方案来帮助我们。 他们的内部交付设计团队也很少有开发人员的要求。 我们都知道通常从模型到生产时会产生错误。 然而,如果曾使实现准确和可重用之后,那么在设计出货产品的质量上会更加自信。 这就是为什么我相信对于关键阶段统一做出的努力是一套产品实现的水平。
我们的框架是如何工作的
第一个版本背后的主要思想是在Photoshop里编译一个巨大的UI工具包，包括所有UI模式,控制和常见的屏幕。 这与Adobe InDesign线框图模板一起并具有外观类似的设计模型。 重要的是让它看起来像一个真正的产品,不仅仅是灰色块。 尽管这些线框模型有小差别,但用于经理和开发人员呈现和讨论已足够了。 当我们开始一个新项目,我们线框排版软件名称中所有屏幕,容易转换成一个可点击的PDF原型并在手机上观看。 如果有任何新的UI模式,我们模拟在Photoshop的细节,然后将它们添加到排版软件名称库。
UI工具包在Photoshop的快照
所有的新模式是包含在统一的代码库中。 我们编译完成页面HTML的现成的组件(如评论或相册)工作原型。 此原型设计师审查并有机会增强视觉和交互设计特定的页面或块。 通过这种方式,我们可以找出许多小问题和想法。
这是一个存储库的结构:
touch.news/
blocks/
logotype/
logotype.png
/* Compiled from blocks and toolkit. Blocks includes pseudobundle common.css */
bundles/
article
toolkit/
blocks/
logotype/
logotype.xml
section/
header/
我们使用模板引擎在用户的浏览器中显示一个页面。 它构建一个最终有效使用代码和格式良好的HTML页面,图像的资产,一个UI模式的样式和脚本。每个页面模板都有一组规则构建页面:块的类型和他们的订单。 值得注意的是,一个模板和数据来构建一个特定页面分离和独立加载。 它帮助我们节省流量,增加速度。 例如,如果一个用户看到一个新闻列表,那么它的模板将在浏览器缓存,因此只有下次下载的内容。
模板引擎的概述
当我们拿出一个新的设计模式或组件(例如,一个新的方式来显示一个相册),然后我们改变它的原型,原型和代码库。 然后,每个项目从统一存储库更新,几乎像一个应用程序从应用程序商店。 最好的部分是,设计师必须审查只有一个实现统一的代码库,而不是检查每个产品。 他们可以确定最终设计的质量。
当前的设计过程与框架
我们将重新考虑UI工具包很快。 设计师将代码而不是创建和更新静态比较在Photoshop和排版软件名称。 但到达那里,我们必须通过创建和实现框架的整个过程:
- 创建一个参考设计平台。
你必须找到一个合适的和可伸缩的信息架构、交互原则,视觉风格和技术解决方案的框架。 - 将所有的产品平台。
UI工具包和统一代码库扩展新模式,和每一个产品的后端与框架的要求一致。 - 重构的设计过程。
技术方案已经调整和核心产品任务已经解决,所以你可以摆脱大多数设计工件和创建新的屏幕的现成的模块统一的代码库。 - 重构设计。
发布12个产品需要大量的时间,所以发射后发现很多问题。 设计趋势也发生了变化。
我们现在在我们的第三和第四步框架实现。 但是我们已经受益于从一开始使用它。 进化设计变得容易,大大减少不必要的工作量。 回首过去,我相信我们可以实现过程更快,更短。 我将讨论我们的好的和坏的决定,你应该决定你的工作是容易跟随我们的路径。
它是如何创建的，第1部分:设计
这一切都始于邮件。 俄罗斯在2012年初集团的主页。 主页是一个门户网站,我们的读者访问使用我们的服务。 在项目的开始,我们达成一个基本的设计方法:一组卡片从不同的产品呈现的信息块。 这也包括了一个共同的风格为页眉和页脚,控制,等等。我们喜欢最初的概念,所以我们决定把它应用到新闻产品。 更多的信息比一页,以及一个复杂结构和几个页面模板。
邮件， 俄文主页:邮件。 俄罗斯的手机版首次亮相于2004年,是基于web的电子邮件,我们的主要产品之一
邮件。 2004年俄罗斯手机邮箱(WAP)
现在是时候来设计导航原理、关键页面的结构和表示的内容。 我们不得不考虑我们的其他项目,也因为他们也遵循这些指导方针。 幸运的是,我们已经在移动工作”活动指南”结构相当复杂的网站和服务。 这个事件的视觉设计指南非常不同于我们所需要的新闻,但大多数UI模式是适用的。
活动指南网站
我们可用性测试的指南。 试验表明,这一概念是工作! 它还帮助我们找到一群的改进。 例如,一个额外的搜索字段在页面的底部受到用户的欢迎。 链接的最后一个卡片一个滑块,所有条目的列表也帮了很大的忙。这是重要发现用户有问题扫描长页面card-less设计(即当块之间没有利润本身和屏幕的边缘),因为内容多样化和严重依赖之间的交联部分和对象。 iOS 7消除卡,我相信card-less方法并不像有利于长页面与一群聚合内容。 谷歌的材料设计方法对这种情况更好。
card-less的方法。
线框图与排版软件名称是我们的下一个步骤。 在这里,我们发现重用模式存在的第一个问题。 我们应该减少时间加载和使用尽可能少的图像,或我们应该视觉和显示为每个链接的插图吗? 你的卡片的方法在边界情况下,比如一篇文章的相关物品:使用所有卡或没有卡吗? 请记住,许多用户访问我们的内容项目从邮件通过特定的文章的链接。 俄文的主页,而另一些则来自一个项目的主页。 “返回”按钮应该领导呢?
线框在Photoshop排版软件名称与设计模型。
设计模拟关键页面都准备好了之后,我们的设计师把它们放进一个文档。 我们有一个UI工具包,使设计师的工作更容易。 快把模型放在一起,它们之间的分歧已经降低了。 我们也开始生产指导方针,这使其他设计师参与移动web设计的框架。 此外,这些指南对开发者而言是一个很好的参考在实现UI模式。 我们准则的结构如下所示:
Overview
Visual style
Grid
Color and textures
Typography
Icons
Interaction
Navigation
Gestures
Selection
Scrolling
Notifications
Basic patterns
Screen structure
Header
Title
Search
…
Footer
Controls
Inputs
Input
Textarea
Select
Date
Checkbox
Radio button
…
Buttons
…
Navigation
Tabs
Slider
Links
Alphabet
…
Dialogs and windows
Popup
Photo viewer
Photo upload
Calendar
…
Lists
Article
Event
Match
Search results
…
Widgets
Weather
Currency
Horoscope
…
Media
Photo
Video
…
Common screens
Login
Registration
Settings
Help
…
Ads
Banners
Internal promo
…
指南的结构的一个快照
所有的碎片聚集在一起。 然而,我们想要检查设计是否可以扩展到几十个项目,所以我们设计了一个星座的网站。 工作的方法,适应快速和容易。 这样的试飞是至关重要的在扩展参考设计一些产品,因为它可以帮助找到弱点在为时过晚之前的概念。
星座的网站
它是如何创建的,第2部分:技术
在讨论的想法统一设计与开发人员,我们研究了技术解决方案已经在我们的项目中使用。 我们的项目都有一个全球品牌头内导航菜单。 和许多较小的解决方案是我们的邮箱产品,如授权弹出窗口和其他地区的UI。 虽然技术必须认真思考,我们从不发动了整个产品基于它。
统一门户菜单在2011年推出
我们的开发人员进行了广泛的研究如何在技术上统一设计。 我们应该创造自己的解决方案或使用现有的框架? 的边界元法(block-element-modifier)意识形态从Yandex完美的框架来考虑。 统一设计的几个产品,我们需要尽可能相似的UI块被重用,而无需审查每个实现。 本保证每一块将独立于周围发生的事情。 你可以把它放在任何页面,它将是相同的。
Yandex库的开源工具,称为bem-tools,框架内更容易工作。 顺便说一下,我们的开发人员提交几个补丁库。 背后的想法本是被称为“绝对独立的块,”和越来越多的这样的框架。
边界元方法
然而,贝姆的模板引擎不够speed-efficient为我们和不符合我们的任务。 我们已经使用基于javascript工具与节点。 js代码在服务器上执行,因此,这是我们的选择。 谢谢,我们有相同的模板在客户机和服务器上,呈现完全相同。 单独的数据传输。 因此,当一个模板被缓存在浏览器(后会发生第一次加载),用户只是下载新内容。 这种方法使过程更快,减少流量。
注意:这里描述的技术部分简要只是给大家了解它是如何工作的。 本文的重点是重新考虑设计过程。
之后,开发人员给我们一个工作原型，并且这个方法成功了。 在两个半月,我们设计了12个项目,为我们的用户体验团队真正的速度记录。 指导方针包括视觉风格,交互原则,信息架构和公共模式如导航、列表、不同类型的卡片,内容表现形式,弹出窗口,图表和一群特定项目的事情。 我们也增加Photoshop UI工具包和排版软件名称模板。
然而,支持三个库(排版软件名称,Photoshop和统一代码库)是一个负担,所以我们找到了一种方法自动化指导支持。 这是一个生活风格指南——一个自动生成的页面,真正的代码是用来代替png。 你可以标注这些模式的描述。 审查已实现的设计一旦你看到生产每个UI代码块是容易得多比获得静态图片(可以是编码不正确)模型。 现在,这种生活风格指南只是一个原型,但重新启动后所有的项目,我们会回来的。 此外,做这样的指导方针,我们将能够使原型的实际代码,完全绕过排版软件名称——保持接近生产另一个方法的代码。
似乎比引导我们走得更远。 流行的引导框架只是一套现成的样式和脚本的代码示例。 但当引导框架本身是更新,推出更改您的项目不是那么容易,有时你也需要更新新版本的HTML。 在我们的例子中,一个项目得到一套现成的UI块不断更新——甚至做出更改后的框架。 此外,引导不支持独立的块模型,所以冲突可能当你连接到第三方库如jQuery UI,因为他们将会覆盖彼此的风格。 引导是为其他任务,比如开始一个项目很快就使用现成的元素。 这是一个像我们这样的问题对任何自定义解决方案——你需要很多的时间来得到它。
这里有一些事实和数字显示的改进我们的工作过程:
- 用户体验和视觉设计的整体速度有所提高。 以前,我们必须模拟大部分屏幕排版软件名称为每个项目和Photoshop。 现在,一篇论文或白板草图就足够了。 备份的聚合模型,展示如何将所有项目的独特的块。 我们可能花了一个多月的设计之前,但现在这一切都发生在一两个星期。
- 发展的速度也增加,所以我们可以更快地推出新设计。 我们不需要代码设计原型或仔细考虑数据结构——我们只是把现有的模式,它会自动在新产品工作。 即使我们想要改变或扩展UI,它又快又便宜。 我们可以发布一个新产品在一个月,而不是几个月。
- 现在获得批准管理是一项容易的工作。 任何设计指南将帮助,但是管理有了更多的信心,因为指南现在获得的一个统一的代码库。 我们有更少的会议现在也接受更少的要求更改。
- 我们也有更少的缺陷在设计实现。 之前我们有框架,每一个设计审查可能会引入50名左右的bug。 现在是类似一打。 然而,引入了一个新问题:在推出一种更新UI模式之前,我们必须检查它不会打破所有的产品中使用。
- 专业知识的重点发生了变化,更熟练front-enders是必要的。 以前,所有的计算都是在后台——front-enders刚放进模板。 因此,任何涉及减少性能问题,如低效率的排序算法,是后端开发人员的责任。 现在开发人员只提供数据。 和的模板是一个JavaScript代码辅助功能可以影响呈现页面的整体性能。 大致说来,在前端性能泄漏的风险从2%跃升至2%。 此外,front-enders必须为每个模式预测扩展功能,使他们不必每次都重写全球。 入门的门槛也在增加。
- 团队成员是可以互换的,可以更容易地重新分配。 编码器的工作项目可以很容易地转移到项目b的工作原则和标准代码和数据都是一样的。 这也使得我们可以把几个front-enders单个项目并行工作。
- 团队可以小和专注。 移动互联网的整个产品线,其10个产品,更新有两个用户体验设计师,两个视觉设计师,六front-enders和三个开发人员。 全职,都没有被分配。
- 设计实验现在容易得多。 改进更快地实现。 这是我们设计师的小梦想:能够船想法比竞争对手更快。
- 保持设计现代和日期比较便宜。 而不是重新设计每隔几年,我们根据需要更新项目的风格,我们只需要几天。
- 今年以来框架,移动应用在我们的内容项目从1至2%上升到7至12%。 两个产品经历了更大的增长——15到20% ! 坦率地说,移动开发的原因不是我们的特定方法,任何方法都做同样的事情——在一个智能手机的市场非常畅销,而是我们的框架,使我们能够推出移动网站快得不可思议。
- 这个框架将用于重新启动我们的主要版本内容的项目,所以他们的发展会便宜一些。 我将在以后的文章中讨论这个在这个系列中。
我们分享的问题。 但是整体的结果对产品和团队是惊人的。
我们的未来框架
最初,我们的框架是为了支持手机的三个类别:现代智能手机(Android、iPhone、Windows Phone),年纪大的智能手机(巴达,Symbian——这些在俄罗斯的安装基础仍然相当大)和功能手机。 此外,对年长的Android浏览器(包括之前出货的标准一个Chrome),我们使用稍微简化版本,因为他们无法足够迅速地呈现的视觉效果。 最初,这个版本从基本设计有更多的差异,但是我们简化它缓解未来支持;后来弃用。
我们的想法是让这个UI自动退化;支持三个指导方针会太贵。 虽然我们是现代智能手机推出一个版本,另外两个手机类别的市场份额下降更多。 所以,看来,我们甚至不需要这个简化的解决方案。
现代触摸屏事件指南网站,年长的智能手机和功能手机
比较老的版本和现代Android浏览器
这样的统一有一个缺点:如果所有的产品有一个类似的设计,然后他们将缺乏一个独特的身份和分化。 我们的经验表明,用户感知一个独立的产品,比如天气预报员是更值得信任和专业比大门户的一部分(即使利用相同的数据)。 所以,视觉上区分一个产品可以帮助改变这种看法。 这还不重要,尽管移动互联网真正的快速增长。 在第一个星期的工作在这个框架中,我们尝试了几种方法使风格化的产品不同,我们将回到它。
不同风格的探索
一些读者会怀疑响应设计;毕竟,Smashing Magazine推动真的很难。 为什么我们启动一个单独的移动web框架? 这是一个漫长和热烈的讨论,每一方清单的利弊。我们必须尽快船舶现代移动版本,和适当的响应方法需要重新启动第一大网络版本。 我们正在努力,我们已经推出了数款产品基于一个类似的框架。 但是这个任务要复杂得多,所以不可能有意义的时间。 我们的方法可以被称为适应性。 Smashing Magazine最近发表的一个伟大的文章的主题。
在任何情况下,我们不做精简移动版本的产品的所有内容和大多数的服务更大的同行。 尽管如此,越来越多的用户,没有所谓的“主要网站。 ”页面他们碰巧看手机是唯一的版本的产品。 对移动设备的研究数据增长2010年和2011年。
有两种方法来设计统一。 你可以详细的指南,然后将它们应用于现有产品,或者你可以重新设计你的产品变得如此好,成功,它可以作为“参考产品。 “有这两种方法的优缺点。 我们去。 我们扩大设计已被证明在实践中与可用性测试和分析优化。 还有风险,我们必须改变一些模式后,因为我们不能看到整个画面一开始,但我们认为产品效率更重要。
小奖金,我们还发现了一种统一的应用程序图标,显示当一个手机网站上智能手机的主屏幕。 这是一个长的路要做到这一点,世界上只有少数公司拥有大量产品组合能够解决它(Yandex,谷歌Android)。 别人只是在角落里放一个小公司logo。
统一的图标
现在我们要更新的视觉设计,我们会发现无论是一样容易。 我们要改变外观,因为它已经超过两年了这个设计最初实现的。 当推出这样的指导方针,有新的设计趋势将出现的风险。 即便如此,设计师应严格遵循他们自己的标准。 当然,作为框架推出,某些产品可能不太新鲜的视觉。 但平台推出后,你会有更新的12个产品的设计在几天之内。
视觉刷新
所以,此前平面设计的趋势将很容易捕捉。 当然,追逐趋势不是一个可行的设计策略。 但在我们的快速变化的行业,激进的转换有时会在一夜之间发生,去年发生在iOS 7。 公司应该有一种方式来应对这些变化很快。
结论
我们最初的目标是更新我们的设计基于内容的项目在手,让他们看起来相似。 完全统一的想法,包括技术方面,出现在我们与开发商谈判。 被好朋友与开发商支付的发现这样的可能性。 大去感谢整个团队的设计师和开发人员使它发生,尤其是安东Eprev,他们建立了技术基础。
将来设计过程的框架
你必须有点权威实现指南时,保持系统的设计的方法。 你应该尽可能使用现有模式。 如果你需要引入新的东西,那么你应该了解你是否将使用它在未来。 这是唯一的方法,使设计框架和产品组合一致的。 支持,也将使它方便、舒适为用户和积极的品牌。
文章来自smashingmagazine，艾欧原译，更多交互设计资讯请关注木卫艾欧网。
原创文章，作者：Smiler李想，如若转载，请注明出处：https://www.iamue.com/3772/
