面向未来的友好设计:Future Friendly

一年前翻译了本文的一部分,最近终于翻译完成。虽然此设计思想的提出已经好几年了,但是还是觉得应该在国内推广一下,让大家知道“内容策略”,“移动优先”,“响应式设计”,“原子设计”等设计思想和技术的根源。这些概念最早其实是由luke wroblewskibrad frost等人在同一个设计思想框架下提出的。笔者经“面向未来的友好设计(Future Friendly Web Design)”设计理念联合创始人Jason Grigsby授权,将此设计思想框架首次翻译为中文版本。

能力所限,敬请指正,欢迎传播,转载时请请注明出处。

一、前言

今天,联网的移动设备数量正在疾速增长,人们的上网习惯也在不断改变,移动互联网的浪潮方兴未艾,作为设计师和开发者,需要了解以下几个现状:

  1. 设备的碎片化问题凸显。未来将诞生越来越多差异化的可访问Web的设备,人们将通过各种奇葩网络环境来使用它们;
  2. 因移动设备间的设计还原能力差异巨大,我们既往千辛万苦沉淀的规范、工作流程、基础框架将无法满足设备间差异化的设计需要;
  3. 解决方案总是优于规范而先出来的,在找到跨设备、跨平台的通用解决方案之前,我们只能着手为若干目标设备寻求单独的针对性解决办法;
  4. 跨平台的通用标准的建立是漫长而曲折的。在寻求解决办法的过程中难免磕磕绊绊,一个标准化的解决方案需要在不断试错的过程中逐步诞生。

拥抱未来

道路是曲折的,前方是光明的。今后网络和设备环境的发展会为我们带来什么,我们无法确知。但是无论如何,我们应该做到:

  • 相信未来,拥抱未知;
  • 在设计工作中学习和应用一些适应未来的设计思想,即面向未来的友好设计思想
  • 用上述思想去帮助和影响他人。

二、 思考

我们的设计应该对未来更加友好一些。我们应该通过对未来的预测,选择适合的技术,为人们创造出既满足今天需要,又能够适应未来变化的产品或价值。以下是一些有关产品、设计和技术的理论思考,如果你对这些理论有新的见解,或者另有蹊径,请不吝分享出来。

专注于内容

我们不要去追求在所有设备上展现全部的内容,我们需要判断哪些内容是用户想要看到的,然后通过合理的方法重新组织起来去适应用户的设备。要知道,用户依赖自己的一双慧眼去筛选自己需要的内容是需要大量做功的。我们可以通过一系列设计和技术方案使用户在各种设备上都能够轻松愉快地获取内容和服务。这种差异化的内容组织或设计方案,可以借鉴下面三种思想:

以用户为中心环绕的数据

现在的用户往往拥有多个可联网的设备,这些设备间能够进行数据互通,就像iCloud一样,如果你使用iPad侧修改通讯录,登录同一个帐号的手机马上就可以获取到你在iPad上修改的内容。面向未来的友好设计中将此称之为“以用户为中心环绕的数据”,主要可以参考以下几点:

  1. 根据设备的特点,在不同的设备上使用独特而灵活的方式来访问数据;
  2. 同一服务在多设备上的数据要遵守一定的规范;
  3. 注重数据长期的完整性;
  4. 内容中引用的参考文献必须有意义且可以长久访问;
  5. 每个设备均应提供读写操作(对内容或内容来源的编辑)。

内容的组织

经过合理组织的内容是设计的核心。既然我们只能让内容去适应林林总总的设备,我们就有必要尽可能地了解设备间的差异、约束和限制。然后根据每种设备的特点去针对性地进行设计。未来是多变的,适应方式也是多样的。唯有大胆探索,合理预测,才能找到合适的解决方案。

无论是高端的智能机,还是受较大限制的老旧设备,设备间内容互通的设计方案同样也是面向未来的友好设计的一部分。

识别未知的设备

面对着各种不同类型的设备,设计工作无疑是个艰巨的挑战。履行web的标准化无疑是简化设计工作的最好办法,与之同时,根据每种不同设备的识别信息,进行个性化的调整,是完成设计工作必要的补充。

将当前需要适应的设备进行分类,并将分类方法应用到今后可能出现的新设备上。

运用各种设备来建立你自己的web生态系统

在我们的数码生活中,每种设备具有每种设备的优势。所以我们会选择适合的设备做适合的工作。当我们高效利用自己手中的若干设备为自己的生活服务时,这些设备就组成了一个环绕我们的web生态系统。在这个生态系统中,设备之间的关系并不是割裂的。而且只有在这个生态系统中,每个设备才能最大化地发挥它的作用。而我们需要考虑的,就是如何利用这个生态系统来提高我们工作的能力和效率。

三、参与

欢迎加入“面向未来的友好设计”。现在你是我们的一份子了。你可以在你的工作中运用,或者向他人推广这种设计思想。比方说你可以做如下的一些事情:

在设计前先思考一下我们的设计哲学

“面向未来的友好设计”描述的是一种设计原则,而不是一种特别的技术实现方案。具体的技术随着时间推移,可能会发展繁荣抑或过时衰亡。同样也没有任何一种方法、技术,或者流程可以像万金油一样解决一切问题。“面向未来的友好设计”是一种设计哲学,这种思想应该是融会在技术之中的。

使用“面向未来的友好设计”这个名称

当你在设计工作中和同伴讨论相关原则的时候,多使用“面向未来的友好设计”这个名称,向同伴们推广这个概念以及概念背后的原则。在微博中添加#ffly标签,以及使用“面向未来的友好设计”的专用logo (.eps 或 .ai)。

传播概念

向你的伙伴、下属、老板介绍“面向未来的友好设计”概念,分享我们的网站。新概念的推广肯定是有阻力的。尝试将我们的设计概念和商业目标、用户体验、关系链提升等硬指标联系在一起去解释,也许就可以争取到大多数人的认同。

选择符合“面向未来的友好设计”的技术实现方案

检查一下现在的项目目标,并且选择符合“面向未来的友好设计”的技术方案去实现它。“面向未来的友好设计 - 思想” 中有你所需的学习资源。很多作者也在不断丰富着我们的理论和技术文章,我们诚挚邀请你来检查我们的工作,同时期待着你的分享:

更多

更多信息可以关注“面向未来的友好设计”的推特@future_friendly或者这份由Dave Olsen不断维护更新的技术实践文章列表

“面向未来的友好设计”倡导者名单

个人整理的一些“面向未来的友好设计”资源

Blog

响应式Web设计创始人 Ethan Marcotte
移动优先的先行者 Luke Wroblewski
“面向未来的友好设计”概念的主要倡导者 Brad Frost

Book

Erin Kissane: "内容策略的元素 The Elements of Content Strategy"
Ethan Marcotte: "响应式设计 Responsive Web Design"
Luke Wroblewski: "移动优先 Mobile First"
Karen Mcgrane: "移动设备上的内容策略 Content Strategy for Mobile"

Article

JOHN ALLSOPP: 网页设计之道 A Dao of Web Design(2000.4.7)
Luke Wroblewski: 移动优先 Mobile First(2009.11.3)
Ethan Marcotte: 响应式设计 Responsive Web Design(2010.5.25)
Luke Wroblewski: RESS: 响应式设计+服务器端的支持 RESS: Responsive Design + Server Side Components(2011.9.12)
Mark Boulton: 关于响应式设计的工作流程 Responsive Summit: Workflow(2012.2.24)

Slides

Thomas Byttebier: 响应式Web设计 Responsive web design(2011.11.29)
Pon Kattera: 响应式设计时代的设计流程 Design Process in the Responsive Age(2012.6.21)

另外还有本人讲述响应式设计的历史和发展的PPT:“响应式设计:Rebuild as Design”,其中附录的一些资源可以作为参考

“Future Friendly Web Design”设计思想原文:http://futurefriend.ly

时间: 2024-10-07 09:40:09

面向未来的友好设计:Future Friendly的相关文章

数字化精准测试工具ThreadingTestCloud面向互联网征集产品设计人员

数字化精准测试工具ThreadingTestCloud面向互联网征集产品设计人员 各位互联网上的测试伙伴,目前我们已经有大量的用户在使用TTC进行数字化的精准测试,从TT升级到TTC历经了整整一年的时间,我们团队这一年一直在全力以赴的研发,我们坚信未来具有规范性.标准性和专业性的数字化精准测试一定会成为专业测试的趋势和潮流. 目前TTC的2.x版本已经发布,该版本是高性能的稳定版本,并且实现了所有规划的核心底层技术,但TTC到目前为止产品设计还是有TTC团队独立完成的,现在已经是大数据时代,大家

面向未来编程

我们一直以来都知道面向对象编程,面向过程编程.大多数时候还是面向工资编程,面向生活编程.面向任务编程,面向公司编程,面向领导编程. 工资不给力,心里认为委屈:生活有压力.影响工作情绪.任务完毕就好,应付一下咯.都是公司的事儿,完毕了就拉倒吧.领导喜欢什么体位就按什么体位来搞喽. 这样导致的结果呢,宝宝有苦可是不说. 工作不开心,压力大.状态不好就导致项目代码不好.文档不够,设计不行,项目管理混乱,对上都是敷衍,对下都是放羊,里外都没有交代. 实际上,我们首先应该是面向自己编程,然后是面向团队编程

面向海量服务的设计原则和策略总结

原文:http://ayufox.iteye.com/blog/676416 互联网服务的特点就是面向海量级的用户,面向海量级的用户如何提供稳定的服务呢?这里,对这几年的一些经验积累和平时接触的一些理念做一个总结.       一.原则       1.Web服务的CAP原理       CAP指的是三个要素:一致性(Consistency).可用性(Availability).分区容忍性(Partition tolerance).CAP原理指的是这三个要素最多只能同时实现两点,不可能三者兼顾,

Google搜索排名优化-面向搜索引擎的网站设计

内容摘要:网站在搜索营销方面最主要的缺点: 行业知识:不知道搜索引擎对吸引的新用户的重要性,在搜索引擎排名服务中追求“傻瓜相关”,购买一些其实没有太多实际意义的行业关键词.其实能够用户输入的关键词越多,其目标性越强,这样的客户价值越高.用户能够直接定位到产品具体内容页比到网站首页有价值的多: 发布技术:网站的网页进入Google的索引量非常小,主要是由于大量使用动态网页造成的.需要将动态页面链接改写成静态 链接: 页面设计:页面标题重复,关键词不突出,过渡使用JavaScript脚本/图片/Fl

面向过程的软件设计

“面向过程”是一种以过程为中心的编程思想.“面向过程”也可称之为“面向记录”编程思想,他们不支持丰富的“面向对象”特性(比如继承.多态),并且它们不允许混合持久化状态和域逻辑.就是分析出解决问题所需要的步骤,然后用函数把这些步骤一步一步实现,使用的时候一个一个依次调用就可以了. 开发阶段的信息流 结构图:程序中模块间的调用关系 1,  模块 2,表示模块A有条件地调用另一个模块B 3,  模块间的信息传递 4,  模块的调用关系和接口 程序的系统结构图 深度:5 宽度:7 结构化设计方法 在系统

面向对阿象设计原则

如何衡量软件设计质量1 首要的标准 满足软件的功能需求 满足软件功能需求的设计并不一定就是好的设计. 好的设计 可读性:软件的设计文档是否轻易被其他程序员理解.可读性差的设计会给大型软件的开发和维护过程带来严重的危害. 可复用性:软件系统的架构.类.组件等单元能否很容易被本项目的其它部分或者其它项目复用. 可扩展性:软件面对需求变化时,功能或性能扩展的难易程度. 可维护性:软件维护(主要是指软件错误的修改.遗漏功能的添加等)的难易程度. 上面四个标准太抽象了,无法考量 内聚度 耦合度 什么是内聚

面向未来的 ES6 模块标准

既然模块化已经越来越重要,那么从语言层面上直接去解决这个问题就显得很有必要(况且其他语言早就有了).于是 ES6 直接在语言标准的层面上,实现了模块功能,而且实现得相当简单,完全可以取代 CommonJS 和 AMD 规范,成为浏览器和服务器通用的模块解决方案. 设计思想 简单来说,ES6 模块的设计思想就是:一个 JS 文件就代表一个 JS 模块.在模块中你可以使用 import 和 export 关键字来导入或导出模块中的东西. ES6 模块主要具备以下几个基本特点: 自动开启严格模式,即使

原创《weex面向未来的架构》

最近一直在做weex的调研工作,整理之后给公司做了一次技术分享. 分享内容如下: 1:Weex是什么? 2:  Weex目前能做什么? 3:  Weex 如何调试 4:  剖析一下Weex原理 5:  跨平台通用组件 6:  Weex的未来发展 1:weex 是什么? 进入到官网:http://alibaba.github.io/weex,简单明了的几个词,揭开了weex的神秘面纱 : write once run everywhere  &&  Native Speed in Nativ

loadrunner中面向目标场景的设计

在一个面向目标的方案中,可以定义五种类型的目标:虚拟用户数.每秒点击次数(仅 Web Vuser).每秒事务数.每分钟页面数(仅 Web Vuser)或方案的事务响应时间.使用“编辑方案目标”对话框可以对方案目标进行定义.就是设置一个运行目标,在Controller中运行相关负载,如果测试的结果达到目标,则说明系统的性能符合测试目标,否则就提示无法到达目标.目标场景是定性型的性能测试,我们只关心最后性能测试的结论是否符合性能需求,常常用在验收测试的场合. 1.下拉选择运行方式: 2.设置方式 3