首页

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

资深UI设计者

在第一篇 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

大屏数据可视化设计指南

ui设计分享达人

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

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


交互设计师常用的设计理论与心理学

ui设计分享达人

掌握好常用的设计理论与心理学知识,能帮助我们对用户的人性特征的拿捏,帮助我们较大的影响用户底层决策,以产品实现业务目标。

一、尼尔森10大可用性原则


1、状态可见原则

不局限于:用户的当前状态、知道当前任务要做什么、任务进度等。

2、环境贴切原则

设计要复合目标用户的认知,符合用户的心智模型,于是熟悉的事物越容易被用户所接受。

3、撤销重做原则

操作前可预知,操作中有反馈、操作后可撤销。

4、一致性原则

不局限于:业内产品的一致性、产品内的一致性、版本迭代间的一致性

5、防错原则

错误行动发生前,引导用户向正确的方向前进;用户触碰到危险操作时给予提示;危险操作发生之后,提供撤回的入口。

6、易取原则

通过使用对象、动作和选项的可视化表达,最大限度地减轻用户的记忆负担。

记住用户的操作记录、一个流程对应一个操作目标、提供适量的信息、选择而不是输入。

7、灵活原则

好的产品需要同时兼顾新用户和资深用户的需求。对新用户来说,需要功能明确、清晰,对于老用户需要快捷使用高频功能。不可迎合某一种用户,把不必要的信息占据重要部分。

8、易扫(读)原则

不要包含不相关或低频次的信息/操作。页面中的每个额外信息都会降低主要内容的相对可见性。

产品设计的四大基本原则:亲密性、对齐、重复、对比。

9、容错原则

错误信息应该用通俗易懂的语言表达,较准确地指出问题,并且提出解决方案。避免通过代码等用户难以理解的形式

即:提供解决方案、帮助用户从错误中恢复

10、人性化帮助

如果系统能让用户不需要阅读文档就会使用那是最好的,但通常情况下还是需要帮助文档的。任何信息应该容易被搜索,且专注于用户的目标任务,并列出具体的步骤来告知用户。


二、费茨定律

翻译成人话就是:

1. 按钮做大点(W大点)更易于点击

2. 将按钮放置在离开始点较近的地方

3. 相关按钮之间距离近点(D小点)更易于点击

4. 屏幕的四角与四边是「无限可选中」位置(非移动端)

5. 通过费茨定律的反向使用,可以降低按钮被点击的可能


三、米勒定律


米勒定律预测人的工作记忆能够记住的项为7(±2)个。1956年认知心理学家乔治·米勒发表了一篇论文,他讨论了短期记忆和记忆跨度的极限。

不要乱用 “神奇的7” 为设计进行不必要的限制;

将内容整理为较小的单元,以便用户轻松地处理、理解和记忆。


比如电话号码的显示方式、银行卡的显示方式等


四、接近法则


观察者看到彼此邻近(空间或时间)的物体时,会将它们视为一个整体。

在界面设计中,对信息的组织已经离不开这个法则了,他在界面中所体现的就是把相关的信息块组合在一起,不太相关的分离开,增强与区分元素之间的关联性,所强调的是空间和位置。

接近法则产生于群组,它可以减少信息设计的复杂性,对引导用户的视觉流、便于用户对界面的解读起到至关重要的作用。


五、席克定律


希克定律是一种心理物理学定律。用户所面临的选择数量越多,做出选择所花费的时间就越长,在人机交互的界面中选项越多,意味着用户做出决策的时间越长。


六、泰斯勒定律(复杂性守恒定律)


泰斯勒定律又称复杂性守恒定律,该定律认为每一个过程都有其固有的复杂性,这个复杂性存在一个临界点,超过了这个点就不能再简化了,你只能将固有的复杂性从一个地方移动到另外一个地方。


七、奥卡姆剃刀原理


奥卡姆剃刀原理的核心思想为:“切勿浪费较多东西去做用较少东西同样可以做好的事——如无必要,勿增实体,即简单有效原理”。


八、防错原则


操作前有提示,操作中有反馈、操作后可撤销。


九、损失厌恶


损失厌恶是指人们面对同样数量的收益和损失时,认为损失更加令他们难以忍受。同量的损失带来的负效用为同量收益的正效用的2.5倍。损失厌恶反映了人们的风险偏好并不是一致的,当涉及的是收益时,人们表现为风险厌恶;当涉及的是损失时,人们则表现为风险寻求。


十、安慰剂效应


“安慰剂效应”指的是,对于某种无效的疗法或干预手段,仅仅是“相信它有效”,就能改善健康,并能改变认知


十一、多尔蒂门槛


研究结果表明,计算机的响应速度直接影响了使用者做出下一个决定所要花费的时间(这个时间被称为用户响应时间),换句话说,计算机相应的时间越长,用户就要花费越多的时间来思考和决定下一步的操作。


合理的操作响应时长、方式有助于用户保持专注和提率。

软件操作的过度动画时间不宜太短或太长,最常见于 400ms 左右。

如果无法避免操作中较长读取、等待时间,那么就用其他更有趣的动画、页面来减少用户的焦虑感。


十二、马斯洛需求层次理论


马斯洛需求层次理论是人本主义科学的理论之一,由美国心理学家亚伯拉罕•马斯洛在1943年在《人类动机理论》论文中所提出。书中将人类需求像阶梯一样从低到高按层次分为五种,从低到高依次是:生理需求、安全需求、社交需求、尊重需求和自我实现需求。

但最终马斯洛添加求知需求和审美需求,自此马斯洛需求层次理论最终定型为8层。

十三、格式塔心理学


格式塔原则描述了当某些条款和条件被应用时,人类大脑如何感知视觉成分。它帮助大脑创造视觉的意象。因此,格式塔原则基于六个主要类别:

位置和位置;

接近;

对称与秩序;

类似;

关闭;

连续性。


十四、自我参照效应


第一种是精细加工说:在记忆过程中,这些事物在头脑中被进行了精细加工,与头脑中的已有知识之间建立了更多的联系,因此回忆时的提示线索更多,回忆效果更好。

第二种是组织加工说:于自我的知识是头脑中存在的一种结构良好的组织体系,它对与自己相关的事物有更好的固着作用;同时,由于自我知识常常被激活,因此与之相关的信息也更容易被相应地激活起来,这样回忆起来也就更容易。

第三种是双过程说:即自我参照任务能提高记忆的机制既包括精细加工因素,也有组织作用的参与

广告商会挖空心思的建立商品和你的关联,告知我们如果你购买了我的商品,你就会获得怎样的好处。而自媒体人则在标题上尽量简明扼要的说明,我要说的事情和你密切相关,不看就亏了。所以,稍微有深度的文章在快餐式的自媒体平台中反而阅读量不高,这是因为文章标题所涵盖的内容可能只和少部分人有关。


十五、上瘾模型


1、触发:提醒人们采取下一步行动


触发分为外部触发与内部触发

外部触发又分为:

付费型触发、回馈型触发、人际型触发、自主型触发。

内部触发

内部触发通过用户记忆存储中的各种关联来提醒他们采取下一步行动。

比如饿了的时候想起饿了么,想健身的时候想起keep


2、行动:人们在期待酬赏时的直接反应


福格行为模型可以用公式来呈现,即B=MAT。B代表行为,M代表动机,A代表能力,T代表触发。要想使人们完成特定的行为,动机、能力、触发这三样缺一不可。 否则,人们将无法跨过“行动线”,也就是说,不会实施某种行为。

比如说中午十一点你饿了想到饿了么订餐但是由于你的手机没电了定不了餐,中午要吃饭是动机,订餐想到叫饿了么外卖是触发,能够用手机订餐是能力,但是因为手机没有电 你就缺乏了相应的能力所以这个行为就没法完成。(当然你也能用朋友的手机订餐,这里只是举个例子)


福格总结了简洁性所包含的6个元素 ,即影响任务难易程度的6个要素,它们是:


  • 时间——完成这项活动所需的时间。

  • 金钱——从事这项活动所需的经济投入。

  • 体力——完成这项活动所需消耗的体力。

  • 脑力——从事这项活动所需消耗的脑力。

  • 社会偏差——他人对该项活动的接受度。

  • 非常规性——按照福格的定义,“该项活动与常规活动之间的匹配程度或矛盾程度”。


四种非常规的效应刺激动机:


  • 稀缺效应:(限量1000件)

  • 环境效应:(同一款啤酒在便利店和高档就把价格不一,但人们愿意为价格买单)

  • 锚定效应:(瑞幸咖啡定价24元的拿铁对标星巴克的32元拿铁)

  • 赠券效应:(利益进度吸引用户动机)


3多变的酬赏:满足用户的需求,激发使用欲


多变性会使大脑中的伏隔核更加活跃,并且会提升神经传递素多巴胺的含量,促使我们对酬赏产生迫切的渴望。 研究测试表明,当赌博者赢了钱,或是异性恋男性看到美女的图片时,大脑伏隔核中的多巴胺含量会上升。

多变的酬赏主要表现为三种形式:社交酬赏、猎物酬赏、自我酬赏。那些让我们欲罢不能的习惯养成类产品或多或少都利用了这几类酬赏。


社交酬赏

所谓社交酬赏,是指人们从产品中通过与他人的互动而获取的人际奖励。比如微信的点赞评论、站酷的推荐,用户能够获得社交的认同。


猎物酬赏

猎物酬赏,是指人们从产品中获得的具体资源或信息。


自我酬赏

所谓自我酬赏,是指人们从产品中体验到的操控感、成就感和终结感。


4、投入:通过用户对产品的投入,培养忠实用户


要想让用户产生心理联想并自动采取行动,首先必须让他们对产品有所投入。


用户对某件产品或某项服务投入的时间和精力越多,对该产品或服务就越重视。事实上,有充分证据表明,用户投入的多寡与其热爱某项事物的程度成正比。


1、文饰效应心理


(1)我们总是高估自己的劳动成果。

(2)我们总是尽力和过去保持行为一致。

(3)我们总是避免认知失调。


2、点滴投入


(1)储存价值

(2)内容

(3)数据资料

(4)关注者

(5)信誉

(6)技能


3、加载下一个触发


用户投入的同时也可以通过加载下一个触发的令自己重新开始上瘾循环,从而增加了进入上瘾循环的可能性。


十六、雅各布定律


雅各布定律(简称雅各布互联网用户体验法则),它指出如果用户已将大部分时间花费在某个网站上,那么他们会希望你的网站可以与那些他们已熟悉的网站一样拥有相似的使用模式。


我们在与新事物互动的过程中,用户使用的是以往的经验


对设计师来说,我们可以匹配用户的心智模型来改善体验。因此,用户可以轻松地将已有经验从一种产品或体验转移到另一种上,无需额外了解新系统的工作原理。

当设计师与用户的心智模型一致时,良好的用户体验就得以实现。


十七、KANO模型


KANO模型大家可以看看这个童鞋的总结很详细

https://www.zcool.com.cn/article/ZMTAyMjQ3Mg==.html


十八、古藤堡表图表法


人们在浏览页面或布局时视线趋于从左上角移动到右下角

古腾堡图表法说明我们观看页面的视线并不是镜面对称的,我们需要在设计中避免出现此类错误但绝不是墨守成规,将页面的 Logo放置在左上角而主体向右下角延伸,左下和右上作为视觉的盲点可以添加辅助元素


十九、尼尔森F型视觉模型


尼尔森F型视觉模型由 Jakob Nielsen于2006年提出

他指出,我们在第一次观看页面时,视线会呈 F的形状关注页面。
1.先从顶部开始从左到右水平移动。
2.目光再下移开始从左到右观察但是长度会相对短些。
3.以较短的长度向下扫视,形成一个 F形状,此时我们的阅读速度较慢,更为系统和条理性。


二十、序列效应


1.在列举信息时,排在最前和最后的元素,比排在中间的更容易让人记住。

2.对排在开头的信息产生加强的回想效果,称为:初始效应,人们有时候会把最前面的信息储存在长期记忆中。排在结尾的信息产生加强的回想效果,称为:时近效应。时近效应适用于听觉刺激。初始效应适用于视觉刺激。

3.在列举信息元素时,如果列举信息属于视觉性,那么把重要的信息放在最前面;如果是听觉性,就放在最后面。如果是用户必须做决定,并且是最后一项出现后马上做决定,那么就将想要用户做决定的信息放置最后,以便增加获选概率,否则放在最前面。

4. 应用例子:比如在很多app产品设计时,个人账户与设置基本放在页面的最前面和最后面,这体现着产品信息的序列关系,重要次序,所以在进行设计时,可以在信息排序上遵循序列效应。 当然还有一些产品想对用户进行引导操作,也可以利用这个法则,将信息放置最前或最后。

转自:站酷-YELLOW_J 

啥?你说我不懂如何设计消息中心?

ui设计分享达人

消息中心设计样式的简单汇总

作为APP标配的消息中心,我们无时无刻不在与其打交道,看似千篇一律的设计实际上其中也有许多值得我们深入探讨的内容,今天我们一起从消息中心页入口出发,一层一层剥开它的秘密。


全文分为五个部分:

一、消息中心页入口位置

二、消息中心页常见的组成模块

三、消息中心页分类导航方式的选择

四、消息列表的呈现形式

五、划重点


一、消息中心页入口位置


消息中心页是应用内系统发送给用户的各种信息的一个集合页面,它的本质是与用户互动沟通。也就是说,产品越是需要与用户进行沟通,消息中心的重要程度也就越高。


一般情况下,不同类型的APP消息中心的重要程度为:社交通讯类>电商类>资讯类>工具类


而消息中心页的入口位置正好侧面反映了其在产品中的重要程度。


1.底部导航栏

消息中心页入口位置放在底部导航栏,属于一级导航,重要程度很高,常见于即时通讯、社交社群类产品,如下图:

即时通讯类的QQ,核心业务就是通讯交流,消息页入口不仅放在底部导航栏,且做为APP的首页。而微博作为最早的社群内容类产品,社交沟通需求也很高,固将消息中心入口放置在底部导航栏。


当然也不是只有社交通讯类产品会选择该位置作为消息中心的入口,如下图淘宝和小红书也将消息中心入口放置在底部导航栏。

淘宝本是电商类产品,消息入口放置在底部导航栏,结合官方号、内容号、小黑群等功能,我的理解是淘宝是想通过社交沟通促使用户更多的购物。


小红书主打生活内容分享,辅助电商购物,是现在比较常见的某个核心业务+社交的产品,这类产品可根据自身一级导航类别的多少决定是否将消息中心入口放置在底部导航栏。


2.顶部导航栏

消息中心页入口放置在顶部导航栏,重要程度根据入口跟随页面的多少分成两种情况:


1)几乎每页跟随,重要程度较高

京东和豆瓣几乎是每个一级页面的顶部都有消息页入口图标,京东甚至在一些二级页面也还保留了顶部消息入口,方便用户随时查看。


2)仅在动态页、首页或个人中心顶部有入口,重要程度较低

如上图所示,爱奇艺的消息入口仅出现在泡泡页面的顶部,KEEP的消息入口在个人中心页的顶部,二者都只有一个入口。


3.个人中心页

消息中心页入口放置在个人中心页除顶部外的区域,重要程度一般,某些APP会在个人中心消息入口直接对其分类展示,用户能快速地到达想去的消息分类。

波洞的消息中心入口在个人中心页就分好了类别,用户点击进入对应的类别,消息页内部没有做类别的划分,相比放一个消息图标入口在个人中心顶部,更加直观。


入口不一定只有一个,三种情况混合使用也是可以的,重点是方便用户,引导用户。即便入口位置本身不显眼,加上红点数字后一样会被用户看到的。



二、消息中心页常见的组成模块


消息中心页的主要组成模块有:分类消息导航、消息列表;辅助组成模块有:搜索区、全部已读、消息设置、通讯录等。


1.主要的组成模块

消息中心的主要组成模块中消息列表是必不可少的(有些在下一级界面中),分类消息导航根据消息类别的多少不一定都有。


前文对消息中心的定义说过:消息中心页是应用内系统发送给用户的各种信息的一个集合页面。集合页面意味着消息本身被划分成了各种类型,这时候适合的分类消息导航能帮助用户快速找到需要的信息。


消息列表引导用户进入消息详情页,做为整个消息中心的核心,需要设计师根据产品需求尽可能多的考虑到囊括的信息类型,从而选择合适的消息列表呈现形式。


在第三部分中会着重介绍4种不同的分类消息导航,第四部分介绍3种不同的消息内容呈现形式。


2.辅助组成模块

所谓辅助的组成模块,就是不一定所有消息中心都有的,要结合产品实际情况增减。主要包括搜索区、全部已读、消息设置、通讯录等。

上图中微博的消息中心基本包括了所有的辅助组成模块,用户可以收发消息,设置消息,搜索消息,形成了针对消息功能的一个闭环。像微博这种消息功能重要,类别多,有社交属性的产品加入这些辅助功能是合适的,但不适合所有产品。


1)搜索区

用来在消息中心页搜索消息、联系人、群聊等的,仅适合消息中心页用户之间互动频繁的产品,如即时通讯类、聊天频繁的社群类产品。搜索区是全局搜索的根据产品自身性能选择加入。


2)全部已读/一键清除

对于用户体量不算大,消息沟通还不太频繁的产品可以不加。但对于消息沟通频繁的产品,不加的话,可能会逼死强迫症......


3)消息设置

用来设置消息提醒方式或屏蔽消息推送,大部分产品会将此功能放入设置中避免用户关闭消息推送,放在消息中心虽可增加用户体验,但也方便了用户直接屏蔽消息。


4)通讯录/发起聊天

常见在有好友通讯录体系或关注粉丝体系的产品中。



三、消息中心页分类导航方式的选择


消息中心分类导航方式主要有四种:顶部固定图标导航、顶部Tab导航、列表导航、顶部Tab混合导航,接下来通过分析它们各自的优缺点帮助你选择合适的消息中心分类导航方式。


1.顶部固定图标导航

顶部固定展示重要的3~5个消息类别,消息列表按照发送的时间顺序依次展示。

优点:可以突出重点消息类别。


缺点:类别切换不方便,需要返回上一级重新进入;超过5个类别后,其他类别只能归入消息列表中。


2.顶部Tab导航

顶部纯文字标签Tab导航,消息类别以标签的形式出现,可左右切换。

优点:切换方便,类别可拓展性强,占据空间小,为消息列表留出更多的空间,纯文字标签设计所需时间成本小。


缺点:分类标签不要超过9个,过多的标签用户切换到后面的成本较高,容易被忽略。


3.列表导航

消息中心列表导航有分类列表导航和混合列表导航两种形式。


1)分类列表导航

分类列表导航将不同的消息类别按照icon+文字的形式从上至下展示,左侧是消息类别,右侧是消息未读红点提醒,每一个列表对应进入一种消息类别。

优点:类别可拓展性强,分类清晰,设计简洁明了,适合轻量、极简风的消息中心页。


缺点:到达具体消息内容的路径较长,不适合复杂的消息中心页。


2)混合列表导航

消息列表与消息类别混合,按照消息发布时间顺序以列表形式展示,常见于重社交、即时通讯类产品。

优点:可拓展性极强,能容纳各种类别的消息。


缺点:消息内容太多后查找麻烦,需要配合搜索区使用,易产生阅读疲劳。


4.顶部Tab混合导航

顶部Tab混合导航,进一步对消息类别细致划分,一级Tab标签一般会划分为两部分:通知及消息/私信,通知一般是产品发送的一些系统消息或推送,消息一般是用户与用户之间的互动消息(包括官方号的信息),私信主要是有关注粉丝体系的产品的分类。二级内容根据需要选择进一步分类导航,如下图:

优点:将消息做了更细致的划分


缺点:有二级分类的页面占的空间大,消息列表展示空间少。



四、消息列表的呈现形式


消息列表是消息中心的核心,我们需要根据内容类型的不同选择合适的呈现形式,便于用户理解。主要的呈现形式有3种,分别是:icon/头像+缩略内容列表、图文列表、纯文字列表。


1.icon/头像+缩略内容列表

最常见的一种消息列表,以icon或头像+缩略内容的形式展示,符合从左到右的浏览习惯,能承载多种类型的消息,包括对话聊天类、订阅号、官方活动、系统通知等等,需要引入下一级页面展示消息详情。适合大部分的产品。


2.图文列表

消息列表采用图文形式,对用户更具吸引力,一般用在消息类别比较单一的消息中心。常见的有上图下文卡片(大图)和左图右文的展现形式。需要注意的是上图下文(大图)的展现形式对图片质量要求较高。常用在活动消息、资讯消息。


3.纯文字列表

消息列表以纯文字形式展示,形式较单一,能展示较多的文字信息,常见于通知消息。



五、划重点


本文主要通过消息入口位置、消息中心页组成、消息中心页分类导航选择、消息列表呈现形式介绍了消息中心页的设计。


消息中心页入口:底部导航栏、顶部导航栏、个人中心页


消息中心页组成模块:分类消息导航、消息列表;、搜索区、全部已读、消息设置、通讯录。


消息中心页分类导航:顶部固定图标导航、顶部Tab导航、列表导航、顶部Tab混合导航。


消息列表的呈现形成:icon/头像+缩略内容列表、图文列表、纯文字列表。

转自:站酷-人類君 

小程序入门到精通:了解小程序开发4个重要文件

前端达人

点击查看原图


1. 小程序没有DOM对象,一切基于组件化

2. 小程序的四个重要的文件

  • *.js —> view逻辑 —> javascript
  • *.wxml —> view结构 ----> html
  • *.wxss —> view样式 -----> css
  • *. json ----> view 数据 -----> json文件

注意:为了方便开发者减少配置项,描述页面的四个文件必须具有相同的路径与文件名。

2.1 WXML

WXML(WeiXin Markup Language)是框架设计的一套标签语言,结合基础组件事件系统,可以构建出页面的结构。WXML 充当的就是类似 HTML 的角色
要完整了解 WXML 语法,请参考WXML 语法参考

2.2 WXSS

WXSS (WeiXin Style Sheets)是一套样式语言,用于描述 WXML 的组件样式。

WXSS 用来决定 WXML 的组件应该怎么显示。

为了适应广大的前端开发者,WXSS 具有 CSS 大部分特性。同时为了更适合开发微信小程序,WXSS 对 CSS 进行了扩充以及修改。

与 CSS 相比,WXSS 扩展的特性有:



尺寸单位

样式导入

2.3 json

JSON 是一种数据格式,并不是编程语言,在小程序中,JSON扮演的静态配置的角色。



全局配置

小程序根目录下的 app.json 文件用来对微信小程序进行全局配置,决定页面文件的路径、窗口表现、设置网络超时时间、设置多 tab 等。



页面配置

每一个小程序页面也可以使用同名 .json 文件来对本页面的窗口表现进行配置,页面中配置项会覆盖 app.json 的 window 中相同的配置项。



工具配置 project.config.json

通常大家在使用一个工具的时候,都会针对各自喜好做一些个性化配置,例如界面颜色、编译配置等等,当你换了另外一台电脑重新安装工具的时候,你还要重新配置。

考虑到这点,小程序开发者工具在每个项目的根目录都会生成一个 project.config.json,你在工具上做的任何配置都会写入到这个文件,当你重新安装工具或者换电脑工作时,你只要载入同一个项目的代码包,开发者工具就自动

注意:

JSON文件都是被包裹在一个大括号中 {},通过key-value的方式来表达数据。JSON的Key必须包裹在一个双引号中,在实践中,编写 JSON 的时候,忘了给 Key 值加双引号或者是把双引号写成单引号是常见错误。

JSON的值只能是以下几种数据格式,其他任何格式都会触发报错,例如 JavaScript 中的 undefined。



数字,包含浮点数和整数

字符串,需要包裹在双引号中

Bool值,true 或者 false

数组,需要包裹在方括号中 []

对象,需要包裹在大括号中 {}

Null

还需要注意的是 JSON 文件中无法使用注释,试图添加注释将会引发报错。


2.4 js

一个服务仅仅只有界面展示是不够的,还需要和用户做交互:响应用户的点击、获取用户的位置等等。在小程序里边,我们就通过编写 JS 脚本文件来处理用户的操作。


注册页面

对于小程序中的每个页面,都需要在页面对应的 js 文件中进行注册,指定页面的初始数据、生命周期回调、事件处理函数等



使用 Page 构造器注册页面

简单的页面可以使用 Page() 进行构造。



使用 Component 构造器构造页面

Page 构造器适用于简单的页面。但对于复杂的页面, Page 构造器可能并不好用。

此时,可以使用 Component 构造器来构造页面。 Component 构造器的主要区别是:方法需要放在 methods: { } 里面。

————————————————

版权声明:本文为CSDN博主「前端岚枫」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/yilanyoumeng3/java/article/details/106292742





2020年,令人惊叹的Echarts!

前端达人

点击查看原图


1.可视化面板介绍

应对现在数据可视化的趋势,越来越多企业需要在很多场景(营销数据,生产数据,用户数据)下使用,可视化图表来展示体现数据,让数据更加直观,数据特点更加突出。

01-技术要点

  1. div + css 布局
  2. flex 布局
  3. Less
  4. 原生js + jquery 使用
  5. rem适配
  6. echarts基础

02-案例适配方案

  1. 设计稿是1920px
  2. flexible.js 把屏幕分为 24 等份
  3. cssrem 插件的基准值是 80px
    插件-配置按钮—配置扩展设置–Root Font Size 里面 设置。
    但是别忘记重启vscode软件保证生效


03-页面主体布局

  1. header布局
  2. mainbox布局
  3. 公共面板模块 panel
  4. 柱形图 bar
因为我们今天的主题是echarts部分所以前面的这些,我就为大家写好框架,里面的布局相信以大家的能力都是分分钟解决的事情。


2.Echarts(重点)

echarts介绍

常见的数据可视化库:

D3.js 目前 Web 端评价最高的 Javascript 可视化工具库(入手难)
ECharts.js 百度出品的一个开源 Javascript 数据可视化库
Highcharts.js 国外的前端数据可视化库,非商用免费,被许多国外大公司所使用
AntV 蚂蚁金服全新一代数据可视化解决方案 等等
Highcharts 和 Echarts 就像是 Office 和 WPS 的关系

ECharts,一个使用 JavaScript 实现的开源可视化库,可以流畅的运行在 PC 和移动设备上,兼容当前绝大部分浏览器(IE8/9/10/11,Chrome,Firefox,Safari等),底层依赖矢量图形库 ZRender,提供直观,交互丰富,可高度个性化定制的数据可视化图表。

官网地址:https://www.echartsjs.com/zh/index.html

echarts体验
下载echarts https://github.com/apache/incubator-echarts/tree/4.5.0

使用步骤(5大步骤):
1.引入echarts 插件文件到html页面中
2.准备一个具备大小的DOM容器

<div id="main" style="width: 600px;height:400px;"></div>

3.初始化echarts实例对象

var myChart = echarts.init(document.getElementById('main'));

4.指定配置项和数据(option)

var option = {
    xAxis: {
        type: 'category',
        data: ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun']
    },
    yAxis: {
        type: 'value'
    },
    series: [{
        data: [820, 932, 901, 934, 1290, 1330, 1320],
        type: 'line'
    }]
};

5.将配置项设置给echarts实例对象


myChart.setOption(option);  


echarts基础配置

这是要求同学们知道以下配置每个模块的主要作用干什么的就可以了

series

系列列表。每个系列通过 type 决定自己的图表类型

大白话:图标数据,指定什么类型的图标,可以多个图表重叠。

xAxis:直角坐标系 grid 中的 x 轴

boundaryGap: 坐标轴两边留白策略 true,这时候刻度只是作为分隔线,标签和数据点都会在两个刻度之间的带(band)中间。

yAxis:直角坐标系 grid 中的 y 轴

grid:直角坐标系内绘图网格。

title:标题组件

tooltip:提示框组件

legend:图例组件

color:调色盘颜色列表

数据堆叠,同个类目轴上系列配置相同的stack值后 后一个系列的值会在前一个系列的值上相加。



option = {

    // color设置我们线条的颜色 注意后面是个数组

    color: ['pink', 'red', 'green', 'skyblue'],

    // 设置图表的标题

    title: {

        text: '折线图堆叠123'

    },

    // 图表的提示框组件 

    tooltip: {

        // 触发方式

        trigger: 'axis'

    },

    // 图例组件

    legend: {

       // series里面有了 name值则 legend里面的data可以删掉

    },

    // 网格配置  grid可以控制线形图 柱状图 图表大小

    grid: {

        left: '3%',

        right: '4%',

        bottom: '3%',

        // 是否显示刻度标签 如果是true 就显示 否则反之

        containLabel: true

    },

    // 工具箱组件  可以另存为图片等功能

    toolbox: {

        feature: {

            saveAsImage: {}

        }

    },

    // 设置x轴的相关配置

    xAxis: {

        type: 'category',

        // 是否让我们的线条和坐标轴有缝隙

        boundaryGap: false,

        data: ['星期一', '周二', '周三', '周四', '周五', '周六', '周日']

    },

     // 设置y轴的相关配置

    yAxis: {

        type: 'value'

    },

    // 系列图表配置 它决定着显示那种类型的图表

    series: [

        {

            name: '邮件营销',

            type: 'line',

           

            data: [120, 132, 101, 134, 90, 230, 210]

        },

        {

            name: '联盟广告',

            type: 'line',



            data: [220, 182, 191, 234, 290, 330, 310]

        },

        {

            name: '视频广告',

            type: 'line',

          

            data: [150, 232, 201, 154, 190, 330, 410]

        },

        {

            name: '直接访问',

            type: 'line',

          

            data: [320, 332, 301, 334, 390, 330, 320]

        }

    ]

};



3.Echarts快速使用

1.官网实例

点击查看原图



官网默认为我们提供了大量的案例,我们需要使用那一种只需要直接点击打开后复制他们的相关配置,然后按照我上面说的5大步骤进行使用即可。

2.社区Gallery

点击查看原图



官方自带的图例,可能在很多时候并不能满足我们的需要,在社区这里可以找到一些基于echart的高度定制好的图表,相当于基于jquery开发的插件,这里是基于echarts开发的第三方的图表。

本案例中使用了地图模拟飞行的案例就是从社区中进行引用的,
参考社区的例子:https://gallery.echartsjs.com/editor.html?c=x0-ExSkZDM (模拟飞机航线)
实现步骤:

第一需要下载china.js提供中国地图的js文件
第二个因为里面代码比较多,我们新建一个新的js文件 myMap.js 引入
使用社区提供的配置即可。
代码已经上传至我的码云如有需要的小伙伴可自行下载:
https://gitee.com/jiuyueqi/echarts

ps:最后呢,如果大家看完楼主的文章觉得对echarts的学习和了解有所帮助,麻烦大家路过点个赞点个关注呗!楼主后续还会继续更新有关前端方面的面试题资料或者其他方面的知识。
————————————————
版权声明:本文为CSDN博主「程序猿玖月柒」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_45257157/java/article/details/106300587

日历

链接

个人资料

蓝蓝设计的小编 http://www.lanlanwork.com

存档