2021年8月

1.1 定义

作为一个B端产品,为了应对公司快速迭代开拓市场和一部分购买者的定制化需求,与此同时还要保障产品间的用户体验一致性,近年来设计规范这一解决方案不断升温,如Salesforce,antdesign、等纷纷推出了自己的设计规范。那么到底什么是设计规范呢?和设计语言、设计原则、组件库等有什么关系呢?

我认为的设计规范是以下的定义:

设计规范由设计原则、设计语言和组件库构成,在设计原则的指导下使用设计语言和组件库创建体验一致的用户界面。

设计原则:即整个设计规范所要遵循的全局规则,为设计提供方向指导。以下给出几个例子:

设计语言:包括色彩,文字、图标等

组件库:分为基础组件(按钮,下拉列表等)及业务组件(商品模块)。

在做设计语言和组件库时,有一个基本原则是,少即是多(less is more),用尽可能少的样式来实现设计目标,例如按钮提供三种尺寸即可,在适应不同场景需求的同时保证体验的一致性;另一方面,保持克制的设计规范可以进一步减少设计师的决策时间,提高设计效率。

1.2 理论基础-原子设计

1.2.1 什么是原子设计

原子设计是构建设计规范的核心指导理论。2013年,Brad从化学中得到了灵感,创建了原子设计理论。在化学中,所有的物体都是由原子构成,原子构成分子,进而构成宇宙万物。对应到界面中,界面也是如此,所有的元素都是由文字、颜色等最基本的元素构成的。这些基本元素构成组件,组件构成页面。

原子设计概念的提出使得设计规范演变成为了一种更为高效、科学的设计规范,极大的改善了设计师与前端工程师的工作体验。

1.2.2 原子设计系统的五个层次

原子设计包含五个同时工作的阶段,以更慎重和更具层次的方式创建界面设计规范。

原子:原子是构成界面的最小元素,例如颜色、文本、图标、线条。它们在在界面这个维度上不能再被细分。例如图标,本身是可以继续细分的,但是对于界面而言,图标细分得到的元素是没有任何意义的。

分子:原子按照一定的规律组合就构成了分子,它们拥有独特的功能,例如下拉列表,步进器等。

组织:在界面中组织体现为由分子原子组成的模块,例如数据概览的卡片。

模板:在界面中,模板的体现是原型图,是页面的基本形态,可以让我们快速试错,搭建出一个功能良好的整体。

页面:在模板的基础上将占位符更换为真实内容,并进行视觉优化即为页面。

1.3 为什么需要设计规范

1.3.1 软件危机

在讲述设计规范之前,我想先讲述一个互联网史上的真实事件——软件危机。

19世纪80年代,软件的复杂度进一步提升,大规模软件甚至会由由数百万行代码组成,有数以百计的程序员参与其中,抽象语言解放了程序员的生产力和想象力,人们可以像写文学小说一样随意发挥地去写代码。摆在面前的问题是如何高效且可靠地维护与迭代如此庞大的软件。之后C++、Java等我们熟知的面向对象的编程语言诞生了。

面向对象这种模式有一个很重要的特征是封装。这就好比当你在写王者荣耀的代码时,小兵是出现频率较高的模块,你可以提前把王者荣耀里的一个小兵封装成一个代码块,当你需要用到它时,不必重新一行一行写,只需要把它整体调用即可。

纵观软件发展史,20世纪60年代的第一次软件危机创造了“模块”概念;20世纪80年代第二次软件危机引出了“面向对象编程”,创造了“对象”概念;模块与对象本质上都是对软件进行拆分与封装,只是对象拆分的粒度更大,维度更高。这点与原子设计的原理不谋而合,从色彩文字等基础元素,到按钮、选择器等基础组件、再到典型模块,也是对大型软件的设计元素不同粒度的拆分与封装。

1.3.2 设计规范的优势

设计层面:解决用户体验一致性,减少设计成本,提高设计效率,使得设计师可以快速承接新需求。沉淀设计资产,使得设计更加持续地输出价值,减少一次性设计,同时使设计师从样式中解放出来,站在更高的层面上来思考业务与体验。

开发层面:与设计规范同步形成研发资产,避免重复造轮子,保证代码质量,降低维护和拓展的成本。

测试层面:避免重复的无意义走查。之前遇到过一个深色模式的需求,尽管只换了颜色,但是测试仍然把所有组件都测试了一遍,加上重复的设计、开发量,导致原本一个很简单的需求,居然花费了12人天的工作量。

产品层面:提高产品迭代与优化效率,降低试错成本。

协作层面:降低不同设计师之间以及设计师与开发工程师之间的沟通成本。

1.4 为什么要自己做设计规范

这个时候可以会有小伙伴问,目前市面上有这么多的第三方设计规范,例如antdesign,element,有必要自己重复造轮子做一遍吗?答案是非常有必要。原因如下:

B端自身的业务性决定了市场上没有万能的设计规范,那些设计规范的组件并不能100%满足我们产品的需求。另外一方面使用封装好的第三方设计规范,在此基础上进行修改,效率很低,适配的复杂度和重新开发相差无几。

大家都在使用第三方设计规范时,产品的同质化便不可避免。为了避免这种情况发生,我们必须要从设计语言开始,设计自己的规范。

那些大厂的成熟的组件库该如何用呢?我认为应该把它当成一个字典,有不会的地方,可以去参考人家的成熟的解决方案。

1.5 设计规范的落地

1.5.1 落不了地的原因

1.设计层面:

a. 组件扩展性弱:有的设计师做出来的组件虽然看着很好,但是实际上使用时,适配效率很低,用组件去扩展和重新做的效率差不多。

b. 脱离业务:大部分时候设计师手中都有任务,于是这个任务就落在了实习生的肩上,但是实习生不了解业务,做出来的是空中楼阁,抛开业务谈设计规范的都是耍流氓。

c. 缺乏开发思维:设计师不了解开发的实现方式,可能会做出来开发较难实现的组件。

2.开发层面

缺少开发资源:设计规范的作用是巨大而缓慢的,不能即时产出很大的价值,另外一方面,设计规范的落地会增加开发工程师很多的工作量,且无法量化收益。这也导致很多时候无法争取到足够的开发资源来做这件事,导致达不到预期的效果。

1.5.2 如何落地

说完了落不了地的原因,那么如何落地呢?我认为要从以下四个方面来推进:

写一份设计规范的价值的提案给领导,争取到足够的开发资源。

借鉴敏捷开发的思想,小步迭代快速推进,将设计规范的覆盖放在每次迭代过程中。

把设计规范的开发交给熟悉业务的设计师来做,通过业务提炼复用率高的典型元素,优先开发,最大化投入产出比。

设计师在做设计规范时,要不断与开发工程师沟通,保证设计规范的还原度。

B端UI界面的视觉设计是一种偏向与排版的设计类型,而其中对于文字的使用更是重中之重。文字包括字体,字重,字号,行高、颜色五个属性。一般情况下,字体采用系统自带的字体(例如苹方、微软雅黑、思源黑体),另外对于B端来说,一般都会有较为重要的数据,这时可以采用特殊字体给与一定的强调,最常用的便是DINpro。还有一点要注意,我们使用的字体一般是基于用户有什么字体,而由于win和Mac默认字体不同,所以要提前预留好字体风格类似的多种字体。并且可以设置多个字体,通过逗号隔开,如果第一个字体用户没有,那么会自动替换成下一个字体。

字号上,精简为主,可以用字重和颜色来表现层级,就不要用字号来体现。淘宝在2019年的改版中便升级了这一点。将原来的11个字体层级缩减至了7个。

行高上,我们目前采用的方案是行高是字体行高为150%字号,取4的倍数。

但是目前会遇到额外间距的问题。

前段时间谷歌发布了新的CSS更新“”leading trim,可能会是之后的行高解决方案。感兴趣的小伙伴可以点击链接了解一下(https://blog.csdn.net/weixin_39781930/article/details/111576051)

字重上,以开发的视角来看的话,包括从100-900的九个字重。一般我们只采用regular、medium、semibold三个字重。

3.1 基本介绍

3.1.1 色彩的作用

B端产品中,颜色不仅仅用来传达品牌调性,更多的是用来传达以下信息:

反馈信息 通过不同的颜色给予信息反馈,例如红色代表错误信息,绿色代表成功信息。

突出层级 通过色彩可以对内容信息进行分层级展示,提高用户读取信息的效率。

表明状态 通过颜色来区分某个事物处于何种状态。

3.1.2 组成

在真实的设计场景中,对色彩的复杂度要求是非常高的。色彩规范应该基本覆盖一套产品对用色的所有场景。

一套完整的色彩规范,包括品牌主色、语义色、中性色。

品牌主色:通常,一套产品只有一个品牌主色,是界面中出现最多的颜色,在需要用色强调而且没有其他要求时,一般都会选择主色,例如tab的选中态,图表的颜色等。

语义色:即功能色,借助人们的对色彩的心理模型,帮助人高效获得信息。例如绿色代表通行、成功,红色代表禁止、错误,橙色代表警告、

中性色:除文字外,中性色还被大量运用在分割线、边框、背景等场景中。

3.1.3 色彩系统的原则

理性的

      我们在选色时,尽可能避免个人的设计风格,减少配色的主观性,理性有逻辑地选色。

可扩展的

      使用这种选色方法可以扩展生成更多的颜色,以适应不同的变化。

和谐的

       色彩规范中的颜色互相搭配使用时,应该是和谐的。

3.2 如何制作色彩规范

在开始制作色彩规范之前,先介绍一下HCL色彩空间。

HCL (Hue-Chroma-Luminance) 与 RGB、HSB一样同属色彩空间的一种,因为最早由国际照明协会 CIE 提出,又被称作 CIELch。

目前大家常用的色彩数值可视化的色彩空间是HSB,设计师可以通过H(色相),S(饱和度),B(明度)三个数值来量化色彩,实现理性配色。但是传统的HSB色彩空间的缺点是,明度数值是基于计算机元件而言,而非人眼。另外,计算机的明度与人眼感觉到的明度并非线性匹配,这就导致在不同颜色中,即使色相相同,我们感觉到的明度(即感官明度)也是不一致的。而HCL就避免了这个缺点,在HCL中,只要两种颜色的L相同,感官明度就是相同的,HCL可以完美的量化我们对色彩明度的感觉。但是目前主流的设计软件基本上不支持HCL色彩空间配色,因此要借助插件或者网站。这里给大家推荐Figma的一个插件:HCL color。不用figma的小伙伴可以去这个网站http://tristen.ca/hcl-picker/#/hcl/12/1.03/000000/F69877。

3.3 落地

落地分为两个方面:设计方面和开发方面。

3.3.1 设计方面

将颜色生成样式库,并规定设计同事不可以手动调色,只可以从设计规范中取色。

3.3.2 开发方面

在前期与开发同事沟通,将每个颜色定义为一个变量,在代码中不使用具体的色值,而是例如red-100的的色值,这样做的好处是,

在需要替换某个色值时,只需要在底层对变量改变即可实现全局的更改,提高了很多效率。

开发同事完全从库中取色,保证了色彩的准确性,提高了设计稿的落地率。

现实生活中的物体不可完全重叠,当光打过来时,每个物体都会产生阴影。这是我们理解物体的层叠关系的重要依据。依据现实中的这一行为,我们把阴影规范挪到屏幕世界中,使得用户更容易理解我们的系统。阴影规范提供给了我们另一个表达元素区别的维度,不同的阴影清楚地传达了不同的交互状态。某一对象在屏幕中的高度视觉表现为其阴影,阴影越大,高度越高。但是生活中真实的阴影错综复杂,我们不可能也没必要完全复刻,我们只需要能够表达出元素层级即可。与按钮相同,我们将阴影分为三个等级,分别为,S、M、L。

S:突出组件悬停效果,表示可供性。对于这个数据概览卡片来说,鼠标移入移出时阴影的显示与隐藏提供了一个交互可能性,表明它是可以点击交互的。

M:给下拉列表,气泡提示等使用的阴影。因为这些元素是与由底层元素展开而来的,但又不属于底层元素,所以将中等层级的阴影给了这些元素。

L:模态组件阴影。例如弹窗。当弹窗出现时,弹窗位于绝对的最顶层,所以阴影最大。

圆角是用一段与图形两边相切的圆弧替换原来的直角,圆角的大小用圆弧的半径R表示。在界面中运用圆角主要有以下两个好处:

亲和感。我们倾向于“避免尖锐的边缘,因为在自然界中它们可能会构成威胁”。运用圆角矩形能给我们带来亲和感,圆角越大,亲和感越高。

辨识度。相对于没有圆角,人可以更快的辨识圆角矩形。

对于组件库来说,我们可以把组件比喻为积木,而布局则是把积木搭建为各种不同成品的图纸。

6.1 盒子模型

6.1.1 设计师为什么需要了解盒子模型

在介绍布局之前,先介绍一下盒子模型。虽然盒子模型是前端开发中的一个概念,但是了解一些前端知识对我们设计的落地以及与前端的沟通上大有裨益。我们可以带着盒子模型的思维去做设计,这样开发人员拿到设计稿后,更容易了解我们的布局逻辑,降低沟通成本,提高落地率。

6.1.2 盒子模型是什么

盒子(box)模型是开发中经常用到的CSS模型,我们日常所见到的界面都是由一个一个的盒子拼接而成的。打开安卓手机的开发者选项中的显示布局边界,便可以看到手机上的各个盒子的排列;在电脑浏览器打开检查视图,也可以看到每个元素对应的盒子。我们可以理解为开发同事都是先画一个一个的盒子,然后在盒子里填充,也与我们提供的矩形切图相对应。并且盒子间存在嵌套情况,几个小盒子可以作为一个大盒子的内容。

以我们的生活来举例的话,例如我们去买月饼,大盒子里装了四个小盒子,每个小盒子里是一个月饼。

6.1.3 设计师如何利用盒子模型

了解了盒子模型后,我们在设计时,该如何利用呢?

做设计时,对任何元素都尽量用一个矩形给他封装,这样子前端在定位元素和确定间距时可完美实现设计稿的内容。

而前段时间figma更新的auto layout 功能与盒子模型基本完美对应。我们在设计时可以使用这个让开发更容易get我们的设计稿,减少沟通时间。


以标签页为例,我们设计时,不只是画个横线与文字就行了,这样开发无法理解到设计稿,后面还会继续找我们询问触控热区。

6.2 导航

导航将网站的信息架构分组归类展示给用户,方便用户到达想去的界面。

6.2.1 顶部导航

优点:

符合人眼浏览网页的视觉动线,给用户提供更沉浸式的浏览体验。

缺点:

扩展性差:由于顶部空间有限,无法承载太多的菜单项,另外由于水平菜单的特性决定了无法承载太多的层级,当扩展至三个或四个层级时,顶部导航的易用性极差。

通用性较差:同样受空间的限制,菜单项字数被严格限制。

适用产品:

整体结构无论是广度还是深度均较简单且之后不会扩展很多功能的产品。

6.2.2 侧边导航

优点:

扩展性好:侧边导航是以树形控件的方式来表示的,相对于顶部导航,无论是数量和层级,扩展性均较好。

方便寻找:由于纵向浏览无需把每个单个菜单完整浏览,相对水平菜单,定位更快。

缺点:

沉浸感低:由于用户在浏览内容的过程中,不可避免会被左侧常驻的导航栏打断视线流,阅读沉浸感较低。

适用产品:

目前结构不是非常复杂但之后会迭代增加很多功能的产品。

6.2.3 混合导航

优点:

扩展性好:由于增加了-个顶部的一级菜单,扩展性是三者中最好的。

缺点:

交互路径长:除了和侧边导航-样存在沉浸感低的问题,由于每个菜单项都需要点击顶部和侧边两次,操作效率低。

占用空间大:在B端产品中,界面空间寸土寸金,混合导航常驻的两个导航占用了较多的空间。

适用产品:

目前结构已经非常复杂的庞大产品。

6.3 栅格

6.3.1 栅格介绍

6.3.1.1 来源

栅格系统原本来源于平面设计,早在20世纪初,德国、荷兰、瑞士等国的平面设计师们发现通过维持视觉秩序,从而使版面能更加清晰有效地传递信息,二战后这种理念在瑞士得到了良好的发展。有兴趣的小伙伴可以去看下由瑞士设计师大师Josef Miller—Brockmann (约瑟夫.米勒-布罗克曼)所著的《平面设计中的网格系统》一书。

6.3.1.2 优势

高效:将布局标准化,可减少设计决策的时间,让设计师专注于内容.上的设计呈现。

响应式布局:由于web端尺寸多样,使用栅格系统可以做到自适应布局(在面对多个分辨率的系统时,无需设计多套方案,仅需设计一套来适配即可)

美观:提高内容的规律性,让设计更有秩序和节奏感,赋予界面数学逻辑美感,提高用户的阅读和浏览效率,为用户提供更好的体验。

协作:由于栅格系统的可复用性,多个设计师合作时,可以共用-套栅格系统,提升整体布局的统-性。同时也避免了设计与开发的反复确认的情况,使得部门内部与部门间沟通更顺畅。

6.3.3 组成与原理

栅格系统包括页边距,列和水槽。

页边距:指内容区与页面的边距。

列和槽:列是承载内容的容器,水槽是两个列(即内容)之间的间距。在前端视角中列宽是根据百分比而不是固定值定义的。通常说的栅格数就指的列数。水槽越宽,页面留白越多,呼吸感越强。

自适应原理:在网页应用的设计中较为常见的一种响应方式,当屏幕宽度改变时,页边距和水槽宽不变,列宽自适应。

计算公式:以24栅格(即有24列)为例,页面自适应部分总宽度: 24*列宽 +23*水槽宽+2*页边距。

6.4 间距

在设计间距系统中,我们一般会基于8点网格系统和亲密性原理规定几个典型值。例如4,8,(12,)16,24,32……。遇到间距时在这些值中选取合适的即可。另外一般我们会使得大模块的纵向间距与栅格系统中的水槽大小相同。

7.1 图标重要性

当一个界面完全由文本构成时,用户被迫阅读每个文字来找到自己想要的信息。而引入图标后,降低了用户的认知负荷,帮助用户更快导航,提高用户使用产品的效率。另外一方面、设计精致风格统一的图标提高界面的美观度的同时,也为用户带来了连贯一致的使用体验。

7.2 图标规范的内容

尺寸:由于不同形状(三角形,圆形、长方形、正方形)具有不同的视觉大小,仅仅规范图标的大小是不够的,通常我们会设计一套图标keyline,来保证不同的图标具有相同的视觉大小。

填充/描边:一般的系统功能图标采用描边。工作台的常用功能入口一般采用带背景的填充图标,原因是在空间有限的的区域,太多形状会显得杂乱,另一方面面型图标的视觉面积较大,短时间内更加容易识别。

除此之外,还包括圆角、端点、线宽、倾斜角度等其他规范。

7.3 落地

在产品中,图标通常有多种尺寸,我们一般会为每个尺寸的图标各创建一个frame来进行管理,其中,我们会把同一个图标的填充版和描边版创建为一个组件集,这样在调用时可以直接控制图标的填充和描边,在做有选中态和非选中态的组件时尤为方便。

另外,在命名上,我们会用图标的内容为它命名而非表意,例如一个灯泡的图标,我们会直接命名为灯泡而非创意。

7.4 图标库推荐

在这里给大家推荐几个我常用的图标库,在来不及画图标时,可以先用这些迅速建立起一个图标组件库。之后有时间了再慢慢更新为自己的图标。

Iconfont:国内功能很强大且图标内容很丰富的矢量图标库,提供矢量图标下载、在线存储、格式转换等功能。特点是图标非常丰富。

Remixicon:Remix Icon 是一套面向设计师和开发者的开源图标库。质量很高,风格中性大气,因此适用于很多风格的项目,分为“线性图标”和“面型图标”两种风格。相比于 Material Icons,RemixIcon 看起来风格会更统一、简约且精致硬朗一些。

IconPark:这是字节CUX设计团队出品和维护的开源图标库,如今已对外开放使用,特点是图标大小,线宽等多个属性均可设置,自由度较高。

8.1 文案是什么

文案是我们的产品与用户交流的最基础最简单的沟通工具。文案存在于产品的各个地方,例如按钮文案告诉用户按钮的作用,轻提示文案告诉用户反馈结果。对于新用户来说,文案肯定比图标易理解,另外一方面,文案更不容易产生歧义,例如一个图标可以会有多种意思,而文案相对更精确。

8.2 文案规范的重要性

伴随着B端的业务功能的快速迭代,由于设计师、产品经理的水平、文案风格、对文案的重视程度不同,导致系统内部文案积累了很多问题,最明显的问题,同一场景文案不一致,会给用户带来体验的割裂感,增加用户使用产品的认知成本。

而通过构建文案规范,可以规范文案的使用和编写,提高文案的质量,给用户带来连贯一致的使用体验。

8.3 文案撰写的原则

这里给大家介绍一些产品文案通用的一些原则,包括,准确,简洁、用户视角

8.3.1 准确原则

8.3.2 简洁原则

8.3.3 用户视角原则

8.4 落地

一般情况下,文案没有专门的人来负责,国外可能会有“UX Writer” 这样的专门职位来负责,在国内一般会交给体验设计师来负责。

文案规范的落地分为四步:

1.    遍历页面,列出所有的文案

2.    梳理相同或相似场景的文案,将文案归类整理

3.    根据实际情况制定产品文案的原则,并撰写一部分典型场景的文案。

4.    输出文档,包含文案撰写原则及典型场景的文案。

9.1 组件库是什么

组件库相当于乐高的一个个积木,通过组件的拼搭可以迅速搭建出一个页面。通常我们将组件库分为基础组件和业务组件两大类,前者是系统通用组件(图标/按钮/输入框等),后者是由业务决定的相对更复杂的组件模块。而对于B端产品和C端产品,二者的组件库又有些许差异。C端的组件库更追求极致的交互和视觉体验,因此需要考虑视觉、性能、实现、兼容性,另一方面,C端会根据活动、节日切换不同的主题,也要考虑组件视觉上的个性化扩展。对于B端而言,组件库更看重可复用性和稳定性,保证可以支持业务快速迭代。另外B端会涉及到各种各样的数据录入与展示,因此相对更高的要求是大而全,覆盖面广。

9.2 如何做组件库

9.2.1 确定组件库的内容

新产品

对于新产品来说,业务体量较小,较难抽取共性,组件也不全面,因此较好的方式是参考大厂的组件库确定要做哪些组件,它们的相对成熟,参考价值较高。

成熟产品

对于已经成熟的产品来说,我们可以直接遍历页面,穷举出所有用到的组件,除基础组件外,提炼出复用率高的业务组件进行结构化和组件制定。

9.2.2 搭建每个组件

以警告提示(Alert)为例,演示单个组件的建立方法。

   1. 定义组件

       根据业务定义警告提示的使用场景,警告提示用于重要信息的提醒,采用非浮层的方式展现在页面顶部,被动出现,且不会自动关闭。

2. 拆分组件

      这一步是将组件拆分为元件。对警告组件进行拆分后得到如下:

   3. 重组输出

       根据业务场景,我们把各个元件重组为组件,建成组件集,并定义各种组件的使用规则。

9.2.3 输出文档并替换到产品中

在组件库建立完成后,只有在日常设计中真正使用组件库,提高组件库在设计稿中的覆盖率,才能真正达到组件库的效果。这就要求我们要输出一份完整的组件库描述文档,在团队中进行推广,加强设计团队的公用意识。另外,我们还要与开发工程师配合逐步完成现有页面的组件替换。

9.2.4 定期维护组件库

组件库的内容并非一成不变,而是在不断地更新,以保证所包含的组件都是最新和有用的。与其他数据一样,组件也会有增删改。

增:当有新的组件产生时,我们需要通过判断它的拓展性和复用率,以确定是否将它入库。

删:随着产品的不断升级迭代,如果某个组件已经不用或复用率很低时,我们可以考虑是否要将它删除。

改:不可避免的,组件会随着业务而进行升级,我们可以通过数据埋点和A/B test的方式来确定某个组件是否要进行改动。

10.1 PC端设计规范

Ant Design

Ant Design是由蚂蚁集团体验技术部经过大量的项目实践与总结,逐步打磨出来的,基于「自然」、「确定性」、「意义感」、「生长性」四大设计价值观,通过模块化解决方案,降低冗余的生产成本,让设计者专注于更好的用户体验,是非常完整的一套设计规范。

Zent 

Zent是有赞 PC 端 Web UI 规范的 React 实现版本,提供了一整套基础的 UI 组件以及常用的业务组件。通过 Zent,可以快速搭建出风格统一的页面,提升开发效率。目前有 50+ 组件,这些组件都已经在有赞的各类 PC 业务中广泛使用。

Element 

Element是由饿了么公司前端团队开源一套为开发者、设计师和产品经理准备的基于 Vue 2.0 的组件库,提供了配套设计资源。

AT-UI 

AT-UI 是一款基于 Vue 2.x 的前端 UI 组件库,主要用于快速开发 PC 网站产品,在众多的的组件库中,AT-UI 属于视觉风格比较清新的一款。

10.2  移动端设计规范

Vant

Vant 是有赞前端团队开源的移动端组件库,于 2017 年开源,已持续维护 4 年时间。Vant 对内承载了有赞所有核心业务,对外服务十多万开发者,是业界主流的移动端组件库之一。目前 Vant 官方提供了 Vue 2 版本、Vue 3 版本和微信小程序版本。

NutUI-JDL

NutUI-JDL 是一套基于京东物流视觉规范的移动端组件库,包含了36+高质量组件和详尽的文档和实例。

本次的分享到这里就结束了,希望可以对大家有帮助。由于文章字数较多,笔者几经修改,仍不免有疏漏错误之处,如发现错误,请读者于评论区或私信指出,不胜感激。

在快节奏的洪流中,保持设计的初心,做有灵魂的设计。


以上文章来源于MICU设计 ,作者JIN石为KAI

链接:https://www.zcool.com.cn/article/ZMTIxODExMg==.html



作者:混沌小肉团01
链接:https://www.jianshu.com/p/26afb8bf783c
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


每天都会去 ProductHunt 看看,这是一个发掘有意思产品的国外平台。

这个平台现在已经成为了用户发现新产品、创业者们获得灵感、投资人们寻找新机会,以及创始人对自己的产品进行推广的最佳去处。

最近一段时间,ProductHunt 平台诞生了很多受欢迎的新产品,这些新产品大都有一个标签:low code。

image

低代码是通过可视化方式创建应用的一种概念,特点是代码量比传统开发少得多,甚至无代码,能显著提升开发效率。而如今,低代码不仅仅局限于软件应用的研发,只要是通过可视化的交互来帮助使用者完成一个作品都属于低代码的范畴。

如果你还不明白低代码是什么概念,可以看一下本文章提及的开源项目。这篇文章盘点了 10 款 GitHub 和码云上最受欢迎的低代码开源项目,记得收藏。


*01. *****快速搭建 H5 页面

鲁班 H5 生成器

鲁班 H5 是基于 Vue2.0 开发的快速生成页面的平台,通过简单的拖拽交互方式即可迅速的完成一个页面的制作,类似 易企秀、Maka、百度 H5 等平台。

左侧是常用的组件,右侧是组件的属性调节界面,中间区域就是编辑和预览区域。鲁班 H5 包含了丰富的组件可以选择,其中包括:

  • 雷达图、折线图、柱状图、饼状图、漏斗图

  • 图片、评分、表单、文字、地图、视频等

image.png

图标和地图组件

image

折线图组件

image


个人作品低代码平台

这个项目基于 Vue.js 技术栈,平台主页面分为四个部分,分别是工具栏、组件列表、画布、属性区域。将组件拖至画布区域。

用户可以将组件列表的组件拖到画布,对画布上的元素进行编辑。这仅仅是一个 Demo,其余更丰富的组件可以二次开发。

image

image


构建页面可视化编辑器

还有一个页面可视化的 Demo,基于 next.js 构建页面可视化编辑器。整个编辑器的研发逻辑为前端开发组件库,编辑器读取组件完成页面搭建,将页面数据发送至服务端保存。访问页面,从服务端拉取页面数据,前端渲染页面即可。

image


随心秀 react 版 H5 微场景编辑器

编辑器功能:拖拽、缩放、旋转、动画、撤销、重做、组合元素

组件:物料、文本、图片、QQ语言通话、背景、地图、音效、模板、视频、艺术字

image


H5-factory

H5 专题页面可视化编辑工具,拖拽编辑,灵活切换,一键生成 HTML 文件。关于这个开源项目的系统架构设计和组件拆分原则可阅读文章:

https://juejin.cn/post/6844903858401968136

image

image


H5 移动端低代码平台

vue3.x vite2.x vant element-plus H5 移动端低代码平台 lowcode 可视化拖拽 可视化编辑器 visual editor 类似易企秀的H5制作、建站工具、可视化搭建工具

image


*02. *****一个海报生成器

海报编辑器最左侧是组件列表。可以在最左侧选择组件,比如文本、二维码、图片等添加到最中间的画布区域,通过右侧的属性调节面板调节添加组件的样式。

快速:三步完成海报开发工作:启动服务 > 编辑海报 > 生成代码

简单:组件丰富、支持拖拽、复制、所见即所得、下载等功能。

动态:无需更改代码,直接在编辑器修改海报即可获得最新的海报。

image.png

上传头像

image.png

进行预览

image.png

获取代码:点击 代码,可以查看相关的接⼝调⽤代码。

image


*03. *****JEECG BOOT 低代码开发平台

JeecgBoot 是一款基于代码生成器的低代码平台!前后端分离架构 SpringBoot2.x,SpringCloud,Ant Design&Vue,Mybatis-plus,Shiro,JWT,支持微服务。强大的代码生成器让前后端代码一键生成,实现低代码开发!

Online表单开发、Online报表、报表配置能力、在线图表设计、大屏设计、移动配置能力、表单设计器、在线设计流程、流程自动化配置、插件能力(可插拔)等等!

image

[图片上传失败...(image-b7c20e-1626093914733)]

[图片上传失败...(image-64c781-1626093914733)]


*04. *****amis 低代码工具

作者认为:对于大部分常用页面,应该使用最简单的方法来实现,甚至不需要学习前端框架和工具。

amix 就是这么一款低代码工具。它通过 JSON 配置就能生成各种后台页面,极大减少开发成本,甚至可以不需要了解前端。它的独特好处是:

  • 不需要懂前端也能能做出专业且复杂的后台界面,这是所有其他前端 UI 库都无法做到的;

  • 不受前端技术更新的影响;

  • 可以完全使用可视化页面编辑器来制作页面;

image


*05. *****Seezoon Stack

Seezoon Stack 是一款基于当前最前沿的前端和后台实现的低代码开发平台。前端技术栈基于 Vue3 + Vite + Antdv,后端技术栈基于 Spring boot。

它以快速开发为目的,在开发速度和代码结构上做出一定取舍,无论如何,你将看到非常地道的 Java 常用开发框架使用。该项目采用主流开发框架,无论打包、编译、部署都按着大公司的标准完成并不断逐步完善。

image

image



作者:小狐憨憨
链接:https://www.jianshu.com/p/1d09e0ed6fa0
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


LowCode 是高效、高性能的拖拽式低代码开发平台. 也是笔者最近一直在研究的方向, 对于可视化搭建平台的实现方案笔者之前写过很多文章, 这里带大家探索一个新方向——基于自然流布局的可视化搭建平台.

在我们之前实现的 h5-dooring 搭建平台中, 我们采用了网格布局的方式来实现拖拽生成H5页面或者Web app, 其好处就是灵活简单, 用户基本没有任何使用成本, 在前端层也能做一定的横向扩展, 但是存在几个缺陷:

  • 实现嵌套组件比较复杂

  • 没有层的概念

虽然通过改造可以实现层和嵌套的问题, 最近也在努力往这个方向实现(虽然和设计初衷相驳, dooring的初衷是抹去层和嵌套的概念, 让搭建扁平化和智能化, 所以没有采用自由布局的方案)

image


但是如果一定要实现嵌套和层的功能, 有没有另一种更简单的方案呢? 笔者目前想到了两种解决方案:

  • 将智能布局改为自由布局, 即可以采用类似 react-resizable 的这种方案

  • 基于自然流来实现, 也就是抹去定位的概念, 完全基于元素在文档的顺序, 层级和定位的选择权交给用户

因为第一种方案笔者在dooring的早期已经实现过一版, 最后弃用采用了网格布局, 所以说我们来探讨一下第二种方案的实现.

基于自然流布局实现拖拽生成页面

自然流布局的好处就是我们不用通过定位的方式来限定元素的位置等信息, 而是以html文档流的方式来布局元素, 并且用户可以灵活的设置元素的层级(layer)和偏移(transform), 接下来我们来看看简单的实现效果.

1. demo效果

image


image


由上图的demo我们可以发现组件在画布中的布局完全是默认的文档流的方式, 所以我们有更灵活的布局实现.

2. 实现思路

具体实现思路主要分以下几个部分:

  • 组件区拖拽至画布

  • 画布区拖拽

  • 组件编辑器和更新机制

第一点和第三点我们在 H5-dooring中已经实现了, 感兴趣的可以看我之前的文章, 我们这里重点来实现画布区拖拽, 也是比较核心的环节.

2.1 H5拖放api基本介绍

拖放(Dragdrop)是 HTML5 标准的组成部分, 早已被大多数浏览器支持. 我们目前使用的拖放插件基本上基于 H5 拖放 API 来实现的,  其实实现第一点组件区拖拽至画布我们完全可以用原生来实现, 这里笔者简单来介绍以下.

首先我们来看看一个完整的拖放过程:

  1. 首先要设置一个元素可拖放(比如<img draggable="true" />)

  2. 设计拖动的时候会发生什么(需要用到ondragstart事件 和 setData(你要传递的数据))

  3. 放到何处,也就是目标容器(通常在目标容器上绑定ondragoverondrop事件)

有了以上3个步骤, 我们就能实现第一点的需求, 笔者写个简单demo来给大家参考一下:

<script type="text/javascript">
  function allowDrop(ev) {
    ev.preventDefault();
  }

  function drag(ev){
    ev.dataTransfer.setData("Text",ev.target.id);
  }

  function drop(ev){
    ev.preventDefault();
    let data=ev.dataTransfer.getData("Text");
    ev.target.appendChild(document.getElementById(data));
  }</script><div id="box" ondrop="drop(event)" ondragover="allowDrop(event)"></div><img id="drag" src="dooring.png" draggable="true" ondragstart="drag(event)" width="336" height="69" />

也就是对应的我们的组件拖放区域, 如下图所示:


image

2.2 画布区拖拽布局实现

因为之前的版本我们采用了网格布局来实现智能拖拽, 由于内部定位机制采用的是绝对定位(absolute), 所以是实现层级和固定组件比较困难, 如果组件的呈现完全脱离了定位的束缚, 我们就可以实现以上的困境了. 所以这里我们调研了一种方案——拖拽排序机制.

自然流布局的规律就是默认情况下html页面是基于dom出现的顺序来排列的, 也就是我们说的堆叠.

image


我们可以遵循这样的设计, 通过排序的方式改变组件的位置从而实现自然流布局的页面搭建.

那么我们再回到上面说的布局问题, 比如说要想实现栅格化布局, 我们只需要定义一个flex容器, 将组件拖拽到容器里就好了, 这样也就解决了嵌套的问题.  同时我们还可以设计嵌套容器的栅格数, 这样就可以实现类似如下的效果:

image

拖拽排序的库我们可以使用:

  • sortable

  • Vue.Draggable

  • react-dnd

还有很多优秀的库, 这里就不一一举例了.

3. 如何实现层级和嵌套

其实在上面的实现思路中我们已经解决了嵌套的问题了, 即提供拖放的容器组件, 利用笔者在上文中介绍的拖放api即可实现. 对于组件层级来说, 因为我们采用的是自然流布局, 所以我们可以轻松的设置元素的定位属性, 比如我们提供一个定位的设置:

image


关于如何设计一个动态的属性编辑器, 笔者之前文章中也就详细的介绍, 大家可以参考:

以上就是自然流布局的基本实现方式, 后续笔者也会在github上同步我们最新的成果.

H5-Dooring编辑器wiki: https://github.com/MrXujiang/h5-Dooring/wiki

最后

觉得有用 ?喜欢就收藏,顺便点个吧,你的支持是我最大的鼓励!搜 “趣谈前端”,发现更多有趣的H5游戏, webpack,node,gulp,css3,javascript,nodeJS,canvas数据可视化等前端知识和实战.



作者:趣谈前端_徐小夕
链接:https://www.jianshu.com/p/7b2052d0a74d
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


导语: 低代码(lowcode)平台是近两年讨论比较火热的话题,其通过自动代码生成和可视化编程,使得使用者只需要编写少量代码,即可快速搭建各种应用,满足了很多技术和非技术人员的需求。最近作者也一直在研究低代码相关的产品设计和技术方案,持续完善可视化编辑器H5-Dooring。接下来将围绕低代码平台以及数据源设计来展开分析, 希望对大家有所帮助.

低代码平台解决的问题

低代码平台属于APaaS(应用平台即服务),其解决的是企业内部应用协调和人效成本的问题. 随着计算机技术诸如云服务等的发展, 传统软件服务已无法满足数字化浪潮的压力, 笔者对企业迫切需要解决的问题做了如下总结:

  • 企业数据孤岛(应用间数据共享,互通困难)

  • 企业定制化需求日益增加(不同行业赋能不同的应用场景, 千“客”千面)

  • IT人才供不应求

  • 沟通成本,研发成本, 研发周期吃紧

  • 产品迭代和响应性迟缓

所以我们迫切需要诸如低代码/零代码这样的方案, 来解决上述问题.

当然lowcode平台很早就已经出现了, 国外的西门子(SAP), 微软, 谷歌已经有非常成熟的方案, 国内也不在少数, 但是形成跨行业通用解决方案, 还有很长的路要走(比如如何解决国内各大平台的小程序搭建化).

其基本流程如下:

image.png

数据源

上面介绍了低代码的基本概念和解决的痛点, 下面我们继续分析一下低代码的组成和数据源设计.

低代码基本包含如下部分:

  • 用户端编辑器

  • 管理终端

    • 数据源

    • 页面(应用)管理

    • 模版管理

    • 组件管理

    • 资源库管理(图片, 字体, 自有sdk, 插件等)

    • 角色管理(非必需)

如下图所示:

image.png

用户端编辑器部分主要是设计拖拽, 组件渲染相关的技术基建, 这部分笔者在这之前文章中也做过大量分享, 比如智能网格布局拖拽模式, 自然流拖拽搭建模式, 自由布局模式等. 详细可参考源码:

本文的重心在数据源设计, 接下来我们开始数据源的分析.

什么是数据源呢? 笔者的理解就是 数据的来源,是提供某种所需要数据的母体。在数据源中存储了所有建立数据库连接的信息, 通过提供正确的数据源名称,我们可以找到相应的数据资产

image.png

低代码的产物, 有纯静态的页面, 也有需要对接动态数据的动态页面, 低代码平台的数据源主要就是为动态页面(业务系统)设计的. 低代码平台使用人员可以选择或者创建数据源, 变量, 函数, 自定义事件等来供页面和组件实现数据对接和页面交互, 通过这种方式可以进一步降低数据对接复杂度并提高研发效能.

image.png

对于数据源的设计, 根据实际的业务需求, 我们可以分为静态数据源和动态数据源. 静态数据源是用户可以通过可视化的方式在低代码平台上创建的, 比如编辑数据表格等.

image.png

动态数据源是指用户可以自定义的请求第三方的数据服务, 组件消费数据源完全是动态调用的, 类似于我们传统开发时使用的ajax请求.

image.png

基于以上的概念, 我来带大家介绍一下

H5-Dooring的数据源实现.

image.png

数据源编辑界面:

image.png

首先Dooring的每个用户都有独立的数据源仓库, 可以配置不同的数据源供组件消费, 数据源会保存在对应的用户下, 用户可以让不同的页面/组件消费数据源.如下:

[数据源模式]

1. 静态数据源实现

静态数据源即用户在平台自己创建的数据源, 我们将此类数据源存放在公共状态中让组件消费, 比如redux或者vuex中, 同时对其进行数据库存储. 具体流程如下:

image.png

从代码层面, 我们只需要把从服务器获取的静态数据源, 存储到客户端全局状态中, 对于用户自己创建的数据源, 我们提供数据库的CURD操作即可.
如下图:

image.png

2. 动态数据源

动态数据源设计需要一套组件数据协定, 需要约定第三方接口遵循低代码平台数据规范来返回数据, 后者手动通过编程的模式来对应字段和组件数据的映射关系.

image.png

具体方案类似于我在可视化组件中实现的第三方数据接入的方案:

image.png

这样, 组件既可以消费静态数据, 也可以动态加载第三方数据, 进而实现了低代码动态页面的搭建.

最后

最近H5-Dooring可视化搭建平台也在持续推迭代, 数据源已基本搭建完成, 后续还会按照更智能化的方向. 一下即是最近的更新日志:

  1. 优化编辑器加载性能

  2. iframe容器组件添加边框等属性

  3. 富文本组件添加背景色配置

  4. 修复真机预览时空数据还能显示二维码bug

  5. 优化页面高度适配问题, 添加高度适配器

  6. 优化组件交互时空链接点击出现message bug

  7. 更新dooring文档

国内lowcode平台仍然有很长的路要走, 期待大家一起努力

目前低代码技术正处在风口,低代码平台产品不断涌现,乱花渐欲迷人眼。作为软件公司或企业IT部门的负责人,在做低代码平台选型时需要关注哪些方面,才能顺利“上车”,让低代码为自己的团队赋能?

除了产品功能是否满足当前项目需求,价格是否在预算范围内之外,以下几个问题的答案同样重要。

Q1:是否支持协同开发和版本管理?

项目开发过程中,我们难免遇到客户反馈某个新开发的功能没有用,但是过一段时间以后反悔,又希望加回来的情况。这是软件开发的常态。为了解决这一问题,传统的软件开发团队都会引入版本管理机制,低代码也不例外。面对频繁的需求变更、棘手的问题排查,低代码平台的版本管理,特定模块回滚等操作的价值就会体现出来。

此外,为了加速项目的交付速度,我们通常需要集中更多人员进行同步开发。只有具备协同开发能力的低代码平台才能让这一过程变得可管理,避免混乱。

所以,不论项目规模大小,选择一款兼容主流代码库、支持敏捷开发的低代码平台都会对开发工作有所帮助。

Git:一款主流的版本控制系统,图片来自Git官网

Q2:是否支持自由设计数据库结构?

数据库是所有企业管理软件的“地基”。为了后续功能的开发更加方便,扩展性更强,维护性更佳,良好的数据库设计至关重要。这个点是企业软件自身的属性决定的,无论是低代码还是传统的纯代码,都不会有变化。

事实上,软件开发技术发展到今天,数据库设计的最佳实践早已被总结成了久经考验的数据库设计范式。低代码开发平台是否能够对开发者开放数据库结构的自由设计能力,能够让开发者基于数据库设计范式不断优化数据结构,直接决定了该平台的专业性。如果你需要开发高标准的核心业务应用,或者对应用后期的可扩展性、可维护性有要求,那么数据库设计能力在评估过程中至关重要。

满足设计范式要求的数据库结构示意图,图片来自网络

Q3:能否灵活自由设计显示页面?

不同的企业、不同的用户都有着差异化的使用习惯和审美风格。即便面对同样的业务需求,客户对软件的页面呈现和交互也会有完全不同的要求。举例来说,客户A比较喜欢在页面的右上角寻找提交按钮;客户B可能习惯于提交按钮出现在页面的正下方,客户C则对提交按钮放到页面的右下角的设计更加青睐。于是我们需要为不同的客户做不同的页面布局,以缩减使用培训成本,提升用户的满意度。

类似的问题和解决方案,我相信您在多年的软件交付经验中已有体会。当然这里举例可能是冰山一角,客户对页面布局和样式风格的差异化要求远不止于此。如果您认可满足用户的使用习惯,适配公司的设计风格的重要性,那么请尽量选择支持灵活自由设计显示页面的低代码平台,以确保我们在项目开发和交付时不会陷入被动。

使用同款低代码平台开发不同样式的表格,图片来自活字格官网

Q4:能否支持前后端分离的系统架构,后端复杂逻辑如何解决?

正如前面所说,软件行业发展了多年,沉淀出了很多最佳实践。与数据库设计范式类似的,还有前后端分离,数据库读写分离等等。上一点重点讲了前端,这里则要将目光转向后端。

在前后端分离架构的支撑下,不论是软件公司还是企业IT团队,在发展的过程中都会积累出自己的“核心数字资产”,这些资产往往表现在一些后台业务复杂逻辑计算方法(有的可能还会包含一些用于调优的“魔法数字”)。后台的逻辑复杂度高、技术积累价值大,相对较为稳定。如何用低代码实现后端复杂的业务逻辑,持续积累“核心数字资产”,是低代码平台必须解决的问题。在做技术评估时,千万别忘了这些运行在后台,没有任何界面的逻辑,因为这些才是系统和开发团队的核心竞争力。

前后端分离,图片来自网络

Q5:是否有全系统模块的解决方案?

在实际项目交付过程中,如果我们仅可以满足99%的需求,另外1%的需求满足不了,真实用户大概率是不会买单的。因此,在评估低代码产品的时候,我们一定要保证该平台可以支撑所有系统模块类型的开发,至少也要有足够的扩展性,可以确保使用纯代码开发出的模块能够与低代码模块进行无缝集成。

考虑到巨大的生产力差距,低代码平台覆盖的模块越多,整个项目的开发效率也会越高。那么,企业软件通常会涉及哪些类型的模块呢?我将其中最常见的列举如下:

  • 多终端页面

  • 可精确打印的报表

  • 图表构成的可视化大屏

  • 自动化任务

Q6:如何保证开发出应用的系统安全性?

安全性对任何一个系统都至关重要。使用低代码平台所开发出的应用中,绝大多数逻辑都是低代码开发者自行构建的,而不是出自低代码平台厂商。所以,我们很难通过平台的安全性报告来简单评判开发出应用的安全性,这就相当于没人关心Visual Studio和eclipse的安全报告一样。

这并不意味着我们不需要关心低代码平台自身的安全性。那么,我们该如何看待低代码平台的安全性,如何评估使用该平台开发出应用的安全性?以下几点值得参考:

  1. 该低代码平台是否有金融或者银行业的客户?这些行业一般对安全性要求比较高,他们能用一般行业肯定可以使用

  2. 在评估阶段,您可以基于该平台创建一个demo程序,并对这个demo做安全性检查,下面是一些安全检查的工具或者产品:ZAP – OWASP(免费)、SonarQube – SonarWorks(收费)、Burp Suite – PortSwigger(收费)、AppScan - IBM(收费)

OWASP的ZAP检测工具,图片来自ZAP官网

Q7:平台是否独立,能够不依赖其他第三方的产品?

这个点听上去有些奇怪,为什么会有低代码平台依赖特定的第三方产品?这就与国内低代码所处的发展阶段有关了。我来举两个例子:

  • 有的产品说他是Excel的设计模式,但是其实他们所有的页面设计都是在Excel中,甚至访问时也是在Excel中访问,听起来没什么大问题,但是这其中有一个非常重要的点,Excel经常会更新Excel2008,Excel2010,Excel2016,….,这样每一次Excel升级,您都需要重新购买一次他们这个平台了;

  • 有的低代码产品说自己是B/S架构,但是你必须安装他们特定的浏览器才能访问,这跟C/S架构的系统有什么区别?

为了确保后面的开发和部署过程可控,我推荐您优先选择独立的低代码平台。如果因为其他原因需要选择一款依赖特定的第三方软件,如数据库、Web服务器等的低代码平台,则需要将这些依赖的软件纳入部署清单和操作手册。

Q8:是否会产生新的“数据孤岛”?

数据孤岛这个概念从提出到现在,一直是企业信息化行业最希望解决的问题。作为新一代的软件开发技术,我们不需要使用低代码开发出来的应用成为新的数据孤岛。所以,不论是连接现有的数据库,还是支持通过Web API与其他软件互通,低代码都必须具有开放性,不能产生新的数据库孤岛。

跟进一步,如果该低代码平台可以帮助我们解决企业的数据孤岛问题,将多个系统打通,通过整合多源数据实现协同增效,那就更是一个加分项目了。

数据孤岛现象,图片来自网络

Q9:该平台的产品生态建设如何,是否有激励机制?

聚沙成塔,如果一个低代码产品选择孤军奋战,没有生态,大概率是不能长久的。对于低代码开发平台,生态的价值主要体现在以下两个方面:

  • 模板:模板也叫开发成果,是指开发者使用低代码平台为特定行业或场景构建的“半成品”系统。基于半成品进行二次开发,可以进一步提升企业应用的构建速度。成熟的低代码平台通常具备模板市场,通过商务和技术手段,鼓励开发者将自己使用该平台开发出的应用放在市场中分享或销售,打造“人人为我,我为人人”的正向循环。

  • 插件:低代码平台通常会开放插件机制,以吸引更多开发者封装自己开发的“模块”。插件和平台在一起运行,让低代码平台的应用场景更丰富。事实上,一家平台厂商的技术能力再强,也不能全部满足客户的所有需求。只有开放插件机制,建立插件付费环境,才能让广大的开发者都参于进来,共同打造更强大的平台。

低代码平台生态的关键在于如何建立长效激励机制,实现正向循环,通俗的理解就是让生态上游的开发者可以通过付费机制获得合理的回报。我们相信,只有提供长效激励机制的平台生态才能持久。

多种连接器插件,图片来自Power Apps官网

小结

在低代码平台的井喷期,使用者更应该擦亮眼睛,选择合适的平台产品,充分利用新技术带来的新价值、新动能。上面九个问题,就是我为您整理的低代码技术选型思路,希望能够帮正在评估低代码平台的软件公司和企业IT部门少走弯路,抓住时代潮流,开启低代码之旅。



作者:低代码观察员
链接:https://www.jianshu.com/p/e9293f6c9add
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。