Sketch + Node.js：多くのプラットフォームとブランドのアイコンを生成する

プロジェクトにアイコンを追加するよりも簡単なことはありません。デザイナーに書き込むだけで、スケッチからそれをエクスポートし、必要なオプションを送信して、コードで使用できます。 多数のプロジェクト、いくつかのプラットフォーム、A / B設計テストが多数ある場合は、同じことを40倍の頻度で行うだけで、どこでも間違いを犯すことはありません...またはプロセスの自動化を試みます。 アンダーカット-そのような自動化の1つの例についての私の同僚Cristiano Rastelliによる記事の翻訳の最初の部分。

解決した問題

Badooでは 、出会い系アプリを開発しています。 実際、これらはいくつかのアプリケーションであり、それぞれがいくつかのプラットフォーム（ iOS 、 Android 、 モバイルWeb 、 デスクトップWeb ）で動作し、いくつかのチームがそれらに取り組んでいます。

開発では、数百の異なるアイコンを使用します。 すべてのアプリケーションで同じものもあれば、特定のブランドに対応するものもあります。 時々、デザインが変更され、それに合わせてアイコンも変更されます。新しいものが表示され、一部は更新され、一部は削除されます（ただし、多くの場合、コードベースに残ります）。

アイコンは設計チームによって作成および管理され、アイコンの作業準備が整うと、デザイナーは通常、メール、チャット、またはクラウドでそれらを送信します。 これには時間がかかるだけでなく、多くの場合エラーが発生しました。 正直に言うと、毎回エラーが発生しました（私たち全員です）：あるプラットフォームでアイコンが更新されたが、別のプラットフォームで更新されなかったり、消えたりフォーマットやサイズと一致しなかったりすることがありました。 そのため、設計者と開発者は常に連絡を取り合う必要がありました。 開発者はSketchファイルからアイコンを直接エクスポートし、コードベースに追加しましたが、データベースで再利用できる同様のアイコンのチェックは行われませんでした。 私が話していることをあなたが理解していると確信しています。

BadooにはCosmosというデザインシステムがあり、最近、マルチプラットフォーム（モバイルWeb、Android、iOS） トークンライブラリを導入しました。 実際、デザインの変更（たとえば、ポップアップウィンドウでのボタンの境界線の外観、ページの背景色、タイトルバーのサイズ、アニメーション期間）は、一連のパラメーターを使用して記述でき、その後、自動的にエクスポートされ、すべてのプラットフォームのすべてのアプリケーションで使用されます。

デザインアイデア（たとえば、色の変更）を短時間で機能するコードに変換できるソリューションは、製品マネージャーとデザイナーに同じように感銘を与えました。 したがって、彼らの次の質問（そして同時にタスク）は、「リソースに対して同様のことを行うことは可能ですか？」と答えました。 「はい、可能です（おそらく）です。 」

最初は盲目的に行動したことを認めなければなりません。 いくつかのアイデアがありましたが、すべての制限を考慮して、それらが機能するかどうかはわかりませんでした。 MVPから始めることにしましたが、すべてが順調に進み、プロジェクトは必要な機能をすべて備えた最終製品になりました。

必要条件

MVPプロ​​ジェクトの要件は明確でした。入力でSketchファイルを受け取り、必要なすべての形式ですべてのアイコンを出力し、A / Bテストのアイコンバリエーションをサポートするツールです。

困難は、同じアイコンがブランドに応じて異なるパラメーター（色、形）を持っていることでした。 以下に、アプリケーションのアイコンをいくつか示します。 ご覧のとおり、完全に同一のものもあれば、パラメーターの数が異なるものもありますが、共通点のないものもあります。



アイコンで使用されている色は単なる色ではなく、 トークンに示されているブランドの色と特定の機能に正確に対応していることに注意してください。



そのため、ツールを開発するときの目標は、さまざまなプラットフォームやブランドのアイコンの作成と配信を自動化するだけでなく、ブランドに応じた動的な色付けを可能にすることでした。

スケッチとスケッチツール

スケッチは、デザイナーの主要なツールです。 また、他のオプション（例： Figma ）を検討しましたが、このプロジェクトのフレームワーク内ではSketch形式のファイルを使用することがわかっていました（デザイナーがこのツールを最適に所有し、現在のアイコンとリソースはすべてこの形式で保存されるため） 。

実際、プロジェクトの開始時には、プラットフォームにどのファイル形式が必要かさえわかりませんでした。 このようなプロセスを想像しました。SVG形式でSketchファイルからアイコンをエクスポートし、SVGファイルをモバイルブラウザーとAndroidのバージョンに「フィード」し、iOSでSVGをPDFに変換するライブラリを見つけます。 それは当初からの計画でしたが、アイデアが機能するかどうか、どのような問題に直面するかはわかりませんでした。 実際、このためにはMVPが必要でした。プロジェクトが実装されているかどうか、実装されている場合はどれだけ時間がかかるかを理解するためです。

PDFコンバーターを使用する必要があるかどうかはわかりませんが、私の経験では、これは悪夢であると言われています。 彼らは常にほとんど仕事をしますが、100％することはありません。 したがって、脊髄、私たちは滑りやすい道を歩いていると感じました。

Sketchからリソースをエクスポートするのは完璧です。SVG、PDF、およびその他の形式をダウンロードする際に問題が発生したことはありません。 したがって、私はスケッチとは異なる方法で対話できるかどうかを調べることにしました-おそらくプログラマチックに、スケッチを介してリソースを直接エクスポートすることもできます。

スケッチファイルの内部構造は、本質的にアーカイブであることを知っていました。 .sketchの名前を.zipに変更すると、ダブルクリックしてファイルを開くことができます。 結果のフォルダに、JSONファイルのリストとPNG形式のプレビューファイルが表示されます。



それで、私はJSONファイルがどのように関連しているかを理解しようとしてJSONファイルを研究し始めました。

ネストの度合いは大きい（サイズは大きい）が、オブジェクト内の異なるエンティティ間の関係はそれほど混乱しないことがわかりました。 ページ、アートボード、レイヤーがあります。 各レイヤーには、共通のスタイルを持つことができるパスが含まれています。 これらの各エンティティには、異なるファイル間の接続を維持できる一意のIDがあります。 すべてのページはJSONファイルに保存され、ページのサブフォルダーに含まれています（ページIDはファイル名として機能します）。

調査中、私は重要な発見をしました。 レイヤー、ページ、スタイルの名前は単なるラベルであり、Sketchファイルの内部構造を乱すことなくいつでも変更できます 。 重要なのは、エンドユーザーには表示されない一意のIDのみです（ただし、JSONファイル内で読み取りおよび参照できます）。 一意のスタイルIDの例を次に示します。

{ "_class": "sharedStyle", "do_objectID": "49BA4E98-8D63-435C-81D9-E2F6CDB63136", "name": "name-of/the-style", "value": {     "_class": "style",     "endMarkerType": 0,     "fills": [         {             "_class": "fill",             "isEnabled": true,             "color": {                 "_class": "color",                 "alpha": 1,                 "blue": 0.7176470588235294,                 "green": 0.4627450980392159,                 "red": 0             },             "fillType": 0,             "noiseIndex": 0,             "noiseIntensity": 0,             "patternFillType": 1,             "patternTileScale": 1         }     ],     "miterLimit": 10,     "startMarkerType": 0,     "windingRule": 1 } } 

したがって、アートボードとページの命名規則を導入して、リソースの関係について何らかのメタ情報を通知し、それらをアセンブリ中にプログラムで使用する可能性について考えました。

スケッチツール

したがって、最初の調査が完了すると、 「アイコンをSVGにエクスポートしてから変換 」という計画が「 最終フォーマットでアイコンを直接エクスポートできるSketch用のプラグインを作成しましょう 」に変わりました。 ただし、それでも作業スキームはかなり曖昧でした（実装されているという事実ではありませんでした）。

既存のプラグインのソースコードを調べて、SketchのエクスポートAPIとやり取りできるかどうか、もしそうであれば、どのようにやり取りできるかを理解しようとしました。 そしてその瞬間、以前に聞いたことのないツールであるSketchToolに出会いました。

SketchToolは公式のSketchツールです（つまり、Bohemian Codingによって開発されました）。 ドキュメントによると、彼は

Sketchにバンドルされているコマンドラインユーティリティであり、Sketch形式のドキュメントで特定のアクション（リソースのチェックやエクスポートなど）を実行できます。 また、プラグインの実行など、コマンドラインからSketch機能を制御することもできます。

リソースをエクスポートするためのコマンドラインユーティリティですか？ 必要なもの！ さらに、これは公式ツールであるため、バージョンの互換性、廃止、サポートなどの問題はないはずです。

私はユーティリティを勉強し始め、すべてのドキュメントを読み始めました-Sketchウェブサイトの唯一のページです （インターネット上で非常に少数の資料が取り上げられているので、今だけ聞いたことは驚くことではありません）。

SketchToolはSketchに添付されており、 Sketch.app/Contents/Resources/sketchtool/ / Sketch.app/Contents/Resources/sketchtool/ / Sketch.app/Contents/Resources/sketchtool/ / Sketch.app/Contents/Resources/sketchtool/

$/Applications/Sketch.app/Contents/Resources/sketchtool/bin/sketchtoolコマンド$/Applications/Sketch.app/Contents/Resources/sketchtool/bin/sketchtool実行すると、次の結果が得られます（データを少し単純化しました）：

 Usage: sketchtool <command> [<args>] [--formats=<string>] [--use-id-for-name{=YES|NO}] [--export-page-as-fallback{=YES|NO}] [--serial{=YES|NO}] [--context=<string>] [--application=<path>] [--without-activating{=YES|NO}] [--item=<string>] [--items=<string>] [--safemode{=YES|NO} | --no-safemode | -S {<YES|NO>}] [--max-size=<float> | -m <float>] [--background=<string> | -g <string>] [--compression=<float> | -c <float>] [--new-instance{=YES|NO}] [--reveal{=YES|NO}] [--timeout=<float>] [--include-symbols{=YES|NO}] [--bounds=<rectangle>] [--outputJSON=<path>] [--filename=<string>] [--wait-for-exit{=YES|NO}] [--scales=<path>] [--overwriting{=YES|NO}] [--group-contents-only{=YES|NO}] [--trimmed{=YES|NO}] [--help] [--progressive{=YES|NO}] [--save-for-web{=YES|NO}] [--output=<path>] Commands: dump               Dump out the structure of a document as JSON. export artboards  Export one or more artboards export layers     Export one or more layers export pages      Export an area from one or more pages export preview    Export a preview image for a document export slices     Export one or more slices help              Show this help message. list artboards    List information on the document's artboards. list formats      List the supported export formats. list layers       List information on all of the document's layers. list pages        List information on the document's pages. list slices       List information on the document's slices. metadata          List the metadata for a document. run               Run a command from a plugin, inside Sketch. show              Show the location of the various sketch folders. See 'sketchtool help <command>' for more information on a specific command. 

ご覧のとおり、このツールには4つの主要な機能があります。

read/dump -内部JSONファイルのメタデータダンプの読み取り/ダンプ、
list-ファイルエンティティのリストを作成し、
exportこれらのエンティティをエクスポートし、
run-プラグインが提供するコマンドを実行します。

これに加えて、各コマンドにはいくつかのオプションがあります。 エクスポートの場合、対応するパネルにあるほとんどすべてのオプションは、SketchToolコマンドラインでも使用できます。



つまり、SketchToolを使用すると、外部コンバーターに頼らずに、Sketchを直接エクスポート（SVGからPNGまたはPDFなど）に使用できます。 いいね！

SketchToolといくつかのアイコンを含む通常のSketchファイルを使用した簡単なテストにより、推測が確認されました。このシンプルなツールのおかげで、エクスポートに外部プログラムを使用できず、独自のプログラムも作成できません。 Sketchは何でもできます！

スケッチファイル

Sketchを使用してアイコンを保存およびエクスポートすることに決めたとき、アプリケーションで使用されるアイコンをSketchファイルに入れるときがきました。

最初は、MVPプロ​​ジェクト用に作成された限られたアイコンセットのみで作業する予定でしたが、重複、不整合、およびその他の問題をすぐに排除するために、すべてのアイコンを収集する方がよいことにすぐに気付きました。

私たちのデザイナーは良い仕事をしました-数日後、Sketchファイルで彼らが使用したリソースの大部分は1つのファイルに集められました。 この段階で、彼は次のように見えました。



ファイル内の各アイコンには、目的のアイコン名に従って名前が付けられた独自のアートボードがありました（その後、同じ名前のSketchが、リソースのエクスポートの結果としてファイルに付けられます）。 すべてのパスはパスに変換され、結合されたパスは1つの形状に縮小されます。 これにより、生成されたリソースは（ソースファイルのように）完全な外観を保持し、さまざまなプラットフォームと互換性があります。

一般的なスタイル（およびトークンデザイン）を使用したアイコンの動的な色付け

アイコンを収集した後の次のステップは、必要な色をアイコンに適用することでした。 Sketchで定義済みの共通スタイル（ 共有スタイル ）のセットを作成しました。その名前は設計システムの トークン名に対応し、それらを使用してアイコンを色付けしました。

特定のレイヤーにスタイルを適用する方法の例を次に示します。



スタイルを宣言してから要素に適用する方法は次のとおりです。



命名規則は重要な役割を果たします。 デザイナーは、サブフォルダー内のスタイルを管理できます。スタイル名は、この色に対応するトークンの名前によって設定されます。 したがって、その後、ビルドスクリプトはプログラムでそれらを操作できます。

A / Bテストに使用されるページとアートボードの名前

デザイナーがアイコンのA / Bテストを実行できるようにする方法を理解する時が来ました。 もう一度、命名規則に頼ることにしました（私はKISS原則の大ファンです）。

この場合、 ページの名前を使用してテストセットを決定し（ XP_プレフィックスを使用）、 アーバーボードの名前を使用して、A / Bテストが属するリソースとそのバリアント（角かっこで示されている）を決定しました。



テストに使用された名前とバリアントは、当社によって発明されたものではありません。これらは、独自の分割テストツールでテストとバリアントに割り当てられた一意のIDと一致する必要があります。 したがって、その後、リソースを特定のユーザーグループに正しくマップできます。

複数のブランドの複数のファイル

最後に興味を持ったのは、ブランドごとに同じアイコンのさまざまな形を維持する方法でしたか？



この要件への準拠は、製品マネージャーにとって非常に重要であり、いくつかの選択肢がありました。 最初は、ブランドに応じて名前が付けられる1つのSketchファイルの異なるページを使用する必要がありました。 しかし、彼らはすぐにこれがデザイナーの生活を複雑にすることに気づきました。異なるブランドのアイコンを絶えず同期させることは容易ではありません。 そこで、いくつかのファイルを使用することにしました。ブランドに応じて変化しないすべてのアイコンが保存される共通ファイルと、共通ファイルの「基本」アイコンを置き換える各ブランドのファイルです。



スケッチファイルの準備ができました！ コードを書く時が来ました。

続きを読む