3個(gè)小時(shí),從學(xué)到做,我用低代碼平臺(tái)搭了一套管理系統(tǒng)(低代碼平臺(tái) 原理)
導(dǎo)語:本文基于作者虛構(gòu)的“幼兒園健康上報(bào)系統(tǒng)”,演示如何用低代碼平臺(tái)快速搭建一套應(yīng)用系統(tǒng),并介紹演示了國內(nèi)外的一些知名aPaaS產(chǎn)品,如Mendix、Outsystems、宜搭、明道云,試圖探討低代碼平臺(tái)在產(chǎn)品設(shè)計(jì)上的核心本質(zhì),從而讓大家對(duì)低代碼有一個(gè)更直觀的理解。
在案例開始之前,我們先聊聊基本概念。
一、低代碼是什么
低代碼平臺(tái)是繼中臺(tái)之后又一個(gè)火爆的話題,實(shí)際上低代碼本身并不是一個(gè)新穎的話題,也不是最近才有的技術(shù)突破和創(chuàng)新,而是存在了十幾二十年的概念。早期的大型管理軟件套件,都有類似于可拖拽式的快速開發(fā)平臺(tái),方便技術(shù)人員不用寫代碼,快速實(shí)現(xiàn)某些基礎(chǔ)功能。
低代碼雖然現(xiàn)在習(xí)慣被稱作aPaaS,好像看起來是一種PaaS,顯得和SaaS有密切關(guān)系,但大家需要認(rèn)識(shí)到,低代碼開發(fā)平臺(tái)并不是因?yàn)镾aaS才有的概念,而是遠(yuǎn)古時(shí)期就已經(jīng)存在了的。
簡(jiǎn)單來講,低代碼平臺(tái)是一套期望通過拖拽配置,就能實(shí)現(xiàn)一套業(yè)務(wù)型軟件系統(tǒng)的開發(fā)平臺(tái),并能無縫的部署上線運(yùn)行。在這個(gè)過程中,當(dāng)然也允許編寫部分代碼,但更重要的是,大量基礎(chǔ)性的編碼工作,都可以被低代碼平臺(tái)快速的自動(dòng)化實(shí)現(xiàn)。
低代碼的第一個(gè)應(yīng)用場(chǎng)景,是為了幫助成熟的軟件產(chǎn)品,低成本的支持個(gè)性化需求,提高開發(fā)速度,甚至做到拓展客群。
例如,很多成熟商業(yè)軟件(包括私有化部署的商業(yè)軟件套件以及SaaS形式的產(chǎn)品),期望通過低代碼平臺(tái)的建設(shè),加強(qiáng)產(chǎn)品擴(kuò)展能力,更好、更快的服務(wù)客戶,以及與 ISV協(xié)作,將產(chǎn)品的目標(biāo)客群拓展到更廣泛的領(lǐng)域和行業(yè)。
在這種情況下,低代碼平臺(tái)是低成本高效解決個(gè)性化需求終極方案。此時(shí),低代碼的目標(biāo)用戶可能包括工程師、實(shí)施顧問。國外的SAP、Oracle、SalesForce,國內(nèi)的用友、金蝶、北森、銷售易等,都有基于自身軟件產(chǎn)品作為基礎(chǔ)核心的低代碼解決方案。
低代碼第二個(gè)應(yīng)用場(chǎng)景,是為了幫助甲方企業(yè),低成本快速搭建全新的應(yīng)用系統(tǒng),尤其是讓不懂編程的業(yè)務(wù)人員也能自主實(shí)現(xiàn),從而讓企業(yè)以更低的成本享受數(shù)字化技術(shù)賦能業(yè)務(wù)的好處。
實(shí)際上,在企業(yè)中大量的應(yīng)用系統(tǒng)都是流程型的,對(duì)于邏輯相對(duì)簡(jiǎn)單,流程鏈條并不復(fù)雜的業(yè)務(wù)場(chǎng)景,找套裝軟件支持大材小用,找外包開發(fā)獨(dú)立系統(tǒng)成本又高,那么低代碼平臺(tái)可能是一個(gè)不錯(cuò)的選擇。此時(shí),低代碼平臺(tái)的目標(biāo)用戶可能包括甲方企業(yè)的業(yè)務(wù)人員,或者IT人員。
國外的OutSystems、Mendix,國內(nèi)的明道云、氚云,都屬于這種情況。需要留意的是,目前國內(nèi)有些做報(bào)表平臺(tái)、流程引擎的廠商,為了蹭熱度,也都稱自己是低代碼平臺(tái)。嚴(yán)格來講,這些廠商提供的產(chǎn)品能力,只是完整低代碼平臺(tái)所需具備能力的子集,并不能算低代碼產(chǎn)品。
說了這么多概念,想必大家對(duì)低代碼的印象依然比較模糊。接下來,我將通過一個(gè)案例,帶著大家去體驗(yàn)一款低代碼產(chǎn)品的使用。開始之前,還有幾個(gè)問題需要和大家強(qiáng)調(diào):
- 低代碼只是應(yīng)用系統(tǒng)建設(shè)執(zhí)行層面的工具,而軟件產(chǎn)品設(shè)計(jì)中的思考方式和建模過程才是核心,所以我們的案例會(huì)花一部分筆墨講述設(shè)計(jì)過程,理解后再去學(xué)習(xí)應(yīng)用低代碼平臺(tái)就會(huì)簡(jiǎn)單很多。
- 我選擇了明道云作為演示產(chǎn)品:第一是因?yàn)樗容^容易上手;第二是因?yàn)槊鞯涝频睦习迦蜗驎煷罄衅饺障矚g寫公號(hào)做分享,我很喜歡他的文章,為了致敬,因此選擇了明道云。需要聲明的是我和明道云沒有任何關(guān)系,甚至試用期間連銷售都沒加過,試用期全程都是我自己對(duì)著幫助手冊(cè)學(xué)習(xí)操作的。
- 明道云的學(xué)習(xí)我大概用了一個(gè)小時(shí)(主要是看幫助文檔),具體上機(jī)實(shí)操將案例中的功能實(shí)現(xiàn)大概用了兩個(gè)小時(shí),整體還是非常好用,容易上手。但這也可能是因?yàn)槲乙郧白鲞^研發(fā),對(duì)很多基礎(chǔ)概念都比較容易理解。
好了,接下來,讓我們進(jìn)入案例。
二、小豚鼠幼兒園的低代碼應(yīng)用
1. 需求調(diào)研
李校長是小豚鼠幼兒園的校長,最近她遇到了一個(gè)煩心事,根據(jù)教委統(tǒng)一要求,疫情期間,需要家長每天上報(bào)小朋友的健康狀況,學(xué)校統(tǒng)一管理,但是教委又沒有提供統(tǒng)一的技術(shù)支持。
為了實(shí)現(xiàn)這個(gè)訴求,幼兒園的老師們想盡辦法,比如說用微信群管理,或者在線文檔管理,但都不是很方便,例如無法做實(shí)時(shí)統(tǒng)計(jì),數(shù)據(jù)容易被誤操作。而如果找一個(gè)軟件公司來幫忙做一個(gè)小系統(tǒng),居然要花三四萬元,對(duì)于一個(gè)幼兒園,這可是一筆不小的開銷。
李校長的侄子小王是一名B端產(chǎn)品經(jīng)理,在閑聊中得知了李校長的難題,心思一動(dòng),問道:
小王:姑姑,您說的這事兒,或許我能幫上忙,做一套軟件系統(tǒng),就可以很好地解決您的問題!
李校長:真的嗎,那太好了,但是我們沒有很多預(yù)算啊!
小王:不用花您一分錢,我?guī)湍赓M(fèi)做,不過我想先了解下您對(duì)這個(gè)業(yè)務(wù)管理的訴求和期望。
李校長:多謝啊!我的訴求很簡(jiǎn)單,就是讓家長們每天打卡,如果有健康異常的情況,我能第一時(shí)間收到提醒,還能讓老師們?nèi)ジM(jìn),看看到底啥問題。另外,就是最好能有一些實(shí)時(shí)報(bào)表,讓我看到最新的健康上報(bào)情況。
小王:得嘞,我了解了,這事兒交給我了,我?guī)湍O(shè)計(jì)一套操作的流程,和支撐的系統(tǒng),免費(fèi)給您用!
了解了大概的背景后,小王開始構(gòu)思這套給小豚鼠幼兒園使用的幼兒健康上報(bào)系統(tǒng)的設(shè)計(jì)方案。
李校長:太棒啦,期待!
2. 產(chǎn)品概要設(shè)計(jì)
小王了解完基本需求后,開始構(gòu)思這套系統(tǒng)該如何設(shè)計(jì)。首先整理下這套系統(tǒng)涉及到的利益方,分別如下:
- 校長:業(yè)務(wù)決策人,系統(tǒng)用戶,希望系統(tǒng)能支撐教委的健康打卡要求,并管理好打卡業(yè)務(wù)。
- 老師:業(yè)務(wù)執(zhí)行者,系統(tǒng)用戶,需要管理班級(jí)和學(xué)生,安排打卡,跟蹤體溫異常的情況。
- 家長:業(yè)務(wù)參與者,系統(tǒng)用戶,需要完成每日健康上報(bào)打卡工作。
雖然業(yè)務(wù)本身過程很簡(jiǎn)單,但因?yàn)楫吘故且惶讖臒o到有搭建的管理系統(tǒng),有些基礎(chǔ)數(shù)據(jù)準(zhǔn)備工作需要完成。小王思考了一會(huì)兒后,繪制出了一份簡(jiǎn)明的業(yè)務(wù)流程圖,如下。
可以看到,期望家長能打卡,有些基礎(chǔ)數(shù)據(jù)要先維護(hù)好,根據(jù)常識(shí),需要維護(hù)包括班級(jí)信息、學(xué)生信息,而打卡動(dòng)作是針對(duì)學(xué)生的,因此要對(duì)學(xué)生關(guān)聯(lián)打卡信息。
另外需求中提到了,如果打卡體溫異常,需要有老師跟進(jìn),我們考慮生成一個(gè)待辦任務(wù)分配給老師,這條待辦任務(wù)關(guān)聯(lián)在異常的打卡記錄上。對(duì)業(yè)務(wù)有了以上分析和思考,我們可以繪制出業(yè)務(wù)背后的ER模型圖(領(lǐng)域模型),如下圖。
每名老師可以管理多個(gè)班級(jí),每個(gè)班級(jí)只能有一名老師管理。每個(gè)班級(jí)可以有多個(gè)學(xué)生,每名學(xué)生有多個(gè)健康上報(bào)記錄(打卡記錄),每個(gè)健康上報(bào)記錄可以產(chǎn)生一條體溫異常跟蹤記錄。
這些抽象出來的實(shí)體,是我們要設(shè)計(jì)的這套健康上報(bào)系統(tǒng)的核心,因?yàn)榇蚩ǎń】瞪蠄?bào))的過程,實(shí)際上就是對(duì)這些實(shí)體數(shù)據(jù)做增刪改查而已。
3. 產(chǎn)品細(xì)節(jié)設(shè)計(jì)
接下來,我們基于流程圖,來思考系統(tǒng)落地執(zhí)行的頁面流轉(zhuǎn)圖:
- 校長管理班級(jí),需要有班級(jí)的列表頁、詳情頁(帶有編輯功能);
- 老師管理學(xué)生,需要有學(xué)生的列表頁、詳情頁(帶有編輯功能);
- 家長上報(bào)健康記錄,需要有健康記錄填報(bào)頁;
- 老師查閱健康打卡記錄,需要有健康打卡列表頁;
- 老師跟進(jìn)體溫異常情況,需要有提問異常任務(wù)的列表頁、詳情頁(帶有編輯功能)。
除了這些頁面級(jí)別的操作需求,還有一些業(yè)務(wù)規(guī)則需求,例如:如果健康上報(bào)體溫異常,自動(dòng)生成一條待跟進(jìn)任務(wù),發(fā)送給該學(xué)生班主任,并推送消息給校長。
總之,我們會(huì)發(fā)現(xiàn),涉及到業(yè)務(wù)運(yùn)作的功能頁面,主要就是ER實(shí)體的列表頁、詳情頁(創(chuàng)建編輯),并且,不同的用戶對(duì)不同頁面以及不同的數(shù)據(jù)具有不同的權(quán)限。
經(jīng)過整理分析,我們可以列示出系統(tǒng)涉及到的相關(guān)頁面,以及權(quán)限表如下(此處僅僅是簡(jiǎn)單示意,后邊在明道云中我們會(huì)展示更加全面詳細(xì)的權(quán)限設(shè)計(jì),包括數(shù)據(jù)權(quán)限的管理設(shè)計(jì)方案):
經(jīng)過以上分析,雖然細(xì)節(jié)還不完備,但我們對(duì)“幼兒園健康上報(bào)系統(tǒng)”的設(shè)計(jì)思路已經(jīng)了然于胸,接下來,我們直接進(jìn)入低代碼平臺(tái)的開發(fā)演示環(huán)節(jié)!
3. 低代碼實(shí)現(xiàn)——通過工作表定義數(shù)據(jù)實(shí)體
首先,我們來到明道云工作臺(tái),點(diǎn)擊“添加應(yīng)用”,創(chuàng)建新應(yīng)用“小豚鼠幼兒園”(已經(jīng)在下圖中)。
接著,我們針對(duì)ER模型中的四個(gè)實(shí)體,分別創(chuàng)建工作表,下圖所示是創(chuàng)建班級(jí)實(shí)體的工作表編輯頁面。
工作表是明道云的概念,所謂工作表,實(shí)際上對(duì)應(yīng)著ER建模中的實(shí)體,工作表中的相關(guān)控件,定義了實(shí)體的字段。例如班級(jí)表單中定義了自增長的“班級(jí)ID”,字符串類型的字段“班級(jí)名稱”,枚舉字段“狀態(tài)”等。
通過表單來呈現(xiàn)出實(shí)體,是一種容易讓人理解的設(shè)計(jì)方式。而實(shí)體背后的本質(zhì),是所謂的“對(duì)象”,以及最終會(huì)轉(zhuǎn)移成數(shù)據(jù)庫的表。在有些低代碼平臺(tái)中,則通過對(duì)象編輯器來定義管理實(shí)體,這是一種靈活性更強(qiáng),但用起來更復(fù)雜的方案,在后文我們還會(huì)進(jìn)一步介紹。
不論是表單編輯器,還是對(duì)象編輯器,原理是一樣的,管理的都是提煉出的實(shí)體。對(duì)于非技術(shù)人員來講,表單可能更容易理解接受一些。
在班級(jí)表單中,有一個(gè)“學(xué)生”的控件,是一種關(guān)聯(lián)記錄組件。因?yàn)榘嗉?jí)和學(xué)生是一對(duì)多關(guān)系,每個(gè)班級(jí)可以擁有多個(gè)學(xué)生,所以在班級(jí)表單中,我們?cè)试S看到關(guān)聯(lián)在班級(jí)下的所有學(xué)生列表,這在B端產(chǎn)品交互中是非常常見的一種設(shè)計(jì)形態(tài)。
實(shí)體之間所謂一對(duì)多、多對(duì)多的關(guān)系,體現(xiàn)的是多個(gè)表之間的關(guān)聯(lián),在設(shè)計(jì)器中可以輕松地定義班級(jí)和學(xué)生的一對(duì)多關(guān)系,如下圖:
實(shí)現(xiàn)了關(guān)聯(lián)后,表單和表單之間建立了連接,在詳情頁(單條表單數(shù)據(jù)的呈現(xiàn)頁面)展現(xiàn)上,也都會(huì)完美的自動(dòng)完成。例如:下圖是針對(duì)某一條班級(jí)數(shù)據(jù)的詳情頁(PC版本):
aPaaS平臺(tái)都會(huì)自動(dòng)完成PC版本和移動(dòng)版本的適配,并且格式都是可調(diào)整的。例如上圖呈現(xiàn)的是PC版的班級(jí)詳情頁,下圖則是移動(dòng)版本:
4. 低代碼實(shí)現(xiàn)——通過視圖編輯器定義數(shù)據(jù)列表呈現(xiàn)
接下來,我們依次完成“學(xué)生”、“健康上報(bào)”、“體溫異常跟蹤”三個(gè)實(shí)體的表單配置。
下圖中,橫排的“校園管理”、“校長控制臺(tái)”,可以理解成我們針對(duì)系統(tǒng)配置的一級(jí)導(dǎo)航,豎排的四張表單,表示歸屬于某個(gè)一級(jí)導(dǎo)航,而每個(gè)表單在右側(cè)主區(qū)域配置的列表視圖,就是二級(jí)導(dǎo)航菜單,如下圖針對(duì)班級(jí)的表單,定義了“全部”、“生效中的班級(jí)”、“已畢業(yè)的班級(jí)”、“我的”四個(gè)列表視圖,也即“校園管理”一級(jí)菜單下的四個(gè)二級(jí)菜單。
那么,什么是列表視圖呢?
工作表只是定義了實(shí)體的具體字段,如何將實(shí)體的列表數(shù)據(jù)呈現(xiàn)出來呢?例如,如何將“班級(jí)”列表數(shù)據(jù)以不同的展現(xiàn)形式呈現(xiàn)出來呢?這就需要視圖編輯器了!
在視圖編輯器中,可以定義實(shí)體對(duì)應(yīng)的多條數(shù)據(jù)的列表化呈現(xiàn),包括列表數(shù)據(jù)默認(rèn)的篩選條件,默認(rèn)的展示字段,默認(rèn)的字段排序,都可以輕松定制,如上圖所示。
在大多數(shù)自研的B端產(chǎn)品中,列表頁(也就是視圖)是最常見的功能頁面,而一般情況下,這類頁面都是硬編碼實(shí)現(xiàn),而非通過類似于視圖編輯器這樣的前端組件實(shí)現(xiàn)。在成熟的軟件產(chǎn)品中,已經(jīng)沒有列表頁的概念,都會(huì)通過視圖編輯器來處理,這樣就大量的簡(jiǎn)化編碼工作。
如下圖,我們針對(duì)“班級(jí)”表單,定義了四個(gè)視圖,分別是“全部”、“生效中班級(jí)”、“已畢業(yè)班級(jí)”、“我的”,其中截圖呈現(xiàn)的是針對(duì)“生效中班級(jí)”視圖的默認(rèn)搜索條件配置,可以看到,我們?cè)O(shè)置了該視圖默認(rèn)查詢條件,是“狀態(tài)”字段為“教學(xué)中”的所有班級(jí)數(shù)據(jù)。
我們先前提到,在“班級(jí)”表單中建立了和“學(xué)生”記錄的一對(duì)多關(guān)系,在“學(xué)生”表單中,同樣需要有一個(gè)字段,關(guān)聯(lián)了“班級(jí)”表單的“班級(jí)ID”字段,從而完成一對(duì)多關(guān)系的定義。
但是,如果我們希望在學(xué)生表單中呈現(xiàn)出所在班級(jí)的名稱,以及在學(xué)生視圖中呈現(xiàn)出所在班級(jí)的字段,該如何實(shí)現(xiàn)呢?
因?yàn)樵诮⒁粚?duì)多關(guān)系式,我們只是定義了ID之間的聯(lián)系,所以,如果想在“學(xué)生”表單中呈現(xiàn)“班級(jí)”名稱,必須做一個(gè)變量引入的特殊處理,在明道云中,采用了一種叫做“他表字段”的設(shè)計(jì)方式,簡(jiǎn)單講,就是把關(guān)聯(lián)表的某個(gè)字段引入過來,進(jìn)行展現(xiàn),如下圖:
下邊的紅框,定義了ID之間的關(guān)聯(lián),上邊的紅框,引入了“班級(jí)”表的“名稱”字段,以便在“學(xué)生”表單和視圖中展現(xiàn)。
在其他低代碼產(chǎn)品中,針對(duì)這類訴求的解決方案不太相同。
嚴(yán)格來講,表單只是數(shù)據(jù)對(duì)象的外化呈現(xiàn),根據(jù)軟件設(shè)計(jì)MVC的分層理念,數(shù)據(jù)定義和前端呈現(xiàn)要分層隔離,對(duì)象編輯器嚴(yán)格定義了數(shù)據(jù)實(shí)體本身,而如果在表單或視圖中需要做多表連接去呈現(xiàn)其他相關(guān)表的某些字段,則是可視化層面需要解決的問題。
因此,在很多更復(fù)雜一些的低代碼產(chǎn)品中,所有可視化的部分,都是基于頁面編輯器來完成,和底層數(shù)據(jù)定義是互相獨(dú)立的兩件事。因?yàn)槊鞯涝频漠a(chǎn)品,為了在很大程度上降低用戶的學(xué)習(xí)成本,所以將數(shù)據(jù)底層的對(duì)象編輯器,和展示層的表單編輯器融合在一起了。
現(xiàn)在,我們來解決一個(gè)棘手的問題。如果我們希望在學(xué)生視圖中,呈現(xiàn)出該學(xué)生的老師姓名,該如何做到呢?通過學(xué)生,可以找到所在班級(jí),但是,負(fù)責(zé)班級(jí)的老師是誰呢?如何定義呢?
一種做法,是針對(duì)“班級(jí)”表單增加一個(gè)字段,可以關(guān)聯(lián)老師的賬號(hào),完成老師和班級(jí)的關(guān)系映射。在明道云,我們采用了另一種取巧的方式,需要由校長,將每一條班級(jí)數(shù)據(jù)的擁有者,修改成具體的老師賬號(hào),如下圖,圖中“王老師”,是一名角色為“老師”的獨(dú)立用戶。
通過這個(gè)動(dòng)作,實(shí)現(xiàn)了對(duì)班級(jí)負(fù)責(zé)老師的分配。接下來,再利用前邊提到過的“他表字段”功能,將這個(gè)字段值引入其他表單對(duì)象中。
如此一來,所有針對(duì)某個(gè)班級(jí)下邊關(guān)聯(lián)的學(xué)生,以及針對(duì)學(xué)生關(guān)聯(lián)的健康上報(bào)記錄,我們就都可以追溯到所負(fù)責(zé)的老師了,這對(duì)下一個(gè)需求的實(shí)現(xiàn)至關(guān)重要!
5. 低代碼實(shí)現(xiàn)——通過流程編輯器定義業(yè)務(wù)過程和事件
我們回憶下,現(xiàn)前有這樣一條需求:如果健康上報(bào)體溫異常,自動(dòng)生成一條待跟進(jìn)任務(wù),發(fā)送給該學(xué)生班主任,并推送消息給校長。
這個(gè)需求該如何實(shí)現(xiàn)呢?這就用到了aPaaS平臺(tái)中非常核心且重要的流程編輯器功能,可以說流程編輯器是低代碼平臺(tái)的靈魂!
將上述需求,進(jìn)一步準(zhǔn)確描述:如果新增或編輯“健康上報(bào)”表單數(shù)據(jù)時(shí),其中的“體溫是否正?!弊侄芜x擇了“否”,則自動(dòng)生成一條狀態(tài)為“待跟進(jìn)”的“體溫異常跟蹤”數(shù)據(jù),并發(fā)送消息給校長,以及該學(xué)生的老師。
在低代碼平臺(tái)中,通過流程編輯器,來實(shí)現(xiàn)類似于以上這類帶有自動(dòng)化觸發(fā)執(zhí)行,以及多表數(shù)據(jù)自動(dòng)更新的功能。我們來到流程編輯器,創(chuàng)建“異常體溫上報(bào)觸發(fā)跟進(jìn)任務(wù)記錄”流程,如下圖:
在圖中,我們?cè)O(shè)計(jì)了三個(gè)流程節(jié)點(diǎn)。
- 第一個(gè)觸發(fā)節(jié)點(diǎn):定義了當(dāng)“健康上報(bào)”表單在新增或更新數(shù)據(jù)時(shí),如果發(fā)現(xiàn)“提問是否正?!弊侄蔚扔凇胺瘛保瑒t往下執(zhí)行。
- 第二個(gè)節(jié)點(diǎn):當(dāng)發(fā)現(xiàn)體溫異常時(shí),創(chuàng)建一條“體溫異常跟蹤”數(shù)據(jù),分配給上報(bào)記錄學(xué)生的老師。
- 第三個(gè)節(jié)點(diǎn):發(fā)送應(yīng)用內(nèi)消息給校長和老師,提醒處理,效果如下圖:
由工作流創(chuàng)建的數(shù)據(jù),創(chuàng)建者字段顯示為工作流,如下圖:
流程編輯器,不是簡(jiǎn)單地工作流引擎,我們一般理解的工作流引擎,例如審批流,只是針對(duì)單一數(shù)據(jù)對(duì)象的多節(jié)點(diǎn)處理。而真正復(fù)雜的流程編輯器BPM,需要在流程中對(duì)不同數(shù)據(jù)實(shí)體進(jìn)行復(fù)雜處理,這也是很多B端業(yè)務(wù)的核心處理邏輯和過程。
當(dāng)然明道云的流程編輯器功能很多,如下圖,我們不再贅述。
截止現(xiàn)在,還有個(gè)核心功能,我們沒有實(shí)現(xiàn),家長如何上報(bào)數(shù)據(jù)?
一種辦法,是針對(duì)每個(gè)家長開通一個(gè)賬號(hào),賬號(hào)和學(xué)生做關(guān)聯(lián),家長登錄系統(tǒng),提交表單時(shí)默認(rèn)會(huì)提交相關(guān)學(xué)生的“健康上報(bào)”記錄。
另一種辦法,是將“健康上報(bào)”的表單公開出去,任何人都可以提交,這樣做的好處是不需一個(gè)一個(gè)維護(hù)家長賬號(hào),壞處是因?yàn)橄到y(tǒng)無法識(shí)別提交人和對(duì)應(yīng)的兒童,需要提交人手工從學(xué)生清單中選擇學(xué)生,操作比較繁瑣。
如下圖,我們將表單設(shè)置了公開鏈接。
6. 低代碼實(shí)現(xiàn)——通過報(bào)表編輯器定義報(bào)表和儀表盤
走到這一步,涉及到業(yè)務(wù)流程的核心功能和數(shù)據(jù)表單都開發(fā)完畢了,接下來,我們需要給李校長配置她的管理工作臺(tái),也就是dashboard。通過類似報(bào)表引擎的功能,配置出校長的監(jiān)控儀表盤,我們將其放在“校長控制臺(tái)”的一級(jí)導(dǎo)航下邊,如下圖:
該功能的使用,和經(jīng)典的報(bào)表引擎相通,不再贅述。
7. 低代碼實(shí)現(xiàn)——配置角色、權(quán)限
最后,我們進(jìn)行角色、權(quán)限的設(shè)置。我們?cè)O(shè)置了兩個(gè)角色,“校長”和“老師”。
B端產(chǎn)品的權(quán)限管理包括兩部分,功能權(quán)限決定了用戶可以訪問哪些菜單,操作哪些按鈕,數(shù)據(jù)權(quán)限決定了用戶可以訪問操作的數(shù)據(jù)集合范圍是什么,一般通過組織機(jī)構(gòu)樹來實(shí)現(xiàn)。
下圖是明道云的數(shù)據(jù)權(quán)限配置管理全貌:
可以看到,每個(gè)針對(duì)每個(gè)角色,設(shè)計(jì)不同表單視圖的查看、編輯權(quán)限,這是功能權(quán)限。
點(diǎn)擊每個(gè)表單最后的設(shè)置按鈕,還可以定義角色針對(duì)表單的數(shù)據(jù)權(quán)限,包括是否允許處理所有數(shù)據(jù),抑或是本人和下屬的數(shù)據(jù),抑或是本人擁有的數(shù)據(jù)(記得前面案例中我們對(duì)班級(jí)的“擁有者”進(jìn)行了調(diào)整么),抑或是本人創(chuàng)建的數(shù)據(jù)。
甚至還可以針對(duì)具體的字段設(shè)置更精細(xì)化的權(quán)限,如上圖左下角窗口所示意。
完成以上配置,我們的低代碼平臺(tái)開發(fā)工作就完畢了,明道云的應(yīng)用系統(tǒng)不需要發(fā)布,配置后立即生效。所有用戶需要注冊(cè)明道云賬號(hào)來使用配置好的系統(tǒng)。配置完成的應(yīng)用沒有獨(dú)立的應(yīng)用程序,通過訪問明道云官網(wǎng)登陸后使用,移動(dòng)版需要下載明道云APP,登陸后進(jìn)行使用。
最后給大家展示下移動(dòng)版應(yīng)用的截圖,這些都是自動(dòng)生成的默認(rèn)設(shè)計(jì),沒有做過調(diào)整。
三、低代碼平臺(tái)的本質(zhì)
通過以上例子,相信大家對(duì)低代碼平臺(tái)的能力已經(jīng)有了一個(gè)直觀的感受。
軟件產(chǎn)品設(shè)計(jì)的標(biāo)準(zhǔn)結(jié)構(gòu)是MVC模型,即Model(數(shù)據(jù))、Controller(邏輯)、View(交互界面),低代碼平臺(tái)正是通過幾個(gè)核心組件,完成了對(duì)MVC三層架構(gòu)模型的支撐,對(duì)應(yīng)著MVC模型,這三個(gè)核心組件分別是數(shù)據(jù)模型設(shè)計(jì)器(對(duì)應(yīng)Model)、流程設(shè)計(jì)器(對(duì)應(yīng)Controller)、頁面設(shè)計(jì)器(包括了報(bào)表設(shè)計(jì)器,對(duì)應(yīng)View)。
1. 數(shù)據(jù)模型設(shè)計(jì)器
數(shù)據(jù)模型設(shè)計(jì),實(shí)現(xiàn)了對(duì)底層數(shù)據(jù)對(duì)象的定義。我們之前已經(jīng)提到過,不同低代碼平臺(tái),對(duì)數(shù)據(jù)對(duì)象的定義實(shí)現(xiàn)方式并不相同。
數(shù)據(jù)模型設(shè)計(jì)器的第一種實(shí)現(xiàn)方式,是通過對(duì)象編輯器實(shí)現(xiàn)數(shù)據(jù)定義。這種方式靈活程度最高,將底層數(shù)據(jù)模型和前端視圖分離,模型聚焦底層,視圖是可視化的呈現(xiàn)。
國外的低代碼平臺(tái)Mendix,國內(nèi)的華為云AppCube都采用了這種方式。另外大型商用軟件的低代碼平臺(tái)也都采用同樣的設(shè)計(jì),例如SalesForce、紛享銷客等。
下圖是Mendix的對(duì)象編輯器,在Mendix中叫做Domain Model(領(lǐng)域模型),實(shí)際上領(lǐng)域模型和對(duì)象編輯都是屬于面向?qū)ο缶幊痰母拍?。?yán)格來講領(lǐng)域模型和我們之前提到的ER模型并不完全相同,領(lǐng)域模型擁有面向?qū)ο缶幊痰奶卣?,例如泛化、聚合,這些概念ER模型中是沒有的。
另外圖中展現(xiàn)的是Mendix的Windows客戶端版本,除了Web版,Mendix還提供了功能更加強(qiáng)大的Windows客戶端。經(jīng)過簡(jiǎn)單體驗(yàn),這套客戶端更像是開發(fā)集成編輯器IDE(程序員寫代碼的軟件平臺(tái))。Mendix本身的功能也非常強(qiáng)大,當(dāng)然學(xué)起來也更困難。
國外另一個(gè)知名aPaaS產(chǎn)品outsystems也采用了底層對(duì)象驅(qū)動(dòng)的設(shè)計(jì),并且也提供了windows版本的客戶端,安裝后有一個(gè)step by step的tutorial,非常驚艷!整套IDE風(fēng)格的產(chǎn)品化設(shè)計(jì),也非常強(qiáng)悍,讓人印象深刻!
華為云的AppCube貌似也是對(duì)象編輯器的設(shè)計(jì)方式,但因?yàn)槲业脑囉蒙暾?qǐng)一直未通過,所以只是通過幫助文檔做了猜測(cè),無法具體體驗(yàn),如下圖:
數(shù)據(jù)模型設(shè)計(jì)的第二種實(shí)現(xiàn)方式,是表單引擎。
對(duì)于設(shè)計(jì)人員來講,只需要把底層的數(shù)據(jù)對(duì)象,理解成Excel的多張獨(dú)立的表,每個(gè)表通過表單采集數(shù)據(jù)。用戶定義數(shù)據(jù)模型,只需要將表單中的數(shù)據(jù)采集控件定義即可。
例如下圖,是釘釘?shù)囊舜畹谋韱尉庉嬈鳎O(shè)計(jì)思路和明道云的表單編輯器類似。表單編輯器將數(shù)據(jù)底層設(shè)計(jì)和可視化呈現(xiàn)打包在一起,對(duì)于非技術(shù)人員更容易理解,但也會(huì)喪失前后端分離的靈活性。
2. 流程設(shè)計(jì)器
定義了底層數(shù)據(jù)后,下一步要定義工作流。對(duì)于業(yè)務(wù)型軟件產(chǎn)品,工作流是支撐業(yè)務(wù)運(yùn)作的核心。業(yè)務(wù)運(yùn)行的本質(zhì),就是一個(gè)個(gè)工作流的執(zhí)行。
淺層次的工作流,是類似于Workflow這樣的審批流,是對(duì)單一數(shù)據(jù)對(duì)象的處理;深層次的工作流,需要能夠支持多數(shù)據(jù)實(shí)體在流程中的自動(dòng)化處理。后者是低代碼產(chǎn)品的核心功能之一,如果不具備后者的能力,基本上除了問卷表,什么系統(tǒng)都搭不出來。
什么叫多數(shù)據(jù)實(shí)體在流程中的自動(dòng)化處理呢?
比如說銷售型CRM系統(tǒng),當(dāng)線索的狀態(tài)變?yōu)橐押藢?shí),就需要自動(dòng)生成一條待跟進(jìn)的商機(jī)記錄,并將商機(jī)分配給合適的銷售,同時(shí)還要生成對(duì)應(yīng)的聯(lián)系人記錄和客戶記錄,商機(jī)、聯(lián)系人、客戶的部分字段數(shù)據(jù)來自于線索實(shí)體。
這個(gè)業(yè)務(wù)邏輯規(guī)則,就需要復(fù)雜的工作流編輯器實(shí)現(xiàn),在這條自動(dòng)化處理流程中,涉及到了四個(gè)實(shí)體數(shù)據(jù)的增刪改查(線索、商機(jī)、客戶、聯(lián)系人)。
下圖展示的是Mendix的Windows客戶端版本下的流程編輯器。
下圖展示的是國內(nèi)產(chǎn)品釘釘宜搭的工作流編輯器,感覺似乎過于簡(jiǎn)單,只是一個(gè)審批流編輯器,也可能是我沒找到完整功能的配置界面?
3. 頁面設(shè)計(jì)器
對(duì)于業(yè)務(wù)型軟件產(chǎn)品,主要功能是對(duì)數(shù)據(jù)的增刪改查,而涉及到的交互頁面,多數(shù)也都是底層數(shù)據(jù)對(duì)象對(duì)應(yīng)的列表頁、詳情頁,除此以外,還包括報(bào)表、儀表盤,以及其他類型頁面。
對(duì)頁面設(shè)計(jì)器的設(shè)計(jì)理念,明顯體現(xiàn)出了不同低代碼平臺(tái)的產(chǎn)品思路,整體來看,可以總結(jié)為兩類形態(tài)。
1)純粹的前端頁面編輯器
包括了報(bào)表、列表、視圖、表單,都在這一體化的頁面編輯器中實(shí)現(xiàn)。比如Outsystems的頁面編輯器,如下圖:
可以看到,這是一套復(fù)雜的前端交互組件設(shè)計(jì)器,包括了類似于數(shù)據(jù)表集合Table Records的集成控件,也包括了表單控件Form,以及其他各類型控件集合,例如復(fù)選框Check Box,單選框Radio Button等等。
在這套編輯器中,操作者可以定義例如列表頁、詳情頁、報(bào)表、儀表盤各類型前端頁面。再比如Mendix的頁面編輯器,也是同樣的設(shè)計(jì)思路,如下圖:
即便是dashboard,也是在同樣的頁面編輯器實(shí)現(xiàn),如下圖是Mendix的dashbaord的demo:
低代碼平臺(tái)的報(bào)表設(shè)計(jì)器組件,和傳統(tǒng)的報(bào)表引擎沒有太大區(qū)別,都是基于底層的數(shù)據(jù),實(shí)現(xiàn)前端可視化輸出,包括表格輸出和圖形輸出。以上是第一種前端交互設(shè)計(jì)的產(chǎn)品形態(tài),可以看出,功能強(qiáng)大、靈活,學(xué)習(xí)成本也比較高。
2)大大簡(jiǎn)化了的頁面配置器
將不同類型的頁面,進(jìn)行模板化配置,主要分為以下幾類。
- 首先:將數(shù)據(jù)對(duì)象和表單相結(jié)合,通過定義表單(Form),完成了數(shù)據(jù)對(duì)象的定義,同時(shí)也構(gòu)建出了詳情頁;
- 其次:通過視圖編輯器這類組件,定義了針對(duì)數(shù)據(jù)對(duì)象的列表頁;
- 最后:通過單獨(dú)的dashboard配置器,完成類似于報(bào)表引擎的定義功能。
當(dāng)然,低代碼產(chǎn)品也會(huì)提供集成頁面的配置,但功能要比前邊提到的功能弱很多。前文已經(jīng)大量描述了明道云的視圖編輯器,不再贅述。
下圖是宜搭的頁面編輯器,展示了對(duì)某個(gè)系統(tǒng)首頁的編輯。相對(duì)明道云,宜搭的頁面編輯器更復(fù)雜一些,功能也更強(qiáng)大一些。
再例如,下圖是宜搭的報(bào)表編輯器:
數(shù)據(jù)模型設(shè)計(jì)器、流程設(shè)計(jì)器和頁面設(shè)計(jì)器,是低代碼平臺(tái)的核心,如果你理解軟件設(shè)計(jì)的MVC分層架構(gòu),就很容易理解低代碼平臺(tái)的核心產(chǎn)品功能,以及不同的產(chǎn)品思路。當(dāng)然不同低代碼平臺(tái)還有更多各具特色的強(qiáng)悍功能,有興趣的讀者可以進(jìn)一步研究。
四、結(jié)語
可以看出,不同的低代碼平臺(tái),設(shè)計(jì)思路并不相同。
產(chǎn)品的易用性和產(chǎn)品的靈活性之間存在平衡和取舍。例如,對(duì)于數(shù)據(jù)底層,究竟選擇表單驅(qū)動(dòng)的設(shè)計(jì),還是領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)?這兩者區(qū)別非常大,后者對(duì)于非技術(shù)人員,基本不可用,而前者雖然易于學(xué)習(xí)理解,但功能確實(shí)也要弱化很多。
因此,低代碼平臺(tái)要明確目標(biāo)用戶群體,究竟是給ISV或IT團(tuán)隊(duì)使用的專業(yè)開發(fā)輔助工具,還是給非技術(shù)人員使用的強(qiáng)化版提效工具?前者更像是IDE的超級(jí)插件包,后者更像是Excel VBA的超強(qiáng)易用版。
對(duì)于B端產(chǎn)品經(jīng)理來講,體驗(yàn)下類似于明道云這樣的低代碼產(chǎn)品,對(duì)理解軟件設(shè)計(jì)很有益處,不論是表單,還是流程,還是權(quán)限管理,所有核心的產(chǎn)品設(shè)計(jì)問題都會(huì)涉及到,并且能夠加深理解。
另外,萬一業(yè)務(wù)有個(gè)大型需求,研發(fā)沒排期,你3個(gè)小時(shí)就用aPaaS配置出來了,年度CEO特別獎(jiǎng)不給你給誰呢!
#專欄作家#
楊堃,公眾號(hào):PM楊堃(ID:pmYangKun)。人人都是產(chǎn)品經(jīng)理專欄作家,《決勝B端》作者,12年互聯(lián)網(wǎng)研發(fā)、產(chǎn)品設(shè)計(jì)經(jīng)驗(yàn),曾任VIPKID產(chǎn)品總監(jiān),百度高級(jí)產(chǎn)品經(jīng)理,現(xiàn)為慢酷咨詢創(chuàng)始人兼CEO。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于 CC0 協(xié)議