小程序下一破局點?釘釘小程序卡片,應用與平台的深度集成


簡介:卡片技術在釘釘上的運用。

封面圖1217.png

20秒了解小程序卡片

案例1:幸福大巴一鍵搶座

1.png

“幸福大巴”是阿里員工在域內使用的城際客運功能,但因為需要來回跳轉VPN工具和H5頁面,在用戶體驗上帶來了一定的障礙

搶座流程對比:

以前H5頁面的搶座流程 現在卡片應用的搶座流程
1.小蜜搜索“幸福大巴” 1.小蜜搜索“幸福大巴”
2.點擊跳轉鏈接 2.一鍵搶座,完事兒
3.連接VPN null
4.打開預訂H5頁面進行搶座 null

與以前相比,一鍵預訂一鍵查詢一鍵取消,班次座位信息實時透出,為每位坐大巴的同學節省兩分鍾。

如何做到?

幸福大巴原本是企業智能在釘釘上開發的一個H5應用,此次基於小程序卡片能力,快速地將前端用戶界面改造為卡片形態,而后端服務依舊復用原來系統。

我們可以這么理解:

以前的大巴系統 = 后端服務 + 前端頁面(跳轉到新的全屏頁面 )

現在的大巴系統 = 后端服務 + 前端卡片(內外小蜜會話中)

而這個前端的卡片,開發方式就與開發一個小程序組件一樣簡單,只要會開發小程序,就會開發卡片。

一段卡片應用代碼示例如下:

2.png

案例2:ICBU客戶邀約卡片

3.png

ICBU基於小程序卡片能力,將原本的客戶邀約系統改造為卡片應用。

系統會通過機器人自動發送客戶邀約,銷售人員直接在卡片上操作,選擇拜訪日期,填寫拜訪計划表單,提交后邀約狀態的表單也會直接展示在卡片內容上。

通過卡片應用,減少了用戶在溝通與業務系統直接的來回跳轉。

從小紅點說起

看到這里,你可能已經對小程序卡片技術有一些應用層面上的了解,但回歸這項技術本身,咱們可能還需要從小紅點說起......

4.png

小紅點(Badge),起於黑莓,被 Apple 發揚光大(專利屬於蘋果),直到現在已然成為 iOS、Android 等各大系統 App 推送提醒 UI 規范。

小紅點的設計是如此成功,拋開 UI 不做討論,個人認為其對於用戶的最大意義在於它將原本需要用戶進入 APP 才能看到的信息直接在其上層載體(比如 App Icon)中進行了標准化透出 ,大大 縮短了信息獲取路徑。

現代操作系統中不乏類似設計,並且更進一步支持了用戶交互。比如 iOS、Android等系統小部件、通知中心、控制中心等。

在雲釘一體的戰略背景下,釘釘將越發成為企業數字化平台的操作系統。為了縮短用戶信息獲取路徑,我們需要一套擁有沉浸式體驗、對開發者友好的,並最終可以 Anywhere運行 的區塊級應用解決方案。

小程序卡片方案 可以很好的滿足以上訴求。

沉浸式體驗

小程序卡片相比於傳統小程序, 其最大優勢是能夠帶來沉浸式的體驗。

傳統小程序是躲在一個圖標(或者分享鏈接)后的應用,用戶想要基於小程序獲取或創造有效信息需要從當前上下文中跳出。這種相對割裂的交互方式某些場景下會對用戶造成較大的困擾,比如 IM ,而釘釘的 IM 作為釘釘的核心能力,承載了大部分與工作相關的溝通信息。

想象一下,銷售小王同學每天早上需要與群內同事同步昨天的工作進度和當天工作安排,並協同其他同事共同完成業務跟進。小王在關注其他同時聊天信息的同時,需要在工作台其他應用中進行客戶信息查詢與修改,這種在聊天窗和其他應用間不斷來回切換,讓小王的工作效率非常低,甚至可能錯過重要信息。

沉浸式交互

為了讓用戶可以直接在 IM 中操作小程序卡片,我們和釘釘 IM 團隊進行了深度合作,在渲染流程、數據鏈路上與 IM 模塊深度整合,將小程序卡片變成一種特殊的消息類型,能夠直接發送到消息列表中。

下圖所示為釘釘文檔卡片權限修改流程,用戶可直接在卡片上修改對應文檔權限:

5.png

並且,結合 IM 本身的特點,在 IM 的中小程序卡片還可支持置頂操作。置頂操作對於那些需要長時間交互的小程序卡片來說非常有意義,比如位置共享、數據大盤等。

實時數據同步

Functional UI 告訴我們 UI = F(data) ,可見數據對於 UI 所起到的決定性重要性。舉個例子:

6.gif

釘釘的群投票卡片允許我們直接在 IM 中進行投票操作。相對於從 IM 中跳轉一個獨立的 "投票" 應用再進行投票的交互體驗,無疑往前邁了一大步。

但如果我們想實時跟蹤投票進度,獲取最終投票結果呢?比如下方所示的能力:

7.gif

想要實現這種能力,常規做法是業務方自己在其業務邏輯中加入數據同步機制,刷新數據進而更新視圖。但這種數據同步方式其實非常低效,作為 client 端,為了保證數據的時效性很多時候只能通過定時器做定時刷新(長連接同樣存在其他問題)。試想下,在一個 100 人的群里,有一張卡片需要進行數據同步,意味着同時會有 100 個請求打到服務器。如果在 n 個群同時存在 m 張卡片呢?

小程序卡片內置了一套高效的數據同步機制,開發者只需將最新卡片數據同步到小程序卡片框架,即可快速將所有同 ID 卡片更新。

8.png

與小程序融合

小程序卡片作為一個獨立應用運行時,由於其區塊級應用定位,無法承載過於復雜的用戶交互和業務流程。此時,小程序卡片可以與小程序能力進行整合,點擊小程序卡片的某個 action 區域,支持半屏喚起一個擁有完整能力的小程序,在保持沉浸式體驗的同時給開發者足夠的能力支撐其業務。

同時,在該小程序內支持訪問小程序卡片的數據並對其進行更改,同樣的,這些數據變更將同步到所有同 ID 的卡片上。

9.png

此時小程序卡片可以做為主體小程序核心信息和操作的載體,用以快速觸達用戶,完成核心業務流程。

10.png

“傳統”應用 vs. 卡片應用

“傳統”應用 卡片應用
藏在圖標或鏈接背后的系統 以區塊化方式,前置到溝通、工作台、搜索等核心場景中
查看數據需要跳轉進入應用頁面,進行操作需要跳轉進入應用頁面 沉浸式交互,無須跳離上下文。卡片上實時透出內容,數據自動更新(實時座位信息);基本交互閉環可以在卡片上操作完成(進行搶座)
人與系統的交互 融入溝通后,增加了人與人的互動

Anywhere 運行

我們希望當開發者完成小程序卡片開發后,可以將其運行在:

多端:iOS、Android、Windows、Mac 端;

多運行時:native(IM列表、搜索結果頁)、小程序、H5,甚至 iOS widget 內。

11.png

傳統小程序使用 webview 作為渲染容器,但如果直接在 IM 中為每張卡片嵌入一個 webview 就顯得過於重了,且多卡片共存情況下內存占用過大的問題也難以解決。

所以,基於同一套 DSL ,我們會通過不同的 compiler 將其打包成不同產物以適應不同的宿主環境,並通過 DSL 的強約束性保證多端渲染一致性。

12.png

依托於當前小程序離線包機制,我們將多種產物(未來可配置)統一打包到小程序離線包內實現資源離線化。

在卡片被渲染前,卡片框架會先判斷當前所處的環境,並根據不同環境選擇不同打包產物進行卡片渲染。

13.png

使用卡片統一 DSL 可以將業務代碼與"卡片底層引擎實現"解耦,未來加入更多渲染引擎支持時業務可以無痛升級。

基於這套方案,釘釘小程序卡片已支持 Webview、Native、小程序 三種容器。

卡片容器的全行業耕耘

卡片技術作為一個全新的應用形態和技術方案,仍有諸多不完善之處,需要持續迭代與優化,提高卡片性能和產品化能力。

但不可否認的是,從 icon 到 card,無疑是當前移動開發領域,在后續發展進程上的一個重要方向。

除了釘釘小程序卡片外,「支付寶」自研的魔方卡片(Cube)也在通過 mPaaS 正式開放對外輸出,每一個魔方卡片(Cube)都可以獨立嵌在原生頁面內的一個區域,將區域內容通過卡片模版進行展示。

提供動態內容展示

魔方卡片(Cube)通過卡片的形式嵌入到原生 Native 頁面中,Android/iOS 雙端的高度一致性可以大大提升開發效率,而僅 5.5mb 的包體積和 32mb 的內存消耗,讓動態化開發更輕量化。

為開發者的“私人定制”

客戶端 SDK 結合服務端卡片管理系統,開發者讓開發者的接入和使用過程更輕巧簡易;多種前端開發語言和完備的調試工具,讓“編譯-預覽-調試-發布”的開發流程更普惠,不用語法的開發者都能獲得最前沿的技術工具。

原文鏈接
本文為阿里雲原創內容,未經允許不得轉載。 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM