2023-12-09 10:20:19 | 新橄榄网
基于微信小程序轻快的特点,我们拟定了小程序界面设计指南和建议。设计指南建立在充分尊重用户知情权与操作权的基础之上。旨在微信生态体系内,建立友好、高效、一致的用户体验,同时最大程度适应和支持不同需求,实现用户与小程序服务方的共赢。
为了避免用户在微信中使用小程序服务时,注意力被周围复杂环境干扰,小程序在设计时应该注意减少无关的设计元素对用户目标的干扰,礼貌地向用户展示程序提供的服务,友好地引导用户进行操作。
每个页面都应有明确的重点,以便于用户每进入一个新页面的时候都能快速地理解页面内容。在确定了重点的前提下,应尽量避免页面上出现其它与用户的决策和操作无关的干扰因素。
此页面的主题是查询,却添加了诸多与查询不相关的业务入口,与用户的目标无关,易造成用户的迷失。
去掉任何与用户目标不相关的内容,明确页面主题,在技术和页面控件允许的前提下提供有助于用户决策和操作的帮助内容,比如最近搜索词等。
操作没有主次,让用户无从选择。
首先要避免并列过多操作让用户选择,在不得不并列多个操作时,需区分操作主次,减轻用户的选择难度。
为了让用户顺畅地使用页面,在用户进行某一个操作流程时,应避免出现用户目标流程之外的内容而打断用户。 新橄榄网
用户本打算进行搜索,在进入页面时却被突如其来的模态抽奖框所打断;对于抽奖没有兴趣的用户是非常不友好的干扰;而即便有部分用户确实被“诱人”的抽奖活动所吸引,离开主流程去抽奖之后可能就遗忘了原本的目标,进而失去了对产品真正价值的利用和认识。
一旦用户进入我们的小程序页面,我们就有责任和义务清晰明确地告知用户身在何处、又可以往何处去,确保用户在页面中游刃有余地穿梭而不迷路,这样才能为用户提供安全且愉悦的使用体验。
导航明确,来去自如
导航是确保用户在网页中浏览跳转时不迷路的最关键因素。导航需要告诉用户,当前在哪,可以去哪,如何回去等问题。首先在微信系统内的所有小程序的全部页面,均会自带有微信提供的导航栏,统一解决当前在哪,如何回去的问题。在微信层级导航保持体验一致,有助于用户在微信内形成统一的体验和交互认知,无需在各小程序和其他微信页面的切换中新增学习成本或改变使用习惯。
微信导航栏
微信导航栏,直接继承于客户端,除导航栏颜色之外,开发者无需亦不可对其中的内容进行自定义。但开发者需要规定小程序各个页面的跳转关系,让导航系统能够以合理的方式工作。
微信导航栏分为导航区域、标题区域以及操作区域。其中导航区控制程序页面进程。目前导航栏分深浅两种基本配色。
导航区(iOS)
微信进入小程序的第一个页面,导航区通常只有一个操作——“返回”,即返回进入小程序前的微信页面。进入小程序后的次级页面,导航区的操作为——“返回”和“关闭”。“返回”,即返回上一级小程序界面或微信界面。“关闭”,即在当前界面直接退出小程序,回到进入小程序前的微信页面。
导航区(Android)
导航区仅存在唯一操作——直接退出小程序,回到进入小程序前的微信或系统桌面,安卓手机自带的硬件返回键执行返回上一级页面的操作。
安卓导航存在一类特殊情况:当用户通过操作区的菜单将小程序添加至安卓桌面,并从安卓桌面打开小程序时,小程序的首页,不展示导航按钮。仅展示小程序标题和操作区。小程序次级页面,导航区只有返回上一级页面的操作,而点击安卓手机自带的硬件返回键也起到相同作用。
微信导航栏自定义颜色规则(iOS和Android)
小程序导航栏支持基本的背景颜色自定义功能,选择的颜色需要在满足可用性前提下,和谐搭配微信提供的两套主导航栏图标。建议参考以下选色效果:
选色方案示例
页面内导航
开发者可根据自身功能设计需要在页面内添加自有导航。并保持不同页面间导航一致。但是受限于手机屏幕尺寸的限制,小程序页面的导航应尽量简单,若仅为一般线性浏览的页面建议仅使用微信导航栏即可。
开发者可选择小程序页面添加标签分页(Tab)导航。标签分页栏可固定在页面顶部或者底部,便于用户在不同的分页间做切换。标签数量不得少于2个,最多不得超过5个,为确保点击区域,建议标签数量不超过4项。一个页面也不应出现一组以上的标签分页栏。
其中小程序首页可选择微信提供的原生底部标签分页样式,该样式仅供小程序首页使用。开发时可自定义图标样式、标签文案以及文案颜色等,具体设置项如图标尺寸等参考可参考开发文档和WeUI基础控件库。
顶部标签分页栏颜色可自定义。在自定义颜色选择中,务必注意保持分页栏标签的可用性、可视性和可操作性。
减少等待,反馈及时
页面的过长时间的等待会引起用户的不良情绪,使用微信小程序项目提供的技术已能很大程度缩短等待时间。即便如此,当不可避免的出现了加载和等待的时候,需要予以及时的反馈以舒缓用户等待的不良情绪。
启动页加载
小程序启动页是小程序在微信内一定程度上展现品牌特征的页面之一。本页面将突出展示小程序品牌特征和加载状态。启动页除品牌标志(Logo)展示外,页面上的其他所有元素如加载进度指示,均由微信统一提供且不能更改,无需开发者开发。
页面下拉刷新加载
在微信小程序内,微信提供标准的页面下拉刷新加载能力和样式,开发者无需自行开发。
微信下拉刷新错误使用案例
请避免以下错误使用情况,确保信息的可见性和页面的可用性。
页面内加载反馈
开发者可在小程序里自定义页面内容的加载样式。建议不管是使用在局部还是全局加载,自定义加载样式都应该尽可能简洁,并使用简单动画告知用户加载过程。开发者也可以使用微信提供的,统一的页面加载样式,如图中例所示。
模态的加载样式将覆盖整个页面的,由于无法明确告知具体加载的位置或内容将可能引起用户的焦虑感,因此应谨慎使用。除了在某些全局性操作下不要使用模态的加载。
局部加载反馈
局部加载反馈即只在触发加载的页面局部进行反馈,这样的反馈机制更加有针对性,页面跳动小,是微信推荐的反馈方式。例如:
加载反馈注意事项
若载入时间较长,应提供取消操作,并使用进度条显示载入的进度。
载入过程中,应保持动画效果;无动画效果的加载很容易让人产生该界面已经卡死的错觉。
不要在同一个页面同时使用超过1个加载动画。
除了在用户等待的过程中需予以及时反馈外,对操作的结果也需要予以明确反馈。根据实际情况,可选择不同的结果反馈样式。对于页面局部的操作,可在操作区域予以直接反馈,对于页面级操作结果,可使用弹出式提示(Toast)、模态对话框或结果页面展示。
页面局部操作结果反馈
对于页面局部的操作,可在操作区域予以直接反馈,例如点击多选控件前后如下图。对于常用控件,微信设计中心将提供控件库,其中的控件都已提供完整操作反馈。
页面全局操作结果——弹出式提示(Toast)
弹出式提示(Toast)适用于轻量级的成功提示,1.5秒后自动消失,并不打断流程,对用户影响较小,适用于不需要强调的操作提醒,例如成功提示。特别注意该形式不适用于错误提示,因为错误提示需明确告知用户,因而不适合使用一闪而过的弹出式提示。
页面全局操作结果——模态对话框
对于需要用户明确知晓的操作结果状态可通过模态对话框来提示,并可附带下一步操作指引。
页面全局操作结果—结果页
对于操作结果已经是当前流程的终结的情况,可使用操作结果页来反馈。这种方式最为强烈和明确的告知用户操作已经完成,并可根据实际情况给出下一步操作的指引。
异常可控,有路可退
在设计任何的任务和流程时,异常状态和流程往往容易被忽略,而这些异常场景往往是用户最为沮丧和需要帮助的时候,因此需要格外注意异常状态的设计,在出现异常时予以用户必要的状态提示,并告知解决方案,使其有路可退。
要杜绝异常状态下,用户莫名其妙又无处可去,停滞在某一个页面的情况。上文中所提到的模态对话框和结果页面都可作为异常状态的提醒方式。除此之外,在表单页面中尤其是表单项较多的页面中,还应明确指出出错项目,以便用户修改。
异常状态——表单出错
表单报错,在表单顶部告知错误原因,并标识出错误字段提示用户修改。
从PC时代的物理键盘鼠标到移动端时代手指,虽然输入设备极大精简,但是手指操作的准确性却大大不如键盘鼠标精确。为了适应这个变化,需要开发者在设计过程中充分利用手机特性,让用户便捷优雅的操控界面。
由于手机键盘区域小且密集,输入困难的同时还易引起输入错误,因此在设计小程序页面时因尽量减少用户输入,利用现有接口或其他一些易于操作的选择控件来改善用户输入的体验。
例如下图中,在添加银行卡时,采用摄像头识别接口来帮助用户输入。除此之外微信团队还对外开放例如地理位置接口等多种微信小程序接口,充分利用这些接口将大大提高用户输入的效率和准确性,进而优化体验。
除了利用接口外,在不得不让用户进行手动输入时,应尽量让用户做选择而不是键盘输入。一方面,回忆易于记忆,让用户在有限的选项中做选择通常来说是容易于完全靠记忆输入;另一方面,仍然是考虑到手机键盘密集的单键输入极易造成输入错误。例如图中,在用户搜索时提供搜索历史快捷选项将帮助用户快速进行搜索,而减少或避免不必要是键盘输入。
避免误操作
因为在手机上我们通过手指触摸屏幕来操控界面,手指的点击精确度远不如鼠标,因此在设计页面上需点击的控件时,需要充分考虑到其热区面积,避免由于可点击区域过小或过于密集而造成误操作。当简单的将原本在电脑屏幕上使用的界面不做任何适配直接移植到手机上时,往往就容易出现这样的问题。由于手机屏幕分辨率各不相同,因此最适宜点击像素尺寸也不完全一致,但换算成物理尺寸后大致是在7mm-9mm之间。在微信提供的标准组件库中,各种控件元素均已考虑到了页面点击效果以及不同屏幕的适配,因此再次推荐使用或模仿标准控件尺寸进行设计。
利用接口提升性能
微信设计中心已推出了一套网页标准控件库,包括sketch设计控件库和Photoshop设计控件库,后续还将完善小程序组件,这些控件都已充分考虑了移动端页面的特点,能够保证其在移动端页面上的可用性和操作性能;同时微信开发团队也在不断完善和扩充微信小程序接口,并提供微信公共库,利用这些资源不但能够为用户提供更加快捷的服务,而且对页面性能的提高有极大作用,无形之中提升了用户体验。
除了以上所提到的种种原则,建议接入微信的小程序还应该时刻注意不同页面间的统一性和延续性,在不同的页面尽量使用一致的控件和交互方式。
统一的页面体验和有延续性的界面元素都将帮助用最少的学习成本达成使用目标,减轻页面跳动所造成的不适感。正因如此,小程序可根据需要使用微信提供的标准控件,以达到统一稳定的目的。
微信内字体的使用与所运行的系统字体保持一致,常用字号为20,18,17,16,1413,11(pt),使用场景具体如下:
主内容Black黑色,次要内容Grey灰色;时间戳与表单缺省值Light灰色;大段的说明内容而且属于主要内容用Semi黑。
蓝色为链接用色,绿色为完成字样色,红色为出错用色Press与Disable状态分别降低透明度为20%与10%。
什么是零代码应用开发平台?
尽管市场上也把建站、网店开发、小程序开发等免代码服务也称为零代码开发,但因为这些平台面向的是特定的目的,服务一个专有的范式,所以一般不将他们划入零代码平台的范畴之内。真正的零代码开发平台面向的是广泛和多样的需求,在设计aPaaS产品的时候,并不确定一个特定的用户会用它来搭建什么应用。
当然,虽说面向的需求是广泛的,也不代表aPaaS是万能的。零代码开发几乎都是面向企业应用世界,而很难扩展到消费者应用领域,比如游戏、社交、工具软件等必然长期属于原生开发的世界。
所以,零代码应用开发平台需要一个比较准确的定义。它是指围绕企业数据和业务管理需求,通过可视化方式设计数据结构,用户交互形式、设置访问权限和定义工作流程的平台。你会发现,即使是原生开发企业软件,大体也是按照以上这几个步骤来进行的。
我用一个相对完整的列表,将零代码开发平台的能力元素和特性描述如下:
1)可视化构筑业务对象数据表(Entity),并支持建立关联。甚至需要支持跨应用的数据表关联。(这是aPaaS未来可能胜出其他方案的关键优势)。
2)为不同的数据场景配置不同类型的视图(View),能够定义数据行和列的过滤,能够设置列表、看板、日历等不同界面形式。
明道云构筑的销售应用数据视图
3)能够定义不同用户角色(Role),并赋予角色不同的数据访问和改写权限(Permission Set)。权限定义越精细越好。
明道云构筑用户角色和权限组合的界面
4)能够建立针对数据的汇总表和统计图表(Report)
5)能够建立自定义的输入表单(Form),分发给不同角色使用。
6)能够建立自定义的打印报表(Form Report),用于输出各类形式表格,通过Email,短信发送或者打印。
7)能够管理企业用户、部门、组织结构,并将其用于应用逻辑关系,比如应用的分发,角色的赋予和工作流中的流向信息。
8)能够可视化配置工作流(Workflow),支持特定条件下的数据新增,改写,删除等操作,并能够融入数据填写,审批等人工流程节点。工作流的运行能够监控和保存日志。
明道云构筑审批工作流的界面
9)应用能够封装后分发(Distribution)给不同的用户。
10)面向企业内部个人用户的工作台,仪表台等特性,实现个性化使用。
不同的aPaaS产品会有不同的特色和侧重点。所以以上特性并不一定存在于每一个aPaaS产品中。但是,特性越完整的,就越接近一个典型意义上的零代码企业应用开发平台。在以上实现中,有纯粹的零代码模式,也有个别需要用低代码方式来降低产品复杂度,但同时也会让非技术人员难以上手。
所以,aPaaS是SaaS应用和开发工具的混合,说它是SaaS,是因为开发者和终端用户使用的是同一个产品,只是通过权限和分发关系让界面千人千面。说它是开发工具,是因为它用模型模拟的应用搭建思路和原生数据库应用开发是类似的。
软件的应用特点和二次开发能力共存也不是一个新鲜事物。用Excel软件构筑一个个人所得税计算器,让用户可以输入自己的工资,即可得到应缴税额,对于使用者来说是应用,对编制这个Excel文件的人来说是开发工具,但他们用的都是Excel。
为什么企业软件领域可以实现零代码开发?
为什么游戏和社交软件做不到零代码开发,而企业软件市场却出现了零代码工具?是因为企业软件的开发比较简单吗?
当然不是。能够模式化完成一个工作的原因在于这项工作具备可重复性,就像我们会用3D打印制作一两件零件,但如果要生产成千上万个同样的零件,我们宁可花费成本先去制作模具。企业软件可以模式化开发的原因就在于大多数企业管理软件都由非常类似的需求和实现方式来构成,如果不积极利用这些相似性和模型化方法就需要不断重复发明类似的轮子。
当然也并非所有的企业应用都有相似性。在特定行业和职能中总有一些需要专门化设计和开发的应用。但在企业的运营全流程中,围绕客户,供应商,销售订单,产品,供应商,采购订单,制造流程,服务流程等商业对象,企业软件要解决的问题具有很强的相似性。这些相似性,或者使用范式可以被概括为以下环节:
1)围绕上述商业对象(Business Objects)的数据搜集和存储,并对数据的有效性进行验证。例如:建立一个采购订单,向特定供应商采购三项商品。
2)数据的查询和呈现。例如:运营部门查询处A仓库在今天应该到货的采购订单。财务部门查询货物已经收讫,并且应该在本周付款的采购订单。
3)数据的计算。例如:当采购订单的货物到达特定仓库后,更新相关商品的库存信息。
4)流程的控制。例如:当起草采购订单并准备发出时,根据采购的类别和金额发起不同的审核流程,在审核通过或者拒绝后执行不同的流程内容。
5)信息通知。例如:在采购订单批准后,自动生成采购单并发送给供应商,并通知仓库准备收货。
6)数据的统计和分析。例如:汇总过去一年的采购订单中按照BOM清单的产品金额分布,或者按照供应商的分布。
企业软件的设计和开发人员对以上这些使用范式都非常熟悉,它们经常出现在各种企业软件的开发需求中。实际上,除了以上抽象出的范式,企业软件的其他独特功能点并不太多了,甚至很多属于所有企业级软件共有的模块,比如管理用户和用户组,权限角色等。正是因为这个原因,企业软件的开发存在高度模型化的可能,从而在大部分场景下,摆脱对原生代码开发的依赖。
在云时代之前,除了Access以外,苹果公司也有FileMaker,Intuit公司也曾经开发过Quickbase(这个名字来源于Intuit公司财务软件产品Quicken),Quickbase后来被剥离,一直到今天都在提供服务。即使在原生开发领域内,企业软件市场也出现了各种现成的开发框架,它们和今天的零代码平台一样,都是为了通过模型化来提高交付效率和质量的办法。
为每个企业的软件需求,都从第一行代码开始写起,单独依靠某种高级语言和集成开发环境建立开发项目,这种做法已经越来越没有必要。正如Gartner的预测,大部分的企业应用将来都会依赖零代码平台,以至于不远的将来,零代码平台并不会刻意保留这个前缀,因为这将成为天经地义的事情,这就像今天为了满足一个通用需求,大多数企业不会去定制开发,甚至零代码平台都不会用,而是直接使用一个标准的SaaS产品。
为什么aPaaS具有难以替代的优势?
用户开始选择aPaaS产品,不仅仅是因为他们可以这样做,更重要的是因为不得不这样做。因为aPaaS与定制开发,以及标准SaaS产品相比有几个难以替代的优势。
1)满足企业的多样化需求
企业软件需求的多样化是定制开发模式的起源。虽然标准SaaS产品能够满足企业应用需求中的共性部分,但是因为行业、规模和产品内在特性的差异,每个企业的管理方式和流程都有自己的特点,而且它还会根据企业的规模阶段不断演变。这种差异在不同职能中程度不一,一般来说,围绕产品设计、制造和服务履行的核心业务流差异度更高,而人事,财务等价值创造的支持环节差异度比较小。
在这种背景下,用户始终在寻求一种既能保持足够的灵活性,又能够控制开发的成本和复杂度的方法。aPaaS基本就是直接针对这个问题而诞生的。
2)从定制开发中需求沟通的痛苦中解脱
企业软件实现过程中的第一痛点还不是贵,而是需求沟通的复杂。有业务需求的人不是开发软件的人,能够开发软件的人对业务痛点并没有切身的体会和经验。于是行业非常依赖专业的企业软件需求分析和实现方法设计能力,但这个能力是非常稀缺的资源。这也难怪企业软件开发需求的提出主体总是五花八门的,他们之间也需要进行复杂的沟通和信息汇总。
更要命的是,很多时候需求在实施之前都无法100%确定,企业自己无法提出一个完整的解决方案。这时候,要么需要求助于咨询机构这样的外脑,要么就只能走一步看一步。这两个方案听起来都不令人舒适。前者绝非普通中小企业所能够承受,后者可能会影响系统的开发和实施质量。
aPaaS的出现倒是让走一步看一步的方案变得更加现实。企业可以通过零代码平台渐进地开始实施。如果整个系统过于复杂,可以先从一个具体的环节开始,局部数字化(比如先把订单管起来)。反正用aPaaS搭建的速度足够快,用户甚至可以利用零代码工具来生成企业应用原型,在实际使用中进行验证,确认了终端用户可以掌握,原先识别的问题可以被有效解决之后,再继续推进更完整的实施。
可以这么说,零代码工具可以让开发者和使用者之间的距离充分缩短。在极端情况下,使用者甚至可以自己就是搭建开发者自己。他们可能在一两个小时的搭建后就能够确认这个方案是不是能够有效地解决问题。
3)在企业内部打通数据中台的需求
在企业IT中,还有一个致命痛点存在,那就是不同业务系统之间的数据相互隔离,不能综合使用,使得企业难以进行跨职能的数据相关性和因果分析,也难以实现跨职能的数据自动化。比如要分析一个价格调整措施对财务报表的影响,这个工作在任何一个孤立的信息系统中是无法完成的,而如果要做到,就至少需要从采购,销售,营销和财务系统中获得数据。同样的道理,企业也很难在遇到财务目标无法达成的情况下,自动做出最优的价格决策。这些都是影响企业运营水平至关重要的问题。近年来,Gartner提出的Paced Layer架构,以及阿里给电商企业提供的中台方案就是针对这种需求的反馈。
大企业当然可以投入专门的资金来打造数据中台性质的系统,但小企业支付不起,并不代表他们不想获得这样的能力。aPaaS平台提供了这个可能性。
首先,因为aPaaS平台管理数据的模型一致,所以它一般能够提供一个标准化程度非常高的编程接口,从外部系统汇合数据变得相对容易很多,这就像路由器一样,不管你有多少联网设备,它们都可以用统一的协议连接在一起。有了集中的数据,各种应用需求都变得容易兑现。哪怕个别系统依然需要通过抽取数据服务后另行原生开发,也比不断重复做数据整合工作要高效很多倍。
甚至,如果用aPaaS平台直接管理业务数据对象,这个数据整合工作都可以免除。用户可以直接在各个职能相关的数据对象中建立关联,建立汇总查询,批量抽取数据到BI平台,建立不同数据之间的自动化。
有关企业数字中台的介绍,建议可以读一下这篇采访文章。
4)突出的成本和效率优势
零代码开发平台和原生代码开发相比到底能够提高多少效率目前还没有精确的计量,但这个效率差至少是10倍以上。传统开发模式需要10天的,aPaaS一天之内就能够搞定。
更重要的效率差别不仅仅是时间,还包括零代码平台可以免除专业技术人员的参与。虽然它要求搭建者熟悉业务,完成基本的逻辑梳理,但毕竟这和动辄需要和好几位技术人员一起开会沟通需求要高效得多。即便在复杂的应用系统上,也至多只需要2-3人分工就能够完成整个项目的实现。因为简化协作的原因带来的成本节省甚至都不值十倍了。因为所有人都知道找到靠谱的定制软件开发团队几乎就是一件撞大运的事情。
同时,定制开发通常很难提供高品质的软件。软件运行的可靠性,缺陷消除的程度都很难和标准化产品相比,毕竟定制软件只有一个用户。而一个aPaaS平台不仅要同时服务很多终端用户,还要服务五花八门的应用搭建者,它能够做到一次对,次次对;一次缺陷消除,所有用户收益的效果。
5)开箱即用和自己动手的两全
和成型的SaaS应用相比,aPaaS看似有一个缺点,就是依然需要“搭建”。这有点像整体家具系统,摆在样品间很好看,但是实际买回家还需要施工人员来拼装才能达到预期的效果。
实际上,这个问题并不是无解,甚至很好解。aPaaS一开始自然不可能获得各个行业的最佳实践,让每个企业都能够看到“样板间”效果。但是,随着时间的推移,用户企业和集成商的参与,样板间会越来越多,甚至比SaaS产品提供的用例方案更加强大,因为后者提供的是一个固定家具的摆设效果,而前者能够根据不同的房型,提供不同的家具组合方案。
而且,在足够明确的细分市场下(比如金属加工制造流程管理这样的颗粒度),可以在aPaaS平台上开发出完全开箱即用的应用,直接分发给不同企业使用。有了这个能力,aPaaS不仅能够服务好终端用户,还能够催生集成商工作模式的变革,他们不仅可以通过出售IT服务挣钱,还能够在服务中加入解决方案的价值,消除定制开发成本,大幅提高项目服务毛利。
有了开箱即用的能力后,就能够大大加速企业采纳的意愿。而且,才采纳以后,“自己动手”的能力依然存在。就像先进的整体家居系统不仅可以组合,而且可以重新组合。企业软件的适用模式永远和企业阶段有关,比如小型制造业并不见得需要质量管理单元,但当年产值突破一亿元左右后,不仅面临ISO认证的刚性需求,也内在地需要引入全面质量管理。这样的企业可以在软件实施后依照实际需要继续调整、改进和增加软件模块。这个过程同样是低成本和高效率的。
6)平台特征提供的计算能力保证
在数据库应用中,有一个潜在的计算性能问题,尤其是在大规模数据表中进行复杂查询和联动计算时。如今,很多行业的企业数据规模都从数千数万条记录增长到百万,千万,甚至电商厂商轻而易举可以达到亿级数据。在制造和物流行业,物联网技术也必然带动更多的联网对象,产生的数据不仅规模巨大,而且计算形式也需要有针对性地加强。
对于定制实施系统来说,要分别通过分布式数据库,流式计算等先进技术来克服性能问题是一件极其昂贵的事情。aPaaS平台虽然为用户提供的是一个应用级的产品,但因为它范式统一,就有机会将这些基础计算隐藏起来,让用户不必关心这些后台事务就能够获得高性能的计算服务。通过aPaaS平台管理的数据表无论规模有多大,读写有多么频繁,实时查询的要求有多高,总有一个计算框架可以胜任。这种平台的扩展性让客户可以真正放心,aPaaS带来的不仅仅是开发效率的提升,还包括一个伸缩自如的基础设施服务。即便企业将来的业务规模成长百倍,也不会需要彻底重建IT系统。实际上,年收入数百亿美元的业务,背后驱动的IT平台极有可能就是Salesforce的平台搭建的应用,而不需要是独立建立的应用系统。
正是因为以上这些优势,aPaaS在没有得到行业命名之前就已经开始逐步渗透到企业IT服务领域。在最近几年正在悄悄替代大量的定制实施软件项目,也让原先依靠标准SaaS产品的企业找到了新的选择。
aPaaS目前适合什么样的企业?
aPaaS虽然拥有巨大的优势,但也不代表它能够满足所有行业和企业的所有IT需求。下面列出了一些常见的排除项。aPaaS方案对这些性质的需求吸引力不强。
1)行业有明显的专有特征
有些行业本身的专有化程度很高,而且企业之间的差异性不大,这时候垂直的行业应用可能更加合理。
围绕这个特征最典型的例子就是餐饮业和酒店业。所有餐饮业的运营逻辑都是类似的,除了单店和连锁可能使用不同复杂度的方案以外,应用模块都大同小异。而且,这个行业解决问题的方法和范式是有明显的行业特征的,比如餐厅的排队等座系统,点单结账系统等。用零代码工具来构建如此专有的场景反而更加麻烦,而且无法有效提供有行业特色的视图。
2)行业有独立的代码审计要求
金融等行业的核心业务系统因为法规等要求不能使用零代码平台,因为它无法满足代码审计的要求。aPaaS平台不一定能够提供源代码给用户企业,而且即使提供,也无法佐证应用系统处理数据的准确性。这些行业因为监管要求高,本身资金也宽裕,所以不会应用aPaaS方案在核心业务环节。
3)面向顾客的前台系统
这个当然就是指的电商网店平台了。虽然电商零售的基本数据管理和aPaaS的能力并无太大的距离,但是面向消费者的前台系统一般要求更高的灵活性和营销设施的配套,用零代码平台创建不如直接使用专门的电商系统,比如有赞、微盟等开店方案。它们提供的不仅仅是店面功能,还包括围绕顾客的营销服务和支付平台,这些是aPaaS所不擅长的领域。
除此之外的大部分企业IT需求,零代码平台都有足够的优势来胜任。而且,随着软件和服务的界限越来越模糊,很难说未来的aPaaS不能扩展它的领地。企业软件的本质就是生产力工具,aPaaS的核心精神就是围绕企业的数字化运营提供高生产力选项。
在用户渗透的过程中,当前阶段的零代码平台更多满足的还不是普通企业的需求,而是那些有一定的自建IT能力的企业。他们一般拥有若干名信息化专员,能够理解自己企业的核心业务流程和问题,能够和业务部门展开有效的沟通。除了终端企业用户外,行业咨询群体和ISV群体也开始更多关注零代码工具,因为行业咨询者永远都希望拥有属于自己的落地工具集,而他们很难投入做出自己高质量的原生软件产品;而ISV群体则常年面临项目实施成本高,客户需求差异度大的痛点,希望通过某种平台来降低开发服务成本,沉淀自己的方案能力,从而让项目实施具备更多的可复制特点。行业咨询、管理咨询和ISV群体对零代码平台的掌握最终会让这个门类的解决方案走入更多的主流企业用户。
读完这段,如果你对零代码平台有兴趣, 明道云 提供直接的使用体验,你可以自助注册试用。
以上就是微信小程序怎么设计全部内容,更多相关信息,敬请关注新橄榄网。WiFi认证中、微信一键上网是怎么实现的?微信WiFi一键上网开通流程:1.具备无线路由器,开通wifi功能;2.准备好一个个人手机微信,要求安装6.1以上安卓版微信或6.2.2以上IOS版微信;3.将以上资料准备好后,联系公众平台第三方服务机构优度网,一般3天内可完成开通;4.每成功添加一台设备,都会收到一条公众号“微信连WiFi助手”的反馈报告。案例如下:
2023-12-08 16:23:00
2023-11-17 15:13:59
2023-12-08 05:32:22
2023-11-25 19:46:07
2023-10-28 16:51:34
2023-10-26 10:44:08