首页

认识 ESLint 和 Prettier

seo达人

ESLint

先说是什么:ESLint 是一个检查代码质量与风格的工具,配置一套规则,他就能检查出你代码中不符合规则的地方,部分问题支持自动修复。


使用这么一套规则有什么用呢?如果单人开发的话倒是没什么了,但是一个团队若是存在两种风格,那格式化之后处理代码冲突就真的要命了,统一的代码风格真的很重要!


(其实以前自己做一个项目的时候,公司电脑和家庭电脑的代码风格配置不一样,在家加班的时候也经常顺手格式化了,这么循环了几次不同的风格,导致 diff 极其混乱

想提高设计转化率,按钮应该放在左边还是右边?

雪涛

任何一名设计师应该都会接触到运营活动页,产品落地页此类需求。而这些落地页设计需求的业务目标衡量标准都相当明确——即转化率。再进一步,与我们的设计输出直接相关的就是首页转化率/点击率。这些数据通过埋点能很轻易地获得,一般情况下,产品经理会提前在需求文档中标明需要埋点的地方(埋点简单说就是测量某个位置或者交互节点的具体数据,例如发生了多少次点击),获得数据用于验证产品最终是否符合预期,是否达到了理想的转化效果。

叮~ 讲到这我们应该明确了一件事,整个落地的设计其实最终都是为那个关键数据服务,无论是点击率还是转化率,达到预期甚至超出预期,那你的设计就完美地完成了任务,这也是验证设计有效性的主要方法,将设计与数据关联,用可量化的数据指标来验证偏感性的视觉工作。

就这样,设计与产品/运营的世纪大战开始了。因为我们都有了一个共同的目标,因此在产品的最终收益、期望效果方面互相都很明确。但在实现手段上,我们很轻易地产生了分歧。主要分歧点就是「按钮在左还是按钮在右」这个问题上。我们需要理解,这不是一个简单的交互问题,因为它其中掺杂了商业内容。如果这是一个交互问题,那我们很容易判断,例如弹窗的主次按钮应该主右副左,这既符合平台规范,也符合用户认知和操作习惯。

然而作为一个强商业属性的落地页,按钮在左或者按钮在右都有其合理性。我选择左,而运营同学代表他们团队要求右。 于是我败下阵来,当然,虽然表面上设计师输了,但我们怎么能服输,于是我想尽办法来验证左侧放置按钮才是更有利于转化的形式。下面我们来看看不同的倾向对应的设计原理。

左与右的矛盾

产生左与右的争执其实主要源于设计与需求方的两个判断方向。首先说一下我的判断逻辑,按照已知经过验证的理论,即 F 阅读顺序(尼尔森的用户阅读视线模型),用户浏览落地页的顺序应当是从左往右自上而下,因此左上角的信息最早触达用户。在当前主流的首图式落地页样式下,首图 banner 中的内容应当置于左侧,以使用户更快地获知产品的关键信息。

在落地页首图的体验文案本身就是一个设计的覆盖范围,因为它直接关系到首页的视觉传达效率,即用户需要花费多长时间、多少精力才能理解你的产品。我们往往在首页体验文案中采用主标题加副标题的形式,着重解释这个产品是个什么东西、用户能从这获得什么,往往通过主副文案搭配的形式,来完成整个大意的阐述。

基于此,核心内容置于左侧,用户在快速扫视时能够第一时间获知产品信息,了解产品利益点,这与我们精心准备整个网站,以及精心准备诱导力文案的方法相契合。这是我做出内容置于左侧的设计决策的主要思路。可以看出,我这里主要参考的是 F 阅读模型这一理论,根据这个经验我得到的结论是 重要的信息应当摆放在左侧以使用户立即触达核心信息,这将有利于接下来的引导或者转化。

另一方面,运营同学又是基于什么考虑决定将核心内容放在右侧的呢?答案是操作习惯,理论化的话可以用费茨定律概括,(目标距离用户距离越短,用户触达的效率越高)。考虑到大部分用户使用右手操作,鼠标也大都悬停在屏幕右侧,因此,按钮置于右侧,用户点击的路径变得更短,也就更容易触达和转化(纯体验角度或者说效率角度)。

你仔细阅读这部分内容,从分歧点到各自的理论支撑实际上都没有太大的漏洞,为什么没有漏洞?因为确实都没有错误,也都存在其合理性。例如我们常用的购物 APP 会把按钮置于右下角,用户操作起来必然比左上角的按钮更加容易。那么在这两种分析都合理的背景下,我们要对比或争论的其实不是哪个判断是错误的,而是哪个判断更有利,更合理,能够带来更多的数据转化。因此,这个问题最终由对错问题,转化为一个优劣问题。

左与右的妥协(一种结论)

有些人很机智,这个时候肯定会想,既然左边最容易触达信息,右边最容易触达按钮操作,那左边放置内容,右侧放置操作不就完美解决了吗?哎呀,读者真聪明。

由于 F 阅读的逻辑,将展示性质的「内容」放置于左侧,使用户更快触达关键信息,由于费茨定律,以及多年来养成的用户习惯(操作组件在右侧,当然现在很多放在中间的情况)将需要执行的操作置于右侧,使用户快速交互并完成任务。有一定道理,甚至在实际落地产品中我们也能看到一些类似的设计,例如豆瓣。 这是一种左与右的妥协

但需要注意的是,豆瓣产品的右侧放置的是较为复杂的交互模块,例如完整的登录注册模块。在该场景下,用户在交互路径更短的右侧区域执行交互效率要明显高于左侧区域。

那么下面开始论述按钮置于左侧的观点

论点一:排版的限制

豆瓣的形式对于落地页产品,可能并不适用。主要有两方面原因。我们都知道,产品落地页首屏的组成为体验文案,主 CTA,插画配图三部分。常规做法是插画作为一组信息置于一侧,文案加按钮作为一组信息置于一侧。因为,体验文案与按钮具有强关联性,同时按钮与文案作为一组信息,才能与另一侧的插画搭配构建平衡的布局,呈现比较优美的视觉效果。

请登录后查看原图,因此,豆瓣那种妥协方式并不适用于商业类落地页。因为内容和操作本身是一体的,这源于排版的规整性的限制,按钮和文案只能同时存在于一侧,如果刻意去追求左侧内容,右侧操作,效果就像下面这样。一方面,只靠文案和按钮无法撑起左右两个区域,一方面文案和按钮被割裂开,用户的视线由文案转到按钮的路径过长,体验较差。(文案与按钮成组后,用户可以在阅读内容产生动机后立即触达交互按钮并完成转化)

论点二:文案与配图孰轻孰重

如果你亲自体验这两种区别的落地页(左图右文/左文右图),你会发现有一个共同点,就是在某个区域的停留时长,没错就是内容区域。以下图的顶部卡片区域为例,在阅读时我的浏览情况是,大致地扫视左侧的插画,然后注视右侧文字区,了解文章的具体内容,并在此区域停留较长时间,毕竟仔细阅读需要花费时间。

这就涉及到一个问题,插画与内容哪个更重要?其实答案很明显,我们只需要舍弃掉其中一项来测试下,看看哪个内容的缺失会对用户理解设计传达的语义产生较大影响。OK,我觉得没必要测试了(虚晃一枪)。很明显,删除插画后,我们仍然可以通过文章的标题来获知文章概要等关键信息,就像落地页首屏的体验文案,即便没有插画我们也能通过首页文案来获知这个产品是什么,能够为我带来什么。

然而如果去掉关键信息,去掉标题与按钮,仅凭插画我们无法分辨当前页面到底在讲述什么东西。设计本身就像是人与人的交流,产品就是我们,而用户则是我们的交流对象,去掉核心的文案,相当于把我们自己变成了哑巴,而去掉插画,最多相当于我们交流时面无表情罢了。

因此,在商业落地页中,我们以转化为核心目标,而能够更快地触达最重要的信息显然是明智之举,因此我们希望将核心的文案内容置于左侧。

(另外,一图胜千言的原理只适用于个别场景,例如数据可视化。设计人员通过将数值数据转化为易于理解的柱状图扇形图,来传达数据结论。而视觉修饰性质的插画则无法做到准确表意,我们通常在产品设计中见到的插画更多的是在情感上和审美上给予我们一定的愉悦,但想要准确描述关键信息,还是需要文字作为核心角色)

论点三:用户会因为便于操作而产生动机?

另一点同样值得我们思考,即用户真的会因为某个按钮更容易点击而被转化吗?或者我们换个形式问,假设你是一名男性,你会因为按钮在鼠标附近而选择点击购买女士内衣吗?你会在自己财务状况较差的时候因为按钮在鼠标附近而点击购买品吗?在大多数理性场景下,我相信你不会这样做。

所以这时候要引入福格模型,用来阐述产生转化的整个路径。福格模型简单来讲就是一个公式:B=MAT。B(behavior) 代表行为,M(motivation) 代表动机也就是用户需求,A(ability) 代表用户使用的门槛,T(trigger) 代表触发。也就是用户行为的产生需要用户需求为基础,需要保证产品的易用性,但是这还不够,在这个基础上我们还需要在产品中通过设计触发用户。完成转化的三个关键要素是,动机、能力、触发,缺一不可。

福格模型帮助我们解决了这个疑问。用户的购买或者转化始于动机,就像我上面举的例子,如果一个用户根本对产品没有需求(男性对女性内衣),那就不会产生动机,在没有动机的情况下,后面两项内容,能力或者触发都没有意义,无法发挥作用。整个转化的流程可以参考下方的示意图。

实际上对于那些有强烈动机购买或使用产品的用户,你的一切设计都没有太大意义,因为用户有强烈诉求的情况下,他会发挥主观能动性去找到转化的入口,主动完成转化。同理,有些用户是完全不会产生动机的,不是目标用户群。

设计策略主要针对的是有动机但不强烈(某种程度上有需求或者被吸引),以及暂时没有动机的两类用户。通过我们的首屏及详细内容,痛点利益点的介绍,来放大用户动机,制造共鸣点,创造美好的想象空间,使用户涌现强烈动机。然后转化就自然而然的产生。

因此,在首屏我们的核心要义是通过内容设计来触发用户动机,而不是想方设法触发操作。走捷径的误触方案设计能保证百分百的触发率,但那种触发没有任何意义。到这里我们应该明确了,用户会因为好的内容所触发的动机而买单,但不会因为你把按钮放在我手边而产生购买冲动。

因此,我的结论是,用户更有可能因为左侧展示的强洞察力的文案而产生动机,而动机是整个转化的起始,也是最关键的一点,有了动机,触发(按钮位置)的效率即便低一点,但转化仍然很有可能继续(就像动机产生了惯性,有了强烈的动机会自发地去寻找触发器,去寻找按钮以自主完成转化,但触发器不会有惯性)

这个观点论述下来,主要涉及到 F 阅读模型,费茨定律以及福格模型,算是很基本的设计原则,也顺便帮大家重温一下。最后,我们再拿一些其他实证来进一步论述,例如国内一线公司的落地页设计。

1. 一线公司落地页布局

2. 全球独角兽企业落地页

文章来源:优设    作者:南山可

B端系统,筛选控件总结

分享达人

写在前面


首先我们先从筛选本身讲起吧~

 

筛选可以说是我使用比较频繁的一种交互形式,比如我点外卖,会选择满减优惠力度大,同时我也可以选择在哪一个价格区间内的产品,这就会用到筛选,而到了B端产品上来,一个CRM系统当中,筛选的逻辑也会比移动端的复杂,伴随着:且关系、或关系、大于、小于等等这样复杂的逻辑,也为设计本身增加了很多难度。因此,今天我们就来讨论讨论筛选控件

 


1、筛选存在的意义


筛选存在的对于整个表单来说是非常重要的,它可以帮助用户,在表单茫茫多的数据当中进行快速的定位;可以对表单进行快速划分,缩短用户对于数据的寻找时间;能够满足用户在工作中,实际业务场景的筛选。

对于实际B端场景来说,筛选是日常数据分类的一个重要途径,我们先来看看实际场景到底有哪些?

 

用几个我们CRM用户日常使用的场景来说:

 

比如今天作为一个电话销售人员,想要联系最近注册的用户时,通常会通过筛选来选出最近几天注册过,同时又没有销售更进的客户,进行一个优先级的排布;

 

再比如说,在销售周报当中,销售主管可以通过筛选得到每个人这周完成的状态,也可以通过筛选得出每个人对于线索的更进情况和对客户的流失状态等等,这些都可以通过各种各样的筛选形式来满足用户对于特定情况下的使用



筛选和搜索、导航的区别?

 

筛选可以通过多个筛选条件进行多维度的寻找,而导航、搜索只能通过单一条件进行指定筛选。

虽然在现在很多搜索都可以支持多维度用空格去进行多字段的关键词搜索,但本质上区别不大

所以在B端项目当中,如果你有表单,那你就需要筛选



2、筛选的类型


我们将筛选分为基础筛选和高级筛选两种,两种筛选会根据业务场景不同,在不同的页面去使用

 

2.1、基础筛选


基础筛选一般为系统预设好的筛选字段,具有很强的业务和场景的需求。基础筛选一般分为四个部分:


筛选条件:是指用户可以筛选的范围

筛选项:是指用户可以选择的筛选项目

已选项:是指用户已经选中的筛选项

备选项:是指用户还没有选择的筛选选项



基础筛选更多作为用户快捷筛选的一种方式,因为一般使用场景当中用户几个筛选逻辑为“且”

同时筛选的逻辑也为简单筛选,所以在使用场景上只适合在对筛选要求不高的场景下使用。


2.2、高级筛选


高级筛选一般为筛选中含有运算符,同时筛选当中包含条件关系,比如且关系或者否关系。一般高级筛选包含以下几类关键词

 

筛选关系:是指几个筛选条件之间的关系,一般为 且、或关系,即 且 关系为几个条件之间的并集;或 关系为几个条件之间的联集

筛选字段:是指在筛选当中,所要的筛选项,一般为表单当中的所有可筛选的字段

筛选操作:是指筛选字段和筛选值之间的关系,常见的筛选操作有:大于、小于、是、否、包含、不包含、为空、不为空等等。

筛选值:你所需要筛选的数值



高级筛选一般满足更多的用户场景,为用户多条件多字段、多个筛选关系、多个筛选操作 提供有利保障。




3、筛选的布局


3.1、上下布局


当在筛选器条件少于5个的情况下,最常使用的就是上下布局,这样筛选能与网站保持统一的情况下,上下布局也更方便用户进行阅读

 

当筛选器过多的情况下(一般在5-15个之间),筛选器过多,需要滚屏才能看到筛选结果,用户使用起来会很别扭。所以在5-15个的情况下,一般会将筛选项进行收折,这样保证筛选整体面积不会太大,同时将用户常用的筛选放在前面,可以满足用户基本的业务需求和使用场景



3.2、左右布局


左右布局在PC端一般是以字段选择进行筛选,通俗来讲就是将用户可以筛选的所有字段全部罗列出来,然后通过勾选选,择出你需要筛选的字段,进行筛选器的使用

 

左右布局的好处是能够将筛选的所有条件都直接的展示出来,可以适应很多场景,在筛选器用15个以上时。通过左右布局的方式,能够让筛选条件进行滚动,在最大限度保持用户使用体验




4、筛选的形式


在日常的B端产品中,筛选的形式有哪些?筛选到底应该怎么设计?接下来为大家总结梳理一些在 B端产品 中的筛选玩法,希望为你开启新大陆。


4.1、平铺型



平铺型一般为用户搜索结果数据量过大,使用户搜索出来的结果与其预期差距过大,用户然后可以通过筛选对数据的再一次分类,使用户能够精准寻找其想要的结果。

平铺型一般为筛选条件少于6个,这样能够通过1行或者2行去展示筛选项的结果

 

多用于信息量大的产品,比如电商、视频网站等等。常见的淘宝、京东、腾讯视频PC端 都采取用这样的方式,将所有的筛选条件列出来。

 

平铺型的好处是将筛选项的结果全部或者部分放出,能够帮助用户快速理解筛选项以及快读找到自己想要的结果。

缺点也是很明显,平铺型的控件占比大,需要占据大量面积展示平铺出的筛选结果。

 

比如淘宝PC端,搜索一个产品后花去40%的面积去展示所有的筛选条件,其实就是想引导用户,淘宝搜索过后spu的数量仍然过大,想通过进一步的筛选,让用户明确自己对想要东西。同时因为面积占比大,通常平铺型都是以收折的状态,只有在搜索触发后才会完全展开


4.2、收折型



收折型筛选是一种简单直接的筛选形式,将用户常用的筛选形式通过下拉框的形式进行筛选。每一个筛选条件就是一个下拉框,这种形式看上去很简单,但是在B端场景中,下拉框对于用户来说认知成本低,操作性也较强,同时在用户重度使用时,又能给用户很好的使用体验的一种方式

 

优点:

用户可以直接对其常用的字段筛选进行一步操作,并且没有复杂的筛选关系,全部都是“且”的筛选逻辑,能够保证用户进行快速的筛选选择

 

缺点:

将所有信息全部平铺展开,信息量过于冗杂繁多,同时在做通用性产品时,这种方式很难做到通用性


 

4.3、单侧筛选



单侧筛选是一种更通用的筛选形式,通过对于你想筛选的字段进行勾选,勾选完成后就会出现筛选条件,然后选择筛选字段、筛选操作、筛选值,一般选择完成所有筛选后,还需要点击查询,筛选操作才算完成。

 

整个单侧筛选,大量的筛选条件可以放置在表单的左侧或者右侧,通过表单纵向空间,去承载大量筛选条件。

 

优点:

节省空间、通用性强。因为在很多Saas系统、Paas系统当中,无法针对每一个客户进行设计,就要考虑到系统通用型高,做一些大而全的功能。在每个表单也所需要定制化修改的地方很少,同时能容纳的信息量可以很大。

 

缺点:

就是在后台系统当中只有这一种筛选形式会面临在我常用的几种筛选的字段中,要通过不断寻找,来满足我的筛选需求,操作麻烦。

 

 

我们产品在某一次改版就将筛选由收折式修改为单侧式,因为我们用户使用筛选的场景非常的多,用户每次筛选都要多进行2、3步操作,导致用户进行了大量的吐槽,后来进行修改,将筛选顺序支持手动调整顺序,用户吐槽的次数才慢慢减少。



4.4、表头筛选

 


表头筛选是一种复杂筛选的形式,其最开始是来源于Excel的筛选形式。点击表单的筛选按钮,可以将表头的筛选字段直接带入,方便用户。之后在后台产品的发展中,得以借鉴过来。

 

优点:

可以通过表头的点击,使用户更快捷进入到自己的筛选条件,在通常情况下,在表单越左的数据显然是越重要的,也是使用筛选去筛频率最高的,因此高频的筛选场景基本还是得到满足。


缺点:

用户第一次进入系统很难理解这种交互形式,且在每个表头都会有一个icon,影响用户对于表头的识别。

 

 

4.5、弹窗式



通过点击筛选按钮,展现出筛选弹窗,进行筛选。这种筛选适合在筛选功能在系统中不是很重要的层级。最常见的就是Tapd,在其中筛选不是很强的一个功能,同时也是系统中十分有必要的。

 

优点:

是能够在节省面积的情况下,可以进行很复杂的筛选,同时可以支持复杂情况下的筛选

 

缺点:

弹窗会遮挡一部分表单数据,会影响筛选人的判断,其次筛选条件的添加也相对更加繁琐。

 

 


5、选择更合适的筛选

在我们一系列筛选的调整过后,我们团队也总结了对于我们来说更重要的条件和形式,来和大家分享探讨一下。

 

5.1、使用频率

我们认为影响筛选控件最重要的是用户的使用频率,因为用户的使用频率和使用方式,直接影响到我们筛选是用普通筛选or高级筛选,也会影响到筛选的形式。

 

5.2、满足实际业务所需

筛选功能的做法,取决于我们产品未来是想往哪一个方向发展,如果想把功能做的强大,就得考虑到筛选的后续扩展性。因此满足实际业务也是十分重要。

 

5.3、用户认知成本

在B端系统当中,最可能遇见的就是你给用户设计的路径但是其实用户根本没有往你想的方向去操作。我们系统最开始给用户设计好了很多功能点,但是用户对于这个点的认知成本实在过低,也导致了后面系统功能点很多都被埋没。因为在你设计好了一个功能点后,要适当引导用户,解释这个功能的使用场景才不会让你设计的功能被淹没。

 

 


其实在B端产品中,易用本身就是难且长的过程,在每一个功能的设计都需要你去思考很多方面:用户易用、信息层级、未来扩展,你都要做出取舍,而对于每个模块都需要你思考、结合用户场景,B端web的设计一直都是摸黑前进,我也只是将自己的一段时间的工作进行总结,说的不正确,欢迎大家指正。

 转自:站酷-Cengg 


Mac 视觉史 vol.1:从 Macintosh 到 Mac OS

雪涛

2009 年,买不起 Macbook 的我在 PC 上装上了黑苹果。在此之前,我用虚拟机体验了 Apple II 、Mac OS 8.1、Mac OS 9.2.2 、Mac OS X 10.6 ,在不断的折腾过程中,我开始对苹果、对GUI 的整个历史发生了兴趣。

此后,我在Jeff Johnson 的《认知与设计》当中,在 Steve Krug 的《Don’t Make Me Think》当中,在一本又一本和UI、交互、体验相关的经典书籍当中, 发现 Mac 系统的界面一直被作为范例来展示。

Mac 确实是优秀设计的典范,是 GUI 设计史当中绕不过去的最重要的操作系统家族。所以,视觉史系列文章的第一篇,我决定从 Mac 系统下手。

两大系列,四个名字

简单来说,我们泛指的 Mac 系统,通常是分为2个大的系列的。

1982 年随 Macintosh 发布的系统,一直到 1999年发布的 Mac OS 9 为第一个系列,一般被统称为「Classic Mac OS」。

而 2001 年之后所诞生的 Mac OS X 系列的操作系统,包括现在所说的 macOS ,则被视作为第二个系列的 Mac 系统,其中 X 是罗马数字 10 的意思。

苹果公司最初只有 Macintosh 电脑,系统并无名称,直到第5个大版本的时候,操作系统才拥有 Macintosh 这个名字。而 Mac OS 这一系统名称,则是在系统更新到第7个大版本的时候才被提出,而自此开始,Mac OS 的称谓正式出现。

而 macOS 则相当于是 Mac OS X 品牌的一次重启。它始于 10.12 Sierra 这一版本,并且为了和 iOS、tvOS、watchOS 这几个系统品牌保持一致,而从 Mac OS X 更名为 macOS。

在很长一段时间,国外很多老用户会将它简称为「OS8」、「OS9」,而在2001年之后直到今天,依然有很多人将它简称为「OSX」,这也是在了在讨论 Mac 系统这个前提下所用到的、带有版本的简略称谓。

注释:国内有不少人会将 Mac 称为「OS系统」,但是 OS 本就是 Operation System 的缩写,意为操作系统,Windows 是 OS,Linux 也是 OS,「OS系统」是一个错误且尴尬的表述。

如果不深究细节的话,Macintosh,MacOS,Mac OS X , macOS 这四个都简称为 Mac 系统。

图形化界面:向施乐偷师

Macintosh 并非最早的图形化界面,但却是真正推动图形化界面操作系统发展的里程碑。

Xerox Alto

对于图形化用户界面的起源,一个相对统一的共识是,它来源于施乐的帕罗奥托研究中心,而最早使用图形化界面的电脑,是当时正出于研发中的 Xerox Alto。在之前的文章当中,我曾经专门聊过最早图形化界面的诞生和设计细节:

比尔盖茨曾经指责乔布斯从施乐这里「偷」走了图形化界面(GUI)的设计,实际上,为了换得机会去施乐的帕罗奥托研究中心去观摩学习研发中的Xerox Alto 和开发工具 Smalltalk,乔布斯是拿股权交换得来的。

这是 Xerox Alto 当时所采用的图形化界面。界面的确图形化了,只不过,从今天的视角来看,整体的界面逻辑并不清晰。

而在GUI的设计细节、实现方式上,Macintosh 则截然不同,可以说是后来居上。

规避纠纷: Macintosh 的名字来源

说回 Mac。

回溯到 1979年,Jef Raskin 是Macintosh 电脑和操作系统项目的发起者和监督者,他想用自己最喜欢的一种苹果(McIntosh)来给这个操作系统命名。

这种名为 McIntosh 的苹果不仅被誉为加拿大国家级苹果,但是更重要的原因在于,当时纽约还有一家名为 McIntosh Laboratory 并且提供高端定制音响服务的公司,为了避免商业品牌上的冲突,Raskin 将系统的名称改为 Macintosh,故意错开了一个字母。当然随后 Macintosh 的名字逐渐超过了前者,在世界范围内,甚至慢慢超过了加拿大最著名的水果。

当然,1984年,最初版本的 Macintosh 系统随着同名的苹果电脑的发布而面向大众,这个并非最早的图形化界面操作系统开始了它的历程,如今它是最著名、最具有影响力的图形化界面的操作系统之一。

Macintosh 电脑的主板由 Burrell Smith 所设计,结合当时的硬件技术,让最终上市的 Macintosh 电脑拥有了一块分辨率为 512×342 的单色显示屏。

在这块寸土寸金的单色屏幕上,Macintosh 系统需要将图形化界面的价值尽可能发挥出来。

Macintosh 系统:正式拥有姓名

Macintosh 电脑开始出现在各大杂志媒体上,蜚声世界,但是此刻,这一操作系统并没有官方的名称。 1.x系列的只有一个非正式的 System 1 的名字,而随后的大版本也被称为 System 2,System 3,等等。

直到 System 5 的时候,这一操作系统才算是正式有了 Macintosh 的名称,而它正式的完整名称是 Macintosh System Software 。

System 1 ~ System 5:功能迭代

最早的 System 1 当中,开机之后有一个非常可爱的欢迎界面:

菜单和窗口的概念清晰,比起 Xerox Alto 的设计更加成熟:

左上角的苹果图标打开之后,本质上是一个程序列表:

在 System 1 当中,文件夹是一个虚拟概念,在文件系统当中其实是根本不存在文件夹的,它是模拟现实文件夹的概念而存在的一个图形化界面概念:

在系统出错之后,系统报错界面中会使用炸弹图标来进行提示:

1984年的 Macintosh 的系统崩溃界面都比 2000 年之后的的 Windows 蓝屏界面来得更加有趣:

当然,用一个带有图形化界面的电脑玩游戏,难道不是一件天经地义的事情吗:

特别值得一提的是,Macintosh 自打一开始就为自己设计了一系列的字体:

其中风格独特的 San Francisco 在多年以后还拥有一个同名的字体,作为系统默认的字体而存在。

随后,在随后的 System 3 当中,垃圾桶的 APP 图标增加了「有垃圾文件」和「已清空」两种状态的区分,并且给系统新增了一个欢迎界面:

文件夹也不再只是一个虚拟的概念了:

同样的,在 System 3 当中游戏的精美程度也有了一定程度的提升:

当然,从 System 1 到 System 4,系统的功能在一代代地增加,但是受限于屏幕和基本的性能,其界面在整体观感上差别并不大:

不过在图标和界面细节的处理上,越来越丰富,越来越细致,比如系统的控制面板,功能和细节比 System 1 时代丰富了许多:

在 System 5 当中,Macintosh 还加入了多任务的功能,也就是 MultiFinder,使得用户终于可以同时运行多个任务,不过因为性能限制,跑多任务的时候,会比单任务慢不少。

System 6 :集大成的版本

对于 Macintosh 系统而言, System 6 是一个阶段性集大成的版本。系统的版本和软件的版本在 System 6 当中进行了统一,并且功能也有了相当程度的完善。

性能更强劲的 Macintosh SE/30 和 笔记本电脑 Macintosh Portable 也是在 System 6 更新期间发售的。

Macintosh Portable

Macintosh SE/30

System 7:拥有色彩的新世代

终于,黑白用户界面的时代在 1991 年终结,Macintosh 系统从 System 7 开始拥有了彩色的用户界面:

色彩的加入,系统图标的拟真度也再一次提升,比如垃圾桶的图标,光影已经相当逼真了。

而为了更好地利用彩色界面的功能,用户可以根据自己的偏好进行全局色彩设置:

软件安装的进度指示方式,比起同时代的系统乃至于后面的很多系统,都要清晰明确:

关键信息的说明和引导上,Macintosh 系统在30年前就已经有明确的范式了,比如重要信息标红强调:

由于这个阶段系统分辨率的限制,在按钮的视觉层次构建上,阴影和按钮凸起的效果,都做的比较简单,但是总体上始终上是在模拟现实存在的元素,通过尽可能贴近现实的视觉设计,来减轻用户的认知负荷,计算器和键盘的设计就非常的典型:

System 7 当中,还内置了交互式的用户帮助系统:

在控制面板当中,图标的统一性再一次得到了提升,风格上明显有着当时的特征,只不过在信息的传达上,还不够优秀,如果没有文本标签,你很难判断每个按钮对应的功能是什么:

值得一提的是,System 7 所处的阶段,大量的兼容机和包括 Windows 在内的操作系统开始出现,激烈的市场竞争之下,苹果也发布了一系列的新款的 Macintosh 电脑:

为了应对激烈的竞争,苹果还想出了新的策略,而这一策略也促成 Macintosh 系统后续逐渐成为一个独立的品牌。

Mac OS :第一次品牌重构

1996年,乔布斯重回苹果。同时在这个阶段,Macintosh 系统也随之进行了品牌重设计,Macintosh 系统更名为 Mac OS。

为了应对激烈的市场竞争,这一阶段的 Macintosh 电脑开始逐步切换到 PowerPC 架构的 CPU 芯片,同时,苹果公司也开始授权一些第三方厂商,使用同样架构的芯片和主板,并且安装System 7 的系统。

可以直接安装 System 7 的 StarMax 兼容机

这样一来,就开始出现问题了:非苹果产的电脑上,也会显示 「Macintosh 」的字样,那这个怎么和原厂的 Macintosh 电脑进行区分呢?

很简单,在原装的 Macintosh 上,依然还是 Macintosh,但是在兼容机上,它就是「黑苹果」——Mac OS:

在当时,很多人认为这种区分,仅仅只是用来进行差异化的临时解决方案。此时乔布斯即将重掌苹果,并且打算把前 CEO 的系统第三方授权策略给干掉。将 Macintosh 更名为 Mac OS 就是解决方案,只不过这个解决方案并后面还有其他的深意。

因为后面还有新系统。

Mac OS 8:一石二鸟的更新

Mac OS 8 是在 1997年7月26日发布的,同一个月另外一件大事,就是乔布斯正式任命为 CEO,执掌大权。

其实,此处的 Mac OS 8 并非真正意义上的大版本更新——它原本应该是 Mac OS 7.7 。但是,前 CEO 同第三方厂商签订的系统授权协议,是基于Macintosh System 7 的,而直接发布 8.0 版本等同于是巧妙地利用命名,直接把后续的服务和协议一起给断掉了,同时新的 Mac OS 系统从名字上也直接区分于原本的 Macintosh,可以说是釜底抽薪的一招绝杀。

同时,新名字,新世代,也是开创新局面的好预兆,一举多得。新的 Mac OS 8 系统在更加优秀的硬件基础上,在显示效果上也一下子进入了高清的时代。

虽然 Mac OS 8 在底层上,依然继承自 System 7 ,但是因为几年前开始的 Copland 项目有不少遗产,身为继承者的 Mac OS 8 在视觉和体验上,提升了相当明显:

Mac OS 8 当中加入了主题选择的功能,虽然比较简单,但是也至少有着跟 Windows 95 相互匹敌:

和同时代的很多操作系统一样,在多媒体软件上, Mac OS 8 有了颇为炫酷的视觉效果:

界面左上角的 Apple LOGO 继续作为程序列表的菜单按钮而存在:

类似 2.5 D 的图标设计,是这个时代的用户界面设计的流行风尚:

而这种变化,在 Mac OS 8.5 这一版本上,有了更为明显的提升——比如文本抗锯齿效果,让文本更加易于阅读:

更加柔和自然的的光影变化,更复杂的交互和界面元素,Mac OS 8.5 所呈现出来的视觉效果乃至于体验,不会弱于同时代的任何系统:

但是也仅仅只是不弱于对手而已。

Mac OS 9:争取时间的权宜之计

Mac OS 9 是 Mac 系统第一个系列的最后一个大版本。

和 Mac OS 8 类似,原本的 Mac OS 9 原本应该作为 Mac OS 8.7 来发布的。

其实早在乔布斯回归并发布 Mac OS 8 之后,Mac OS 9 的发展路径和命运就已经注定了:为老硬件和老用户更新,并且继续为真正的新系统争取时间。

Mac OS 9 是在 1999 年 10 月 23 日发布的。这个面向新世纪而发布的操作系统,苹果是以「有史以来网络功能最好的操作系统」来进行宣传。

此时,乔布斯重组的设计团队,已经为新的操作系统挑选好了新的设计语言,而此时发布的 Mac OS 9 当中,也适当地加入了一些为真正的下一代系统所准备的视觉元素,比如播放器软件中的不锈钢拉丝效果:

窗口界面中的元素有着细腻微妙的光影起伏:

搜索应用中的内阴影、高度拟物化的小图标:

特别要说的是,此时的 Mac OS 9 中已经可以找到很多贴合现代 UI 设计中的诸多原则了,比如富有逻辑的分组:

容纳多个并列分组的标签页交互:

在诸如帮助页面和安装界面中,使用了层级丰富的排版视觉设计:

也许现在你对于字体的这种投影深恶痛绝,但是在20年前,这样的视觉效果是令人惊艳的:

Mac 系统第一系列自此收官

Mac 系统的第一个操作系统系列,在明面上有着相对清晰的脉络:自家电脑,用自家系统。通过这一系列的界面设计,可以总结出下面的几点:

  • 第一个系列的 Mac 系统在交互和整体框架上,保持了高度了延续性;
  • 模拟现实世界中元素的设计理念,从 Xerox Alto 一直延续下来没变过;
  • 在已有屏幕分辨率基础上,最大化地提供优质的视觉体验,是它的宗旨;
  • Mac 系统确实在很早的阶段,就已经开始注意体验和「不言自明」的交互逻辑;

Mac 的图形化界面,始于施乐,成于乔布斯,在迭代中一步步完善。

不过,从 System 7 开始,它的危机就已经出现了。从 1991 年到 1999 年这 8 年时间当中,暗地里发生了一系列的事情,这些事情是 Mac 系统视觉史当中,不可或缺的组成部分。

下一篇,依然是 Mac 系统的视觉史,其中包括 WIndows、NeXTstep、BeOS,当然,还有 Mac OS X。

参考:
https://history-computer.com/ModernComputer/Personal/Macintosh.html
https://en.wikipedia.org/wiki/Xerox_Alto
https://web.archive.org/web/20001109004000/http://www.apple.com:80/macos/
https://apple.fandom.com/wiki/Mac_OS_8.5
https://en.wikipedia.org/wiki/System_7
https://www.versionmuseum.com/history-of/classic-mac-os
https://en.wikipedia.org/wiki/Macintosh_clone
https://en.wikipedia.org/wiki/Classic_Mac_OS

https://guidebookgallery.org/guis/macos/macos10


文章来源:优设    作者:陈子木

Mac 视觉史 vol.2:90年代失败操作系统大赏

雪涛

在第一篇 Mac 视觉史当中,我梳理过了整个 Mac 系统第一阶段的明线,而这一篇,我们来聊一下它的「暗线」。

这一章所涉及到的项目,几乎可以组成一个 大型的「90年代失败操作系统大赏」,在主要由成功者们所构成的故事、新闻乃至与传说当中,这些失败的故事和项目,被提及的次数很少。

但是对于 Mac OS X 而言,这里的每一次作死和失败都充满了意义。

对于绝大多数的用户而言,Mac OS X 是21世纪初顶尖设计的范式,在今天,它是最优秀操作系统的当中的典型。

但是仔细想想看:从 System 1.0 到 Mac OS 9.2.2,长达15年时间的挤牙膏渐进式升级的Classic Mac OS,怎么可能突然一下子就变成了充满现代感的 Mac OS X?这种翻天覆地式的变化的确充满了戏剧感,但那是在今天的视角之下。

在这场「90年代失败操作系统大赏」当中,无疾而终者多不胜数,你所看到的不仅有粉墨登场,还有各式各样的粉末谢场。在 Mac 的视觉史当中,这一篇应该是一个大型的「处刑现场」。

失败的尝试,同样是 Mac 整个视觉演变史当中,绕不过去的部分——没有这些失败,就没有今天我们所熟知的 macOS 的视觉风格,没有后面 iOS 、iPadOS、watchOS 等等一系列交互界面和视觉。

来自内部的压力

虽然我们此刻所谈及的是操作系统的视觉史,但是操作系统背后最重要的始终是推动它的「人」。谈 Windows 必然会涉及 比尔·盖茨,而谈到 Mac ,也不得不说乔布斯。

和当年很多操作系统不一样的地方在于,乔布斯一直坚持硬件和软件(操作系统)理应是一体的。这也是为什么在很长的一段时间以内,Macintosh 指的既是硬件(电脑),也是软件(操作系统),而因为这台电脑是更容易被指代的对象,当用户在指代系统的时候,使用的是诸如 System 1 ,System 2 这样的词汇。

原本的 Maciontsh 是有内部竞争对手的——Lisa,这个以乔布斯女儿命名的电脑研发项目被夺走之后,乔布斯在 Macintosh 上投注了300% 的精力,亲手操刀了不少设计。拥有大量资源倾斜的 Lisa 在当时那个阶段,看起来也并不差:

在这个 1983年的 UI 界面上,细节处理其实也算得上非常用心了,比如顶部菜单上的「阴影渐变效果」:

当然,Lisa 的定位也非常明确,它就是一台办公电脑,所以它的系统名称也非常简单直接地使用了 Lisa Office System 这样的名字:

也正是在这样的对比之下,有着丰富字体、多样的媒体功能、能够玩游戏的 Macintosh 在这场内部竞赛中,得以胜出。

当然,如同我们都知道的,乔布斯在发布 Macintosh 的 2年后被迫离开自己创立的公司。当然,更重要的是,硅谷的巨头们更加清楚计算机的发展方向。这使得 Macintosh 面对的外部压力骤增。

激烈的外部竞争

图形化界面(GUI)的概念和交互模式——这个点子本身可能比实现技术来得更重要。

在高手云集的硅谷,虽然绝大多数的企业和开发者都是后期入局者,但是他们只要投入足够多的技术人员和时间,类似的图形化交互界面总归是能做出来的。

比如 Visi Corp 给 IBM 提供了 Visi On 这样的图形化程序:

微软也在 1985 年为 IBM 的 PC 提供了 Windows 软件:

Commodore 的图形化界面也差不多同期问世:

而 GEOS 甚至为更老的 Apple ][ 提供了图形化界面的操作系统:

这些系统都是在 Macintosh 发布那一两年内相继问世的。

从 System 6 开始新尝试

操作系统领域的竞争,刺激着苹果寻求突破。

多数企业都不会把鸡蛋放在一个篮子里,这样孤注一掷的决策确实有太大的风险。其他的商用操作系统,都开始拥有日渐完善的桌面端图形界面,使得苹果在差异性和独特性上不足。除了在硬件性能和产品线上增加投入,他们也开始尝试开发更优秀的图形化界面和下一代操作系统。

在上一篇当中,我提到过,在 80 年代末所发售的 System 6 是一个集大成的版本,在硬件性能和黑白显示器之下,这个操作系统本身的核心功能已经颇为完善了。这个时候,苹果开始有意识地进行一些探索性的项目。

「Pink」和「Blue」项目

某种意义上来说,「Blue」 和「Pink」 两个项目几乎是同时开始的。

虽然 1988 年的时候,乔布斯早已离开,但是他所塑造的 Macintosh 是当之无愧的传奇,那种「内部创业」和「改变世界」、「创造传奇」的硅谷精神对于此刻的苹果员工依然有着极大的影响。

当时苹果内部 5 名躁动不安的中层开发工程师想拜托日渐僵化的内部管理,想改变当时 System 6 表现欠佳的局面,想打造一个次世代的旗舰操作系统——某种意义上重现 1984 Macintosh 的传奇。

他们在这次私底下的会议上重新梳理并规划未来的操作系统。他们将System 6 基础上的可以增量更新的特性、可以很快实现的功能,写在蓝色的卡片上,将技术上更加先进、符合长期价值的功能(比如当时 Macintosh 所缺乏的抢先式多任务处理和组件化程序设计)写在粉色的卡片上,将更加激进的特性写在红色的卡片上。

这次会议基本上就塑造了后面的「Blue」和「Pink」两个项目,而红色卡片上的特性由于过于激进,仅仅只是备案而没有成立项目。

数百名工程师继续在 System 6 的基础上按部就班地更新功能、维护代码库,继续「Blue」项目,而它的最终产物,就是后面我们看到的 System 7:

而另外一边的「Pink」项目,一开始并不是公开的。当时 Erich Ringewald 领导这发起这次会议的核心 5人组,想像 Macintosh 项目开始那样,找一个隐秘的房间开始这次「内部创业」。

他们看上了 位于 Bubb Road 的一间仓库,当他们进去的时候,才发现这个仓库已经被另外一个正在秘密进行 Newton 项目的团队给占了。

当然这款同样极为传奇的(失败)掌上设备我们回头再说。

一路膨胀的「Pink」项目

「Pink 」项目开局的时候,有 6个人,但是考虑到要彻底放弃 System 6 的遗产,重新开始全新的操作系统,程序要是面向对象的,要有内存保护,要抢先式多任务处理,要支持多语言足够国际化,还要有全新的图形库,这个团队开始一路膨胀。

先是苹果的先进技术小组(ATG)加入团队,人数变为11人。 2个月后,「Pink」项目增加到 25 人。7个月后,原始的5人组几乎都因为「人员多到失控」而离开「Pink」项目。1年后,「Pink」项目的开发组多达100人。

原本计划在2年后发布的「Pink」操作系统在原计划的2年之期到期之时,拥有了 150 人的超大规模,高级副总裁和市场营销部门的首脑领导着这个庞大的开发团队。

「Pink 什么时候上市?答案永远都是2年后。」

这是当时流传的一个内部笑话。

但是这个笑话只是刚刚开始。因为它才刚刚开始膨胀。

系统开发需要时间,而随着时间推移,市场变化需要「Pink」 更有竞争力,然后原本位于红色卡片上的「激进功能」开始不断的加入到「Pink」当中,然后项目就需要更多时间来开发——恶性循环开始了。

在「Pink」上,苹果投入了太多,放弃是不可能放弃了,唯一的办法就是拉更多人入局。当时的 CEO John Sculley 对外宣称「Pink」操作系统代码已经多达 150 万行,并去 IBM 做了内部演示。

然后,这个看起来像是被移植到 PC 上的 System 7 成功地引起了 IBM 的注意。让比尔·盖茨最不想看到的事情发生了:苹果、IBM 和 摩托罗拉成立 AIM 联盟。

从未发布的「Taligent」系统

AIM 联盟成立于 1991年10月2日,此时距离「Pink」项目开始已经过去了3年半。半年之后,苹果和 IBM 正式组建了合资公司 Taligent .inc ,而其中苹果占股较小。

原本被拿来吹嘘的「Pink」操作系统,此时也更名为 Taligent 。

Taligent OS 的确有着很多超越 Macintosh 的功能,比如更的程序机制,3D功能等等等等。在整个 UI 界面上,Taligent OS 使用了继承自「Pink」项目的一些设计:等轴测的图标,伪3D风格的图标,还有非矩形的窗口(注意看窗口的顶部菜单栏)。

当然,Taligent OS 从「PInk」项目继承过来的最大特性是:一直在开发,从未正式发布。

1994年,HP 入局,加入 Taligent 公司并且持股 15%,Taligent OS 的一部分技术开始运用到 HP 家的 NewWave 桌面环境中了:

与此同时,Windows 95 的关注度越来越高,而媒体吐槽苹果久未发布的新系统,并嘲讽难产多年的 Taligent OS(还有 Pink),已经成了一件政治正确的事情。

虽然 1994 年的时候,Taligent OS 在 SFA 展会上使用 Macintosh IIcI 展示了运行速度和崩溃速度同样快的 3D 应用,但是它最终还是没有发布。

1995年,苹果出售股权退出 Taligent 公司,「Pink」 项目的最终产品也并非 Taligent OS,而是 IBM 公司的 AIX 系统中的 Common Point 应用。

「Pink」到此终结。失败。

最终迷航的「StarTrek」计划

在 Taligent OS 研发期间,苹果将鸡蛋还放到了另外一个篮子里面,这个项目的代号借用了著名的科幻电影《星际迷航》,项目的 Slogan 是「大胆地探索 Mac 之前从未去到过的地方」。

这个地方就是使用英特尔芯片的 X86 架构的电脑上。

「StarTret」项目中,苹果是和当时的服务器供应商 Novell 共同构思的,这个项目最终因为内部斗争、人事纠纷、市场问题而关闭。值得一提的是,同样的尝试在 1985年的时候就有过,不过那次尝试很快就被中止了,以至于至今没有一个正式的代号留下来。

这算是2次失败。

「Copland」 操作系统

作为 「Blue」项目产物的 System 7 最终并没有彻底解决苹果在操作系统上的困顿处境,系统依然问题很多,内存保护机制、抢先式多任务处理依然还没有。而 1994年3月开始的「Copland」项目,就是为此做准备的,它的代号来源于美国作曲家 Aaron Copland 。

除了在内存分配和多任务处理等核心功能上进行开发提升,它在 GUI 的视觉层面上的优化,也花费了相当多的心思。在视觉层面上,Copland 新设计的一套主题名为 Platinum ,所有的元素都有着颇为细腻的阴影,窗口元素则有着明显的突起,原本「Pink」项目中的等轴测图标也加入了进来。

除了 Platinum 之外,Copland 还加入了面向儿童的主题P,以及更加具有未来派风格的主题Z。

除了主题本身之外,Copland 还支持窗口最小化到底部为标签,多用户登录(Windows 98 之后才有这个功能),这种功能类似于现在的家长管理——管理员帐号可以决定其他用户可以使用哪些应用。可以说,非常超前了。

当你在 Copland 中拖动文件到不同文件夹的时候,这些文件夹可以自动打开,这一功能在当时也是非常先进的。

不过,Copland 极具前瞻性的另外一面,就是它本质上是一个「要你命3000」。各种新的功能和特性出于市场需求和项目需求毫无节制地被加入进来,所有的功能相互之间都存在冲突和影响,所有人都很清晰地知道,Copland 是不可能被作为正式产品所发布出来的。

「它只是一个不同团队开发产品的合集……并且期望它们能够神奇地组合到一起。」

这是当时的 CEO Amelio 自己说的。

当然,Copland 的阵亡不可避免,只不过它的界面管理器和 Platinum 主题最终留到了 Mac OS 8 当中,为苹果公司的自救大业添砖加瓦。

Copland 失败了。自家开发团队搞不定,只能从外部想办法了。

4个外部备选方案

当时,CEO Amelio 个人比较倾向于 Windows NT,并且为此专门同盖茨通了电话,而盖茨也表示如果愿意使用 Windows,他可以组建团队将苹果的拳头产品 QuickDraw 移植过来。此时,WIndows 95 已经发布一年了,而 Windows NT 也刚刚发布,市场反响极好,份额节节攀升。

当然,苹果和微软的命运纠缠并不是此时才开始的。Windows 1.0 时代,图形化界面的专利授权是苹果授权给微软的。

而 Windows 2.0 继续沿用 1.0 时代的设计,但是苹果没有给 2.0 授权,最终引起了纠纷,盖茨借用不维护 Word 和 Excel 软件和当时的 CEO 达成了庭外的和解。这些事情回头有机会细说。

和CEO的想法不同,当时苹果的 CTO Ellen Hancock 其实是想选择 Solaris 来着,不过它还没有一套友好的用户界面,赢面不大。

最终摆在苹果CEO 和董事会桌面上的,就剩下两个备选了,一个是 BeOS,另一个是乔布斯的 NeXTSTEP。

然而这毫无疑问是一次极具戏剧化的选择,因为这两个操作系统背后的两个人,有着极深的纠葛。

让-路易·加西 和乔布斯的纠葛

Be 公司的 CEO 是法国人 让·路易·加西,他是 1981 年加入苹果公司并负责当时欧洲业务。

1985年,他在得知乔布斯计划在阵亡将士纪念日罢免 CEO 约翰·斯卡利(John Sculley)的计划后,抢先告知董事会,最终导致乔布斯从苹果辞职。

1987年,加西启动了 「Skunkworks」项目,而这个项目的产物就是后来的掌上电脑 Newton MessagePad,而最终这条产品线也是乔布斯关停的。当年的「Pink 」五人组在仓库里撞见的,就是加西的团队。

1990年,加西和CEO交恶,并且董事会对于他所推出的 Macintosh 产品不满意,最终导致他离开了苹果,并于次年创立了自己的 Be 公司。

彼时正在艰难推进 NeXT 电脑业务的乔布斯,在媒体那边的口碑并不好。而加西反而在这个时候,对 NeXT 不吝溢美之词。

当然,最终乔布斯的 NeXT 和 加西的 Be 最终还是摆在了同一张桌子上,被选择。

极具潜力的 BeOS

BeOS 是一个在当时来看极为激进的操作系统。它并不是为当时更为流行的办公场景而构建,而是一款旨在为多媒体处理而生的操作系统。

它并没有采用当时所流行的 Unix 的架构,有着一套相对更加独特的系统逻辑和设计规则。

它同样延续了当时最为流行的等轴测图标设计,在配色上更为鲜亮,在视觉化设计上,一点都不弱于同时期的任何操作系统,包括 Macintosh 和 NeXTSTEP。

在交互逻辑上,BeOS 沿用了当时很多 Unix 操作系统的右侧交互工具工具栏,正在运行的程序可以清晰地在此预览,而右上角的 BeOS LOGO 则类似开始菜单,可以呼出程序列表:

BeOS 的图标设计在统一性和规范性上极高,即使在今天看来,很多设计都不落俗套:

BeOS 能进入苹果的备选,一个很重要原因是这套操作系统兼容当时 Macintosh 所用的 PowerPC 的架构。尽管它一直都未曾推进到 1.0 正式版,但是并不影响它在电脑领域收割一大波粉丝。

但是作为一个操作系统而言,在消费市场上依然是一个失败的产品。

定位高端的 NeXTSTEP

另外一边,乔布斯 的 NeXT 电脑并没有复制 Macintosh 消费市场上的成功。不过,NeXT 作为定位高端的工作站,倒是吸引了不少科学家和计算机领域的研究人员以及顶尖的数字创意从业者的注意。

在接近被收购的当口,NeXTSTEP 系统已经推进到了4.0 的大版本。由于它本身在硬件性能上的突出表现,在操作系统的各种细节上,一点都不吝惜,竭尽全力地刻画细节。而这其中,有很多概念和想法是从 Macintosh 时代继承并发扬出来,并惠及后面的 MacOSX 乃至于 macOS。

精巧的 3D 小插件,全彩高清大尺寸拟物化图标,底部程序坞组件,以及可以购买软件的软件商店,甚至于著名的游戏 Doom 和 Quake 都是在 NeXTSTEP 上首发的。

无论是内部的功能,还是外部的 UI 元素的细节控制,NeXTSTEP 都在当时条件允许的前提下,做到了尽善尽美。比如登录和关闭窗口中的光影细节:

(注:NeXTSTEP 是操作系统,而OpenStep 是一套 API。)

当然,NeXT 本身并不算成功,被苹果收购是最好的结局之一,这不仅是市场的选择,也是苹果的选择,是乔布斯的选择。

结语:自此重启

终极对决发生在 1996年10月12日,地点是帕罗奥托的花园庭院酒店。

CEO Amelio、CTO Hancock ,以及另外 的 6 位董事会成员是最终决策者。加西志得意满,没有作任何演示,而乔布斯不仅使用了他的天赋技能「现实扭曲力场」,而且如同魔术师一般演示了 NeXTSTEP 的各种功能和特性。

苹果公司,乔布斯,加西 三方的命运在此汇聚碰撞,然后再次扭转。当然,这个扭转的过程并非一帆风顺,此时,距离苹果的命运彻底改变,还有4年时间。

在离开苹果、创立 NeXT 的阶段,乔布斯和苹果曾数度交恶,其中所产生的纠纷与诉讼在此刻依然是障碍。

NeXT公司同意了种种限制条款:其产品将作为高端智能终端直接销售给高校,而且NeXT公司不能在1987年3月之前推出产品。苹果公司还坚持,NeXT的机器「不能使用与Mac兼容的操作系统」。后来的情况表明,如果当时苹果公司的要求刚好相反,会对自身更为有利。

——《史蒂夫·乔布斯传》

看完了这些失败的产品的产品,我们终于要说一下成功的产品了。

下一篇,我们将从「水」聊起。

引用来源:

https://en.wikipedia.org/wiki/Jean-Louis_Gass%C3%A9e
https://guidebookgallery.org/articles/sortingoutfactfromfiction
http://toastytech.com/guis/guitimeline2.html
https://lowendmac.com/2005/apples-copland-project/
https://en.wikipedia.org/wiki/Appearance_Manager
https://en.wikipedia.org/wiki/Star_Trek_project
https://dl.acm.org/doi/book/10.5555/582997
https://en.wikipedia.org/wiki/System_7
https://web.archive.org/web/20070120202050/http://robinnet.net/resume/Robin_portfolio_Taligent.htm
https://web.archive.org/web/20070106224709/http://www.wildcrest.com/Potel/Portfolio/InsideTaligentTechnology/WW87.htm
https://www.operating-system.org/betriebssystem/_english/bs-aix.htm

https://www.wired.com/1993/02/taligent/


文章来源:优设    作者:陈子木

以动物为灵感的 LOGO 设计欣赏

前端达人

    对于许多公司和品牌而言,使用带有含义的动物logo,能非常准确的传递品牌信息!比如说豹子的敏捷,狮子的勇猛,长颈鹿的优雅,独角兽的神秘等等!这种品牌意识在其徽标中使用动物象征来策划。根据所选动物的类型,品牌是强大,快速,奢华,关怀,神秘和许多其他情感。

1.jpg2.jpg3.jpg4.jpg5.jpg6.jpg7.jpg8.jpg9.jpg10.jpg11.jpg12.jpg13.jpg14.jpg15.jpg16.jpg17.jpg18.jpg19.jpg20.jpg21.jpg22.jpg23.jpg24.jpg25.jpg26.jpg27.jpg28.jpg29.jpg30.jpg31.jpg32.jpg33.jpg34.jpg35.jpg36.jpg37.jpg38.jpg39.jpg40.jpg41.jpg42.jpg43.jpg


大数据可视化设计赏析(二)

前端达人


    随着大数据产业的发展,越来越多的公司开始实现数据资源的管理和应用,尤其是一些在日常生活中经常使用大屏幕的大中型企业。此时,用户界面设计者需要呈现相应的视觉效果。接下来为大家介绍大屏可视化的UI设计。


点击查看原图

 --大屏UI设计--


3.jpg

 --大屏UI设计--


4.jpg

 --大屏UI设计--


5.jpg


 --大屏UI设计--





7.jpg


 --大屏UI设计--



8.jpg


 --大屏UI设计--



9.jpg


 --大屏UI设计--



点击查看原图

 --大屏UI设计--


点击查看原图


 --大屏UI设计--




点击查看原图


 --大屏UI设计--

(图片均来源于网络)

  蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服


    更多精彩文章:

       

 大数据可视化设计赏析(一)

  大数据可视化设计赏析(二)

  大数据可视化设计赏析(三)

  大数据可视化设计赏析(四)

  大数据可视化设计赏析(五)

  大数据可视化设计赏析(六)

  大数据可视化设计赏析(七)


2020年最火的设计趋势Neumorphism

蓝蓝

蓝蓝注:我非常喜欢这个风格。


日前,在网上流行起了一种叫 Neumorphism 的新风格,也有人称为 Soft UI,这是一种类似于浮雕的效果。这种风格的出现,给目前流行的扁平化设计增加了一种新的设计形式,很多媒体甚至还将这个风格列为 2020 的设计趋势,三星 Galaxy 系列的发布会宣传海报也使用了这种风格,可见这个风格的火热程度。那么一开始我们不讨论这个风格好还是不好,先来了解一下这个新风格趋势。

什么是Neumorphism?

最开始是一位来自乌克兰的设计师 Alexander Plyuto 在各平台发布了新的作品「Skeuomorph Mobile Banking」。这个作品自发布以来就获得了数十万浏览量,数千点赞数,热度持续飙升并登上 Popular 榜首。

作者是用 Skeuomorph 来命名这个作品风格,评论区就开始了这种风格的讨论,有的人说这是新的拟物风格(New Skeuomorphism),也有人说这是拟物风格 2.0 版本(Skeuomorph 2.0),而后来就有设计师创出一个新的虚构名词,把 New Skeuomorphism 两个词组合,Neo 谐音 New 就是 Neuomorphism。

这个名字就这么火了。大家都开始用上了这个名词出作品,成为了设计新趋势。甚至连作者后面的作品,也使用了这个名称。

再后来国外知名设计师 Michal Malewicz 发布了一篇关于这个风格的文章,将 Neuomorphism,删减了里面的字母「O」,改成了 Neumorphism。在大神的推动下大家又开始争先恐后地使用这个名称。

目前有各种对名称的说法,Neuomorphism,Neumorphism,Skeuomorphism,Soft UI,在没有实际确定的情况下,其实怎样叫都无所谓,重点是我们要知道这种设计风格趋势,关注的不是名字,而是设计。

还记得拟物风格吗?

既然 Neumorphism 只是一个虚构词,也没有任何官方认定,那就先不纠结应该叫什么,我们还是来说说它的前身吧,也就是 Skeuomorphism(拟物)。这是最早被 Apple 提出的设计概念,就是在界面中模仿现实物体纹理材质的设计,目的是让人们在使用界面时习惯性地联想到现实物体的使用方式。

拟物写实的设计风格曾经风靡全球,当时的 UI 设计师几乎都对拟物作品着迷。

而在 2013 年的 WWDC 大会中,苹果公司发布的 iOS7 系统,系统 UI 使用更简洁的设计风格。这场大会也使拟物风格逐渐过时,直到现在扁平风格的全面普及,拟物风格就再没有被广泛应用。

从前几年的设计趋势可以看到,扁平风格作为更更简洁的风格被设计师推崇,再加上苹果系统 iOS 7 设计风格的面世和谷歌系统规范 Material Design 的普及,扁平风格在 UI 设计中一直占据重要位置。

但设计的流行趋势也一直在改变着,在苹果公司发布的 iOS 13 系统中,就有出现轻拟物的设计手法,接着就有一大堆设计师猜测是不是拟物风格的回归,但我看系统中大部分界面设计也还是扁平风格,并没有把拟物风格作为主要设计风格,也许只是某种程度上解决了画笔的视觉识别问题。

拟物效果能否回归,这个言之尚早,但是新的风格趋势也许可以在扁平同质化的时候增添一点灵感与乐趣。

能用在实际项目中吗?

1. 设计

其实要做到这个效果并不难,了解一下这个风格的结构。

主要有三个样式组成,1 个背景+ 2 个投影。在这个基础上,通过改变颜色和大小参数来达到不同效果。

我尝试着使用彩色去做这个效果,使用浅色背景时还是有效果的,但使用深一点的颜色时,问题就出现了,效果更像是外发光或者普通投影。这也可能是为什么大多数作品都采用比较素的颜色作为背景的原因。

2. 浏览

这个风格最大的问题就是缺少对比度。在色彩使用上比较克制,没有大面积的平铺颜色,仅在极少的位置进行色彩点缀,作用是吸引眼球。从众多设计师的作品可以看出,整体视觉是比较平的,缺少层次。

我拿其中两张图进行了 15% 强度的模糊处理,可以看到除了点缀的位置以外,界面是没有重点的。

3. 操作

因为在界面中除了文字以外,几乎所有元素都应用了这种效果,导致界面所有内容看起来都是按钮的错觉。界面中的主要操作按钮也没有被重点提亮。正常态和点击态的对比度并没有拉开,容易造成状态混淆。点击欲望比较低,不利于引导用户进行下一步操作。

4. 动画

跟拟物效果的动画有同样的问题,元素动画效果很难做得轻快,更适合按钮的使用。由于视觉层级跟背景没有实际分离开,就像固定在了背景上一样,所以动画效果只要出现移动,就会让人觉得不合理,容易给人一种虫子在皮肤底下蠕动的感觉。

5. 开发

问题跟当年的拟物效果的实现类似,要实现这个风格,主要有两个方式。

切图:对元素的每个状态(Normal、Hover、Pressed),设计师都需要分别提供一张切图,这个会导致资源库增加大量的图片。 代码实现:这个风格的实现效果是对元素增加两个不同方向的投影,通过代码可以实现。但是需要开发对每个元素添加投影,样式代码增多,繁琐的工作量,开发也不会乐意。

附 CSS 实现新风格的网站:Neumorphism 的生成器

综合分析来看,这种设计风格目前在项目中推广和实现中并不合适。

总结

这个风格的出现也确实给大家带来了一个新的思考,这个风格会持续吗?可用吗?也许扁平风格的多年流行后,设计潮流开始往回走,但并不是直接回到拟物风格,而是在效率和视觉效果中找一个平衡点。不论这个风格的对错,起码引起了设计师的注意,也激发了很多设计师的灵感,就像当年拟物风格和扁平风格的讨论一样,不分对错,设计师也不妨多留意一下这个风格,试着做一下效果图,或许会有新的发现。

JavaScript中的Event Loop(事件循环)机制

seo达人

事件循环

JavaScript是单线程,非阻塞的

浏览器的事件循环


执行栈和事件队列

宏任务和微任务

node环境下的事件循环


和浏览器环境有何不同

事件循环模型

宏任务和微任务

经典题目分析

1. JavaScript是单线程,非阻塞的

单线程:


JavaScript的主要用途是与用户互动,以及操作DOM。如果它是多线程的会有很多复杂的问题要处理,比如有两个线程同时操作DOM,一个线程删除了当前的DOM节点,一个线程是要操作当前的DOM阶段,最后以哪个线程的操作为准?为了避免这种,所以JS是单线程的。即使H5提出了web worker标准,它有很多限制,受主线程控制,是主线程的子线程。


非阻塞:通过 event loop 实现。


2. 浏览器的事件循环

执行栈和事件队列

为了更好地理解Event Loop,请看下图(转引自Philip Roberts的演讲 《Help, I'm stuck in an event-loop》)

Help, I'm stuck in an event-loop


执行栈: 同步代码的执行,按照顺序添加到执行栈中


function a() {

   b();

   console.log('a');

}

function b() {

   console.log('b')

}

a();

我们可以通过使用 Loupe(Loupe是一种可视化工具,可以帮助您了解JavaScript的调用堆栈/事件循环/回调队列如何相互影响)工具来了解上面代码的执行情况。


调用情况


执行函数 a()先入栈

a()中先执行函数 b() 函数b() 入栈

执行函数b(), console.log('b') 入栈

输出 b, console.log('b')出栈

函数b() 执行完成,出栈

console.log('a') 入栈,执行,输出 a, 出栈

函数a 执行完成,出栈。

事件队列: 异步代码的执行,遇到异步事件不会等待它返回结果,而是将这个事件挂起,继续执行执行栈中的其他任务。当异步事件返回结果,将它放到事件队列中,被放入事件队列不会立刻执行起回调,而是等待当前执行栈中所有任务都执行完毕,主线程空闲状态,主线程会去查找事件队列中是否有任务,如果有,则取出排在第一位的事件,并把这个事件对应的回调放到执行栈中,然后执行其中的同步代码。


我们再上面代码的基础上添加异步事件,


function a() {

   b();

   console.log('a');

}

function b() {

   console.log('b')

   setTimeout(function() {

       console.log('c');

   }, 2000)

}

a();

此时的执行过程如下

img


我们同时再加上点击事件看一下运行的过程


$.on('button', 'click', function onClick() {

   setTimeout(function timer() {

       console.log('You clicked the button!');    

   }, 2000);

});


console.log("Hi!");


setTimeout(function timeout() {

   console.log("Click the button!");

}, 5000);


console.log("Welcome to loupe.");

img


简单用下面的图进行一下总结


执行栈和事件队列


宏任务和微任务

为什么要引入微任务,只有一种类型的任务不行么?


页面渲染事件,各种IO的完成事件等随时被添加到任务队列中,一直会保持先进先出的原则执行,我们不能准确地控制这些事件被添加到任务队列中的位置。但是这个时候突然有高优先级的任务需要尽快执行,那么一种类型的任务就不合适了,所以引入了微任务队列。


不同的异步任务被分为:宏任务和微任务

宏任务:


script(整体代码)

setTimeout()

setInterval()

postMessage

I/O

UI交互事件

微任务:


new Promise().then(回调)

MutationObserver(html5 新特性)

运行机制

异步任务的返回结果会被放到一个任务队列中,根据异步事件的类型,这个事件实际上会被放到对应的宏任务和微任务队列中去。


在当前执行栈为空时,主线程会查看微任务队列是否有事件存在


存在,依次执行队列中的事件对应的回调,直到微任务队列为空,然后去宏任务队列中取出最前面的事件,把当前的回调加到当前指向栈。

如果不存在,那么再去宏任务队列中取出一个事件并把对应的回到加入当前执行栈;

当前执行栈执行完毕后时会立刻处理所有微任务队列中的事件,然后再去宏任务队列中取出一个事件。同一次事件循环中,微任务永远在宏任务之前执行。


在事件循环中,每进行一次循环操作称为 tick,每一次 tick 的任务处理模型是比较复杂的,但关键步骤如下:


执行一个宏任务(栈中没有就从事件队列中获取)

执行过程中如果遇到微任务,就将它添加到微任务的任务队列中

宏任务执行完毕后,立即执行当前微任务队列中的所有微任务(依次执行)

当前宏任务执行完毕,开始检查渲染,然后GUI线程接管渲染

渲染完毕后,JS线程继续接管,开始下一个宏任务(从事件队列中获取)

简单总结一下执行的顺序:

执行宏任务,然后执行该宏任务产生的微任务,若微任务在执行过程中产生了新的微任务,则继续执行微任务,微任务执行完毕后,再回到宏任务中进行下一轮循环。


宏任务和微任务


深入理解js事件循环机制(浏览器篇) 这边文章中有个特别形象的动画,大家可以看着理解一下。


console.log('start')


setTimeout(function() {

 console.log('setTimeout')

}, 0)


Promise.resolve().then(function() {

 console.log('promise1')

}).then(function() {

 console.log('promise2')

})


console.log('end')

浏览器事件循环


全局代码压入执行栈执行,输出 start

setTimeout压入 macrotask队列,promise.then 回调放入 microtask队列,最后执行 console.log('end'),输出 end

调用栈中的代码执行完成(全局代码属于宏任务),接下来开始执行微任务队列中的代码,执行promise回调,输出 promise1, promise回调函数默认返回 undefined, promise状态变成 fulfilled ,触发接下来的 then回调,继续压入 microtask队列,此时产生了新的微任务,会接着把当前的微任务队列执行完,此时执行第二个 promise.then回调,输出 promise2

此时,microtask队列 已清空,接下来会会执行 UI渲染工作(如果有的话),然后开始下一轮 event loop, 执行 setTimeout的回调,输出 setTimeout

最后的执行结果如下


start

end

promise1

promise2

setTimeout

node环境下的事件循环

和浏览器环境有何不同

表现出的状态与浏览器大致相同。不同的是 node 中有一套自己的模型。node 中事件循环的实现依赖 libuv 引擎。Node的事件循环存在几个阶段。


如果是node10及其之前版本,microtask会在事件循环的各个阶段之间执行,也就是一个阶段执行完毕,就会去执行 microtask队列中的任务。


node版本更新到11之后,Event Loop运行原理发生了变化,一旦执行一个阶段里的一个宏任务(setTimeout,setInterval和setImmediate)就立刻执行微任务队列,跟浏览器趋于一致。下面例子中的代码是按照的去进行分析的。


事件循环模型

┌───────────────────────┐

┌─>│        timers         │

│  └──────────┬────────────┘

│  ┌──────────┴────────────┐

│  │     I/O callbacks     │

│  └──────────┬────────────┘

│  ┌──────────┴────────────┐

│  │     idle, prepare     │

│  └──────────┬────────────┘      ┌───────────────┐

│  ┌──────────┴────────────┐      │   incoming:   │

│  │         poll          │<──connections───     │

│  └──────────┬────────────┘      │   data, etc.  │

│  ┌──────────┴────────────┐      └───────────────┘

│  │        check          │

│  └──────────┬────────────┘

│  ┌──────────┴────────────┐

└──┤    close callbacks    │

  └───────────────────────┘

事件循环各阶段详解

node中事件循环的顺序


外部输入数据 --> 轮询阶段(poll) --> 检查阶段(check) --> 关闭事件回调阶段(close callback) --> 定时器检查阶段(timer) --> I/O 事件回调阶段(I/O callbacks) --> 闲置阶段(idle, prepare) --> 轮询阶段...


这些阶段大致的功能如下:


定时器检测阶段(timers): 这个阶段执行定时器队列中的回调如 setTimeout() 和 setInterval()。

I/O事件回调阶段(I/O callbacks): 这个阶段执行几乎所有的回调。但是不包括close事件,定时器和setImmediate()的回调。

闲置阶段(idle, prepare): 这个阶段仅在内部使用,可以不必理会

轮询阶段(poll): 等待新的I/O事件,node在一些特殊情况下会阻塞在这里。

检查阶段(check): setImmediate()的回调会在这个阶段执行。

关闭事件回调阶段(close callbacks): 例如socket.on('close', ...)这种close事件的回调

poll:

这个阶段是轮询时间,用于等待还未返回的 I/O 事件,比如服务器的回应、用户移动鼠标等等。

这个阶段的时间会比较长。如果没有其他异步任务要处理(比如到期的定时器),会一直停留在这个阶段,等待 I/O 请求返回结果。

check:

该阶段执行setImmediate()的回调函数。


close:

该阶段执行关闭请求的回调函数,比如socket.on('close', ...)。


timer阶段:

这个是定时器阶段,处理setTimeout()和setInterval()的回调函数。进入这个阶段后,主线程会检查一下当前时间,是否满足定时器的条件。如果满足就执行回调函数,否则就离开这个阶段。


I/O callback阶段:

除了以下的回调函数,其他都在这个阶段执行:


setTimeout()和setInterval()的回调函数

setImmediate()的回调函数

用于关闭请求的回调函数,比如socket.on('close', ...)

宏任务和微任务

宏任务:


setImmediate

setTimeout

setInterval

script(整体代码)

I/O 操作等。

微任务:


process.nextTick

new Promise().then(回调)

Promise.nextTick, setTimeout, setImmediate的使用场景和区别

Promise.nextTick

process.nextTick 是一个独立于 eventLoop 的任务队列。

在每一个 eventLoop 阶段完成后会去检查 nextTick 队列,如果里面有任务,会让这部分任务优先于微任务执行。

是所有异步任务中最快执行的。


setTimeout:

setTimeout()方法是定义一个回调,并且希望这个回调在我们所指定的时间间隔后第一时间去执行。


setImmediate:

setImmediate()方法从意义上将是立刻执行的意思,但是实际上它却是在一个固定的阶段才会执行回调,即poll阶段之后。


经典题目分析

一. 下面代码输出什么

async function async1() {

   console.log('async1 start');

   await async2();

   console.log('async1 end');

}

async function async2() {

   console.log('async2');

}

console.log('script start');

setTimeout(function() {

   console.log('setTimeout');

}, 0)

async1();

new Promise(function(resolve) {

   console.log('promise1');

   resolve();

}).then(function() {

   console.log('promise2');

});

console.log('script end');

先执行宏任务(当前代码块也算是宏任务),然后执行当前宏任务产生的微任务,然后接着执行宏任务


从上往下执行代码,先执行同步代码,输出 script start

遇到setTimeout,现把 setTimeout 的代码放到宏任务队列中

执行 async1(),输出 async1 start, 然后执行 async2(), 输出 async2,把 async2() 后面的代码 console.log('async1 end')放到微任务队列中

接着往下执行,输出 promise1,把 .then()放到微任务队列中;注意Promise本身是同步的立即执行函数,.then是异步执行函数

接着往下执行, 输出 script end。同步代码(同时也是宏任务)执行完成,接下来开始执行刚才放到微任务中的代码

依次执行微任务中的代码,依次输出 async1 end、 promise2, 微任务中的代码执行完成后,开始执行宏任务中的代码,输出 setTimeout

最后的执行结果如下


script start

async1 start

async2

promise1

script end

async1 end

promise2

setTimeout

二. 下面代码输出什么

console.log('start');

setTimeout(() => {

   console.log('children2');

   Promise.resolve().then(() => {

       console.log('children3');

   })

}, 0);


new Promise(function(resolve, reject) {

   console.log('children4');

   setTimeout(function() {

       console.log('children5');

       resolve('children6')

   }, 0)

}).then((res) => {

   console.log('children7');

   setTimeout(() => {

       console.log(res);

   }, 0)

})

这道题跟上面题目不同之处在于,执行代码会产生很多个宏任务,每个宏任务中又会产生微任务


从上往下执行代码,先执行同步代码,输出 start

遇到setTimeout,先把 setTimeout 的代码放到宏任务队列①中

接着往下执行,输出 children4, 遇到setTimeout,先把 setTimeout 的代码放到宏任务队列②中,此时.then并不会被放到微任务队列中,因为 resolve是放到 setTimeout中执行的

代码执行完成之后,会查找微任务队列中的事件,发现并没有,于是开始执行宏任务①,即第一个 setTimeout, 输出 children2,此时,会把 Promise.resolve().then放到微任务队列中。

宏任务①中的代码执行完成后,会查找微任务队列,于是输出 children3;然后开始执行宏任务②,即第二个 setTimeout,输出 children5,此时将.then放到微任务队列中。

宏任务②中的代码执行完成后,会查找微任务队列,于是输出 children7,遇到 setTimeout,放到宏任务队列中。此时微任务执行完成,开始执行宏任务,输出 children6;

最后的执行结果如下


start

children4

children2

children3

children5

children7

children6

三. 下面代码输出什么

const p = function() {

   return new Promise((resolve, reject) => {

       const p1 = new Promise((resolve, reject) => {

           setTimeout(() => {

               resolve(1)

           }, 0)

           resolve(2)

       })

       p1.then((res) => {

           console.log(res);

       })

       console.log(3);

       resolve(4);

   })

}



p().then((res) => {

   console.log(res);

})

console.log('end');

执行代码,Promise本身是同步的立即执行函数,.then是异步执行函数。遇到setTimeout,先把其放入宏任务队列中,遇到p1.then会先放到微任务队列中,接着往下执行,输出 3

遇到 p().then 会先放到微任务队列中,接着往下执行,输出 end

同步代码块执行完成后,开始执行微任务队列中的任务,首先执行 p1.then,输出 2, 接着执行p().then, 输出 4

微任务执行完成后,开始执行宏任务,setTimeout, resolve(1),但是此时 p1.then已经执行完成,此时 1不会输出。

最后的执行结果如下


3

end

2

4

你可以将上述代码中的 resolve(2)注释掉, 此时 1才会输出,输出结果为 3 end 4 1。


const p = function() {

   return new Promise((resolve, reject) => {

       const p1 = new Promise((resolve, reject) => {

           setTimeout(() => {

               resolve(1)

           }, 0)

       })

       p1.then((res) => {

           console.log(res);

       })

       console.log(3);

       resolve(4);

   })

}



p().then((res) => {

   console.log(res);

})

console.log('end');

3

end

4

1

最后强烈推荐几个非常好的讲解 event loop 的视频:


What the heck is the event loop anyway? | Philip Roberts | JSConf EU

Jake Archibald: In The Loop - JSConf.Asia

大屏数据可视化设计指南

分享达人

可能是目前大屏数据可视化设计介绍最详尽的一篇文章了,可以当做设计手册使用的一篇经验分享

Image title


一、基础概念


1、什么是数据可视化


把相对复杂、抽象的数据通过可视的方式以人们更易理解的形式展示出来的一系列手段叫做数据可视化,数据可视化是为了更形象地表达数据内在的信息和规律,促进数据信息的传播和应用。


在当前新技术支持下,数据可视化除了“可视”,还可有可交流、可互动的特点。数据可视化的本质是数据空间到图形空间的映射,是抽象数据的具象表达。

Image title


数据可视化作品《launchit》

作者:Shane Mielke 

作者写了本书,地图上显示了世界各地读者的分布情况及对应人数

Image title


数据可视化作品《world-drawn-by-travelers》

作者:TripHappy

国家之间相互连通的旅游路线,颜色越相近的国家,表明两国家的人们互动越频繁

Image title


2、什么是大屏数据可视化


大屏数据可视化是以大屏为主要展示载体的数据可视化设计。

“大面积、炫酷动效、丰富色彩”,大屏易在观感上给人留下震撼印象,便于营造某些独特氛围、打造仪式感。电商双11类大屏利用此特点打造了热烈、狂欢的节日氛围,原本看不见的数据可视化后,便能调动人的情绪、引发人的共鸣,传递企业文化和价值。

Image title

Image title


利用面积大、可展示信息多的特点,通过关键信息大屏共享的方式可方便团队讨论、决策,故大屏也常用来做数据分析监测使用。大屏数据可视化目前主要有信息展示、数据分析及监控预警三大类。


数据分析类

图片来源:必应;图片作者:帆软软件有限公司

Image title


二、大屏数据可视化设计原则:设计服务需求、先总览后细节


设计服务需求


大屏设计要避免为了展示而展示,排版布局、图表选用等应服务于业务,所以大屏设计是在充分了解业务需求的基础上进行的。那什么是业务需求呢?业务需求就是要解决的问题或达成的目标。设计师通过设计的手段帮助相关人员达成这个目标,是大屏数据可视化的价值所在。


先总览后细节


大屏因为大,承载数据多,为了避免观者迷失,大屏信息呈现要有焦点、有主次。可以通过对比,先把核心数据抛给用户,待用户理解大屏主要内容与展示逻辑后,再逐级浏览二三级内容。部分细节数据可暂时隐藏,用户需要时可通过鼠标点击等交互方式唤起。



三、大屏可视化设计流程


规范的流程是好结果的保证。找到一个可参考的流程,然后步步为营,就能避免很多不必要的返工,保证设计质量和项目进度。

Image title


1、根据业务场景抽取关键指标


关键指标是一些概括性词语,是对一组或者一系列数据的统称。一般情况下,一个指标在大屏上独占一块区域,所以通过关键指标定义,我们就知道大屏上大概会显示哪些内容以及大屏会被分为几块。以共享单车电子围栏监控系统为例,这里的关键指标有:企业停车时长、企业违停量、热点违停区域、车辆入栏率等。


确定关键指标后,根据业务需求拟定各个指标展示的优先级(主、次、辅)。

Image title



2、确立指标分析维度


“横看成岭侧成峰”。同一个指标的数据,从不同维度分析就有不同结果。很多小伙伴做完可视化设计,发现可视化图形并没有准确表达自己的意图,也没能向观者传达出应有的信息,可视化图形让人困惑或看不懂。出现这种情况很大程度就是因为分析的维度没有找准或定义的比较混乱。

Image title

上图向大家展示了数据分析常用的4个维度,我们在选定指标后,就需要跟项目组其他小伙伴讨论:我们的各个指标主要想给大家展示什么,更进一步的讲,是我们想通过可视化表达什么样的规律和信息。而上图,可以引导我们从“联系、分布、比较、构成”四个维度更有逻辑的思考这个问题。


联系:数据之间的相关性

分布:指标里的数据主要集中在什么范围、表现出怎样的规律

比较:数据之间存在何种差异、差异主要体现在哪些方面

构成:指标里的数据都由哪几部分组成、每部分占比如何


当然,上图例举的示例图表都比较传统,在大屏数据可视化中常还有另一类地理信息(常以2/3D地图、地球呈现)出现。上图虽未包含这类图形,但它提供给我们的确定数据分析维度的思路和方法是相通的,可借鉴。


3、选定可视化图表类型


当确定好分析维度后,事实上我们所能选用的图表类型也就基本确定了。接下来我们只需要从少数几个图表里筛选出最能体现我们设计意图的那个就好了。


选定图表注意事项:易理解、可实现;


易理解就是可视化设计要考虑大屏最终用户,可视化结果应该是一看就懂,不需要思考和过度理解,因而选定图表时要理性,避免为了视觉上的效果而选择一些对用户不太友好的图形。

Image title


可实现


1、我们需要了解现有数据的信息、规模、特征、联系等,然后评估数据是否能够支撑相应的可视化表现

2、我们设计的图形图表,要开发能够实现。实际工作中,一些可视化效果开发用代码写很容易实现,效果也不错,但这些效果设计师用Ps/Ai/Ae这些工具模拟时会发现比较困难;同样的,某些效果设计师用设计工具可以轻易实现,但开发要用代码落地却非常困难,所以大屏设计中跟开发常沟通非常重要,我们需要明确哪些地方设计师可以尽情发挥,哪些地方需要谨慎设计!一个项目总有周期与预算限制,不会无限期的修改迭代,所以设计师在这里需要抓住重点,有取舍,不钻牛角尖、死磕不放

Image title


4、了解物理大屏,确定设计稿尺寸

多数情况下设计稿分辨率即被投大屏的信号源电脑屏幕的分辨率有多个信号源时,就会有多个设计稿,此时每个设计稿的尺寸即对应信号源电脑屏幕的分辨率

Image title

一般情况下设计稿的分辨率就是电脑的分辨率,当有多个信号源时,有时会通过显卡自定义电脑屏幕分辨率,从而使电脑显示分辨率不等于其物理分辨率,此时,对应设计稿的分辨率也就变成了设置后的分辨率;此外,当被投电脑分辨率长宽比与大屏物理长宽比不一致时(单信号源),也会对被投电脑屏幕分辨率做自定义调整,这种情况设计稿分辨率也会发生变化。所以设计开始前了解物理大屏长宽比很重要。



5、页面布局、划分


尺寸确立后,接下来要对设计稿进行布局和页面的划分。这里的划分,主要根据我们之前定好的业务指标进行,核心业务指标安排在中间位置、占较大面积;其余的指标按优先级依次在核心指标周围展开。一般把有关联的指标让其相邻或靠近,把图表类型相近的指标放一起,这样能减少观者认知上的负担并提高信息传递的效率。

Image title


6、定义设计风格


很多小伙伴也许没接触过大屏设计工作,但大多数人都应该有APP或者Web风格定义的经验。我们在定义一款APP或者Web页面设计风格时常用的方法是什么呢?情绪版!

大屏虽酷炫,但实际上也是运行在浏览器里的Web页面,所以大屏设计风格定义方法也同样可以是用情绪版来做,这种方法也是目前比较科学的风格定义手段

Image title

上图提供了情绪版应用的脑图,具体操作细节不做介绍,不太了解的小伙伴可以自己找找资料哈。

情绪版的一套流程下来,我们定义的风格基本是科学准确的,可以指导我们执行设计。如果是给甲方爸爸做大屏,这个流程也可以让我们提出的方案更有说服力



7、可视化设计


根据定义好的设计风格与选定的图表类型进行合理的可视化设计。目前来讲大屏可视化主要有指标类信息点和地理类信息点两大可视化数据。指标类信息点可视化效果相对简单易实现,而地理类信息点一般可视化效果酷炫,但是开发相对困难,需要设计师跟开发多沟通的。地理类信息一般具有很强的空间感、丰富的粒子、流光等动效、高精度的模型和材质以及可交互实时演算等特点,所以对于被投电脑、大屏拼接器等硬件设备的性能会有要求,硬件配置不够的情况下可能出现卡顿甚至崩溃的情况,所以这点也是需要提前沟通评估的。

Image title


8、样图沟通确认


这里的沟通分三个层面:设计师对内沟通、设计师对外沟通、设计师与大屏的“沟通”。

Image title

样图沟通环节,最初的样图不需要十分精致,我们可以把它理解为一个“低保真”原型,然后通过不断沟通修改,让它逐步完善精致起来,也就是小步快跑,避免那种一下子走到终点,然后又大修大改的情况。


因为我们在前几步已经分别确定了页面布局、图表类型、页面风格特点,所以这一步我们需要用尽可能简单的方法 ,把之前几步的成果在页面上快速体现出来,然后根据样图效果尝试确定五方面内容:

1、之前确立的布局在放入设计内容后是否依然合适

2、确立的图表类型带入数据后是否仍然客观准确

3、根据关键元素、色彩、结构、质感打造出的页面风格是否基本传达出了预期的氛围和感受

4、已有的样式、数据内容、动效等在开发实现方面是否存在问题

5、大屏是否存在色差、文字内容是否清晰可见、页面是否存在变形拉伸等现象


跟大屏“沟通”是比较重要也是个特殊的环节,这也是我觉得大屏设计跟其它设计不一样的地方,大屏有它自己独特的分辨率、屏幕组成、色彩显示以及运行、展示环境,这里的很多问题只有设计稿投到大屏上才能够被发现,所以这一步在样图沟通确认环节非常重要,有时候需要开发出demo,反复测试多次。



9、页面定稿、开发


事实上页面开发阶段并不是到了这一步才进行,这里说的页面开发仅指前端样式的实现,实际上后台数据准备工作在定义好分析指标后就已经开始进行了,而我们当前的工作是把数据接入到前端,然后用设计的样式呈现出来。

Image title

切图与标注

由于大屏实际就是一个web页面,所以开发阶段的切图与标注是少不了的。


切图:哪些元素需要切图,怎么切?

一般开发用代码写不出的样式或动效,都需要设计师切图作支持:比如数据容器的边框、小的动效、页面整体大背景、部分图标等。切图按正常网页设计标准切就可以了。


标注

Web页面用什么插件做标注这个大家都很熟悉,我就不多说了。需要注意的是,如果大屏页面需要在不同比例的终端展示,那么此时的标注与开发可以使用rem作为基本单位来实现,这样实现的大屏页面在后期会有更好的扩展性与适应性。



10、整体细节调优与测试


这部分是指页面开发完成后,将真实页面投放到大屏进行的测试与优化。这里主要有两部分工作。


视觉方面的测试(有点像APP的UI走查):关键视觉元素、字体字号、页面动效、图形图表等是否按预期显示、有无变形、错位等情况。


性能与数据方面的测试:图形图表动画是否流畅、数据加载、刷新有无异常;页面长时间展示是否存在奔溃、卡死等情况;后台控制系统能否正常切换前端页面显示。



四、大屏设计的注意事项


1、字体使用


字体优先使用系统默认字体,需要嵌入字体时考虑字体的可识别性、与当前设计风格是否融合、是否可免费商用。

Image title

如果页面是云端部署,需要嵌入字体包时,我们可以使用FontCreator这类的软件把那些用不到的字符从字体包中删掉,然后重新打包上传,减小字体包大小,可以优化页面加载体验,避免在替换默认字体的过程中出现页面文字跳动等现象。(一般来讲一套字体文件包含了阿拉伯文、符号、拉丁文、日文、西里尔文、希腊文、拼音、注音符号等多种字符,对于大屏这个明确的场景,我们可以删掉其它使用不到的字符,仅保留中文、拼音和数字)

Image title

关于字体版权获取相关问题,公众号回复“可视化”获取



2、颜色搭配


 1、色彩明度与饱和度差异显著、对比鲜明, 尽量避免使用邻近色配色

Image title

2、使用深色暗色背景:深色暗色背景可减少拼缝带来的不适感。由于背景面积大,使用暗色背景还能够减少屏幕色差对整体表现的影响;同时暗色背景更能聚焦视觉,也方便突出内容、做出一些流光、粒子等酷炫的效果,


3、渐变色慎重使用:大屏普遍色域有偏差,显示偏色,因而使用渐变色需要根据大屏反馈确定是否调整,纯色最佳。



3、页面布局

主次分明、条理清晰、注意留白,合理利用大屏上各小的显示单元,并尽量避免关键数据被拼缝分割

Image title



五、Q&A


1、设计稿投到大屏上显示效果不佳怎么办?

大屏的分辨率、比例、使用环境、投射方式等均会对设计造成影响。理想情况下,我们应该在设计开始前,就能打开大屏系统做一些简单测试。我们可以从网上收集不同设计师不同风格的大屏设计作品,然后投上去查看实际效果。因为大多数时候大屏都会存在色彩偏差,这时通过测试我们就能发现渐变色、邻近色等不同类型的色彩搭配是否可以在目标大屏上良好呈现,如果不可以,那我们设计进行时就不要使用显示效果不佳的色彩搭配。另一方面,样图沟通环节及时测试也很重要。



2、大屏设计定稿后,切图切几倍图?

由于是将我们电脑屏幕投射到了大屏,大屏上的内容是运行在我们电脑浏览器上的页面。所以切图根据我们电脑的分辨率,正常切1倍图就可以



3、1920*1080的设计稿,投到9000*4320的屏幕上,文字图片会发虚么?

看情况,视大屏系统硬件规格与观看距离来定。这块有四个概念需要跟大家交流下。

大屏逻辑分辨率(设计稿尺寸)——显卡输出分辨率——视频矩阵切换器(DVI)支持分辨率——大屏实际物理分辨率。


一般后两个是没问题的,大屏跟矩阵切换器是由大屏厂商提供,一般刚好配套大屏。容易问题的是显卡输出分辨率,我们电脑屏幕分辨率并不是最终显卡传递到DVI接口的分辨率,传递到DVI接口的分辨率是电脑显卡所能输出的最大分辨率(部分电脑可设置或自定义输出分辨率)。输出分辨率等于DVI支持分辨率时显示效果最佳。输出分辨率低于DVI支持分辨率,DVI会将信号放大后传递到大屏,放大的过程中就有图像信息丢失,虽然此过程中有各种算法支持去保证图像尽可能清晰,但算法再好,跟真实图形还是有差距的。此外,多信号源投射效果优于单个信号源投射。对于现场直播数据大屏,一般至少有两个信号源,一个投屏,另一个也投屏但是处于备用状态。


离大屏的距离也影响观感,一般离得近,颗粒感明显,距离稍远,会显的较为清晰



4、设计稿完成开发后,发现在大屏上页面有被拉伸或者压缩的情况,怎么补救?

一般来讲,开发只需要对设计图做还原即可。但特殊情况下,比如显示器扩展不正确导致页面被拉伸或压缩,这时就需做处理:我们可以先得到被拉伸/压缩的比例,然后对整体视图做压缩/拉伸处理,再由其拉伸/压缩,这样被拉伸/压缩的瑕疵就可以得到一定程度上的矫正。另外,了解被投电脑硬件特点,有的电脑可以通过自定义分辨率解决这部分问题。



5、除自行开发可视化大屏外,还可以通过哪些第三方服务来快速实现?

阿里云DataV、腾讯云图、百度Sugar等



6、数据可视化的图表样式可以在那些地方找到参考?

图表部分的二个库是我们设计师可以打开浏览产看的,这里面所有的图表样式都是基于代码实现的,可以作为我们设计图表的参考,也可以让开发拿代码去用,或者在这些图表的基础修改

工具类的需要有一定的代码基础,里面同样有丰富的图表,所以跟开发的沟通也很重要,因为他们可能会了解多一些更新的前沿的图表形式是我们设计师不知道的,所以彼此多沟通交流是在太重要了

Image title


总结:数据可视化是一门庞大系统的科学,本文所有讨论仅针对大屏数据可视化这一特定领域,管中窥豹,如有遗漏或不足之处欢迎大家讨论交流

转自UI中国-BYMD


日历

链接

blogger

蓝蓝 http://www.lanlanwork.com

存档