我仍然記得第一次使用豆瓣 App 詳情頁時的美妙感受，既可以順着內容滑動一路看下去，也可以拖拽起底部的模態面板快速瀏覽影評。這種交互模式既可以像全新的頁面容納大量信息，但是又沒有跳轉到新頁面那麼重的負擔，比起模態彈窗沒有那麼強的阻斷感。
iOS 13 官方規範也提供了這種新模態面板的介紹。往往這種新交互都得佔用大量開發資源，很難推動。沒想到自己居然有機會在工作中運用了一次。
多層級數據的難題
我們的 App 新上線了某專業數據庫模塊。由於用戶之前在書本中查找數據習慣了五級目錄的，因此 App 中也採用了五級目錄。如果是層級深在交互上倒不是大問題，難點在於每一級，從二級分類來時目錄節點本身也有內容。
原本的設計方案如下，我們在數據庫的主頁透出 2 級內容和部分 3 級、4 級、 5 級的內容，通過「更多」能查看當前 2 級分類的完整結構目錄。同時在詳情頁用麪包屑導航的方式提供結構目錄的入口。
顯然這個方案目錄的位置藏得太深了，很多用戶不僅沒注意到目錄的入口，而且完全意識不到我們的數據庫是按 5 級分類來設計的。完全不符合我們想象中用戶閱讀完一個詳情頁後通過目錄接着閱讀其他相關詳情頁的設計。於是整個項目組的人聚在一起來思考如何優化。
我首先想到的是企業組織架構和我們的數據庫有類似的結構，於是參考釘釘的組織架構管理。但是目錄佔用的面積太大，侵佔了內容區域，肯定不能採用。
想了好幾種方案都不行，於是開始看交互比較新潮的豆瓣。如果採用模態面板呢？把目錄作爲模態面板雖然不影響詳情內容的閱讀，但是詳情頁底部本身有工具欄，位置有衝突。
同事靈機一動，如果反過來呢？模態面板顯示詳情頁內容，頁面底板展示目錄。類比一下這個信息展示模式不就是地圖嘛！目錄有若干層級，地圖上每個地址（國家-省份-城市等）也是不同層級的。點開目錄是詳情頁模態面板，點開地圖的標記同樣有地址信息的模態面板。
爲了讓目錄和詳情的關係更明顯，我們在每次打開詳情內容時都有動畫暗示內容居於目錄之上。當然這個方案有另外一個缺點是每次想退出都不得不再看一次目錄，此外模態面板頂部無法承載過多的操作，模態面板上有其他模態操作時，層級太多對交互和開發的邏輯來說都有些複雜。當然這些問題能克服。
於是我興沖沖地把這個方案做成可交互原型，通過了評審，開發同事對新結構躍躍欲試。
上線後詳情頁閱讀提升明顯，文章看到這裏你以爲就結束了嗎？順利的事情總是有反轉，失敗的經驗價值總比成功的更高。
回到原點
上線一段時間後我們對用戶進行了訪談，發現仍然有用戶不知道數據庫內容有四層的情況。而且問題不是出在詳情頁，在數據庫首頁用戶忽略了“更多”，以爲首頁呈現的就是數據庫所有的完整內容，都沒來得及探索我們精妙設計的詳情頁。另外模態面板在豎直方向上並沒有佔用整個屏幕高度，加上我們底部還有工具欄，導致閱讀空間顯得特別侷促。後期規劃在詳情頁右上角加其他功能也變成了不可能。
這時候由產品總監牽頭討論琢磨着該怎麼優化，在原有需求基礎上實在想不到什麼新點子了，最後反過來推導需求的合理性，真的有必要在 App 裏體現傳統書籍的五層結構嗎？另外，我們的數據分類方式其實也並不是全行業通用的，用戶看到首頁二、三級分類時都得在猜一下，找的四、五級內容是在這個分類下嗎？
基於上面的討論，最後做了一個非常痛苦的決策，去掉數據的五級內容結構，二到五層合併爲同一層，信息架構扁平只有兩級。直接在首頁以 A-Z 展示所有內容列表，雖然會導致列表展示非常長，但是對於沒有行業通用的分類來說，越是傳統的分類方式反倒是更容易找到內容。
新的方案交互非常傳統，從炫酷的普通，設計師和程序員多少都有些沮喪。上線後數據表現穩定，沒有新的增長，但沒有再收到找不到數據、使用不方便的用戶反饋。
總結
通過這個項目的歷練，我明白了：
- 模態面板不適合展示長篇沉浸閱讀內容，適合做複雜度不是特別高的臨時任務。
- 如果遇到一個前無古人後無來者的交互挑戰難題，有可能需求本身就不合理。
- 如果需求不合理，要大膽的提出來推動需求方改變。