一、寫在前面

早在2017年，數(shù)棧當時沒有這么多子模塊，只有【離線開發(fā)+實時開發(fā)】2個部分，所以在導航設計上不存在問題，僅僅按照數(shù)據(jù)開發(fā)的通用設計邏輯即可。在2018年，增加了數(shù)據(jù)質(zhì)量、數(shù)據(jù)API等幾個模塊，涵蓋多個模塊，整體的導航規(guī)劃就變得很重要，搞得好的話，增加新的模塊，可以繼承現(xiàn)有的設計，搞不好，后續(xù)的改動就會比較大，甚至可能推翻重來，所以導航的重要性就在這里。

二、設計思考

既然包含了多個模塊，有幾個問題是需要重點考慮的：

1、向后兼容性問題，未來增加新的模塊，對現(xiàn)有的導航方式必須改動很小，最好是不要改代碼，而是改數(shù)據(jù)庫或者配置的方式。

2、共性模塊的抽取，每個模塊大概有哪些功能，哪些模塊是共性或十分類似的，應該抽取為統(tǒng)一的頁面進行管理。

3、共性部分在聚合在一起的同時，也要有良好的產(chǎn)品體驗，不能因為解耦造成體驗很差。

4、結(jié)合商業(yè)模式也要考慮解耦性，未來產(chǎn)品的售賣模式是單獨售賣，例如數(shù)據(jù)API可以不依賴其他模塊單獨輸出。

三、問題解決思路

對于數(shù)棧產(chǎn)品經(jīng)理來說，這是一個之前從來沒遇到過的問題，那要怎么解決呢？這里提供一種思路：

自己沒遇到過的問題，考慮一下別人有沒有遇到過，如果有的話，那就去學習，如果沒有，說明這個問題本身可能有問題
——簡單地說，就是“借鑒”

整理了上述問題之后，首先不是思考如何畫原型，而是去找哪里借鑒這個設計。

如何去找借鑒的地方呢？當時主要考慮了以下3個因素：

1、友商的產(chǎn)品要比我們多，最好能多很多，而且必須集成在1個導航體系內(nèi)。

2、友商不能只有SaaS服務，因為SaaS服務可以做很高程度的耦合，但我們還要考慮各種產(chǎn)品獨立部署的場景，要可拆分、可解耦。

3、最好是2B類產(chǎn)品，2C類產(chǎn)品這種場景的好像也不太多。

按上面的思路，能確定幾類友商范圍：

1、公有云：公有云一般有上百個產(chǎn)品，遇到的問題比我們更是復雜，既然參考了更復雜的案例，產(chǎn)品數(shù)量少就是小case，例如阿*云、亞*遜a*s、微*az*re及G**gle。

2、國內(nèi)的企業(yè)服務廠商，華*、亞*，遇到的問題與我們是類似的，一般是輸出有限的幾個模塊，面向?qū)ｉT的一家客戶服務，也可以參考，例如：華*，國外的這方面友商不太了解。

四、參考產(chǎn)品的設計特點

1、友商一

登錄后直接進入門戶，平鋪各種產(chǎn)品的入口鏈接，便于直接分流，分流可以說是此頁面的唯一目的

頂部導航可根據(jù)需求定制，將常用產(chǎn)品「掛」上去

進入某個產(chǎn)品后，通過面包屑的形式提供多層導航

設計的優(yōu)缺點

優(yōu)點

• 產(chǎn)品線特別多，所以容納性很強

• 導航清晰、簡單、對公有云來說，在沒有訂購任何產(chǎn)品的情況下，會進入產(chǎn)品介紹頁面，體驗比較好

缺點：

• 頂部菜單沒有充分利用，但對于深度用戶可以自定義頂部導航，彌補了這個缺點

2、友商二

首頁以dashboard的形式鋪開，便于用戶觀察核心指標，但只能依靠左側(cè)的導航來尋找產(chǎn)品。

設計優(yōu)缺點

優(yōu)點

• 左側(cè)導航雖然是2級，但是融合性很好

• 首頁進入后有核心報表，雖然也是分流，但體驗較好，將核心監(jiān)控指標直接露出

缺點

• 感覺頂部菜單沒有充分利用，左側(cè)菜單收縮的位置太靠下了，一大片空白下面可能還有個按鈕

3、友商三

友商某產(chǎn)品截圖，利用頂部導航拆分各個模塊，同時借鑒了G**gle Dashboard的形式，將關(guān)鍵指標體現(xiàn)在首頁。

設計優(yōu)缺點

優(yōu)點

• 首頁進入后有核心報表，雖然也是分流，但體驗較好，將核心監(jiān)控指標直接露出

缺點：

• UI不太美觀

• 報表固定，當增加、減少時，報表部分要重新處理布局、重新開發(fā)

五、數(shù)棧的導航設計

參考了以上幾個產(chǎn)品之后，數(shù)棧在設計上要注意以下幾個問題：

1、可能最多有7—8個產(chǎn)品，但不會有公有云那么多。

2、數(shù)據(jù)質(zhì)量、數(shù)據(jù)API、智能標簽、數(shù)據(jù)地圖等模塊，會逐步演變的比較復雜，應充分利用頂部菜單，如果后續(xù)需要擴展功能，可以設計左側(cè)菜單，便于擴展。

3、首頁無需強分流，數(shù)棧幾個產(chǎn)品的相關(guān)度很高，首頁可以借鑒Google的dashboard模式。

4、導航上，充分利用頂部導航，為頁面下面留出空間。

5、公有云大部分產(chǎn)品不使用頂部導航，猜測可能是因為二級菜單過多，無法統(tǒng)一（阿里云的dataworks使用頂部導航，也是由于其功能可以劃分，且只用左側(cè)導航會出現(xiàn)導航過多、無法與數(shù)據(jù)開發(fā)集成等問題；AWS的Cloud9也是使用了頂部導航）。

6、用戶獨立部署一個產(chǎn)品或多個產(chǎn)品時，導航的體驗一致（包括從一個產(chǎn)品升級為多個產(chǎn)品）。

7、部署單一組件和多組件的區(qū)別就在于頂部上多了一個“xx產(chǎn)品”的icon，其他導航菜單不動，這樣比較簡潔，且體驗一致。

六、數(shù)棧的設計方案

設計方案1

• 如果只部署一個產(chǎn)品，則左上角的產(chǎn)品矩陣icon不應該再顯示了，子產(chǎn)品icon需要向左移動

• 如果由一個產(chǎn)品升級為多個產(chǎn)品，則左上角的產(chǎn)品矩陣icon需要顯示出來，且子產(chǎn)品icon向右移動

設計方案2

• 一方面解決了單個部署和多個部署的體驗一致的問題，部署多個產(chǎn)品和單個產(chǎn)品的區(qū)別在于頂部多了一個icon，且給人整體體驗一致的感覺

• 另一個好處是，核心導航比較清晰，低頻使用的功能放在不重要的位置

七、總結(jié)分析

以上內(nèi)容就是數(shù)棧導航的一些設計過程和思路，最終選擇了第二種設計方案。當然，這種方案也有一些問題，例如首頁沒有體現(xiàn)Dashboard等，有些問題已經(jīng)有了解決思路，會在未來版本中逐步迭代優(yōu)化掉。

本文首發(fā)于：數(shù)棧研習社

數(shù)棧是云原生—站式數(shù)據(jù)中臺PaaS，我們在github上有一個有趣的開源項目：FlinkX ?? DTStack/flinkxgithub.com

FlinkX是一個基于Flink的批流統(tǒng)一的數(shù)據(jù)同步工具，既可以采集靜態(tài)的數(shù)據(jù)，比如MySQL，HDFS等，也可以采集實時變化的數(shù)據(jù)，比如MySQL binlog，Kafka等，是全域、異構(gòu)、批流一體的數(shù)據(jù)同步引擎，大家如果有興趣，歡迎來github社區(qū)找我們玩~