如何建立公司自己的网站,莱芜seo排名,个人网站可以做淘宝客网站吗,wordpress技术类博客简介#xff1a;卡片技术在钉钉上的运用。 20秒了解小程序卡片
案例1#xff1a;幸福大巴一键抢座 “幸福大巴”是阿里员工在域内使用的城际客运功能#xff0c;但因为需要来回跳转VPN工具和H5页面#xff0c;在用户体验上带来了一定的障碍
抢座流程对比#xff1a;
以…简介卡片技术在钉钉上的运用。 20秒了解小程序卡片
案例1幸福大巴一键抢座 “幸福大巴”是阿里员工在域内使用的城际客运功能但因为需要来回跳转VPN工具和H5页面在用户体验上带来了一定的障碍
抢座流程对比
以前H5页面的抢座流程现在卡片应用的抢座流程1.小蜜搜索“幸福大巴”1.小蜜搜索“幸福大巴”2.点击跳转链接2.一键抢座完事儿3.连接VPNnull4.打开预订H5页面进行抢座null
与以前相比一键预订一键查询一键取消班次座位信息实时透出为每位坐大巴的同学节省两分钟。
如何做到
幸福大巴原本是企业智能在钉钉上开发的一个H5应用此次基于小程序卡片能力快速地将前端用户界面改造为卡片形态而后端服务依旧复用原来系统。
我们可以这么理解
以前的大巴系统 后端服务 前端页面跳转到新的全屏页面
现在的大巴系统 后端服务 前端卡片内外小蜜会话中
而这个前端的卡片开发方式就与开发一个小程序组件一样简单只要会开发小程序就会开发卡片。
一段卡片应用代码示例如下 案例2ICBU客户邀约卡片 ICBU基于小程序卡片能力将原本的客户邀约系统改造为卡片应用。
系统会通过机器人自动发送客户邀约销售人员直接在卡片上操作选择拜访日期填写拜访计划表单提交后邀约状态的表单也会直接展示在卡片内容上。
通过卡片应用减少了用户在沟通与业务系统直接的来回跳转。
从小红点说起
看到这里你可能已经对小程序卡片技术有一些应用层面上的了解但回归这项技术本身咱们可能还需要从小红点说起...... 小红点Badge起于黑莓被 Apple 发扬光大专利属于苹果直到现在已然成为 iOS、Android 等各大系统 App 推送提醒 UI 规范。
小红点的设计是如此成功抛开 UI 不做讨论个人认为其对于用户的最大意义在于它将原本需要用户进入 APP 才能看到的信息直接在其上层载体比如 App Icon中进行了标准化透出 大大 缩短了信息获取路径。
现代操作系统中不乏类似设计并且更进一步支持了用户交互。比如 iOS、Android等系统小部件、通知中心、控制中心等。
在云钉一体的战略背景下钉钉将越发成为企业数字化平台的操作系统。为了缩短用户信息获取路径我们需要一套拥有沉浸式体验、对开发者友好的并最终可以 Anywhere运行 的区块级应用解决方案。
小程序卡片方案 可以很好的满足以上诉求。
沉浸式体验
小程序卡片相比于传统小程序, 其最大优势是能够带来沉浸式的体验。
传统小程序是躲在一个图标或者分享链接后的应用用户想要基于小程序获取或创造有效信息需要从当前上下文中跳出。这种相对割裂的交互方式某些场景下会对用户造成较大的困扰比如 IM 而钉钉的 IM 作为钉钉的核心能力承载了大部分与工作相关的沟通信息。
想象一下销售小王同学每天早上需要与群内同事同步昨天的工作进度和当天工作安排并协同其他同事共同完成业务跟进。小王在关注其他同时聊天信息的同时需要在工作台其他应用中进行客户信息查询与修改这种在聊天窗和其他应用间不断来回切换让小王的工作效率非常低甚至可能错过重要信息。
沉浸式交互
为了让用户可以直接在 IM 中操作小程序卡片我们和钉钉 IM 团队进行了深度合作在渲染流程、数据链路上与 IM 模块深度整合将小程序卡片变成一种特殊的消息类型能够直接发送到消息列表中。
下图所示为钉钉文档卡片权限修改流程用户可直接在卡片上修改对应文档权限 并且结合 IM 本身的特点在 IM 的中小程序卡片还可支持置顶操作。置顶操作对于那些需要长时间交互的小程序卡片来说非常有意义比如位置共享、数据大盘等。
实时数据同步
Functional UI 告诉我们 UI F(data) 可见数据对于 UI 所起到的决定性重要性。举个例子 钉钉的群投票卡片允许我们直接在 IM 中进行投票操作。相对于从 IM 中跳转一个独立的 投票 应用再进行投票的交互体验无疑往前迈了一大步。
但如果我们想实时跟踪投票进度获取最终投票结果呢比如下方所示的能力 想要实现这种能力常规做法是业务方自己在其业务逻辑中加入数据同步机制刷新数据进而更新视图。但这种数据同步方式其实非常低效作为 client 端为了保证数据的时效性很多时候只能通过定时器做定时刷新长连接同样存在其他问题。试想下在一个 100 人的群里有一张卡片需要进行数据同步意味着同时会有 100 个请求打到服务器。如果在 n 个群同时存在 m 张卡片呢
小程序卡片内置了一套高效的数据同步机制开发者只需将最新卡片数据同步到小程序卡片框架即可快速将所有同 ID 卡片更新。 与小程序融合
小程序卡片作为一个独立应用运行时由于其区块级应用定位无法承载过于复杂的用户交互和业务流程。此时小程序卡片可以与小程序能力进行整合点击小程序卡片的某个 action 区域支持半屏唤起一个拥有完整能力的小程序在保持沉浸式体验的同时给开发者足够的能力支撑其业务。
同时在该小程序内支持访问小程序卡片的数据并对其进行更改同样的这些数据变更将同步到所有同 ID 的卡片上。 此时小程序卡片可以做为主体小程序核心信息和操作的载体用以快速触达用户完成核心业务流程。 “传统”应用 vs. 卡片应用
“传统”应用卡片应用藏在图标或链接背后的系统以区块化方式前置到沟通、工作台、搜索等核心场景中查看数据需要跳转进入应用页面进行操作需要跳转进入应用页面沉浸式交互无须跳离上下文。卡片上实时透出内容数据自动更新实时座位信息基本交互闭环可以在卡片上操作完成进行抢座人与系统的交互融入沟通后增加了人与人的互动
Anywhere 运行
我们希望当开发者完成小程序卡片开发后可以将其运行在
多端iOS、Android、Windows、Mac 端
多运行时nativeIM列表、搜索结果页、小程序、H5甚至 iOS widget 内。 传统小程序使用 webview 作为渲染容器但如果直接在 IM 中为每张卡片嵌入一个 webview 就显得过于重了且多卡片共存情况下内存占用过大的问题也难以解决。
所以基于同一套 DSL 我们会通过不同的 compiler 将其打包成不同产物以适应不同的宿主环境并通过 DSL 的强约束性保证多端渲染一致性。 依托于当前小程序离线包机制我们将多种产物未来可配置统一打包到小程序离线包内实现资源离线化。
在卡片被渲染前卡片框架会先判断当前所处的环境并根据不同环境选择不同打包产物进行卡片渲染。 使用卡片统一 DSL 可以将业务代码与卡片底层引擎实现解耦未来加入更多渲染引擎支持时业务可以无痛升级。
基于这套方案钉钉小程序卡片已支持 Webview、Native、小程序 三种容器。
卡片容器的全行业耕耘
卡片技术作为一个全新的应用形态和技术方案仍有诸多不完善之处需要持续迭代与优化提高卡片性能和产品化能力。
但不可否认的是从 icon 到 card无疑是当前移动开发领域在后续发展进程上的一个重要方向。
除了钉钉小程序卡片外「支付宝」自研的魔方卡片Cube也在通过 mPaaS 正式开放对外输出每一个魔方卡片Cube都可以独立嵌在原生页面内的一个区域将区域内容通过卡片模版进行展示。
提供动态内容展示
魔方卡片Cube)通过卡片的形式嵌入到原生 Native 页面中Android/iOS 双端的高度一致性可以大大提升开发效率而仅 5.5mb 的包体积和 32mb 的内存消耗让动态化开发更轻量化。
为开发者的“私人定制”
客户端 SDK 结合服务端卡片管理系统开发者让开发者的接入和使用过程更轻巧简易多种前端开发语言和完备的调试工具让“编译-预览-调试-发布”的开发流程更普惠不用语法的开发者都能获得最前沿的技术工具。
原文链接 本文为阿里云原创内容未经允许不得转载。
