移动端搜索功能设计:3个阶段解析搜索流程设计要点
如果您想订阅本博客内容,每天自动发到您的邮箱中, 请点这里
这篇文章笔者想和大家聊一聊有关搜索功能的设计,搜索功能是每个内容型APP的核心,它的易用性决定了用户是否能从APP里快速找到自己想找的内容,那么决定搜索体验好坏的关键点又是什么呢?这里我总结了两点,“操作的易用性”和“结果的准确性”。看似简单的两点却有很多的学问,笔者把搜索的交互流程划分成三个关键阶段,“搜索前、搜索中及搜索后”,接下来将从这三个阶段逐一分析整个搜索流程中的相关设计。
在不同的APP或者不同的场景下搜索入口有着不同的表现形式,具体的表现形式取决于产品对搜索功能权重的定义,如果说在某一场景下搜索功能是用户常用的核心功能那么他在界面上所表现出来的权重就要高些,反之则低些。下图是常见的搜索功能的入口形式,他们的权重从左到右依次降低,笔者将对他们一一进行分析
如下图APP Store的搜索形式,搜索放在标签栏上作为一个独立的功能模块,它的功能层级是最高的。不管用户操作到哪里都可以随时进入搜索页面,这样的搜索入口通常用在搜索场景非常多的内容型APP上,方便用户在任何时候快速进入搜索页面。
如下图是京东app的搜索入口,它将搜索框外漏在nav bar上,这样的形式有着两个设计的关键点:
关键点一:搜索框外漏在顶部导航条上
搜索框直接外漏在导航条上是为了突显该功能,这一功能往往是用户在该页面非常核心的操作任务,类似天猫京东这类电商型app,通常情况下用户都是带着明确目的来购买东西的,那么他们采取的最快最直接的方式就是搜索。
关键点二:在向上滚动界面时,搜索框一直悬停在顶部
这样做的场景是这样的,在用户滚动页面寻找内容时,可能并不能找到自己想要的内容,搜索框一直悬停一是为了暗示用户可以进行搜索,二是为了让用户在想搜索时快速触发搜索
如下图是微信在聊天页面和通讯录页面的搜索入口,初始化状态时聊天页面的搜索框是不出现在用户的可视范围内的,当页面下滑时搜索框才出现,而在通讯录页面里搜索框是默认出现在用户的可视范围内的。
分析:微信在最近联系人和通讯录上搜索框的默认状态不同,这很好地诠释了这两种场景下的搜索功能的权重。最近联系人页面上的搜索入口显得更加隐蔽,因为在这个页面下用户产生搜索的场景很少,把其隐藏简化了界面的元素,提升了界面的美观性。
如下图是淘票票的搜索的入口,通过点击右上角的搜索icon进入搜索页面:
分析:在界面权重上,这样的方式相对于以上三种方式来说显得较弱一点,因为在这样的场景下用户使用搜索的概率并不是很高,如果把搜索外漏就会占据更多的屏幕空间,破坏界面的权重等级和美观性。
总结:依据用户的需求场景,搜索入口放在不同的位置,如果说在该页面搜索是一个主要的功能,我们就应该去突显它,提升它在界面上的权重,反之则减轻它的权重。
搜索中间页本来应该是一个轻量化的页面,用户在这里输入内容进行搜索即可。但随着运营需求的扩张,这个页面逐渐成为了一个运营重灾区,多了很多推荐的内容。笔者将从“输入框提示信息、搜索分类、搜索历史、搜索推荐、搜索输入、搜索建议”等方面分析一下这个页面的设计。
搜索框内的提示信息通常是提示用户当下可以搜索什么样的内容,如下图bilibi的搜索提示,告诉用户可以进行“视频、番剧、UP主或者AV号”的搜索,这样的提示信息对用户也是一种良性的引导,给用户提供了一个心理预期,同时也对用户随意输入关键词造成无结果的伤害体验的可能进行了限制。例如一个房产APP,搜索框内提示输入楼盘或小区名,如果没有这样的提示有的用户可能就会去输入价格去筛选房源,这句提示语很好地降低了这样的风险。
但随着人们对APP使用的熟悉,用户在这里的认知负担基本消除,运营人员逐渐抢占了这块地方,这句话变成了内容的推荐或者产品的Slogan,这些推荐的内容可以是运营人员手动维护的也可以是依据用户的购买和行为习惯进行推荐的。如下图右边是淘宝的搜索提示,搜索框的文案变成了“红人最爱潮牌名服”,这就是运营人员在为特定内容进行导流。
在内容型APP中搜索时通常会对内容进行分类搜索,这是为了帮助用户更地找到相关内容,分类的操作可以发生在搜索前也可以发生在搜索后,如下图是“淘宝、微信、网易云音乐”搜索分类的方式,笔者将分别对他们进行分析。
淘宝是将搜索分类前置,默认搜索宝贝,点击后弹出浮层进行切换。这样的方式存在一个明显的缺点就是由于该入口所占空间位置不显著,会导致用户感知太弱。 这样的方式通常用在用户大多数情况下只搜索某一分类的内容,如淘宝这样,用户大部分的搜索场景都是在寻找宝贝。
微信默认搜索所有内容,将分类通过通过三个很显著的入口放在搜索框下方,当点击某一分类时跳转到该分类的搜索界面,同时搜索框的文案以及搜索界面的内容发生相应变化,提示用户搜索范围被改变。这种方式通常用在这些分类搜索的场景都很常见时,它的缺点在于,从界面表现形式来看,这三个分类更像是三个功能的入口,他们与搜索框联系得不是很紧密,很多用户最开始使用时并不知道点击这些分类是进行搜索范围的限制。经测试3个从未使用过该功能的用户,他们都认为点击朋友圈后就是进入朋友圈,点击文章后就是显示所有文章。
网易云音乐是将搜索分类进行后置了,在下文关于搜索结果的展示我会分析它的优劣势。
搜索历史记住用户的足迹,方便用户快速向以前搜索过的内容进行转换。设计上我们需要注意的一点就是需要把搜索历史和搜索推荐区分开来,在位置上,尽量让搜索历史靠近搜索框(如下图),因为从认知心理学上来讲,越靠近搜索框的内容越能表示它是搜索历史。在表现形式上,搜索历史和搜索推荐尽量采用不同的表现形式。搜索历史伴随的交互操作有删除单条或者清空搜索历史
这里的搜索推荐通常有三种来源:
它存在的目的主要有两个:
建议:
受移动端操控方式的限制,在输入内容时存在两个明显的痛点:“修改内容”和“输入速度”。
关于修改内容:当用户想更改语句中一部分文字时,将光标移动到想要更改的地方是一件很难的事,点击操作真的很令人发狂,通常情况下我宁愿重新输入。但是针对这一点搜狗输入法做了一个很人性的交互,当用户按住键盘左右滑动时就能移动光标(如下图)。
关于输入速度:很早之前偶然间发现了UC浏览器在输入文字时的一个交互功能,如下图所示,当输入文字后,用户可以将搜索建议的词语直接加入到搜索框中然后继续输入文字。这样的需求场景在很常见,比如我想搜索“交互设计师的前景”,当我输入交互二字后就会有“交互设计”的搜索建议,点击搜索建议后面的箭头将这个词直接加入搜索框,然后就出现了“交互设计师的前景”的搜索建议,点击搜索建议后进入搜索结果的页面,这个过程中我少打了很多字,对我的搜索速度有很大的提升。
当用户输入内容后,搜索框下面出现了众多的搜索建议,这些搜索建议是为了帮助用户快速向目标进行转化,如下图是京东的搜索建议,当我输入画框后,一系列画框的搜索建议就出来了,它还有一个亮点就是在此提供了细化筛选条件,画框后面紧跟了“长方形、实木、正方形”等关键的筛选条件,为用户省去了到结果页进行筛选的步骤。
搜索结果是搜索过程中最关键的点,结果的准确性确定了用户体验的好坏,笔者将从“搜索结果的形式、搜索结果的操作、搜索结果的分类、搜索结果的排序”等方面来对搜索结果进行分析。
搜索结果一般分为两种,一种是所见即所得,用户输入内容后出现在搜索框下面的搜索建议就是搜索结果,这种搜索通常出现在一些轻量化的APP中,因为搜索建议对应的就是唯一的搜索结果,如下图微信的搜索一样。
第二种形式就是一个关键词对应了多个搜索建议,每个搜索建议又对应了多个搜索结果,当用户点击搜索后进入了一个专门的搜索结果页,如下图京东的搜索一样。
依据用户的需求目的,在搜索结果的列表上我们可以外漏用户大部分情况下会采取的操作,比如说视频类网站,用户搜索到某一内容后,最常采取的操作就是播放,我们就可以把播放按钮外漏,缩短用户的操作路径(如下图爱奇艺的搜索结果页)
通常的分类方式是TAB切和卡片,以下是微信和网易云音乐的分类。
这两种方式有各自的应用场景,TAB切主要应用在搜索结果有固定的几种分类,并且通常的情况下搜索结果都有很多的内容,如上图的网易云音乐,每一个分类都有很多的搜索结果,如果它采用卡片式的瀑布流布局,用户需要不停往下翻才能看到第二种分类的内容。卡片式主要运用在搜索结果的内容不多,如微信这样的情况,每一类结果并不是很多,卡片式的瀑布流布局能让用户快速定位到自己想要的内容,如果这里用TAB切就很尴尬了,因为每一类的内容都很少或者很多类里根本没有内容,这样的用户感受就不好了。
搜索结果的排序是一个比较复杂的工作,里面涉及了很多的算法逻辑,笔者对这块也不是很清楚,但是一般的垂直内容型APP并没有这么复杂的算法在里面,就是按照搜索的关键字去一一匹配。
如下图是说我在QQ阅读输入一个“男”字,然后就给我建议第一个字是“男”的所有可能的结果,当第一个字匹配完后就匹配第二个字,这样以此类推。他们的整体顺序就是按照匹配关键字的先后进行排列的,其实在排序中还牵涉了很多的算法,比如说它可能会掺杂一些“热度、人气、人为意图、语义”等因素的权重,这里不展开赘述了。
以上就是笔者对搜索功能的介绍和思考,希望能对大家有所帮助。
本文由 @不知名设计师 原创发布于人人都是产品经理。未经许可,禁止转载。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
几个月之前,我曾经在一篇文章中说过 Magic 和 Operator 这样的应用将会成为下一个重大突破。
它们的独特之处在于,它们没有采用传统的 UI(用户界面)作为交互方式。
如果您想订阅本博客内容,每天自动发到您的邮箱中, 请点这里
摘要: 什么是ATL(与COM的关系,及MFC与COM的关系)自从1993年Microsoft首次公布了COM技术以后,Windows平台上的开发模式发生了巨大的变化,以COM为基础的一系列软件组件化技术将Windows编程带入了组件化时代。广大的开发人员在为COM带来的软件组件化趋势欢欣鼓舞的同时,对于COM开发技术的难度和烦琐的细节也感到极其的不便。COM编程一度被视为一种高不可攀的技术,令人望而却步
什么是ATL (与COM的关系,及MFC与COM的关系)
自从1993年Microsoft首次公布了COM技术以后,Windows平台上的开发模式发生了巨大的变化,以COM为基础的一系列软件组件化技术将Windows编程带入了组件化时代。广大的开发人员在为COM带来的软件组件化趋势欢欣鼓舞的同时,对于COM开发技术的难度和烦琐的细节也感到极其的不便。COM编程一度被视为一种高不可攀的技术,令人望而却步。开发人员希望能够有一种方便快捷的COM开发工具,提高开发效率,更好地利用这项技术。
针对这种情况,Microsoft公司在推出COMSDK以后,为简化COM编程,提高开发效率,采取了许多方案,特别是在MFC(MicrosoftFoundationClass)中加入了对COM和OLE的支持。但是随着Internet的发展,分布式的组件技术要求COM组件能够在网络上传输,而又尽量节约宝贵的网络带宽资源。采用MFC开发的COM组件由于种种限制不能很好地满足这种需求,因此Microsoft在1995年又推出了一种全新的COM开发工具ATL。
ATL是ActiveX Template Library的缩写,它是一套C++模板库。使用ATL能够快速地开发出、简洁的代码(Effectiveand Slimcode),同时对COM组件的开发提供最大限度的代码自动生成以及可视化支持。为了方便使用,从MicrosoftVisual C++ 5.0版本开始,Microsoft把ATL集成到VisualC++开发环境中。1998年9月推出的Visual Studio 6.0 集成了ATL3.0版本。目前,ATL已经成为Microsoft标准开发工具中的一个重要成员,日益受到C++开发人员的重视。
ATL究竟给开发人员带来了什么样的益处呢?这还要先从ATL产生以前的COM开发方式说起。
在ATL产生以前,开发COM组件的方法主要有两种:一是使用COMSDK直接开发COM组件,另一种方式是通过MFC提供的COM支持来实现。
直接使用COMSDK开发COM组件是最基本也是最灵活的方式。通过使用Microsoft提供的开发包,我们可以直接编写COM程序。但是,这种开发方式的难度和工作量都很大,一方面,要求开发者对于COM的技术原理具有比较深入的了解(虽然对技术本身的深刻理解对使用任何一种工具都是非常有益的,但对于COM这样一整套复杂的技术而言,在短时间内完全掌握是很难的),另一方面,直接使用COMSDK要求开发人员自己去实现COM应用的每一个细节,完成大量的重复性工作。这样做的结果是,不仅降低了工作效率,同时也使开发人员不得不把许多精力投入到与应用需求本身无关的技术细节中。虽然这种开发方式对于某些特殊的应用很有必要,但这种编程方式并不符合组件化程序设计方法所倡导的可重用性,因此,直接采用COMSDK不是一种理想的开发方式。
使用MFC提供的COM支持开发COM应用可以说在使用COMSDK基础上提高了自动化程度,缩短了开发时间。MFC采用面向对象的方式将COM的基本功能封装在若干MFC的C++类中,开发者通过继承这些类得到COM支持功能。为了使派生类方便地获得COM对象的各种特性,MFC中有许多预定义宏,这些宏的功能主要是实现COM接口的定义和对象的注册等通常在COM对象中要用到的功能。开发者可以使用这些宏来定制COM对象的特性。
另外,在MFC中还提供对Automation 和 ActiveXControl的支持,对于这两个方面,VisualC++也提供了相应的AppWizard和ClassWizard支持,这种可视化的工具更加方便了COM应用的开发。
MFC对COM和OLE的支持确实比手工编写COM程序有了很大的进步。但是MFC对COM的支持是不够完善和彻底的,例如对COM接口定义的IDL语言,MFC并没有任何支持,此外对于近些年来COM和ActiveX技术的新发展MFC也没有提供灵活的支持。这是由MFC设计的基本出发点决定的。MFC被设计成对Windows平台编程开发的面向对象的封装,自然要涉及Windows编程的方方面面,COM作为Windows平台编程开发的一个部分也得到MFC的支持,但是MFC对COM的支持是以其全局目标为出发点的,因此对COM的支持必然要服从其全局目标。从这个方面而言,MFC对COM的支持不能很好的满足开发者的要求。
随着Internet技术的发展,Microsoft将ActiveX技术作为其网络战略的一个重要组成部分大力推广,然而使用MFC开发的ActiveXControl,代码冗余量大(所谓的“肥代码 FatCode”),而且必须要依赖于MFC的运行时刻库才能正确地运行。虽然MFC的运行时刻库只有部分功能与COM有关,但是由于MFC的继承实现的本质,ActiveXControl必须背负运行时刻库这个沉重的包袱。如果采用静态连接MFC运行时刻库的方式,这将使ActiveXControl代码过于庞大,在网络上传输时将占据宝贵的网络带宽资源;如果采用动态连接MFC运行时刻库的方式,这将要求浏览器一方必须具备MFC的运行时刻库支持。总之MFC对COM技术的支持在网络应用的环境下也显得很不灵活。
解决上述COM开发方法中的问题正是ATL的基本目标。
首先ATL的基本目标就是使COM应用开发尽可能地自动化,这个基本目标就决定了ATL只面向COM开发提供支持。目标的明确使ATL对COM技术的支持达到淋漓尽致的地步。对COM开发的任何一个环节和过程,ATL都提供支持,并将与COM开发相关的众多工具集成到一个统一的编程环境中。对于COM/ActiveX的各种应用,ATL也都提供了完善的Wizard支持。所有这些都极大地方便了开发者的使用,使开发者能够把注意力集中在与应用本身相关的逻辑上。
其次,ATL因其采用了特定的基本实现技术,摆脱了大量冗余代码,使用ATL开发出来的COM应用的代码简练,即所谓的“SlimCode”。ATL在实现上尽可能采用优化技术,甚至在其内部提供了所有C/C++开发的程序所必须具有的C启动代码的替代部分。同时ATL产生的代码在运行时不需要依赖于类似MFC程序所需要的庞大的代码模块,包含在最终模块中的功能是用户认为最基本和最必须的。这些措施使采用ATL开发的COM组件(包括ActiveXControl)可以在网络环境下实现应用的分布式组件结构。
第三,ATL的各个版本对Microsoft的基于COM的各种新的组件技术如MTS、ASP等都有很好的支持,ATL对新技术的反应速度大大快于MFC。ATL已经成为Microsoft支持COM应用开发的主要开发工具,因此COM技术方面的新进展在很短的时间内都会在ATL中得到反映。这使开发者使用ATL进行COM编程可以得到直接使用COMSDK编程同样的灵活性和强大的功能。
本文的目的就是希望在有限的篇幅中能够使读者对ATL的使用和基本原理有一个初步的了解,为广大的COM开发人员更好地使用ATL开发起到抛砖引玉的作用。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
出处:https://www.cnblogs.com/pengdai
二、S单一职责SRP
1、定义
2、原则分析
3、优点
4、例子
三、O开放封闭原则OCP
1、定义
2、原则分析
3、例子
四、L里氏替换原则LSP
1、定义
2、原则分析
里氏代换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象。
五、I接口隔离法则
1、定义
2、原则分析:
六、D依赖倒置原则DIP
1、定义
2、原则分析
3、例子1
[img]https://ss.csdn.net/p?https://mmbiz.qpic.cn/mmbiz_png/ ... rFZQ/640?wx_fmt=png[/img]
七、合成/聚合复用原则
1、定义
2、原则分析
八、迪米特法则
1、定义
2、法则分析
5、例子
九、Q&A1、面向对象设计其他原则?
2、你能解释一下里氏替换原则吗?
3、什么情况下会违反迪米特法则?为什么会有这个问题?
4、给我一个符合开闭原则的设计模式的例子?
5、什么时候使用享元模式(蝇量模式)?
如果您想订阅本博客内容,每天自动发到您的邮箱中, 请点这里
最近一段时间一直在建立APP的设计规范,从一开始的立项到现在落地上线,可以说是从零开始进行APP全部细节的梳理并且规定规范,这一路走过来还是能总结出很多心得,本文将分为3个部分,阐述如何从0到1建立设计规范。
目录:
一、如何确定内容,规范里要写什么
二、如何写
三、如何推动规范落地
一、如何确定内容?
这里我总结了三步:
1)确定目标用户、用户目标、设计目标
根据不同的用途和目标,不同的团队对设计规范的制定是不一样。比如为了指导与规范全球第三方开发者进行设计和开发,Google建立的Material Design覆盖面广,每个组件细节写得非常细致。Ant Design则是直接做出了组件,方便直接进行调用。有些国内设计团队的规范则是主要描述常用控件和色值。因此我们需要确立用户目标和设计目标,这样才能确定我们的规范侧重点是什么,需要做成怎么样的形式。
在这里我列举了自己撰写规范时的用户与目标:
2)模范大平台,先列全
一个规范里面的东西是很多的,那么我们究竟需要做什么呢?假如一开始我们没有方向,找一个,列一个,这样我们很容易疏漏很多情况。在这里我采用的的一个办法是:首先熟读iOS,Material Design规范,并且模范他们,在脑图中,把规范中应含有的所有内容罗列出来,罗列一个大纲。
这里我列举当时自己做的一个脑图大纲,覆盖了主流规范中的所有细节,大家可以进行参考并模仿:
3)针对自己情况进行删减
列完齐全的大纲后,我们需回顾设计目标,对大纲里的内容进行删减。(比如在组件、模式这些地方,可以对着自己的APP,进行挨个寻找,看自己的APP当前是不是运用了这个组件,没有的话就进行删减。)
在这里我列举了针对自身APP的情况删减后的大纲图:
二、如何写
进过了以上的三步,我们基本得出了要写什么的框架了,接下来就是如何写规范的阶段。
这里我总结了3步:
1)确定优先级
我们可以通过版本迭代计划+性价比+重要性(该组件在页面出现的场景次数以及当前的不统一对APP体验影响程度)这几个维度分别确定每块内容的优先级和分工。基础的、必要的、高性价比的放在第一期,复杂的向后放,随着产品的迭代,我们的规范也会越来越完整。
同时需要留意版本规划,了解即将要做的功能或即将要改版的页面。我们可以提高这里面牵涉到的控件、组件等内容的优先级。庞大复杂,牵涉到很多页面的,我们可以先降低其优先级:比如全局提示框的规范,toast的规范。
同时,我们也需常与开发沟通,争取把可复用性高、组件日后变化幅度少的组件做成开发组件库。
2)确定规范书写格式
我们制定的规范本身也是设计的交付物,假如每个设计师都按照自己的喜好来编写规范,那么这个规范本身也会变得不规范,规范自身保持一致性是提高规范阅读效率的一部分。
我们可以回归我们之前制定的用户目标和设计目标来制定我们规范的书写格式。规范的用户群是谁,主要想达到什么作用,是通过文档展示还是网上展示,确定了这些问题后,就可确定规范的详细程度、主要的展示形式(比如前文说到的Ant Design和Material Design)。
这里我的思考点是:假如规范写太多字就会变得很臃肿,没有人喜欢慢慢仔细的阅读你写的规范,所以我们应该做到写得简明扼要,再辅以例子说明(根据开发的习惯,都是喜欢直接看例子,看标注)。
我的书写格式是:先写描述这个组件是什么,再列举出现的场景,然后编写交互规则,最后给出视觉标注+例子。
3)逐步对单个规范进行整理与书写
当确定了要写什么东西和格式之后,我们开始进入到细节,对每个内容进行整理,制定规范了。
通过对每个内容制定规范规范也是有方法的:
下面我通过整理“列表”这个规范来讲解:
1.收集出现的所有的场景。
当一个产品已经趋于成熟,这个组件出现的场景就会非常多,比如对话框,toast,列表这些组件出现的地方很多,需要我们自己仔细地体验产品,把所有页面都找出来。
2.提取共性,归纳分类
我们需要分析每个页面的特点并且把相同特点的页面归纳一起,众多的页面场景就能整理成几个典型的种类,然后只需对这几个典型的种类进行定义和描述即可。
在列表中,我分为了大封面列表、小封面列表、用户列表、单行列表
3.编写规则
在分类好后,我们可以对每个种类编写规则,在这里我们需要描述好每个种类有什么特点或属性,什么时候场景下适用,并且给出标注和例子,方便阅读者理解。
4.多与组内成员讨论修改
在制定好初稿后,我们可以与组内成员宣讲下自己制定的规范。多从别人的角度出来,确保你编写的规范是否易懂,是否包含了全部的情况,是否容易执行落实。
三、如何推动规范落地
写完内容后,最重要的一步就是推动落地,规范要真正有人用才能体现价值,在这里我给出几点帮助推动规范落地的小建议:
1.制定规范推进进度表
表格里面应该包含规范制定的优先级,分工进度,分工人员,并且确定每一期进度的交付时间,开会讨论的时间,作为负责人,也可以适时提醒成员每次的开会时间(毕竟deadline是第一生产力)。
2.编写过程中多与其他成员讨论,达成一致性共识
制定规范后,与部门其他人员进行宣讲,灌输概念,针对如何更好的落实进行讨论调整。在设计中都不可能一次就完美,我们需要不断的在修改中逐渐完善。
3.规范建成后放在网上
同步在网上,方便部门内的其他成员能随时查看和团队成员对规范的更新修改、同步。
4.强制性制定规则要求团队成员执行。
有明确的惩罚机制和要求才能更好的执行,不然在规范制定后很容易健忘此事。(我们组的惩罚机制就是罚钱)。
5.规范保持持续的更新迭代。
规范推动落地后并不是完全了事,要根据产品的迭代,保持规范的更新。
这整个制定规范的项目中,还是有不少反思的地方,值得我们深思和注意:
1.切记不要为设计规范而做规范
规范最重要的点是能推动落地,能确确实实改善产品,达到统一性。因此我们在设计规范时,并不需要“高大上”术语,给出一大堆的设计理念用来提升设计逼格。而是真正的回归到我们的设计目标,针对目标用户制定规范,做到简朴、易懂、能落地。
2.没人愿意阅读长篇文字
我们应该尽量控制文案长度,做到通俗易懂即可。
3.要时刻围绕我们的目标做规范
比如,我这次做的规范中有一项是去工具化,在制定控件中,空白页面中就会加入很多趣味化的设计。
4.灵活变通
规范只是适合大多时候的场景,对于一些规范中没有包含或者不符合规范的场景,我们可以灵活变通,积极创新或者是补充新的规范(前提是与组内积极沟通,达成共识)。
总结:
再来回顾如何从0到1建立规范
一、确定内容
1.确定用户目标和设计目标
2.模仿大平台,列全
3.针对自己情况进行缩减
二、写
1.确定优先级
2.确定规范书写格式
3.逐步对单个内容进行整理与书写:a.收集全部情况 b.分类归纳 c.提取共性,编写规则
三、推动
1.制定规范推进进度表
2.编写过程中多与其他成员讨论
3.把规范建成后放在网上
4.强制性制定规则要求团队成员执行
5.规范保持持续的更新迭代
今天分享的内容就是这些了,希望能帮助到大家,感谢阅读~
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务。
经过一个多月的闭关潜修,新MMORPG回合制游戏《魔力物语》近期又准备和大家见面了。至于具体的开测日期,容小编先卖个关子(PS:我绝对不会说其实我也不知道)。在上次结束之后,我们针对测试出现的问题进行修复并优化游戏。在一个多月的优化中,游戏将会脱胎换骨,以更完善的姿态和大家见面。下面就让大家看下游戏UI界面优化的成果。
如果您想订阅本博客内容,每天自动发到您的邮箱中, 请点这里
用css隐藏页面元素有许多种方法。
opacity属性的意思是设置一个元素的透明度。它不是为改变元素的边界框(bounding box)而设计的。这一位着将opacity设置为0只能从视觉上隐藏元素。而元素本身依然占据它自己的位置并对网页的布局起作用,它也将响应用户交互。
visibility
第二个要说的属性是visibility。将它的值设为hidden将隐藏我们的元素。如同opacity属性,被隐藏的元素依然会对我们的网页布局起作用。与opacity唯一不同的是它不会响应任何用户交互。此外元素在读屏软件中会被隐藏
注意,如果一个元素的visibility被设置为hidden,同时想要显示它的某个子孙元素,只要将那个元素的visibility显式设置为visible即可。
dispaly
display属性依照词义真正隐藏元素。将display属性设为none确保元素不可见并且连盒模型也不生成。使用这个属性,被隐藏的元素不占据任何空间。不仅如此,一旦display设为none任何对该元素直接打用户交互操作都不可能生效。此外,读屏软件也不会读到元素的内容。这种方式产生的效果就像元素完全不存在。
任何这个元素的子孙元素也会被同时隐藏。为这个属性添加过度动画是无效的,他的任何不同状态值之间的切换总是会立即生效。
不过请注意,通过DOM依然可以访问到这个元素。因此你可以通过DOM来操作它。
position
假设有一个元素你想要与它交互,但是你又不想让它影响你的网页布局,没有合适的属性可以处理这种情况(opacity和visibility影响布局mdisplay不影响布局但又无法直接交互)。在这种情况下,只能考虑将元素移出可视区域。这个办法既不会影响布局,有可能让元素保持可以操作。
隐藏元素的另一种方法是通过剪裁它们实现。
opacity
如果您想订阅本博客内容,每天自动发到您的邮箱中, 请点这里
用css隐藏页面元素有许多种方法。
opacity属性的意思是设置一个元素的透明度。它不是为改变元素的边界框(bounding box)而设计的。这一位着将opacity设置为0只能从视觉上隐藏元素。而元素本身依然占据它自己的位置并对网页的布局起作用,它也将响应用户交互。
visibility
第二个要说的属性是visibility。将它的值设为hidden将隐藏我们的元素。如同opacity属性,被隐藏的元素依然会对我们的网页布局起作用。与opacity唯一不同的是它不会响应任何用户交互。此外元素在读屏软件中会被隐藏
注意,如果一个元素的visibility被设置为hidden,同时想要显示它的某个子孙元素,只要将那个元素的visibility显式设置为visible即可。
dispaly
display属性依照词义真正隐藏元素。将display属性设为none确保元素不可见并且连盒模型也不生成。使用这个属性,被隐藏的元素不占据任何空间。不仅如此,一旦display设为none任何对该元素直接打用户交互操作都不可能生效。此外,读屏软件也不会读到元素的内容。这种方式产生的效果就像元素完全不存在。
任何这个元素的子孙元素也会被同时隐藏。为这个属性添加过度动画是无效的,他的任何不同状态值之间的切换总是会立即生效。
不过请注意,通过DOM依然可以访问到这个元素。因此你可以通过DOM来操作它。
position
假设有一个元素你想要与它交互,但是你又不想让它影响你的网页布局,没有合适的属性可以处理这种情况(opacity和visibility影响布局mdisplay不影响布局但又无法直接交互)。在这种情况下,只能考虑将元素移出可视区域。这个办法既不会影响布局,有可能让元素保持可以操作。
隐藏元素的另一种方法是通过剪裁它们实现。
opacity
移动端推广速度快,效果好,越来越多的企业,商家开始重视移动站的建设和移动页面(h5)的制作。随着移动页面的玩法越来越多,对前端技术的要求也会越来越高。
关于移动设备一些基本概念的理解。
网站示例
网址:https://github.com/amfe/lib-flexible;
蓝蓝设计的小编 http://www.lanlanwork.com