整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
要
單選按鈕控件(RadioButton控件)為用戶提供由兩個(gè)或多個(gè)互斥選項(xiàng)組成的選項(xiàng)集。當(dāng)用戶選中某單選按鈕時(shí)，同一組中的其他單選按鈕不能同時(shí)選定。
正文
當(dāng)用戶選擇一個(gè)選項(xiàng)按鈕 (也稱為組中的單選按鈕) 時(shí)，其他人會(huì)自動(dòng)清除。 給定容器中的所有 RadioButton 控件（如 a Form）構(gòu)成組。 若要在一個(gè)窗體上創(chuàng)建多個(gè)組，請(qǐng)將每個(gè)組放置在其自己的容器中，例如或GroupBoxPanel控件。
RadioButton 控件 CheckBox 具有類似的功能：他們提供用戶可以選擇或清除的選項(xiàng)。 區(qū)別在于可以同時(shí)選擇多個(gè) CheckBox 控件，但選項(xiàng)按鈕互斥。
屬性
CheckAlign | 獲取或設(shè)置 RadioButton 的復(fù)選框部分的位置。 |
Checked | 獲取或設(shè)置一個(gè)值，該值指示是否已選中控件。 |
方法
BringToFront() | 將控件帶到 Z 順序的前面。 |
Focus() | 為控件設(shè)置輸入焦點(diǎn)。 |
Hide() | 對(duì)用戶隱藏控件。 |
Show() | 向用戶顯示控件。 |
事件
CheckedChanged | 當(dāng) Checked 屬性的值更改時(shí)發(fā)生。 |
Click | 在單擊控件時(shí)發(fā)生。 |
一個(gè)例子
在窗體上添加3個(gè)RadioButton，點(diǎn)擊時(shí)在窗口顯示選中的RadionButton 文本。
private void radioButton1_CheckedChanged(object sender, EventArgs e)
{
this.Text=((RadioButton)sender).Text;
}這里有一個(gè)操作，就是將3個(gè)RadioButton的CheckedChanged事件同時(shí)綁定到一個(gè)后臺(tái)事件上。
修改一下界面，我們添加一個(gè)GroupBox容器，在窗口中添加三個(gè)RadionButton，你會(huì)發(fā)現(xiàn)這三個(gè)與先前的三個(gè)不在一組中。
我們新增一個(gè)Button，點(diǎn)擊判斷groupBox1中誰被選中了。
絡(luò)收音機(jī)這個(gè)名字在很多人眼里可能只是一類軟件的名字，但以前它也曾經(jīng)有另一種定義：一種基于網(wǎng)絡(luò)的音樂播放器，它無須自備 CD 、卡帶、存儲(chǔ)卡等音樂載體，直接通過網(wǎng)絡(luò)接收音樂。這種方式與收音機(jī)有點(diǎn)類似，而且那時(shí)候音樂網(wǎng)站并不多，實(shí)際上收聽的內(nèi)容也是以各個(gè)電臺(tái)的網(wǎng)絡(luò)直播為主，并且很多產(chǎn)品自己也直接命名為收音機(jī)，比如 Roku 公司的 SoundBridge Radio 系列和羅技的 Squeezebox Radio ，所以這類播放器就被叫做網(wǎng)絡(luò)收音機(jī)了。
這類產(chǎn)品出現(xiàn)至少已經(jīng)有10年以上的歷史，天龍、安橋、雅馬哈、曼哈卡頓、 SONY 、先鋒、 BOSE 等等很多老牌音響廠商都有生產(chǎn)，但國(guó)內(nèi)一直并不紅火。但這兩年“智能設(shè)備”風(fēng)潮井噴式爆發(fā)，也順帶著連這類產(chǎn)品一起炒紅了，但操作面板被移植到了手機(jī)、平板上，并有了更加新潮的名字：智能 WiFi 音箱。這次體驗(yàn)的 SUGR 方糖音箱就是這樣的一款產(chǎn)品，也是我遇到設(shè)計(jì)最另類的一款音響產(chǎn)品。
一、開箱及外觀介紹
方糖采用了現(xiàn)在主流的簡(jiǎn)約包裝方式，綠色的紙?zhí)咨蟽H有一個(gè) SUGR Cube 的品名及一個(gè)極具蘋果風(fēng)格的圓角正方形圖標(biāo)。
取掉紙?zhí)缀蟛攀钦嬲陌b盒，同樣的簡(jiǎn)約風(fēng)格，類似首飾盒的斜向開蓋。
開蓋后就能看到 SUGR 立在里面，四周都有泡沫防護(hù)很是安全，音箱底下的小盒子里放著電源等配件。
方方正正一小塊確實(shí)與方糖這個(gè)名字很契合，前面板造型與紙?zhí)咨系膱D標(biāo)長(zhǎng)的一模一樣，看不到任何開關(guān)或按鈕，這種簡(jiǎn)約的外形設(shè)計(jì)很是討喜。
方糖的體積僅有 104*104*108 ，實(shí)測(cè)重量 596g ，與2個(gè)月大的小貓放在一起都顯得很小，算得上小巧輕便，內(nèi)置 6000mAh 電池可提供7小時(shí)的播放時(shí)間。與傳統(tǒng)音箱最大的區(qū)別在于它還有 1G 的 x-brust CPU 、 4GB 閃存和 WiFi 支持。音頻方面則是 4W 的輸出功率和3寸全頻揚(yáng)聲器，并沒有提供頻率范圍參數(shù)。
方糖的背后則為塑料質(zhì)地，正中間是音量旋鈕兼電源開關(guān)，旋鈕上那個(gè)扁長(zhǎng)小孔是指示燈。旋鈕上方的小孔是麥克風(fēng)，下方大孔則是倒相管，可增加音箱的低頻量，右下角則是 Micro-USB 充電孔和 Reset 孔。需要注意的是雖然方糖使用 Micro-USB 接口，但它所需的充電電壓是 12V 1A，并不能直接用普通 USB 充電器給它充電。
雖然方糖外觀上有著漂亮的原木紋理，但實(shí)際上它并非原木箱體，而是貼的一層原木木皮。原木木皮是用天然木材旋切出來的一層約 0.5mm 的薄片，所以有著天然木材的觸感和紋理。這是音箱和家具都普遍采用的一種方式，比如上圖背景就是我的電腦桌，貼的樺木木皮，色彩和我這個(gè)方糖用的北美白楓很接近。
方糖的底部則是一片橡膠，起到避震和防滑的作用。從橡膠上下露出的部分可以看到木皮接縫的地方。
從揚(yáng)聲器周圍一圈的板材截面紋理也可以明顯看出，方糖的前面板并非原木而是密度板。 Kickstarter 網(wǎng)站的 Sugr Cube 介紹頁面也寫明了箱體采用 9mm 中密度纖維板( MDF )制造。
這問題我也問了很多朋友，多數(shù)妹紙表示看不出來，覺得方糖的木質(zhì)造型很漂亮，但多數(shù)男性朋友一眼看出了問題所在：直接原木打造不可能一圈連貫的順紋，總要有橫截面才對(duì)。
方糖附帶的充電器挺讓人驚喜，居然采用了高通 QuickCharge2.0 快速充電器，插頭則是拆卸式，遺憾的是只附帶了國(guó)標(biāo)插頭，附帶的 USB 線很粗但很柔軟。
這個(gè)充電器支持 100-240V 全球電壓，高通 QuickCharge2.0 快充規(guī)格也支持 5V 、 9V 、 12V 幾種輸出，能根據(jù)手機(jī)自動(dòng)判斷充電電壓，所以這個(gè)充電器也能用來給平板和手機(jī)充電，出行就可以少帶個(gè)充電器了。
拆卸式插頭組裝后體積會(huì)偏大，但也能通過換插頭支持全球使用，只是插頭不大好買，要方糖能附贈(zèng)多個(gè)插頭就好了。
功率計(jì)實(shí)測(cè)方糖充電功率為 11.3W ，估算充電效率及方糖的電池容量，充滿電大概需要1.3小時(shí)左右。
外觀介紹就到這里，下面開始操作及功能說明。
二、操作及功能說明
現(xiàn)在音箱的操作方式越來越多了，比如京東和科大訊飛合作推出的 Dingdong 就加入了語音控制功能，全身沒有按鈕的方糖當(dāng)然也要有自己獨(dú)有的操作方式。
方糖采用了特殊的“體感”操作方式，輕拍音箱頂部就能開始播放音樂或暫停。
向左或向右傾斜則能切換上下曲目，這也就意味著要擺放在比較空的地方才有操作空間。
未來還能設(shè)計(jì)更多的操作方式，比如在 Kickstarter 站的介紹里就有長(zhǎng)按頂部分享音樂的操作，以后國(guó)內(nèi)可能也會(huì)有一按微博或朋友圈的選項(xiàng)呢。
體感操作很好玩，但是也給我造成一定困擾，我家的貓?zhí)矚g去踩它了。。。
當(dāng)然主要操作方式還是依賴手機(jī)，畢竟選曲、選功能只有手機(jī)App 上才能設(shè)置。方糖說明書上的安卓 App 居然掃碼直接找不到頁面，因此本次測(cè)試都是在 iOS 下進(jìn)行的。
方糖音箱目前主要有六大功能：放松音樂、收音機(jī)、 RANDORA 、荔枝 FM 、豆瓣 FM 、本地音樂，但方糖的系統(tǒng)是可更新的，只要合作方增加以后資源也會(huì)更多，比如百度音樂、 QQ 音樂等將來都有可能進(jìn)駐。
方糖目前的前三個(gè)功能都不大具有實(shí)用性，我就一句話帶過了,后面主要介紹后三個(gè)主要功能。
放松音樂：內(nèi)置的雨聲、海浪聲、鳥叫聲等，但是這些聲音都太短，并且兩次循環(huán)中間會(huì)有那么一秒無聲。
收音機(jī)：主要是 BBC 等國(guó)外電臺(tái)，連接不大穩(wěn)定，并非帶寬問題，1 00M 電信光纖依舊經(jīng)常卡。
PANDORA ：僅允許美國(guó)、澳大利亞和新西蘭的IP訪問，國(guó)內(nèi) IP 無法使用。
荔枝 FM 的音樂內(nèi)容并不突出，但相聲、評(píng)書、脫口秀、有聲小說等方面的資源特別多。方糖聽荔枝 FM 非常流暢，音質(zhì)也很好，缺點(diǎn)是沒有搜索也不能收藏，每次只能從榜單或分類里慢慢找。
豆瓣 FM 也有著不能搜索的問題，雖然增加了收藏功能，但賬號(hào)不知何故無法登陸，所以也只有直接從列表里選。
方糖內(nèi)置的 4GB 存儲(chǔ)空間可以存放不少的音樂文件，因此最后一個(gè)功能目前來說是最實(shí)用的。音樂文件可以直接從手機(jī)傳送進(jìn)去，電腦則要用瀏覽器訪問方糖的 IP ，從專用頁面來上傳。除了常見的 MP3 外，方糖還支持 WAV 、 APE 等多種無損格式，因此這個(gè)方式也能獲得最好的音質(zhì)。但這個(gè)功能還是有類似前面的問題，它只能按順序播放里面的所有音樂，不支持自建播放列表或分類，也不能對(duì)音樂文件進(jìn)行排序，因此不能隨心情隨意調(diào)用不同類型的音樂。
除了幾個(gè)主要功能外，方糖還附帶了鬧鐘、煲機(jī)和濾鏡的功能。但濾鏡暫時(shí)還是空的，鬧鐘不能選擇音樂，只有 iPhone 的鬧鐘聲音一種，只有煲機(jī)的實(shí)用性較高。本文后面的音質(zhì)測(cè)試部分都是在煲機(jī)超過15小時(shí)候進(jìn)行的。
除了作為網(wǎng)絡(luò)音樂播放器外，方糖還提供了 AirPlay 功能，以后通過軟件升級(jí)，方糖也可能會(huì)支 持DLNA 、 UPnP 等無線模式。 iPhone 、 iPad 、蘋果電腦等都能通過 AirPlay 直接把聲音通過 WiFi 傳送給方糖。 PC 安裝 iTunes 后也可以通過 AirPlay 用方糖來播放音樂，但其它軟件就不支持了。
有了 AirPlay 的支持，用 iPad 玩游戲、看電影、聽音樂就不再局限于內(nèi)置喇叭了，外接音箱的效果會(huì)好的多。但實(shí)測(cè)發(fā)現(xiàn)看視頻時(shí)候會(huì)有聲畫不同步的情況，希望下一次系統(tǒng)升級(jí)能解決這個(gè)問題。
三、音質(zhì)主觀測(cè)試
當(dāng)我在官網(wǎng)和 Kickstarter 看到這張頻譜曲線的時(shí)候是很震驚的，這圖完全不像是一個(gè)全頻帶音箱，而是2.1音箱中的衛(wèi)星箱。從頻譜曲線看來方糖的高頻整體略為提升， 2K - 8K 一段比較平直， 8K-11K 段更加提升，一直到 20K 都沒有跌落。從這一部分來看方糖語音的清晰、明亮度表現(xiàn)應(yīng)該不錯(cuò)，高音的層次和色彩以及泛音都應(yīng)該挺好。
但看低音段就非常奇怪了，通常小尺寸全頻帶音箱的低音截止頻率會(huì)設(shè)定在 80-100Hz ，因?yàn)?80Hz 以下的低頻不是小尺寸音箱能駕馭的，駕馭不好反而影響效果，而 80-160Hz 這一段是極為重要的低音基音區(qū)，聲音的厚實(shí)感主要就來自這里，量不足則音色會(huì)表現(xiàn)的很無力，方糖居然從大約 150Hz 開始就迅速跌落，這是要放棄低音？還是準(zhǔn)備再出一個(gè)配套的低音炮？
通常我們都不會(huì)拿耳機(jī)和音箱做比較，但方糖的頻譜曲線實(shí)在太奇怪了，而我又沒有全頻段表現(xiàn)良好的大尺寸音箱作為比較，所以就動(dòng)用了森海 HD598 ，這個(gè)耳機(jī)在 60 - 300Hz 之間還是非常平直的。
順便我還用 BOSE 的 SOUNLINK mini 做為對(duì)比參考， BOSE 在小體積音箱上的低音量感上無人能及，而高音方面則相對(duì)保守，可以說跟方糖是完全相反的設(shè)計(jì)。
測(cè)試曲目主要是惠威2010年的試音碟和雨果發(fā)燒碟一，全部采用 WAVE 格式，方糖直接播放內(nèi)存中的音樂文件，而 BOSE 和 HD598 均用 iPhone5C 。選擇雨果發(fā)燒碟一主要是因?yàn)樗峁┝藦?25Hz 到 20KHz 近30個(gè)頻率點(diǎn)的測(cè)試信號(hào)，剛好可以用來驗(yàn)證方糖的頻率范圍。
低音范圍測(cè)試：
我用 250Hz 測(cè)試信號(hào)把方糖、 BOSE 和 HD598 都調(diào)到聽感上基本一致的音量，然后從高到低試聽各個(gè)設(shè)備的回放效果， HD598 作為參考標(biāo)準(zhǔn)。
方糖 200Hz 時(shí)還基本與 HD598 保持一致，到 160Hz 就已經(jīng)明顯低于 HD598 了，到 100Hz 已經(jīng)非常微弱， 63Hz 完全聽不到了，這一結(jié)果基本與官網(wǎng)公布頻譜曲線吻合。
BOSE 一直到 160Hz 都基本與 HD598 都保持一致， 125Hz 和 100Hz 兩個(gè)點(diǎn)則明顯高于 HD598 ，到 63Hz 還量感十足， 56Hz 則完全聽不到了。
這一測(cè)試中我還發(fā)現(xiàn)方糖的底噪表現(xiàn)明顯優(yōu)于藍(lán)牙連接的 BOSE ，正常聽音距離下聽不到電流聲，只有貼著耳朵才能聽到。
音質(zhì)主觀測(cè)試：
從前面的測(cè)試可以看出方糖是個(gè)極為偏食的音箱，但測(cè)試中我還是選擇多范圍的音樂進(jìn)行比較。小提琴《梁祝》：小提琴的頻率范圍是方糖可以完美掌控的，在小提琴的音色、泛音、空間感方面方糖要明顯優(yōu)于 BOSE ，但是在曲子始末的合奏部分方糖則明顯吃虧，鼓聲和大提琴的聲音損失了太多細(xì)節(jié)。鋼琴協(xié)奏曲《黃河》：音域極光的鋼琴顯然不是方糖的菜，雖然方糖的節(jié)奏、清晰度都明顯優(yōu)于 BOSE ，但低音細(xì)節(jié)損失過多，氣場(chǎng)差太遠(yuǎn)了。《女聲清唱-試音方程式》：人聲方面方糖表現(xiàn)極好，明快干凈的聲音遠(yuǎn)遠(yuǎn)強(qiáng)于 BOSE ，在聽荔枝 FM 上聽各種脫口秀、相聲、有聲小說等內(nèi)容，方糖的表現(xiàn)都非常好。
四、體驗(yàn)總結(jié)
方糖算是我體驗(yàn)過非常另類的音箱，它有著小巧的外形和特別的操作方式，原木質(zhì)感的外觀也很漂亮，放在床頭或茶幾上是個(gè)挺不錯(cuò)的裝飾品。它的聲音干凈清爽，但低頻缺失的問題會(huì)讓它非常偏食，這似乎并不符合現(xiàn)在的主流方向，否則主打低音的 BOSE SOUNLINK mini 也不會(huì)這么紅了。方糖的 App 界面同樣干凈清爽，但播放列表、搜索這些基礎(chǔ)功能還是應(yīng)該加上，否則實(shí)在有點(diǎn)影響使用。
語：本文基于作者虛構(gòu)的“幼兒園健康上報(bào)系統(tǒng)”，演示如何用低代碼平臺(tái)快速搭建一套應(yīng)用系統(tǒng)，并介紹演示了國(guó)內(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í)施顧問。國(guó)外的SAP、Oracle、SalesForce，國(guó)內(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人員。
國(guó)外的OutSystems、Mendix，國(guó)內(nèi)的明道云、氚云，都屬于這種情況。需要留意的是，目前國(guó)內(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)：
好了，接下來，讓我們進(jìn)入案例。
李校長(zhǎng)是小豚鼠幼兒園的校長(zhǎng)，最近她遇到了一個(gè)煩心事，根據(jù)教委統(tǒng)一要求，疫情期間，需要家長(zhǎ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è)幼兒園，這可是一筆不小的開銷。
李校長(zhǎng)的侄子小王是一名B端產(chǎn)品經(jīng)理，在閑聊中得知了李校長(zhǎng)的難題，心思一動(dòng)，問道：
小王：姑姑，您說的這事兒，或許我能幫上忙，做一套軟件系統(tǒng)，就可以很好地解決您的問題！
李校長(zhǎng)：真的嗎，那太好了，但是我們沒有很多預(yù)算啊！
小王：不用花您一分錢，我?guī)湍赓M(fèi)做，不過我想先了解下您對(duì)這個(gè)業(yè)務(wù)管理的訴求和期望。
李校長(zhǎng)：多謝啊！我的訴求很簡(jiǎn)單，就是讓家長(zhǎng)們每天打卡，如果有健康異常的情況，我能第一時(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ì)方案。
李校長(zhǎng)：太棒啦，期待！
小王了解完基本需求后，開始構(gòu)思這套系統(tǒng)該如何設(shè)計(jì)。首先整理下這套系統(tǒng)涉及到的利益方，分別如下：
雖然業(yè)務(wù)本身過程很簡(jiǎn)單，但因?yàn)楫吘故且惶讖臒o到有搭建的管理系統(tǒng)，有些基礎(chǔ)數(shù)據(jù)準(zhǔn)備工作需要完成。小王思考了一會(huì)兒后，繪制出了一份簡(jiǎn)明的業(yè)務(wù)流程圖，如下。
可以看到，期望家長(zhǎng)能打卡，有些基礎(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ù)做增刪改查而已。
接下來，我們基于流程圖，來思考系統(tǒng)落地執(zhí)行的頁面流轉(zhuǎn)圖：
除了這些頁面級(jí)別的操作需求，還有一些業(yè)務(wù)規(guī)則需求，例如：如果健康上報(bào)體溫異常，自動(dòng)生成一條待跟進(jìn)任務(wù)，發(fā)送給該學(xué)生班主任，并推送消息給校長(zhǎng)。
總之，我們會(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é)！
首先，我們來到明道云工作臺(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í)表單中定義了自增長(zhǎng)的“班級(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)版本：
接下來，我們依次完成“學(xué)生”、“健康上報(bào)”、“體溫異常跟蹤”三個(gè)實(shí)體的表單配置。
下圖中，橫排的“校園管理”、“校長(zhǎng)控制臺(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)系映射。在明道云，我們采用了另一種取巧的方式，需要由校長(zhǎng)，將每一條班級(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)重要！
我們回憶下，現(xiàn)前有這樣一條需求：如果健康上報(bào)體溫異常，自動(dòng)生成一條待跟進(jìn)任務(wù)，發(fā)送給該學(xué)生班主任，并推送消息給校長(zhǎng)。
這個(gè)需求該如何實(shí)現(xiàn)呢？這就用到了aPaaS平臺(tái)中非常核心且重要的流程編輯器功能，可以說流程編輯器是低代碼平臺(tái)的靈魂！
將上述需求，進(jìn)一步準(zhǔn)確描述：如果新增或編輯“健康上報(bào)”表單數(shù)據(jù)時(shí)，其中的“體溫是否正常”字段選擇了“否”，則自動(dòng)生成一條狀態(tài)為“待跟進(jìn)”的“體溫異常跟蹤”數(shù)據(jù)，并發(fā)送消息給校長(zhǎng)，以及該學(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)。
由工作流創(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)，家長(zhǎng)如何上報(bào)數(shù)據(jù)？
一種辦法，是針對(duì)每個(gè)家長(zhǎng)開通一個(gè)賬號(hào)，賬號(hào)和學(xué)生做關(guān)聯(lián)，家長(zhǎng)登錄系統(tǒng)，提交表單時(shí)默認(rèn)會(huì)提交相關(guān)學(xué)生的“健康上報(bào)”記錄。
另一種辦法，是將“健康上報(bào)”的表單公開出去，任何人都可以提交，這樣做的好處是不需一個(gè)一個(gè)維護(hù)家長(zhǎng)賬號(hào)，壞處是因?yàn)橄到y(tǒng)無法識(shí)別提交人和對(duì)應(yīng)的兒童，需要提交人手工從學(xué)生清單中選擇學(xué)生，操作比較繁瑣。
如下圖，我們將表單設(shè)置了公開鏈接。
走到這一步，涉及到業(yè)務(wù)流程的核心功能和數(shù)據(jù)表單都開發(fā)完畢了，接下來，我們需要給李校長(zhǎng)配置她的管理工作臺(tái)，也就是dashboard。通過類似報(bào)表引擎的功能，配置出校長(zhǎng)的監(jiān)控儀表盤，我們將其放在“校長(zhǎng)控制臺(tái)”的一級(jí)導(dǎo)航下邊，如下圖：
該功能的使用，和經(jīng)典的報(bào)表引擎相通，不再贅述。
最后，我們進(jìn)行角色、權(quán)限的設(shè)置。我們?cè)O(shè)置了兩個(gè)角色，“校長(zhǎng)”和“老師”。
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)整。
通過以上例子，相信大家對(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）。
數(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)。
國(guó)外的低代碼平臺(tái)Mendix，國(guó)內(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é)起來也更困難。
國(guó)外另一個(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ì)喪失前后端分離的靈活性。
定義了底層數(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客戶端版本下的流程編輯器。
下圖展示的是國(guó)內(nèi)產(chǎn)品釘釘宜搭的工作流編輯器，感覺似乎過于簡(jiǎn)單，只是一個(gè)審批流編輯器，也可能是我沒找到完整功能的配置界面？
對(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)行模板化配置，主要分為以下幾類。
當(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)一步研究。
可以看出，不同的低代碼平臺(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é)議
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
