<table>
<tr>
<td>姓名:</td>
<td contentEditable="true"></td>
</tr>
<tr>
<td>密码:</td>
<td contentEditable="true"></td>
</tr>
</table>
<view class="gallery">
<view class='tipTitle'>
快去上传自己的照片吧
</view>
<view class='item-ot'>
<view class="item">
<!-- 添加按钮 -->
<view class="addIcon" bindtap="chooseImage" wx:if="{{imgBoolean}}">
<view class=''>+</view>
</view>
<!-- 上传的图 -->
<view class='itemImg' >
<image src="{{item}}" data-src="{{item}}" bindtap="previewImage" mode="aspectFill" />
<!-- 删除按钮 -->
<view class="delete" bindtap="deleteImg" data-index="{{index}}">X</view>
</view>
<view class='boxStyle'></view>
</view>
<view class='itemTxt'>正面照</view>
</view>
<view class='uploadFinish'>
<a class="uploadFinishBtn" href="javasctipt:;" bindtap="submit">提 交</a>
</view>
</view>
/*画廊*/
.gallery {
width:100%;
margin: 0 auto;
display: flex;
justify-content: flex-start;
flex-wrap: wrap;
background: #fffaf0;
}
/*每张图片所占容器*/
.item-ot{
margin:0 auto;
width: 100%;
height: 100%;
}
.item {
position:relative;
margin:0 auto;
width:370rpx;
height:490rpx;
background:#eee;
border:2rpx solid #f9c4c2;
/* overflow:hidden; */
}
.itemImg{
position: absolute;
left: 0;
top:0;
width: 100%;
height: 100%;
overflow: hidden;
z-index:1;
}
.itemImg image{
width: 100%;
height: 100%;
}
/*add按钮*/
.addIcon{
position:absolute;
left: 0;
top: 0;
width: 100%;
height: 100%;
text-align:center;
line-height:490rpx;
font-size:80rpx;
background: #fff;
color: #999;
z-index:2;
}
/*删除按钮*/
.delete {
position:absolute;
right:0;
top:0;
/* background:#ccc; */
opacity:1;
height: 36rpx;
font-size:22rpx;
font-weight:700;
padding:0 8rpx 0 10rpx;
color: #999;
}
.itemTxt{
text-align: center;
font-size: 30rpx;
color: #999;
margin-top: 50rpx;
margin-bottom: 70rpx;
font-weight: 700;
}
.uploadFinish{
width: 100%;
height: 100%;
padding: 0 30rpx;
box-sizing: border-box;
}
.uploadFinishBtn{
background: #ff6666;
color: #fff;
display: block;
width: 100%;
padding: 26rpx 0;
text-align: center;
font-size: 36rpx;
border-radius: 10rpx;
margin-bottom: 40rpx;
}
.tipTitle{
text-align: center;
font-size: 30rpx;
color: #f6a29d;
font-weight: 700;
width: 100%;
margin: 50rpx 0;
}
.boxStyle{
width:300rpx;
height:100rpx;
position:absolute;
bottom:-1rpx;
border-radius:50%;
box-shadow:0rpx 10rpx 100rpx #fddbd9;
margin-left:35rpx;
}
Page({
data: {
uploadedImages: [],
imgBoolean: true,
},
onLoad: function (options) {
var that = this;
},
chooseImage: function () {
var that = this;
// 选择图片
wx.chooseImage({
count: 1, // 默认9
sizeType: ['original', 'compressed'], // 可以指定是原图还是压缩图,默认二者都有
sourceType: ['album', 'camera'], // 可以指定来源是相册还是相机,默认二者都有
success: function (res) {
// 返回选定照片的本地文件路径列表,tempFilePath可以作为img标签的src属性显示图片
var tempFilePaths = res.tempFilePaths
that.setData({
item: tempFilePaths[0],
imgBoolean: false
});
}
})
},
// 图片预览
previewImage: function (e) {
var current = e.target.dataset.src
wx.previewImage({
current: current,
urls: [current]
})
console.log("这是1" + current);
},
//删除图片
deleteImg: function (e) {
var that = this;
var images = that.data.uploadedImages;
that.setData({
uploadedImages: images,
imgBoolean: true
});
},
// submit: function () {
// },
})
],
如果想控制百分比最大到100% 可添加
yAxis : [
{
type : 'value',
max:100,//Y轴最大值 不写的话自动调节
axisLabel:{formatter:'{value} %'}
}
],
> max:100,//Y轴最大值 不写的话自动
<table>
<tr>
<td>姓名:</td>
<td contentEditable="true"></td>
</tr>
<tr>
<td>密码:</td>
<td contentEditable="true"></td>
</tr>
</table>
当我们回顾近20年的手机发展历程,可以发现2007年iPhone的横空出世真正改变了手机这个行业。乔布斯在发布会上展示初代iPhone给行业带来的冲击力是前所未有的,对人机交互领域也带来了了深远的影响。
任何一个新事物的出现,人们总是倾向于从现有的知识体系中寻找类似的事物进行描述与概括,以寻求情感上的归属和理性上的辨识。但是过于超前的创新,往往是现有的知识体系无法解释的。无法解释,自然无法接受。
文章来源:站酷
踏破铁鞋无觅处,得来全不费功夫。微信付费阅读一出,对优质内容创作者来说,无疑从天而降了一条增收渠道。微信为什么在要此时推出付费功能?在付费阅读最终推出之前,微信做了哪些准备?如何打造一个成功的平台?
微信公众号付费最早的新闻出现在2017年2月14日,马化腾在朋友圈回复评论人洪波说,正在加快微信公众号付费订阅功能。
转眼三年过去,付费阅读才姗姗来迟。这是一个极佳的根据内外环境来演进产品的案例。
首先我们来看微信付费阅读的要求,前两条“公众号注册超过3个月”和“3个月内无严重违规纪录”,都是对使用权益的基本要求;最后一条“已发表至少3篇原创文章”则是典型用户的关键特征,从此项出发,可以推导出产品功能商业化演进的关键路径点。
通过商业化关键特征“原创性”,找到了关键演进路径的起点:原创。
下面是围绕原创的各项关键事件时间节点:
2017年11月22日正式发布原创功能:
公众号文章可以使用“原创声明”和“留言”功能。背后依托的是腾讯在文章重复率检查的技术。一篇上万字的文章,点击“原创声明”时,几乎无感知收到检查的结果。原创声明的扩展功能包括:打赏、转载、白名单。
2018年6月6日正式恢复文章打赏功能:
微信最早在2016年就推出了文章赞赏功能,此项功能一波三折,中间经历了与Apple AppStore平台的分成博弈,还有作者的所得是否该纳个税的社会舆论;最后在2018年6月6日正式恢复:赞赏的钱直接给到作者。
微信与Apple是竞合策略(Coopetition)运用。微信作为Apple App,打赏功能根据AppStore规则应由Apple分羹。而作为拥有9亿用户的微信,又为Apple创造了一个杀手级的App——你能想象同一个打赏,安卓手机上的微信能让创作者收入更高吗?那Apple用户的高价值如何体现?数字化产品中竞合策略的发生,取决者两者既可集成(Integration)又可分离(Separation),并且需要进行商业上的决策。
2019年10月29日原创文章规模达到1.1亿:在北京由腾讯主办的《互联网社交平台知识产权保护论坛》上,腾讯宣布,原创声明标识的文章规模已超过1亿。其中腾讯的原创保护贡献在累计删除15万的涉嫌侵权文章、6万品牌侵权信息,每天主动拦截假冒注册行为11,000次。
产品内部演进总结:
原创产品的内部演进,经历了关键技术突破、商业规则变革和规模化三个关键节点。至此产品市场已经成熟。
知识付费市场是由视频、音乐用户付费习惯的不断成长而带动的。艾瑞《2018年中国在线知识付费市场研究报告》预测,到2020年,中国知识付费市场规模将达到235.1亿人民币。
艾瑞这份报告偏差在于:价值链分析只将微信视为了渠道,在2018年微信已经拥有原创+付费两大基本要素之后,艾瑞也未在竞争格局将微信视为潜在进入者。
2019年知识付费“风口”过去之时,对行业中依然处于中小规模,无法站稳用户基础的创业公司而言,就将成为即将摔下来的猪,而此时市场却初步成熟,正是巨头进入的时机了。
市场趋势发展总结:
初期市场进入容易,因参与者少,供给远小于需求时,初创公司容易获得用户,面对竞争少。但随着用户使用、购买习惯的养成,越来越多的竞争者进入,达到供需平衡时刻(即市场均衡)时,新进入者获客、现有的供给方留客将越来越困难。如果此时市场规模足够大,达到数百亿甚至千亿级别,它将成为巨头们的主战场。
艾瑞报告中知识付费产业价值链定义了三类参与者,内容提供方和知识付费平台类又共细分为六个角色。而微信付费阅读将整个产业价值链供应端重塑为了两个角色:平台和原创作者。这一重塑极大地简化了价值创造与交付过程,也提升了价值获取的份额。对整个产业来说,是一次有效的增值。
在知识付费产业还存在一个潜在进入者,就是工具应用,比如阿里巴巴推出的语雀知识管理平台,就提供了非常好用的文章编写和管理工具。但平台能够快速替换掉独立知识付费平台、头部知识内容商以及KOL、经纪/孵化公司,是因为平台的独特技术(核武器):生成性。
生成性 Generativity——平台具备创造新产品的技术能力(Technology supports the creation of novel products.)
正是生成性,使平台成为了数字化时代最高生产力的代表。仅仅使用微信付费阅读功能,作者就可以直接创造出读者可购买的产品,这就是微信作为平台的核心颠覆能力。而头部知识内容商的签约作者、KOL,均可以通过入驻微信公众号以及运营微信群,完成整个商业模型的闭环。
打造一个平台,需要根据外部市场趋势,不断地进行内部产品演进和内外商业生态治理。
但微信付费阅读的成功递进,不仅仅是技术或简单商业化(变现)的转变,而是抓住了知识付费产业的第一性原理:知识产权保护。
根据科斯定理,在一个产权清晰的市场中,它的配置将会是最有效的。抓住知识产权生态的微信付费,有可能实现内容创作者与阅读者之间更有效的资源配置。
文章来源:人人都是产品经理
语言设置
校验消息默认是英文的,定义中文或其他语言的错误提示消息
-
import VeeValidate from 'vee-validate';
-
import Vue from 'vue'
-
Vue.use(VeeValidate)
-
-
var dict = {
-
zh_CN: {
-
messages: {
-
required: function(field){
-
return field + '不能为空!';
-
},
-
between: function(field){
-
return field + '输入不符合设定规则!';
-
},
-
min : function (field,leng) {
-
return field + '长度不能小于'+leng+'位';
-
}
-
}
-
}
-
};
-
-
VeeValidate.Validator.localize('zh_CN', dict.zh_CN);
校验的时候需要设置语言
this.$validator.localize('zh_CN');
错误消息显示
显示指定字段的第一个错误
this.$validator.first('fieldname')
显示所有字段的第一个错误消息
this.$validator.errors.all()
配置
路由拦截配置不需要修改之前的代码,匹配的url请求会直接通过mock而不是请求服务器
-
const handler = req => {
-
return {mock数据};
-
}
-
Mock.mock('url拦截规则,正则表达式',handler)
配置延迟时间
模拟服务器请求的异步特性
-
Mock.setup({
-
timeout:1000
-
})
模块化
多人协作,或者中大型的项目需要把store分为模块
-
const a = {
-
state : {foo:1},
-
mutations : {hello(state)=> {}},
-
modules : {
-
...嵌套
-
}
-
}
-
const b = {}
-
const store = {
-
state : {},
-
mutations : {},
-
actions : {},
-
modules : {
-
module_name_a:a,
-
module_name_b:b
-
}
-
}
在调用的时候,state 有命名空间的,而mutation和actions都与父模块共用同样的命名空间所以不能定义与父模块同名的mutation 或 action
获取模块的state
this.$store.state.module_name_a.foo
调用模块的mutation
this.$store.commit('hello')
namespace
定义了namespace ,mutations 和 action 会带上模块的命名: module_name/muation
-
const store = {
-
modules : {
-
namespace : true,
-
a: {
-
muations : {
-
test(state) => {...}
-
}
-
}
-
}
-
}
这时候调模块内的mutation
this.$store.commit('a/test')
日期选择控件
设置默认值
<datepicker v-model="mydate" </datepicker>
日期格式化
<datepicker :format="'yyyy-MM-dd'"> </datepicker>
语言选择(默认是英文)
导入语言资源文件,然后再设置:language
设置成中文
-
语言设置
校验消息默认是英文的,定义中文或其他语言的错误提示消息
-
import VeeValidate from 'vee-validate';
-
import Vue from 'vue'
-
Vue.use(VeeValidate)
-
-
var dict = {
-
zh_CN: {
-
messages: {
-
required: function(field){
-
return field + '不能为空!';
-
},
-
between: function(field){
-
return field + '输入不符合设定规则!';
-
},
-
min : function (field,leng) {
-
return field + '长度不能小于'+leng+'位';
-
}
-
}
-
}
-
};
-
-
VeeValidate.Validator.localize('zh_CN', dict.zh_CN);
校验的时候需要设置语言
this.$validator.localize('zh_CN');
错误消息显示
显示指定字段的第一个错误
this.$validator.first('fieldname')
显示所有字段的第一个错误消息
this.$validator.errors.all()
配置
路由拦截配置不需要修改之前的代码,匹配的url请求会直接通过mock而不是请求服务器
-
const handler = req => {
-
return {mock数据};
-
}
-
Mock.mock('url拦截规则,正则表达式',handler)
配置延迟时间
模拟服务器请求的异步特性
-
Mock.setup({
-
timeout:1000
-
})
模块化
多人协作,或者中大型的项目需要把store分为模块
-
const a = {
-
state : {foo:1},
-
mutations : {hello(state)=> {}},
-
modules : {
-
...嵌套
-
}
-
}
-
const b = {}
-
const store = {
-
state : {},
-
mutations : {},
-
actions : {},
-
modules : {
-
module_name_a:a,
-
module_name_b:b
-
}
-
}
在调用的时候,state 有命名空间的,而mutation和actions都与父模块共用同样的命名空间所以不能定义与父模块同名的mutation 或 action
获取模块的state
this.$store.state.module_name_a.foo
调用模块的mutation
this.$store.commit('hello')
namespace
定义了namespace ,mutations 和 action 会带上模块的命名: module_name/muation
-
const store = {
-
modules : {
-
namespace : true,
-
a: {
-
muations : {
-
test(state) => {...}
-
}
-
}
-
}
-
}
这时候调模块内的mutation
this.$store.commit('a/test')
日期选择控件
设置默认值
<datepicker v-model="mydate" </datepicker>
日期格式化
<datepicker :format="'yyyy-MM-dd'"> </datepicker>
语言选择(默认是英文)
导入语言资源文件,然后再设置:language
设置成中文
-
从性质上来说,我们看到的背景一般都会分为 5 种:纯色、渐变、肌理、图形、全图,但在真正开始做设计之前,我们并不会直接在这 5 种性质的背景里挑选,反而会从一些其他的维度先去思考,才能做出具体的选择。
△ 发布会背景的 5 种性质
因此在这 5 个性质之外,我们还要引入其他的思考维度,而这些思考的维度才能够让我们真正能做出「符合当前页面内容」的幻灯片背景。
按照幻灯片背景设计的时间流程线,可以分为 8 大维度:直观感,主视觉、布局感、场景感、设计感、平衡感、氛围感、跳跃率。
△ 发布会背景定制的 8 个维度
通常我们拿到客户的标配原稿都是白底黑字的形式,这时我们首先考虑的出发点是:
整个幻灯片希望给人传达的是偏向「明亮阳光」、「沉稳大气」的哪种感觉,这两种截然不同的感受会让我们在背景选取的时候,倾向于「亮色调」,或是「暗色调」。
在这个阶段我们并不会思考幻灯片背景到底是属于「纯色、渐变、肌理、图形、全图」哪种,这个阶段思考这个问题实在是太早了,我们只能从一个非常简单却又截然相反的两条路径,这时候是没有任何细节可言的。
——这被我称之为「直觉感」。
这是我们根据信息片段,不用太多思考,而出现的想法、感觉、信念或者偏好,可以帮助我们进行快速决策——这是设计师/团队对内容而产生的直觉洞察,本质上是个人的知识体系和经验对其做出的判断,没有过多的原因。
△ 纯白/纯黑背景的内容原稿
这两者的选取会在一开始做设计的时候,就会带给我们不同的思考角度,当我们确定了调性后,我们就会把原稿的背景色直接改为纯白或是纯黑,方便我们潜移默化地思考气质。
但这个阶段确认方向,有便于自己找到调性上的初心,不会在后期的细节设计中陷入方向性的错误。
当我们把整个页面的直观感受判断清楚以后,接下来可以涉及一些具体的设计性质,通常设计情况分为两种:一种是「有迹可循」,另外一种是「无迹可循」,分别对应不同的背景设计方法。
对于发布会而言,「有迹可循」的情况最直接的就是主视觉(Key Visual)沿用的情况(以下称之为主KV);「无迹可循」就需要从所需传递出的感觉和美感相结合来考虑,将在「场景感」和「设计感」两个维度谈及。
每一场活动基本都会有一个主 KV 用于奠定活动的视觉基调,所以幻灯片在大概率上和主 KV 会有一定的联系——但这中间会需要我们准确判断出两个小的隐藏需求:
这两个隐形需求,在前期沟通的时候一定要确认出来,否则的话有可能会造成很大的误解,导致很多额外、不应发生的问题。就此说明一下:
1. 客户对于主KV的态度
一种情况,是需求方对于这个主 KV 本身有一定的不满,但由于各种各样的因素最终使用了这个主 KV,如:
△ 需求方可能不太满意的主 KV
由于主 KV 已定,需求方会寄希望于幻灯片的设计上,内心的需求是:「能够基于主 KV,但不止于主 KV」。
另一种情况,是需求方对主 KV 的某些部分乃至全部部分都比较满意,允许设计师/团队使用主 KV 的部分亮点元素进行设计——其中的幅度最好在前期设计之前探索清楚,具体沟通的技巧涉及两方自身和彼此的合作经验,需两方共同配合。
△ 需求方比较满意的主 KV
其中有一个技巧就是:看看需求方是否有将主 KV 应用到整个大会的物料设计之中,如果有的话,那么幻灯片遵循对应风格一般都属于「政治正确」的操作。
2. 客户对幻灯片的期望
正如需求方对主 KV 的态度会影响他对幻灯片的期望,需求方希望设计师/团队能遵循统一的调性(毕竟是同一场大会),但如果直接 100% 沿用主 KV 的话,也可能会出现问题。
因此,设计师/团队需要和需求方确认幻灯片设计对于主 KV 的「沿用自由程度」。
△ 对主 KV 元素的 3 种沿用自由程度
这三种情况其实都真实存在,实际上我也都遇到过。
这里有个经验,是如果设计师/团队只问一个非常简单的问题:「幻灯片设计是否要按照主 KV 来走」。需求方一般会说:「我们要遵循主 KV 的风格」,实际情况是能要求完全不遵循主 KV 的需求方很少,除非设计师/团队成功做出了能惊艳到需求方的作品。
但由于没有明确「沿用自由程度」,就会在设计的时候带来较大困扰。
这个困扰主要来源于:对于主 KV 的「沿用自由程度」,直接决定了对于幻灯片的「设计自由程度」。
△ 扩充「设计自由程度」
设计师/团队和需求方确认主 KV 的「沿用自由程度」时,并不是在限制自己的「设计自由程度」,反而是在扩充「设计自由程度」——要知道设计过程中有哪些是不能做的,而有哪些是可以去尝试的,从而来确认有多少设计想法是被允许的,有多少程度是能被实施的。
因此在有主 KV 的大会,幻灯片背景设计的首要考虑维度是「主视觉」。
着手制作幻灯片背景的时候,在整体角度考虑下的「布局感」尤其重要,我们先看一个设计需求较高的案例:
对于设计感要求非常强的需求方,会希望每一页的背景都都尽可能的多变(即使是同样的元素,也希望把位置稍微调配一下),这一种需求对于设计的要求是比较高的。
△ 每一页背景都尽可能多变的需求
我们可以这么理解:
并不是背景每一页不同就是好的设计,对于内容比较多的幻灯片,需要在内容上分层级,例如有 4 个篇章的幻灯片,可能每一个篇章的背景是统一的,在下一个篇章的时候才会做一定的调整,正如「002 号知识发布会」的背景:
△ 通过整体布局规划实现背景布局感
幸运的是,在真实的使用场景中,所需要的程度通常是:在某一些页面有单独的定制化,而其他的页面可以使用统一的背景。如:20 页不同的背景,改为 8 个不同的背景(相当于:4 个章节+ 4 种背景+ 4 种背景),这是通过规划背景来提高统一性并降低设计难度,有实际应用意义。
需求方没有给到主 KV,或者甚至主 KV 也是由设计师/团队设计的时候,就要和需求方沟通他们想要的感觉,尤其注意演示场景对背景设计的影响,兼并考虑效果的美感度。
从单页的角度看,所有的背景都要考虑现场演示的「场景感」,其中较为突出的是纯色背景和经典搭配的渐变背景。
1. 纯色:简约大气
纯色的技法不难,但颜色选取非常重要,其中的难点主要是对于客户想表达的这一个内容的颜色匹配和颜色选取上。
其中分为:纯黑背景和其他颜色的纯色背景。纯黑背景带给人极其稳重的感觉,而其他颜色的纯色背景则相反,带给人干净洁净的感觉。
△ 不同气质的多种纯色背景
无论哪种纯色背景,其中有两个隐形的要求:
成像质量高的屏幕能让观众拍照时不会受到太多由于亮色纯色带来的成像问题,而越接近纯白色的色调就越需要现场灯光的配合,如果配合得不好,可能演讲人会成为背景上的「剪影」。
2. 渐变:经典搭配
渐变是发布会中一直都比较流行的背景色,Keynote 的自带模板 Gradient 就是这样的典范。
从上到下的黑色渐变到「深紫」「深蓝」「深灰」的搭配,在发布会中被使用频繁,由于底部颜色较浅,能更好衬托内容和演讲人,是发布会的经典搭配。
△ Keynote 的 Gradient 背景
除了之前提到的各种考虑外,设计的美观程度非常重要,有的页面在「纯色」「渐变」「肌理」等都可以选择的情况下,「设计感」就是其中很重要的思考出发点。
1. 渐变:多变流行
随着审美不断地提高,有很多国内大厂的发布会渐变是没有太多规律的,这种流线型的美感容易让别人对科技感和定制化感受深刻,这种渐变的制作难度会更高。
这种出彩的颜色在新兴行业使用较多,偏传统类型的公司就不太适合。
△ 背景非线性渐变背景的发布会应用
此外,接近纯色的背景上通过光影制造亮点也是高级手段,能让画面呈现丰富细节,显得耐看很多。
△ 通过光影制造背景亮点
2. 肌理:细腻耐看
单纯以肌理作为背景的设计并不算特别多,它的好处主要是在于让整个画面看起来更加有质感一点,比纯色要显得更加有设计感。
通常肌理也会和光影相结合,来体现这一个页面的高档和奢华感。通过案例我们也可以看到为了突出产品和高档气质的发布会页面会使用这一种设计。
△ 通过肌理突出页面气质氛围
由于每一页的幻灯片内容容量的差异,会造成在每页的版式差异,不同版式所需的「平衡感」所需背景是不同的:
△ 背景中添加辅助元素结合版式平衡页面
这 5 个性质的背景,都具备一个隐性的作用,就是对内容进行含义赋予,也就是增加「氛围感」。
如果一个幻灯片从头到尾都是纯色的背景,甚至也都是单一的背景,这一个背景能赋予这个页面的含义就是单一的,可能就是让人感觉到某一种感受,仅此而已。
△ 单一的背景
如果定制化比较强,就会有不同的需求对页面背景进行含义赋予,如:
1. 图形:属性点缀
有的时候我们也会用点线作为页面背景元素,使用「点阵」或者「多线段混合工具」效果填充页面,让整体的页面图版率提高。
△ 「点阵」和「多线段混合工具」效果
也会有一些情况会用圆形、点线、多边形来做页面的点缀,不同属性的形状会有不同的气质:
所以在选择的时候,我们会考虑想要体现的感觉来选取形状。
△ 圆形、三角形、多边形的图形背景
2. 全图:氛围浓烈
前段时间很多大厂不约而同使用了全图型背景,让这种设计手法广为流传。
具象的图片让观众直接身临其境,时间的朋友的「大豆君」、「深圳」都是这样的用法;而在一些企业愿景页上,直接放上公司的图片也能体现出非常直接的关联性。
△ 具象式配图
全图型的图片不一定和具体的内容完全一一对应,存在象征的可能,无论是:星空、山川,还是用黑板的粉笔字比喻算法等,都会在实际使用时起到象征的意义。
△ 象征式配图
如果既不是产品对应的具象图片,也不是起到象征意义的配图,就不要为了美观而放和主题无关的图片,否则容易让观众困惑。
实际使用的过程中,往往由于各种原因,直接找到的真实图片不足以支撑整个发布会背景,如:
这时我们就需要对图片「融合背景」处理,既和整体背景统一,也加入了页面的必要内容。
△ 象征式配图
如果页面内容需要实际真实可观的场景来辅助呈现,就需要通过合成来「制造场景」,让观众能直观看到文案含义,就能加速对内容的理解;还可以合成现实中不存在的图片作为背景,增加氛围的感受力度。
△ 象征式配图
背景的「跳跃率」是我从「文字」和「图片」的含义中引申使用的。
△ 文字跳跃率
△ 图片跳跃率
△ 图片跳跃率
文字跳跃率和图片跳跃率描述的是素材之间的大小、景深的差异,而借用「跳跃率」的名词来用在背景上解释,就是整个幻灯片背景的素材各方面的差异程度。
△ 整体调性和每页的调性
即使每一页单独看起来是比较和谐的,但受限于每页内容的图片质量、色调等的不同,不可避免地有可能整体看起来会显得比较混乱,这时就要做一定的调整,确保整体统一性,才能让作品形成整体。
其中要把握的是:既不能完全一样,也不能完全不同,这之间的取舍体现出的就是设计师在制作时的把握度了,也是功力的体现。
对于以下场景,你是不是有那么一点点熟悉:
视觉A:「视觉 B,把你之前的稿子发我下,我的页面里也有组件 A」
视觉A:「稿子里的组件 A 怎么跟视觉 C 刚刚发群里的不一样啊,我以哪个为主?」
视觉B:「刚刚业务通知组件 A 得修改,这次大促有 30+ 个页面都用到,这修改量这么大咋办?」
交互A:「这个 tab 上的文字看不清」,视觉A:「我觉得挺清晰的了」
开发:「为什么每次给的设计稿,明明长得都差不多,可尺寸就差了几个像素,我又得写新的样式表进去」
以上的对话,在大型且多人合作的项目中尤为常见。
随着大促项目体量越来越大,参与人员越来越多,这些问题越发明显,直接影响了活动的视觉统一性和整体的工作效率。因此我们开展了营销组件库的设计。
组件库就是界面设计常用控件或元件的集合,「组」是设计元素的组合方式,「件」由不同的元件组成。
其工作方式和乐高原理差不多,玩家(设计师)通过小元件(设计元素)或组件(模板)的不同组合形式,层层搭建和嵌套,最终组成建筑(页面)。
△ 乐高W16搭建过程,图片来自「什么值得买」
△ 页面设计过程
1. 保证用户体验的一致性
对于大促这种含有多个子项目,涉及到 30+ 的页面同期输出的复杂项目,每个独立的子项目虽然在需求上有一定区别,但整体的用户体验需要满足基本的一致性,减少用户认知和负担,提高用户的使用效率。组件库的建立,其统一的设计语言能保持设计结果的统一性,避免多人多风格的现象。
2. 提升效率
不同行业、不同产品、不同项目的组件库因其业务特点不同,其差异会非常大。那怎样的组件库才能满足「大促营销类」的项目需求?
分析研究
行业设计:行业优秀的设计系统、组件库搭建思维,以及其源文件,是最宝贵的学习资源。
主站设计:保证全站设计的一致性的同时,也是重要的学习参考;
过往问题:对过去项目的横向和纵向对比和分析,理解业务结构以及特点,从需求出发,拆解页面表达结构和所需组件的特点。
设计方向
通过前期的分析,明确了针对营销大促类组件库的设计方向:
拆分重组的组件化思维,解决模板灵活性和一致性的诉求
在设计方法上,我以 2013 年 Brad Forst 提出的原子设计方法论作为指导。方法的本质其实就是将页面拆解为最小元素(原子),然后原子可以演变成分子,分子通过多维度的组合形式成为组织,再到模板,最终生成页面(原理如下图)。
营销需求的多变性体现在分子的组合方式各不相同,但其共用特征是最小元素(原子)基本相同,因此统一最小元素,定义其组合的规则,即可从源头把控设计的一致性。同时通过特定的组合原则,设计师结合各项目需求根据组合和应用原则(布局、文字等)进行设计,从而实现其灵活性。
原子设计理论延展阅读:
明确了设计方向和设计方法后,结合营销项目自身的特点,开始了组件库的设计实施,整体流程如下:
梳理组件库
将近几期具有典型代表的页面收集整理分析,主要是为了以下 2 个方面的内容
ps:组件库强调的是通用和复用,因此无需把所有模块都纳入整理清单,做「合适」的,而不是大而全但可能臃肿的组件库。关于这个组件库的体量应该如何选择,可以看下文末的参考文献。
设计环节
梳理完组件库,按照原子设计方法论组件嵌套的形式进行组件设计。在 Brad 的概念里,是将系统分为了 5 个层级,但针对营销业务的多变性,要满足复用性和灵活性,越往上的层级复用性越差,因此在现阶段,采用了 3 个层级「原子-分子-组织」构成营销组件库。
「全局考虑」在设计的整个过程中,需考虑每个组件后续的使用场景以及设计师的使用方法,利用 sketch 功能(symbol 嵌套、丰富的配置项、响应式设计等),可以设计出一个高通用性的组件(如下图),以此达到增强每个组件的复用性,以及精简组件库的目的。(因文章篇幅受限,详细内容可见文末参考文献)
下面为每一个层级的详细设计:
第一层:「原子」是最基本和最小颗粒度的单位,工作中常以「元素」命名,例如:颜色、文字、图标、分割线等
布局:系统布局规范,需要通过统一的设计元素和间距规范去引导使用者们使用并且能够适配不同屏幕尺寸,目的是达到一致性,可适配、可控性原则。
「网格系统」通过前期的研究,网格系统采用的是目前最常用的「8点网格」,能更好地适配不同屏幕尺寸,2 倍的变化均能更好地保持偶数,不出现小数点的情况。
「设计原则」遵循格式塔理论:建立良好的信息层级,能让用户快速获取和理解有用、感兴趣的信息,并产生下一步行为。
颜色体系:「色值标准」为保证文本可识别性,结合Web内容无障碍指南(WCAG)2.0标准,做了以下定义:
颜色对比度检测工具:https://contrast-finder.tanaguru.com/
「衍生色设定规则」规律性设定衍生色,更好地打造页面信息层级
根据以上规则设定颜色体系
文字体系:项目中字体根据实现类型分为系统字体以及图片字体
「系统字体」为了较好的用户浏览体验,设计中优先采用开发直接写的系统实现的字体类型,不会因适配而产生文字不清晰或做图时不同系统渲染效果不同导致的不统一。
「图片字体」考虑到版权,以及字体在不同系统下渲染差异化的原因,选择了免费商用的思源黑体。
基础原子:「灵活性设置」充分考虑应用场景,利用 sketch 功能提高其包容性和灵活性。
第二层:「分子」原子排列组合构成了分子,工作中多以「模板」命名,例如:品牌模板、单品模板等
「局部到整体,整体到局部」原子和分子,其实是一个系统中,相互依赖的元素。因此在分子的设计过程中,会遇到原子包容性不足的情况,因此实际设计中,是不断在原子分子之间切换设计,不断完善各自的设计。
第三层:「组织」原子、分子排列组合构成了组织,工作中多以「模块」命名,例如:商品列表、内容卡片、入口模块、瀑布流图等
「保持克制,宁缺毋滥」该层面设计时,「局部影响整体,整体影响局部」的关系体现得更为明显,会在原子/分子/组织三个层面不断切换,进一步完善各个层面的设计。但过程中需保持克制,所有的设计应是围绕「复用性」和「灵活性」进行设计的,而非组合方式越多越好,多即意味着一致性在一定程度会受到影响。因此,应是从过往项目中,预测未来可能出现的情况,穷举后提取通用的组合规则后进行设计。
过程中多尝试不同方案设计,结合实际项目测试,择取最优方案。
整理设计文件,输出设计规范文档和使用说明。除了整理设计文件,梳理设计规范外,组件库相当于一个产品,需要有一份使用说明,为用户提供基础学习,提升团队成员的使用效率。
4. 迭代设计和维护
一个优秀的组件库绝不是 30 天速成班就结束的项目,而是一款产品,需有专人长期的跟进和维护,例:优化组件包容性;补充组织的种类等,从而逐步建立起适用于团队的组件库。
1. 打造组件库的几个关键步骤
2. 项目成果
组件库在 19 年双 11 项目中的应用,统一性显著提升,对比往年节省 76 人/天,平均效率提升 30%,其中主会场提升了 50%。
3. 项目反思
4. 设计小感悟:
蓝蓝设计的小编 http://www.lanlanwork.com