常春藤線上影院體驗
當 2017 年初我們第一次考慮創建自己的設計到程式碼交付系統時，許多人已經在談論它，有些人甚至正在這樣做。 然而，迄今為止，人們對建立跨平台設計系統的經驗知之甚少，也沒有明確且經過驗證的方法來描述將設計實現過程轉變為已經工作的產品的技術和方法。 而「程式碼中的元件」通常意味著非常不同的事情。
同時，公司的員工年復一年地增加——有必要擴大設計部門的規模，並優化創建和轉移開發佈局的流程。 我們將所有這些乘以需要支援的平台“動物園”，我們得到了巴比倫混亂的外觀，它根本無法“正常進行”並產生收入。 平台的開發通常是並行進行的，相同的功能可能會在不同的平台上發布，但會有幾個月的延遲。
每個平台都有單獨的佈局集
傳統上，我們從設計系統有助於解決的問題開始，並制定其設計要求。 除了創建統一的視覺語言、提高佈局和開發速度以及提高產品的整體品質之外，盡可能統一設計也至關重要。 這是必要的，以便在我們的所有平台上同時開發功能：Web、iOS、Android、智慧電視、tvOS、Android TV、Windows 10、xBox One、PS4、Roku - 無需單獨處理每個平台。 我們做到了！
設計→數據
當產品和開發部門之間達成基本協議後，我們坐下來選擇技術堆疊並製定整個流程的細節 - 從佈局到發布。 為了完全自動化將設計轉移到開發的過程，我們探索了直接從帶有佈局的 Sketch 檔案解析元件參數的選項。 事實證明，找到我們需要的程式碼片段並提取我們需要的參數是一項複雜而危險的任務。 首先，設計者在命名原始碼的所有層時必須非常小心，其次，這只適用於最簡單的元件，第三，依賴他人的技術和原始Sketch佈局的程式碼結構會危及整個Sketch佈局的未來。項目。 我們決定放棄該領域的自動化。 這就是設計系統團隊中第一個人的出現，其輸入是設計佈局，輸出是描述組件所有參數並根據原子設計方法分層排序的資料。
剩下要做的唯一一件事是在哪裡以及如何儲存數據，如何將其傳輸到開發以及如何在我們支援的所有平台上的開發中解釋它。 夜晚不再是慵懶的…由各平台的設計師和團隊負責人組成的工作小組定期召開會議，達成了以下協議。
我們手動將視覺效果解析為原子元素：字體、顏色、透明度、縮排、四捨五入、圖示、圖片和動畫持續時間。 我們從這些按鈕、輸入、複選框、銀行卡小部件等中收集資訊。我們將非語義名稱分配給任何級別的樣式（圖標除外），例如城市名稱、仙女名稱、寶可夢、汽車品牌.. .只有一個條件－清單不能排完，款式如何結束－秀必須走！ 例如，您不應該被語義迷惑，這樣您就不必在「小」和「中」之間添加中間按鈕。
視覺語言
開發人員必須考慮如何以適合所有平台的方式儲存和傳輸數據，而設計人員必須設計出美觀且在整個支援設備上有效工作的介面元素。
先前，我們已經成功地「測試」了Windows 10應用程式中的大部分設計元素，當時Windows XNUMX對我們來說是一個新平台，也就是說，它需要「從頭開始」渲染和開發。 透過繪製它，我們能夠準備和測試大部分組件，並了解其中哪些應該包含在未來的 Eevee 設計系統中。 如果沒有這樣的沙箱，這樣的經驗只能透過在已經運行的平台上進行大量迭代來獲得，而這需要一年以上的時間。
在不同平台上重複使用相同的元件會顯著減少設計系統的佈局數量和資料數組，因此設計必須解決一個以前在產品設計和開發實踐中沒有描述過的問題 - 例如，如何：手機和平板電腦的按鈕可以在電視上重複使用嗎？ 那麼在如此不同的平台上我們該如何處理字體和元素的大小呢？
顯然，有必要設計一個跨平台模組化網格，為每個特定平台設定我們所需的文字和元素大小。 作為網格的起點，我們選擇了想要在特定螢幕上看到的電影海報的大小和數量，並基於此制定了構建網格列的規則，前提是一列的寬度相等到海報的寬度。
現在我們需要將所有大螢幕調整為相同的佈局尺寸並將它們放入公共網格中。 Apple TV 和 Roku 的設計尺寸為 1920x1080，Android TV - 960x540，智慧電視（取決於供應商）是相同的，但有時為 1280x720。 當應用程式渲染並顯示在全高清螢幕上時，960 乘以 2，1280 乘以 1,33，並按原樣輸出 1920。
跳過無聊的細節，我們得出的結論是，一般來說，包括電視螢幕在內的所有螢幕，就元素及其尺寸而言，都被一種設計佈局所覆蓋，並且所有電視螢幕都是一般跨平台網格的特例，由五到六列組成，就像普通的平板電腦或桌上型電腦一樣。 有興趣了解詳情的可以評論區留言。
適用於所有平台的單一 UI
現在，要繪製新功能，我們不需要為每個平台繪製佈局，以及每個平台的適應性選項。 它足以顯示一種佈局及其對任何寬度的所有平台和設備的適應性：電話 - 320-599，其他所有 - 600-1280。
數據→開發
當然，儘管我們希望實現完全統一的設計，但每個平台都有自己獨特的功能。 儘管 Web 和 Smart TV 都使用 ReactJS + TypeScript 堆疊，但 Smart TV 應用程式在舊版 WebKit 和 Presto 用戶端上運行，因此無法與 Web 共用樣式。 電子郵件通訊完全被迫使用表格佈局。 同時，沒有一個非 html 平台使用或計劃使用 React Native 或其任何類似物，因為擔心效能下降，因為我們有太多的自訂佈局、具有複雜更新邏輯的集合、圖像和影片。 因此，提供現成的 CSS 樣式或 React 元件的常見方案並不適合我們。 因此，我們決定以 JSON 格式傳輸數據，以抽象聲明的形式描述值。
所以財產
rounding: 8Windows 10 應用程式轉換為CornerRadius="8"，網絡-border-radius: 8px， 安卓 -android:radius="8dp", iOS -self.layer.cornerRadius = 8.0.
財產offsetTop: 12同一 Web 用戶端在不同情況下可以解釋為top,margin-top,padding-top或transform
所描述的聲明性也意味著，如果平台在技術上無法使用某個屬性或其值，則可以忽略它。 在術語方面，我們做了一種世界語：有些取自Android，有些取自SVG，有些取自CSS。
如果在特定平台上您需要以不同方式顯示元素，我們已經實現了以單獨的 JSON 檔案的形式傳輸相應資料產生的功能。 例如，智慧電視的「焦點對準」狀態指示海報下方文字位置的變化，這意味著對於該平台，「縮排」屬性值中的該元件將包含其所需的 8 個縮排點。 儘管這使設計系統的基礎設施變得複雜，但它提供了額外的自由度，使我們有機會自己管理平台的視覺“差異”，而不是受制於我們創建的架構。
象形圖
數位產品中的圖像始終是一個龐大且不是最簡單的子項目，通常需要單獨的設計師。 字形總是有很多，每個字形都有多種尺寸和顏色，平台通常需要不同的格式。 總的來說，沒有理由不將所有這些都納入設計系統中。
字形以 SVG 向量格式加載，顏色值自動替換為變數。 客戶端應用程式可以接收它們以供使用 - 任何格式和顏色。
預習
在 JSON 數據之上，我們編寫了一個用於預覽組件的工具 - 一個 JS 應用程序，它通過其標記和样式生成器動態傳遞 JSON 數據，並在瀏覽器中顯示每個組件的各種變體。 本質上，預覽版與平台應用程式是完全相同的客戶端，並且使用相同的數據。
了解特定組件如何運作的最簡單方法是與其互動。 因此，我們沒有使用Storybook之類的工具，而是做了一個互動式預覽——你可以觸摸、指向、點擊……當向設計系統添加新元件時，它會出現在預覽中，以便平台在使用時有需要注意的內容。實施它。
Документация
根據以 JSON 形式提供給平台的數據，自動產生組件的文件。 描述了屬性清單以及每個屬性中可能的值類型。 自動生成後，可以手動澄清訊息並添加文字描述。 預覽和文件在每個元件層級相互交叉引用，且文件中包含的所有資訊都可以附加 JSON 檔案的形式提供給開發人員。
棄用者
另一個必要條件是能夠隨著時間的推移更換和更新現有組件。 設計系統已經學會告訴開發人員哪些屬性甚至整個元件不能使用，並在所有平台上不再使用它們時立即刪除。 這個過程中還有很多「體力」勞動，但我們並沒有停滯不前。
客戶開發
毫無疑問，最複雜的階段是在我們支援的所有平台的程式碼中解釋設計系統資料。 例如，如果網路上的模組化網格並不是什麼新鮮事，那麼 iOS 和 Android 原生行動應用程式的開發人員就會努力工作，然後才弄清楚如何使用它。
為了佈局 iOS 應用程式螢幕，我們使用 iviUIKit 提供的兩種基本機制：元素的自由佈局和元素集合的佈局。 我們使用VIPER，所有與iviUIKit的互動都集中在View中，而Apple UIKit的大部分互動都集中在iviUIKit中。 元素的大小和排列是根據在本機 iOS SDK 約束之上工作的列和語法結構來指定的，使它們更加實用。 這尤其簡化了我們使用 UICollectionView 時的生活。 我們已經為佈局編寫了幾個自訂包裝器，包括相當複雜的包裝器。 客戶端程式碼最少，並且它變成了聲明性的。
為了在Android專案中產生樣式，我們使用Gradle，將設計系統資料轉換為XML格式的樣式。 同時，我們擁有多個不同等級的生成器：
- 基本的。 解析更高層級生成器的原語資料。
- 資源。 下載圖片、圖示和其他圖形。
- 成分。 它們是為每個元件編寫的，描述了哪些屬性以及如何將它們轉換為樣式。
應用程式發布
設計人員繪製新組件或重新設計現有組件後，這些變更將輸入到設計系統中。 每個平台的開發人員正在微調他們的程式碼產生以支援這些變化。 之後，它可以用於需要該組件的新功能的實作。 因此，與設計系統的互動不是即時發生的，而是僅在組裝新版本時發生。 這種方法還可以更好地控制資料傳輸過程，並確保客戶端開發專案中的程式碼功能。
結果
設計系統成為支持Ivy線上影院發展的基礎設施的一部分已經一年了，我們已經可以得出一些結論：
- 這是一個龐大而複雜的項目，需要持續的專用資源。
- 這使我們能夠創建自己獨特的跨平台視覺語言，以滿足線上影片服務的目標。
- 我們不再擁有視覺和功能上落後的平台。
Ivy設計系統組件預覽—
來源： www.habr.com