UIキットからデザインシステムまで

アイビーオンラインシネマ体験

2017 年の初めに、私たちが独自のデザインからコードへの配信システムの作成を初めて考えたとき、すでに多くの人がそれについて話しており、実際に実行している人さえいました。 しかし、今日に至るまで、クロスプラットフォーム設計システムの構築経験についてはほとんど知られておらず、設計実装プロセスをすでに動作する製品に変換するためのテクノロジと方法を説明する明確で実証されたレシピはありません。 そして、「コード内のコンポーネント」とは、多くの場合、まったく異なる意味を持ちます。

一方、同社はスタッフを年々倍増させました。設計部門を拡大し、開発用のレイアウトの作成と転送のプロセスを最適化する必要がありました。 これらすべてに、サポートが必要なプラットフォームの「動物園」を掛け合わせると、「普通にやって」収入を生み出すことがまったく不可能なバビロニアの大混乱のようなものになります。 プラットフォームの開発は並行して進められることが多く、同じ機能が数か月遅れて異なるプラットフォームでリリースされることもありました。


プラットフォームごとに個別のレイアウト セット

従来、私たちはデザインシステムが解決に役立つであろう問題から始めて、そのデザインの要件を定式化しました。 統一されたビジュアル言語を作成し、レイアウトと開発の速度を向上させ、製品全体の品質を向上させることに加えて、デザインを可能な限り統一することが重要でした。 これは、Web、iOS、Android、スマート TV、tvOS、Android TV、Windows 10、xBox One、PS4、Roku のすべてのプラットフォームで、それぞれを個別に作業することなく同時に機能の開発が可能になるために必要です。 そして、私たちはそれをやり遂げました！

デザイン→データ

製品部門と開発部門の間で基本的な合意に達したとき、私たちはテクノロジー スタックを選択し、レイアウトからリリースまでのプロセス全体の詳細を検討しました。 設計を開発に移行するプロセスを完全に自動化するために、レイアウトを含む Sketch ファイルからコンポーネント パラメーターを直接解析するオプションを検討しました。 必要なコードを見つけてパラメータを抽出するのは、複雑で危険な作業であることがわかりました。 第一に、デザイナーはソース コードのすべてのレイヤーに名前を付ける際に細心の注意を払う必要があります。第二に、これは最も単純なコンポーネントに対してのみ機能します。第三に、他の人のテクノロジと元の Sketch レイアウトのコード構造に依存すると、全体の将来が危険にさらされます。プロジェクト。 私たちはこの分野での自動化を放棄することにしました。 これが、設計システム チームに最初の人物が登場した方法です。入力は設計レイアウトであり、出力はコンポーネントのすべてのパラメータを記述し、アトミック設計方法論に従って階層的に順序付けされたデータです。

残された唯一のことは、データをどこにどのように保存するか、データを開発に転送する方法、およびサポートされているすべてのプラットフォームで開発時にデータを解釈する方法だけでした。 夕方は気だるいものではなくなりました... 各プラットフォームのデザイナーとチームリーダーで構成される作業グループの定期的な会議の結果、次の点で合意されました。

ビジュアルを手動で解析して、フォント、色、透明度、インデント、丸め、アイコン、画像、アニメーションの長さなどの基本的な要素に分割します。 そして、このボタン、入力、チェックボックス、銀行カードのウィジェットなどから収集します。都市の名前、ニンフの名前、ポケモン、車など、アイコンを除くレベルのスタイルに非意味的な名前を割り当てます。ブランド... 条件は XNUMX つだけです。スタイルが終了する前にリストを使い果たしてはなりません。ショーは終了する必要があります。 たとえば、「小」と「中」の間に中央のボタンを追加する必要がないように、セマンティクスに夢中になるべきではありません。

視覚言語

開発者は、すべてのプラットフォームに適した方法でデータを保存および転送する方法を考える必要があり、設計は、サポートされているデバイス全体で見栄えが良く、効果的に機能するインターフェイス要素を設計する必要がありました。

以前は、Windows 10 用アプリケーションのほとんどの設計要素をすでに「テスト」できていましたが、当時 Windows XNUMX は私たちにとって新しいプラットフォームであり、レンダリングと開発を「最初から」行う必要がありました。 それを描くことで、ほとんどのコンポーネントを準備してテストし、将来の Eevee デザイン システムにどのコンポーネントが含まれることになるのかを理解することができました。 このようなサンドボックスがなければ、そのようなエクスペリエンスは、すでに動作しているプラ​​ットフォーム上で多数回反復することによってのみ取得でき、これには XNUMX 年以上かかります。

異なるプラットフォームで同じコンポーネントを再利用すると、レイアウトの数と設計システムのデータ配列が大幅に削減されるため、設計では、これまでの製品設計と開発の実践では説明されていなかったもう XNUMX つの問題を解決する必要がありました。たとえば、次のような方法です。携帯電話やタブレットのボタンをテレビで再利用できますか? そして、このような異なるプラットフォームでのフォントや要素のサイズはどうすればよいのでしょうか?

明らかに、特定のプラットフォームごとに必要なテキストと要素のサイズを設定する、クロスプラットフォームのモジュラー グリッドを設計する必要がありました。 グリッドの開始点として、特定のスクリーンで見たい映画ポスターのサイズと数を選択し、これに基づいて、XNUMX つの列の幅が等しいという条件でグリッド列を構築するためのルールを策定しました。ポスターの幅に合わせます。

次に、すべての大きな画面を同じレイアウト サイズにして、共通のグリッドに合わせる必要があります。 Apple TV と Roku は 1920x1080、Android TV は 960x540 のサイズで設計されています。スマート TV はベンダーによって異なりますが、同じサイズですが、1280x720 の場合もあります。 アプリをフル HD 画面にレンダリングして表示する場合、960 を 2 倍、1280 を 1,33 倍し、1920 がそのまま出力されます。

退屈な詳細は省略して、一般に、テレビ画面を含むすべての画面は、要素とそのサイズの点で XNUMX つのデザイン レイアウトでカバーされ、すべてのテレビ画面は一般的なクロスプラットフォーム グリッドの特殊なケースであるという結論に達しました。平均的なタブレットやデスクトップと同様に、XNUMX つまたは XNUMX つの列で構成されます。 詳細に興味がある人は、コメント欄に書き込んでください。

すべてのプラットフォームに対応する単一の UI

新しい機能を描画するために、各プラットフォームのレイアウトに加えて、それぞれの適応性オプションを描画する必要はありません。 320 つのレイアウトと、あらゆる幅のすべてのプラットフォームとデバイス (電話機 - 599 ～ 600、その他すべて - 1280 ～ XNUMX) に対するその適応性を示すだけで十分です。

データ→開発

もちろん、完全に統一されたデザインを実現したいと考えていますが、各プラットフォームには独自の機能があります。 Web とスマート TV の両方で ReactJS + TypeScript スタックが使用されていますが、スマート TV アプリは従来の WebKit および Presto クライアントで実行されるため、Web とスタイルを共有できません。 そして、電子メール ニュースレターは完全に表形式のレイアウトで動作することを強制されます。 同時に、カスタム レイアウト、複雑な更新ロジックを含むコレクション、画像、ビデオが多すぎるため、パフォーマンスの低下を恐れて、HTML 以外のプラットフォームはどれも React Native やその類似品を使用していないか、使用する予定もありません。 したがって、既製の CSS スタイルや React コンポーネントを提供する一般的なスキームは私たちには適していません。 そこで、抽象的な宣言型で値を記述したJSON形式でデータを送信することにしました。

だから財産 rounding: 8 Windows 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 ファイルの形式で転送する機能を実装しました。 たとえば、スマート TV の「フォーカス中」状態は、ポスターの下のテキストの位置の変更を指示します。これは、このプラットフォームでは、「インデント」プロパティの値のこのコンポーネントに、必要な 8 つのインデント ポイントが含まれることを意味します。 これにより、設計システムのインフラストラクチャが複雑になりますが、自由度がさらに高まり、プラットフォームの視覚的な「相違点」を自分たちで管理し、作成したアーキテクチャの人質にならずに済む機会が得られます。

ピクトグラム

デジタル製品のアイコンは常に大規模であり、最も単純なサブプロジェクトではなく、多くの場合、別のデザイナーが必要になります。 常に多くのグリフがあり、それぞれにいくつかのサイズと色があり、プラットフォームは通常、それらを異なる形式で必要とします。 一般に、これらすべてをデザイン システムに取り入れない理由はありません。

グリフはSVGベクター形式でロードされ、色の値は自動的に変数に置き換えられます。 クライアント アプリケーションは、任意の形式と色ですぐに使用できるようにそれらを受信できます。

試写

JSON データに加えて、コンポーネントをプレビューするためのツールを作成しました。これは、マークアップおよびスタイル ジェネレーターを介して JSON データをオンザフライで渡し、ブラウザーに各コンポーネントのさまざまなバリエーションを表示する JS アプリケーションです。 基本的に、プレビューはプラットフォーム アプリケーションとまったく同じクライアントであり、同じデータを操作します。

特定のコンポーネントがどのように機能するかを理解する最も簡単な方法は、コンポーネントを操作することです。 したがって、Storybook のようなツールは使用せず、インタラクティブなプレビューを作成しました。タッチ、ポイント、クリック... 新しいコンポーネントをデザイン システムに追加するときに、プラットフォームが注目すべき点があるようにプレビューに表示されます。それを実装することです。

Документация

JSON 形式でプラットフォームに提供されたデータに基づいて、コンポーネントのドキュメントが自動的に生成されます。 プロパティのリストと、それぞれの値の可能なタイプについて説明します。 自動生成後、情報を手動で明確にし、テキストによる説明を追加できます。 プレビューとドキュメントは各コンポーネントのレベルで相互参照されており、開発者はドキュメントに含まれるすべての情報を追加の JSON ファイルの形式で利用できます。

非難者

もう XNUMX つの必要性は、既存のコンポーネントを時間の経過とともに交換および更新できることです。 設計システムは、どのプロパティやコンポーネント全体が使用できないかを開発者に通知し、すべてのプラットフォームで使用されなくなったらすぐにそれらを削除することを学習しました。 このプロセスでは依然として多くの「手作業」が行われていますが、私たちは立ち止まっているわけではありません。

クライアント開発

間違いなく、最も複雑な段階は、サポートされているすべてのプラットフォームのコード内のデザイン システム データの解釈でした。 たとえば、Web 上のモジュラー グリッドが新しいものではない場合、iOS および Android 用のネイティブ モバイル アプリケーションの開発者は、それをどうやって使用するかを理解する前に、懸命に努力したことになります。

iOS アプリケーション画面をレイアウトするには、iviUIKit が提供する XNUMX つの基本メカニズム、要素の自由なレイアウトと要素のコレクションのレイアウトを使用します。 私たちは VIPER を使用しており、iviUIKit との対話はすべて View に集中し、Apple UIKit との対話のほとんどは iviUIKit に集中しています。 要素のサイズと配置は、ネイティブ iOS SDK の制約に基づいて機能する列と構文構造の観点から指定されているため、より実用的になります。 これにより、特に UICollectionView を使用する際の作業が簡素化されました。 私たちは、非常に複雑なものを含む、レイアウト用のカスタム ラッパーをいくつか作成しました。 最小限のクライアント コードがあり、宣言型になりました。

Android プロジェクトでスタイルを生成するには、Gradle を使用し、デザイン システム データを XML 形式のスタイルに変換します。 同時に、さまざまなレベルのジェネレーターがいくつかあります。

• 基本。 上位レベルのジェネレーターのプリミティブのデータが解析されます。
• リソース。 写真、アイコン、その他のグラフィックをダウンロードします。
• 成分。 これらはコンポーネントごとに書かれており、どのようなプロパティと、それらをスタイルに変換する方法が説明されています。

アプリケーションのリリース

設計者が新しいコンポーネントを描画するか、既存のコンポーネントを再設計した後、これらの変更は設計システムに入力されます。 各プラットフォームの開発者は、変更をサポートするためにコード生成を微調整しています。 その後、このコンポーネントが必要な新しい機能の実装に使用できます。 したがって、設計システムとの対話はリアルタイムでは行われず、新しいリリースを組み立てるときにのみ行われます。 このアプローチにより、データ転送プロセスをより適切に制御できるようになり、クライアント開発プロジェクトでのコード機能が保証されます。

結果

デザイン システムが Ivy オンライン シネマの開発をサポートするインフラストラクチャの一部になってから XNUMX 年が経過しましたが、すでにいくつかの結論を導き出すことができます。

• これは大規模で複雑なプロジェクトであり、継続的な専用リソースが必要です。
• これにより、オンライン ビデオ サービスの目的を満たす独自のクロスプラットフォーム視覚言語を作成することができました。
• 視覚的にも機能的にも遅れているプラ​​ットフォームはもうありません。

Ivy デザイン システム コンポーネントのプレビュー - design.ivi.ru

出所： habr.com