1、寫在前面git
早在2017年，數棧當時沒有這麼多子模塊，只有【離線開發+實時開發】2個部分，因此在導航設計上不存在問題，僅僅按照數據開發的通用設計邏輯便可。在2018年，增長了數據質量、數據API等幾個模塊，涵蓋多個模塊，總體的導航規劃就變得很重要，搞得好的話，增長新的模塊，能夠繼承現有的設計，搞很差，後續的改動就會比較大，甚至可能推翻重來，因此導航的重要性就在這裏。github
2、設計思考數據庫
既然包含了多個模塊，有幾個問題是須要重點考慮的：工具
一、向後兼容性問題，將來增長新的模塊，對現有的導航方式必須改動很小，最好是不要改代碼，而是改數據庫或者配置的方式。佈局
二、共性模塊的抽取，每一個模塊大概有哪些功能，哪些模塊是共性或十分相似的，應該抽取爲統一的頁面進行管理。學習
三、共性部分在聚合在一塊兒的同時，也要有良好的產品體驗，不能由於解耦形成體驗不好。優化
四、結合商業模式也要考慮解耦性，將來產品的售賣模式是單獨售賣，例如數據API能夠不依賴其餘模塊單獨輸出。阿里雲
3、問題解決思路url
對於數棧產品經理來講，這是一個以前歷來沒遇到過的問題，那要怎麼解決呢？這裏提供一種思路：.net
本身沒遇到過的問題，考慮一下別人有沒有遇到過，若是有的話，那就去學習，若是沒有，說明這個問題自己可能有問題
——簡單地說，就是「借鑑」
整理了上述問題以後，首先不是思考如何畫原型，而是去找哪裏借鑑這個設計。
如何去找借鑑的地方呢？當時主要考慮瞭如下3個因素：
一、友商的產品要比咱們多，最好能多不少，並且必須集成在1個導航體系內。
二、友商不能只有SaaS服務，由於SaaS服務能夠作很高程度的耦合，但咱們還要考慮各類產品獨立部署的場景，要可拆分、可解耦。
三、最好是2B類產品，2C類產品這種場景的好像也不太多。
按上面的思路，能肯定幾類友商範圍：
一、公有云：公有云通常有上百個產品，遇到的問題比咱們更是複雜，既然參考了更復雜的案例，產品數量少就是小case，例如阿*雲、亞*遜a*s、微*az*re及G**gle。
二、國內的企業服務廠商，華*、亞*，遇到的問題與咱們是相似的，通常是輸出有限的幾個模塊，面向專門的一家客戶服務，也能夠參考，例如：華*，國外的這方面友商不太瞭解。
4、參考產品的設計特色
一、友商一
登陸後直接進入門戶，平鋪各類產品的入口連接，便於直接分流，分流能夠說是此頁面的惟一目的
頂部導航可根據需求定製，將經常使用產品「掛」上去
進入某個產品後，經過麪包屑的形式提供多層導航
設計的優缺點
優勢
- 產品線特別多，因此容納性很強
- 導航清晰、簡單、對公有云來講，在沒有訂購任何產品的狀況下，會進入產品介紹頁面，體驗比較好
缺點：
- 頂部菜單沒有充分利用，但對於深度用戶能夠自定義頂部導航，彌補了這個缺點
二、友商二
首頁以dashboard的形式鋪開，便於用戶觀察覈心指標，但只能依靠左側的導航來尋找產品。
設計優缺點
優勢
- 左側導航雖然是2級，可是融合性很好
- 首頁進入後有核心報表，雖然也是分流，但體驗較好，將核心監控指標直接露出
缺點
- 感受頂部菜單沒有充分利用，左側菜單收縮的位置太靠下了，一大片空白下面可能還有個按鈕
三、友商三
友商某產品截圖，利用頂部導航拆分各個模塊，同時借鑑了G**gle Dashboard的形式，將關鍵指標體如今首頁。
設計優缺點
優勢
- 首頁進入後有核心報表，雖然也是分流，但體驗較好，將核心監控指標直接露出
缺點：
- UI不太美觀
- 報表固定，當增長、減小時，報表部分要從新處理佈局、從新開發
5、數棧的導航設計
參考了以上幾個產品以後，數棧在設計上要注意如下幾個問題：
一、可能最多有7—8個產品，但不會有公有云那麼多。
二、數據質量、數據API、智能標籤、數據地圖等模塊，會逐步演變的比較複雜，應充分利用頂部菜單，若是後續須要擴展功能，能夠設計左側菜單，便於擴展。
三、首頁無需強分流，數棧幾個產品的相關度很高，首頁能夠借鑑Google的dashboard模式。
四、導航上，充分利用頂部導航，爲頁面下面留出空間。
五、公有云大部分產品不使用頂部導航，猜想多是由於二級菜單過多，沒法統一（阿里雲的dataworks使用頂部導航，也是因爲其功能能夠劃分，且只用左側導航會出現導航過多、沒法與數據開發集成等問題；AWS的Cloud9也是使用了頂部導航）。
六、用戶獨立部署一個產品或多個產品時，導航的體驗一致（包括從一個產品升級爲多個產品）。
七、部署單一組件和多組件的區別就在於頂部上多了一個「xx產品」的icon，其餘導航菜單不動，這樣比較簡潔，且體驗一致。
6、數棧的設計方案
設計方案1
- 若是隻部署一個產品，則左上角的產品矩陣icon不該該再顯示了，子產品icon須要向左移動
- 若是由一個產品升級爲多個產品，則左上角的產品矩陣icon須要顯示出來，且子產品icon向右移動
設計方案2
- 一方面解決了單個部署和多個部署的體驗一致的問題，部署多個產品和單個產品的區別在於頂部多了一個icon，且給人總體體驗一致的感受
- 另外一個好處是，核心導航比較清晰，低頻使用的功能放在不重要的位置
7、總結分析
以上內容就是數棧導航的一些設計過程和思路，最終選擇了第二種設計方案。固然，這種方案也有一些問題，例如首頁沒有體現Dashboard等，有些問題已經有了解決思路，會在將來版本中逐步迭代優化掉。
本文首發於：數棧研習社
數棧是雲原生—站式數據中臺PaaS，咱們在github上有一個有趣的開源項目：FlinkX DTStack/flinkxgithub.com
FlinkX是一個基於Flink的批流統一的數據同步工具，既能夠採集靜態的數據，好比MySQL，HDFS等，也能夠採集實時變化的數據，好比MySQL binlog，Kafka等，是全域、異構、批流一體的數據同步引擎，你們若是有興趣，歡迎來github社區找咱們玩~