月度归档:2015年03月

2015非官方的iOS APP全方位设计指南

有时候为iOS设计app并不是一件简单的事,但是如果你能找到正确的最新的苹果设备信息,并按照正确的方向,那么为iOS设计app或许会变得简单容易些。

关于这些指南

这些指南描述了如何遵守苹果的iOS 人机交互指南来设计app,而不是讲用自定义控件可以做成什么样的设计,有时候打破规则也很重要。该文档的目的并不是为一些复杂的设计问题提供解决方案。该文档是非官方的,将会定期更新和扩充内容,最近一次更新是2014年11月11日。

分辨率和显示屏规格(Resolutions和Display Specifications)

Points 和Pixels的区别

Pixels(像素)是数字显示屏上我们可控制的最小物理元素,在一个特定屏幕尺寸中可以有多个像素,PPI(pixels-per-inch)越高,则渲染的内容会越清晰。

Points用以衡量分辨率。根据屏幕的像素密度,一个point可以包含多个像素(比如在常规的retina屏上,1pt包含2 x 2的像素)。

当你针对多个显示屏类型进行设计时,你应该以points进行思考,但以pixels进行设计。这意味着你仍需要以3种不同的分辨率来输出设计资产,不管你针对哪个分辨率设计应用程序。

iPhone 6+缩减像素取样

在iOS上渲染像素和物理像素(physical pixels)是等同的,只有一个例外:iPhone 6 Plus的Retina HD显示屏。由于它屏幕的像素分辨率要低于一个常规的@3x分辨率,所以被渲染内容会自动调整为原始尺寸的87%(从2208*1242像素来适应为1920*1082像素的显示屏分辨率)

iPhone 5S, 6 以及6+显示屏区别的详细信息可参看:The Ultimate Guide To iPhone Resolutions

App Icons

自动应用效果

多尺寸的应用程序icon通常被添加到应用程序包中,当在设备上渲染时,iOS会将效果应用在应用程序icon上。

(1)圆角

圆角半径值已经不存在了。从iOS 7开始,app icon已经使用了超椭圆的形状。由于苹果没有发布该形状的官方模板,所以你得精确地使用非官方的模板。

圆角的图形不应该包含在最终的输出资产中,但如果你想要添加和应用程序icon拐角对齐的描边和阴影效果,那你可能还会用到圆角图形。

提醒:因为你想将应用效果和icon拐角对齐,所以如果你正使用超椭圆的形状对icon资产进行蒙版(遮罩),那要确保在遮罩外的区域不能使用任何透明的图形。应用程序icon不支持透明度,相反作为纯黑色进行渲染。如果你的遮罩不是百分百精确,那用户将会在圆角边缘看 到黑色的锯齿。推荐将canvas的背景设置成和app icon一样的背景。

(2)边框描边(某些情况下)

如果你使用的app icon有白色的背景,那么将会应用1pixel的灰色边框,以便更容易地识别icon的边缘。这只能在设置app和App Store中进行。

(3)后续问题(iOS 6 和之前的版本)

在旧的iOS版本中,这些效果会自动应用:可以被禁用的圆角(和iOS 7+中使用的icon不同)、主屏幕上的阴影效果以及关泽效果等。

栅格系统

苹果开发了具有黄金分割比例的栅格系统,可用以正确地调整和对齐icon上的元素。不过,甚至是苹果设计师的原生app icon也没有完全严格地遵守栅格系统。所以如果你的icon上的元素在没有严格遵守栅格系统的情况下能更好地展示,那你可以考虑下打破一些固有的规则。

字体排版

所有的iOS版本中默认字体都是Helvetica Neue。从iOS 7开始,苹果使用了稍作修改的字体,但是在你的设计过程中使用原始的Helvetica Neue是极好的。除了默认字体外,你还可以使用很多可选的字体,你可以在此查看完整的预置字体列表。

自定义字体

从技术角度讲,True Type Font (.ttf)可以被用在iOS app中,但要注意许可问题。一般来说,使用完全免费或者商业化的字体是安全的。MyFonts最大数量地包含了可用在app中的许可字体。

调色板

iOS 7以后,苹果在操作系统和预装app中使用了更有生机和活力的调色板。虽然你可以使用上边默认的iOS调色板,但你也可以使用自己的颜色(如果你想与众不同,当然要使用了)。

图标

在iOS app中,icon一个很好的用法是使用视觉化的关系来支持文本标签,从而执行一些操作或者完全取代文本(最常用的比如”New”、”Delete”等)。通常,我们使用icon来区分导航栏、工具栏以及标签栏。

各种”栏”的按钮icon

各种”栏”中的按钮icon应该有两种状态:默认状态下的1或者1.5pt笔画宽度的轮廓样式,以及纯色填充的活跃状态。

不要在按钮icon上添加任何额外的效果,比如下拉阴影或者内阴影,因为这些是iOS 7之前版本中的用法。按钮icon应该在一个透明背景上以一种纯色进行绘制–icon的形状作为遮罩,颜色将会以编程形式应用。

活动视图图标

活动视图(通常指分享弹出视图)中的icon以轮廓样式设计,但苹果在iOS 8以后回归到白色背景上的实体填充icon风格。

常用设计元素

iOS提供了很多不错的现成的视图和控件,可帮开发者快速构建页面。开发者可以将一些元素自定义到某个级别,但是也有一些元素不能或者不应该进行自定义。当为iOS设计应用程序时,你应该知道一些工具集的使用,只要是可能,就应该坚持下去。但在一些情况下,可能需要设计一些自定义控件,因为你需要一个更加定制化的界面或者想要改变现有控件的功能(有点危险)。几乎任何一件事情都是有可能的,而有时候你需要打破既有的规则,不过需要三思。

状态栏

状态栏包含了基本的系统信息,比如运营商、时间、电池状态以及其他等,它在视觉上通常与导航栏联系在一起,并且使用相同的背景填充。为了匹配你的app的风格,并且易于阅读,状态栏的的内容一般有两种不同的风格:深色(黑色)和浅色(白色)。

你可以隐藏导航栏,但要思考清楚。比如在app下载web内容时,用户可能对设备是否连接上WiFi网络比较感兴趣,在app要求蓝牙连接第三方硬件时,用户可能会想知道应用是否启用了蓝牙。一个令人信服的隐藏状态栏的理由是你想移除对的那个元素的所有干扰信息,比如全屏展示内容,比如图片。

导航栏

导航栏包含在app多个视图间进行导航的控件,以及在当前视图中管理内容的选项。导航栏通常展示在屏幕的顶部,状态栏的底部。默认情况下,背景是半透明的,在导航栏下方还有模糊的内容。导航栏的背景可以是纯色的,渐变的或者是自定义的位图模式。

竖屏模式下的iPhone 6导航栏。

横屏模式下的iPhone 4S导航栏。导航栏的高度减了12pt,除了iPad。这也是常见的横屏模式下隐藏状态栏的方法。

元素应当遵循特定的对齐模式:

1.返回按钮通常居左对齐。

2.当前视图的标题应当居中展示在bar中。

3.Action按钮通常居右对齐。如果可能的话action按钮应当限制在一个主要操作行文,以避免错误点击,并维持其简洁性。

工具栏

工具栏包含用于管理或者操作当前视图中内容的一些操作。在iPhone上,它通常出现在屏幕的底部,但在iPad上也能出现在屏幕的顶部。

和导航栏类似,工具栏的背景填充也能调整,默认情况下工具栏本身是半透明的,在其下方还有模糊的视图内容。

当一个特定视图要求三个以上主要活动,但放在导航栏上又显得凌乱时,你可以使用工具栏。

搜索栏

搜索栏默认有两种风格:突出的和最小化的。两种类型的搜索栏在功能上是一样的。

1.只要用户没有输入文本,搜索栏中会展示占位符文本,而书签icon则可用来访问最近或者保存的搜索。

2.键入搜索项目后,占位符消失,一个清晰的删除按钮会出现在搜索栏的右侧。

搜索栏可以利用一个提示–一个短句来介绍搜索的上下文环境。比如”键入某个城市、邮政编码或者机场”

不使用提示和使用提示两种风格

最小化搜索栏类型

想要提供对检索词条的更多控制,可用scope bar(范围栏)限制搜索栏,scope bar会使用和搜索栏一样的风格,当搜索结果有清晰的定义类别时,这种方法比较有用。比如,在一款音乐类app中,搜索结果可以按照专辑和歌曲再次过滤。

标签栏

用户可使用标签栏在app的单个视图间快速导航,并且标签栏也只能用于这个目的。标签栏通常出现在屏幕的底部。默认情况下,标签栏是略透明的,并且向导航栏一样使用系统的模糊效果。

标签栏包含固定的最大数量的tabs,一旦标签数量超过其可容纳的最大数量,后边的标签将会展示在隐藏的”More-tab”列表中,并且有一个选项可重排标签顺序。

虽然iPhone上最多可展示5个标签,但是在iPad上最多可展示7个标签。

为了提醒用户视图上的新信息,有时候需要在标签栏按钮上使用标记数量。如果一个视图被临时禁用,那么相关的标签按钮不应当完全被隐藏,相反应当淡出视觉范围以表示其禁用状态。

表视图(Table View)

表视图以单列或者多列形式展示少数或者多个列表风格的信息,并有能将内容分组的选项。根据你展示的数据类型,通常可使用两种基本的表视图风格:

无格式的

无格式表视图包含的几行内容的顶部可以有页眉,最后一行后边可以有页脚。可以在屏幕右边缘展示垂直导航,以便在表中进行导航,这种情况适合展示以某种方式储存的大数据集的时候,比如按照字母降序排列。

分组样式

分组表视图允许用户对内容进行分组。每个分组可以有页眉(最佳用法是描述类组的上下文环境)和页脚(适用于帮助文本等)。一个分组的表视图至少需要包含一个类组,并且每个类组至少要包含一行内容。

对于以上两种表视图类型,可用几种风格来展示数据,以方便用户快速扫描、阅读和适当调整内容。

默认

默认的表视图有一个居左对齐的可选图片和标题。

带有副标题

在每行标题下展示小字号的副标题,适用于进一步的解释说明或者简短描述。

带有数值

带数值表类型可展示与行标题相关的特定数值。类似默认的类型,每行都有一个居左对齐的图片和标题。在该类型中,数值居右对齐,通常使用比标题淡一点的文本颜色。

模态视图、弹出视图以及提醒(警示)视图

iOS提供了多种风格的临时视图,可以某种方式在既定的情况下展示、编辑或者操作数据。虽然每种临时视图因某个非常特定的目的而存在,但外观上却大有不同,不过所有临时视图都有一个相同的地方:在展示时,它就是当前视图上最上方的图层,下方的内容被一个黑色的背景所覆盖。

活动视图(ACTIVITY VIEW)

活动视图用以展示特定的任务。这些任务可以是系统默认的任务,比如通过可用选项分享内容,或者是完全自定义的活动。当为自定义任务按钮设计icon时,你应当遵从活跃状态和栏按钮icon的一些设计指南–纯色填充、无任何效果、以及在一个透明背景上。

活动(ACTIONS)

活动页面用来执行可用操作列表中的单项操作,并且强迫用户确认或者取消某个活动。

在竖屏模式下(以及尺寸比较小的横屏模式下),actions以按钮列表形式滑入,并呆在屏幕的底部。这种情况下,活动列表应该有一个取消按钮来关闭视图和执行任何列表中的action。

当有足够可用的空间时(比如iPad上),活动列表可在视觉上转为弹出视图。不过此时不一定非得有一个关闭按钮,用户点击弹出视图外的任何地方都能关闭弹出视图。

提醒视图

提醒视图的目的是用来通知用户一些关键性的信息,并有选择地迫使用户做出选择。

提醒视图通常包含一个标题文本(最好不要超过一行)、一个(纯信息提醒,比如”OK”)或者两个按钮(要求用户做出决定,比如”Send”或”Cancel”)。

你可以在提醒视图中添加消息文本,如果需要的话则可添加两个文本域,其中之一可以是蒙版的输入区,适合密码或者PINs之类的敏感信息。

编辑菜单(EDIT MENU)

用户可使用编辑菜单执行复制、粘贴以及剪切等操作。虽然你能控制用户可以选择哪个操作,但是编辑菜单的视觉外观是设定好的,不能重新配置,除非你设计一个完全自定义的编辑菜单。

弹出视图(Popovers)

当某项特定操作要求多个用户输入才能继续进行时弹出视图就非常有用了。在水平方向上,弹出视图可通过箭头指向展示下方相关的控件(比如按钮)。弹出控件的背景透明度稍有降低,可展示其下方的模糊内容,像iOS 7以后其他很多UI元素一样。

弹出视图是一种非常强大的临时视图,可包含类似导航栏、表视图、地图或者web视图等对象。随着弹出视图所包含内容和元素的增加,其窗口也能滚动展示。

模态视图

模态视图适用于需要多个命令和用户输入的情况,位于屏幕上所有内容的最上方。典型的模态视图通常提供:

1.描述任务的标题。

2.关闭模特视图的按钮,没有保存或执行任何其他操作。

3.保存或者提交任何已输入内容的按钮。

4.模态窗口主体中提供大量用户可输入的元素。

有三种可用的模态视图类型:

1.全屏模式:覆盖整个屏幕

2.页表模式:竖屏模式下,模态视图覆盖屏幕上的部分内容,仅在半透明的暗色背景上展示部分父视图的内容。横屏模式下,模态视图会像全屏模态视图那样展示。

3.表格页面模式:竖屏模式下,模态视图出现在屏幕的中间。模态视图范围之外,父视图内容展示在半透明背景之下。当需要展示键盘时,模态视图的位置会自动调整。横屏模式下类似全屏模态视图。

控件(Controls)

iOS为基本上任何类型的输入需求提供了各种各样的控件。以下列出的是最常用的控件,但想要看详细的完整的可用控件列表,请在iOS Developer Library中查看。

按钮

最常用的控件可能是按钮。iOS 7以来,默认的按钮设计看起来更像一个纯文本链接。按钮控件支持高度自定义。按钮可以有几种不同的状态,可以使用视觉语言传达:默认、突出、选择以及禁用等。

选择器(PICKERS)

选择器用来在一个可用值列表中选择某个值,和Web上的下拉选框功能类似。选择器的扩展版本是日期选择器,允许用户滚动日期和时间列表来选择一个月、日以及具体时间。

左:表视图中的日期选择器,右:选择器作为键盘

除了背景色外,不可能更改其视觉风格或者尺寸。很多时候,选择器位于屏幕的底部,像键盘一样展示,但不能用在其他地方。

分段控件(SEGMENT CONTROLS)

分段控件包含一组至少两个以上的分段,可用来过滤内容或者为清晰分类的内容创建标签。

不带icon与带icon的分段控件

每个分段可包含一个文本标签或者一个图片(icon),但不能同时包含两者。另外,不建议在一个分段控件中混合使用不同的分段风格,比如文本和图片。每个分段的宽度会基于分段的数量自动调整(两个分段各占50%,5个分段各占20%)。

滑杆(SLIDERS)

滑杆控件允许用户从允许值范围中选择一个特定的值。由于使用滑杆选择一个值的操作非常流畅,并且无需额外的步骤,所以建议在选择预估值的时候使用滑杆,而不是选择精确的值。比如滑杆可以很好地用来设置音量,用户可以听到和看到音量大小的不同,而通过输入文本来设置精确的dB值是不切实际的。

不带icon与带icon的滑杆控件

可以为最小值和最大值设置icon,icon会展示在滑杆控件的开始和末尾两端,从而在视觉上加强滑杆的目的。

进步器(STEPPER)

当用户从一个有限的值范围中(比如1-10)键入准确的值的时候,可使用进步器。进步器通常包含两个分段按钮,一个是降低当前值,一个是增加当前值。

进步器的视觉外观支持高度自定义:

1.可使用自己的icon作为进步器按钮;

2.当想维持iOS原生的外观时,你可以自定义进步器边框、背景以及icon的颜色。

3.如果你更进一步使用自定义,那你可以为进步器的按钮和分割符使用完全自定义的图片。

开关(SWITCH)

用户可使用开关在”ON”和”OFF”两种状态间切换。设计师可自定义两种状态的颜色,但是开关按钮的外观和尺寸是设定好的不能更改。

键盘(KEYBOARDS)

有多重键盘类型可为特定的文本输入提供最好的键盘。虽然你可以使用自己完全自定义的剑兰,但默认的键盘无需调整风格和尺寸,很多时候更加方便一些。

2015年移动设备界面设计趋势及用户交互操作数据统计

前提:2014年,Google推出影响全球设计趋势的materialDesign,接着苹果推出ios8和两台影响ios屏幕适配的大屏手机
1.大屏手机的普及化
首先让我们看一眼友盟的数据
Android

ios


3.5英寸~4英寸——平衡单手操作的合理尺寸范围。

51%的用户适应双手操作

盲区(深色区域)更多响应时间

为什么我们需要大屏手机?

展现、承载更多的内容:游戏、阅读、播放视频…

(以上,参考 大屏手机时代,如何重塑界面交互)

面对大屏手机,苹果做了什么?
轻触两次home键……

搜狗做了什么?
单手键盘

google做了什么?
在纷乱的智能设备和杂乱的屏幕种类中,
发布Material Design,构建跨平台和超越设备尺寸的统一体验

我们该怎么做?

充分利用全屏构造更大的展示空间,创建沉浸式体验:

以内容为核心,用UI支撑内容。

  • 简化排版结构
  • 去除视觉修饰
  • 聚焦(突出重点)
  • 增大字间距、行高度
  • 只使用一种字体

(我感觉是借鉴了印刷上的一些规范准则和版式设计)

大量留白。

让重要内容、功能醒目聚焦。

可用性问题:

  1. 纵向单手操作机身
  2. 边角、顶部、左右侧边难以触达
  3. 放置在以上盲区的点击入口,将导致体验路径中断

设计安全区域,避开操作盲区,比如在左上角操作盲区展示logo

使用场景路径触发的连贯性,操作区域集中在安全区域

materialDesign的悬浮按钮(贴近手指);

全局切换(左右滑动在页面可控区域进行页面间转换)

miniplayer左右滑动切歌(更轻更扁平)

  • 更多手势(以手势驱动界面);


时效性产品的下拉刷新(获取最新信息,新内容上浮,旧内容下沉)

滑动代替了点击(屏幕太他妈大了,我一个弹钢琴的都点不到盲区有木有!!)


语音代替键盘输入

内容跟随设备(屏幕)旋转
聚焦用户关心的主要内容

横屏Pad化的操作设计,以及更多的内容展现,如同网页的Responsive Layout概念。
2.动效的广泛应用(app的肢体语言)
Authentic motion
Easing Functions Cheat Sheet
Animated Checkboxes and Radio Buttons with SVG

用动效表现四维时空——展示Z轴空间、时间变化
随着显卡的提升,像素的增多,我们不禁要问,为什么像素少得可怜的时候我们要拟物化GUI,而像素多得吓人的时候我们反而极简而扁平呢?
ios7发布引发了全民扁平化,而动效为设计带来更多的可能和惊喜。设计师们又多了一片可发挥的领域。

仅用在希望吸引用户注意的部分
展示面积相同时,用户注意力会按这个顺序依次被吸引

相对面积和时长划分为四种动效

1.面积大、时间长
产品介绍

2.面积大、时间短

难看清

用于页面切换,展现界面之间的空间关系

见“转场动画”

3.面积小、时间短

轻引导、轻反馈、轻提示→不打断用户流程,却轻轻吸引注意力(情感化设计)

quora的搜索

从横屏切换会的google被弄歪了=_=

4.面积小,时间长

一直持续轻微吸引用户,不干扰其他功能和信息

滑动指向性动效(理清物体排列状况)
chrome

Safari

对象切换-指向性动效
当前物体后移(变暗淡透明),新物体出现
YouTube

flickr

添加-指向性动效
新物体滑入,挤出旧物体

any do

clear

固定标签
头部标签始终固定在顶部直到被顶走
p1

下滑消失,上滑出现(增大可读区域)
storehouse

点击-提示性动效

滑动-提示性动效

切换对象-指向性动效
storehouse

分合-指向性动效
any do 的任务的详细信息的修改(上层和下层合在一起)
胡痴儿按:几乎所有动效的进场和出场都是正方向和反方向的关系,也就是假如录成一段动画就是可循环重复的
分合就像约会。当你点击,一个妹子从雪山上来,当你点返回,她又回雪山去了

动效控件
案例:posegram

flickr的收藏

加载动画:
京东app的刷新

loading设计 _加载界面_loading图片素材欣赏_UI/UX图片大全

展开-空间扩展动效
if

转场动画(用产品连续性表达了设计的前后关系)
(坚硬的,刚性强,却不灵活)
案例:Flipboard
相似案例:deal in

对比案例:ibook(柔软的曲面,刚性差,但灵活)
相似案例:play books
play books for Ios
play books for Android

paper的卡片式翻页(这种神级的存在(@﹏@)~ )

Steller的翻图(每张图都美到心醉)

暗示运动轨迹、动态焦点移动
胡痴儿按:

  • 物体运动受推力、风阻、重力影响
  • 物体按轨迹运动却不可见,除了黑夜里的火花、雪地里的足迹
  • ios的运动轨迹非常自然,它是有一定弧度的,像鱼儿水里游,像少女的乳头一浪接一浪
  • Android5.0之前的运动轨迹就是直线的、刚性的,机械得像个跳机械舞的

ios应用启动

案例:QQ音乐的MiniPlayer切换至播放页

分成动画:底层、信息层、唱片封面层 用不同的轨迹

慢入慢出(惯性)如:

  • 车的启动
  • 压缩的弹簧展开
  • 坐下&站起
  • 球落地不断弹起
  • 动画:在运动开始和结束时更多的帧,而过程中用较少的帧

开始时慢慢加速,停止时慢慢减速,如图:


apple的messages

翻动app们

案例:same的尖叫博物馆(你给我滚看看→ →)

案例:知乎Android客户端的“三”和“←”之间的切换(完美地参考Gmail,很好地遵循了materialDesign)

以操作焦点为中心的空间扩展(翻动、放大,拓展空间内容,简化引导流程)
集合视图转换
UI Collection View Transition Layout
运动路径以用户操作焦点为中心或轴的运动,以衔接界面切换中的过渡动态,引导视觉焦点

案例:Google
以触摸点为中心延展

告诉用户他在哪,从哪里来到哪里去
从缩略图到全屏,同时中心点转移

案例:pages

空间速率Parallax
界面视差空间结构(越靠近屏幕边缘启动速度越快、越靠近屏幕中心启动速度越慢)
胡痴儿按:我记得我学画画时总听老师说怎么拉空间,苹果用动态拉空间真是吊爆了,让我感觉中心点离我更近,屏幕边缘离我更远{>~<}

ibook

ios的日历

预期动效(预感即将发生)
IOS6

capture
1.在运动发生前的准备阶段
2.运动过程本身

3.运动产生的结果

sunnycomb

百度魔拍

nice

招牌动效(加深用户印象的差异化展现)

path的“+”
堆叠物体被展开

facebook 推出的paper关闭消息的拉伸曲线动画。
这种动效设计是有具前瞻性的尝试和探索,像path的那个展开的“+”引发了跟风潮流。

强奸处女座的拉动
Google+的下拉刷新(像素越拉越细→ w→)

掐死same

拆散一对same(我当时看到这俩分离再相聚的时候心都醉了)

flickr的下拉刷新

3.更生动的情感化设计
404页面设计 _404 not found_404出错页面_404错误页面图片素材欣赏

4.遵循iOS和Android的各个平台规范

  • 没有用户学习成本,且用户可使用自定义;
  • 统一跨平台的视觉交互体验;
  • 降低设计开发成本,会自动更新;

(胡痴儿按:一个产品,要和iOS交配产生一个个体,具有iOS交互属性的后代,又要和Android交配,携带Android交互基因的后代,也就是说这个产品的视觉上要像他父亲(公司产品线),界面和交互上要像她母亲(iOS或Android),还要和她母亲的孩子们在移动端和谐相处{>~<})
(沉浸式体验的除外)

案例:豆瓣使用了iOS的系统主题UIkit

  • 用半透明底板:关联使用场景、区分内容;
  • 使用系统字体:确保易读性、可调节性;
  • 无边框按钮(被激活时高亮)

5.hamburger导航变tab导航(当时我设计恋爱笔记时参考的豆瓣小组,后来豆瓣小组改为底部导航,我们也改了)
扁平结构层级,从深到广,从多到简。减少入口和用户思考时间,更快找到自己所需的功能,功能更专精。
案例:豆瓣小组

6.数据可视化(数据表现越来越丰富,如饼状、柱状、曲线、图案)

视差滚动
胡痴儿按:我想到了坐火车时看窗外,物体分了很多层,远处的山缓慢而悠闲,近处的电线杆飞窜着,拍出来的照:近处产生了运动模糊,远处清晰,由近向远越来越清晰。。太美了{>~<}

从一定距离的两点,观察同一目标的方向差异。

黄油相机的欢迎页
(注意每个元素的运动速度!)

一些新的交互探索

用陀螺仪的重力感应看全景图!
paper

red dot

人与摄像头交互
(捕捉用户运动轨迹)
flutterapp.com/
FLUTTER
将手掌往摄像头一按,音乐停止,再按继续播放

格灵深瞳

camme
通过前置摄像头捕捉手掌动作或眨眼实现快门

Goccia
扣在手机的前置摄像头上,获取光信号,发出携带数据的彩光,向手机传输数据。
由手机摄像头捕捉后转化为电信号数据储存到手机或者云端

旋转交互
Nest
转动调整、按下确定

招手取消报警

后台自动完成的交互
追踪睡眠和呼吸等信息

Owlet
采集婴儿信息

FitBark
采集宠物信息

Google glass的敲击发送

Voice in:发出指令
google glass的“Ok glass”

Voice out:反馈延伸
moov
运动设备
siri给出语音反馈

nike+的Fuelband
硬件更便携延展至app上

模块化处理
为解决用户对不同功能产品的选择困惑
分离部件(相同接口、不同功能),封装在不同模块中(芯片、电池、马达、各种传感器…),厂商和用户可根据需求自由组合,如

  • 电池续航模块
  • 记录卡路里消耗的模块
  • 监测心率模块

Google积木手机
中控中界面
tesla中控

智能外设
解决了屏幕软件上的操控缺陷,强化扩展功能

  • 钱包
  • 游戏机
  • 诊疗设备
  • 耳机孔外设
  • 与手机摄像头交互的外设
  • 与屏幕交互的智能笔

Square
移动支付设备

oppo的O-Click的遥控拍照

关怀设计

Smart PJ’s
代替自己给孩子讲故事

Sensefloor

摔倒报120

huggies tweetpee
尿不湿更换通知器
当尿不湿的承载量已经达到极限时会通过tweet通知家长换尿不湿

Quick Trainer
当人体需要尿尿时发出警报

Nex Band
最多5个模块组合,追踪解析数据

智能家居公司belkin

给用户一点小惊喜(我当时一不小心屏幕横过来就被感动了)

补充:

个性的字体
随着各移动系统的设计规范逐渐统一和技术的愈发成熟,移动应用将会有更美观的字体。

Roboto,安卓标准字体
Roboto & Noto fonts
2014年Adobe与Google宣布推出思源黑体(更适合在移动设备及高分辨率屏幕上呈现)

颜色

Ios的Key color

Android

Color – Style

icon的几层境界:

  • 适合不同背景
  • 简洁有力(在小尺寸时清晰突出)
  • 高辨识度,吸引眼球
  • 塑造品牌
  • 隐喻(设计背后的故事)
  • 情感连接

品牌

  • 自然地融入品牌
  • 巧妙地订制淡淡的水印

day one翻到底部时

Path翻到底部时

windows下如何使用git命令及如何使用ssh-keygen创建github ssh 公钥

1. 安装git,从程序目录打开 “Git Bash” 程序

2. 键入命令:ssh-keygen -t rsa -C “email@email.com”

“email@email.com”是github账号

3. 提醒你输入本地存储路径及key的名称,默认为id_rsa,直接按回车使用默认的名称即可

4. 创建成功:   提示如下

Your identification has been saved in /c/Users/xiaoming/.ssh/id_rsa
Your public key has been saved id /c/Users/xiaoming/.ssh/id_rsa.pub

5.用记事本打开id_rsa.pub文件,复制内容,在github.com的网站上到ssh密钥管理页面,添加新公钥,随便取个名字,内容粘贴刚才复制的内容。

6.完成了!

ps:需要注意如果步骤4中产生的密钥文件在当前用户的根目录,必须把这两个文件放到当前用户目录的“.ssh”目录下才能生效。
在windows中只能在命令行下输入创建”.”开头的文件夹。命令为 mkdir .ssh

git bash

 

semver语义化版本概念详解及为什么使用语义化版本控制

语义化版本2.0.0

摘要

版本格式:主版本号.次版本号.修订号,版本号递增规则如下:

  1. 主版本号:当你做了不兼容的API 修改,
  2. 次版本号:当你做了向下兼容的功能性新增,
  3. 修订号:当你做了向下兼容的问题修正。

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。

简介

在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷,系统规模越大,加入的套件越多,你就越有可能在未来的某一天发现自己已深陷绝望之中。

在依赖高的系统中发布新版本套件可能很快会成为恶梦。如果依赖关系过高,可能面临版本控制被锁死的风险(必须对每一个相依套件改版才能完成某次升级)。而如果依赖关系过于松散,又将无法避免版本的混乱(假设兼容于未来的多个版本已超出了合理数量)。当你专案的进展因为版本相依被锁死或版本混乱变得不够简便和可靠,就意味着你正处于依赖地狱之中。

作为这个问题的解决方案之一,我提议用一组简单的规则及条件来约束版本号的配置和增长。这些规则是根据(但不局限于)已经被各种封闭、开放源码软件所广泛使用的惯例所设计。为了让这套理论运作,你必须先有定义好的公共API。这可以透过文件定义或代码强制要求来实现。无论如何,这套API 的清楚明了是十分重要的。一旦你定义了公共API,你就可以透过修改相应的版本号来向大家说明你的修改。考虑使用这样的版本号格式:XYZ (主版本号.次版本号.修订号)修复问题但不影响API 时,递增修订号;API 保持向下兼容的新增及修改时,递增次版本号;进行不向下兼容的修改时,递增主版本号。

我称这套系统为“语义化的版本控制”,在这套约定下,版本号及其更新方式包含了相邻版本间的底层代码和修改内容的信息。

语义化版本控制规范(SemVer)

以下关键词MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、 RECOMMENDED、MAY、OPTIONAL 依照RFC 2119 的叙述解读。(译注:为了保持语句顺畅, 以下文件遇到的关键词将依照整句语义进行翻译,在此先不进行个别翻译。)

  1. 使用语义化版本控制的软件“必须MUST”定义公共API。该API可以在代码中被定义或出现于严谨的文件内。无论何种形式都应该力求精确且完整。
  2. 标准的版本号“必须MUST”采用XYZ的格式,​​ 其中X、Y和Z为非负的整数,且“禁止MUST NOT”在数字前方补零。X是主版本号、Y是次版本号、而Z为修订号。每个元素“必须MUST”以数值来递增。例如:1.9.1 -> 1.10.0 -> 1.11.0。
  3. 标记版本号的软件发行后,“禁止MUST NOT”改变该版本软件的内容。任何修改都“必须MUST”以新版本发行。
  4. 主版本号为零(0.yz)的软件处于开发初始阶段,一切都可能随时被改变。这样的公共API 不应该被视为稳定版。
  5. 1.0.0 的版本号用于界定公共API 的形成。这一版本之后所有的版本号更新都基于公共API 及其修改内容。
  6. 修订号Z(xyZ | x > 0)“必须MUST”在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改。
  7. 次版本号Y(xYz | x > 0)“必须MUST”在有向下兼容的新功能出现时递增。在任何公共API的功能被标记为弃用时也“必须MUST”递增。也“可以MAY”在内部程序有大量新功能或改进被加入时递增,其中“可以MAY”包括修订级别的改变。每当次版本号递增时,修订号“必须MUST”归零。
  8. 主版本号X(Xyz | X > 0)“必须MUST”在有任何不兼容的修改被加入公共API时递增。其中“可以MAY”包括次版本号及修订级别的改变。每当主版本号递增时,次版本号和修订号“必须MUST”归零。
  9. 先行版本号“可以MAY”被标注在修订版之后,先加上一个连接号再加上一连串以句点分隔的标识符号来修饰。标识符号“必须MUST”由ASCII码的英数字和连接号[0-9A-Za-z-]组成,且“禁止MUST NOT”留白。数字型的标识符号“禁止MUST NOT”在前方补零。先行版的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能无法达到兼容的需求。范例:1.0​​.0-alpha、1.0.0-alpha.1、 1.0.0-0.3.7、1.0.0-x.7.z.92。
  10. 版本编译信息“可以MAY”被标注在修订版或先行版本号之后,先加上一个加号再加上一连串以句点分隔的标识符号来修饰。标识符号“必须MUST”由ASCII的英数字和连接号[0-9A-Za-z-]组成,且“禁止MUST NOT”留白。当判断版本的优先层级时,版本编译信息“可SHOULD”被忽略。因此当两个版本只有在版本编译信息有差别时,属于相同的优先层级。范例:1.0.0-alpha+001、1.0.0+20130313144700、 1.0.0-beta+exp.sha.5114f85。
  11. 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时,“必须MUST”把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较(版本编译信息不在这份比较的列表中)。由左到右依序比较每个标识符号,第一个差异值用来决定优先层级:主版本号、次版本号及修订号以数值比较,例如1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。当主版本号、次版本号及修订号都相同时,改以优先层级比较低的先行版本号决定。例如:1.0.0-alpha < 1.0.0。有相同主版本号、次版本号及修订号的两个先行版本号,其优先层级“必须MUST”透过由左到右的每个被句点分隔的标识符号来比较,直到找到一个差异值后决定:只有数字的标识符号以数值高低比较,有字母或连接号时则逐字以ASCII的排序来比较。数字的标识符号比非数字的标识符号优先层级低。若开头的标识符号都相同时,栏 ​​位比较多的先行版本号优先层级比较高。范例:1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0- rc.1 < 1.0.0。

为什么要使用语义化的版本控制?

这并不是一个新的或者革命性的想法。实际上,你可能已经在做一些近似的事情了。问题在于只是“近似”还不够。如果没有某个正式的规范可循,版本号对于依赖的管理并无实质意义。将上述的想法命名并给予清楚的定义,让你对软件使用者传达意向变得容易。一旦这些意向变得清楚,弹性(但又不会太弹性)的依赖规范就能达成。

举个简单的例子就可以展示语义化的版本控制如何让依赖地狱成为过去。假设有个名为“救火车”的函式库,它需要另一个名为“梯子”并已经有使用语义化版本控制的套件。当救火车创建时,梯子的版本号为3.1.0。因为救火车使用了一些版本3.1.0 所新增的功能, 你可以放心地指定相依于梯子的版本号大等于3.1.0 但小于4.0.0。这样,当梯子版本3.1.1 和3.2.0 发布时,你可以将直接它们纳入你的套件管理系统,因为它们能与原有相依的软件兼容。

作为一位负责任的开发者,你理当确保每次套件升级的运作与版本号的表述一致。现实世界是复杂的,我们除了提高警觉外能做的不多。你所能做的就是让语义化的版本控制为你提供一个健全的方式来发行以及升级套件,而无需推出新的相依套件,节省你的时间及烦恼。

如果你对此认同,希望立即开始使用语义化版本控制,你只需声明你的函式库正在使用它并遵循这些规则就可以了。请在你的README 文件中保留此页连结,让别人也知道这些规则并从中受益。

FAQ

在0.y.z 初始开发阶段,我该如何进行版本控制?

最简单的做法是以0.1.0 作为你的初始化开发版本,并在后续的每次发行时递增次版本号。

如何判断发布1.0.0 版本的时机?

当你的软件被用于正式环境,它应该已经达到了1.0.0 版。如果你已经有个稳定的API 被使用者依赖,也会是1.0.0 版。如果你很担心向下兼容的问题,也应该算是1.0.0 版了。

这不会阻碍快速开发和迭代吗?

主版本号为零的时候就是为了做快速开发。如果你每天都在改变API,那么你应该仍在主版本号为零的阶段(0.yz),或是正在下个主版本的独立开发分支中。

对于公共API,若即使是最小但不向下兼容的改变都需要产生新的主版本号,岂不是很快就达到42.0.0 版?

这是开发的责任感和前瞻性的问题。不兼容的改变不应该轻易被加入到有许多依赖代码的软件中。升级所付出的代价可能是巨大的。要递增主版本号来发行不兼容的改版,意味着你必须为这些改变所带来的影响深思熟虑,并且评估所涉及的成本及效益比。

为整个公共API写文件太费事了!

为供他人使用的软件​​编写适当的文件,是你作为一名专业开发者应尽的职责。保持专案高效一个非常重要的部份是掌控软件的复杂度,如果没有人知道如何使用你的软件或不知道哪些函数的调用是可靠的,要掌控复杂度会是困难的。长远来看,使用语义化版本控制以及对于公共API 有良好规范的坚持,可以让每个人及每件事都运行顺畅。

万一不小心把一个不兼容的改版当成了次版本号发行了该怎么办?

一旦发现自己破坏了语义化版本控制的规范,就要修正这个问题,并发行一个新的次版本号来更正这个问题并且恢复向下兼容。即使是这种情况,也不能去修改已发行的版本。可以的话,将有问题的版本号记录到文件中,告诉使用者问题所在,让他们能够意识到这是有问题的版本。

如果我更新了自己的依赖但没有改变公共API 该怎么办?

由于没有影响到公共API,这可以被认定是兼容的。若某个软件和你的套件有共同依赖, 则它会有自己的依赖规范,作者也会告知可能的冲突。要判断改版是属于修订等级或是次版等级,是依据你更新的依赖关系是为了修复问题或是加入新功能。对于后者,我经常会预期伴随着更多的代码,这显然会是一个次版本号级别的递增。

如果我变更了公共API 但无意中未遵循版本号的改动怎么办呢?(意即在修订等级的发布中,误将重大且不兼容的改变加到代码之中)

自行做最佳的判断。如果你有庞大的使用者群在依照公共API 的意图而变更行为后会大受影响,那么最好做一次主版本的发布,即使严格来说这个修复仅是修订等级的发布。记住, 语义化的版本控制就是透过版本号的改变来传达意义。若这些改变对你的使用者是重要的,那就透过版本号来向他们说明。

我该如何处理即将弃用的功能?

弃用现存的功能是软件开发中的家常便饭,也通常是向前发展所必须的。当你弃用部份公共API 时,你应该做两件事:(1)更新你的文件让使用者知道这个改变,(2)在适当的时机将弃用的功能透过新的次版本号发布。在新的主版本完全移除弃用功能前,至少要有一个次版本包含这个弃用信息,这样使用者才能平顺地转移到新版API。

语义化版本对于版本的字串长度是否有限制呢?

没有,请自行做适当的判断。举例来说,长到255 个字元的版本已过度夸张。再者,特定的系统对于字串长度可能会有他们自己的限制。

关于

语义化版本控制的规范是由Gravatars创办者兼GitHub共同创办者Tom Preston-Werner所建立。

如果您有任何建议,请到GitHub上提出您的问题。