利用の状況について考察します。使うことになったのかについて著しました。我々のチーム内でうまく機能しています。それはインターフェイスの理解の共有や、さらなるモジュール化への移行、我々のデザイン言語の進化などに貢献しました。おけるいくつかのコンセプトについては最初から明確でしたが、その他はあいまいに感じていました。集まったグループ」と定義しています。違い、そもそも双方のタイプがなぜ必要なのかなど、正確に理解するのに苦労しています。部分はとても良く似ています。分けることについて、3つの利点があると考えました。それをおこなうにはおそらく単純すぎるだろう)。デザインの観点からは、それはデザインの理解と、何から構成されているかを理解するのに役立ちます。デザイン時において正しい要素をより早く見つけるのに役立ちます(例えば、「ここにこのコンテントを共有させるための要素が必要なんです、えーと、これを見て欲しいのですが、、」)。パターンライブラリの観点からは、要素を整理し見つけ易くするのに役立ちます(少なくとも我々が使っていたひとつの長いリストよりは簡単です)解決しようとしていた問題しかしながら、どのように分割すればよいかという共通理解がチーム内にありませんでした。論争するのに長い時間をかけてしまいました。討論は常に生産的である訳は無く、我々はそれを続ける余裕はありませんでした。そこで、どうすれば要素を分類分けするのにより効率的になれるかを確認するため、我々はデザイナーやフロントエンドの開発者とのワークショップを開くことを決めました。ワークショップいつものように、我々はインターフェイスの要素を紙上に書き出しました(上の画面参照)。我々は小さいチームに分かれ、それぞれのグループに、インターフェイスの要素をすでに整理したパターンライブラリよりも分かりやすい形で分類するよう(カードの分類のように)依頼しました。狙いは、皆がどんなグループ分けをするのか確認することでした。ワークショプの結果ワークショップの結果は、要領を得ないものでした。チームは様々な方法でモジュールを分類し、最終的には異なったグルーピングになってしまいました。そこには二つの明らかなタイプがありました。我々が気付いたのは、いくつかのモジュールはそれら自身にも使われる一方、他のモジュールは、他のモジュールの一部としてのみ動作するということです。これらの二つのコンポーネントは機能的にもプレゼンテーションのレベルでも全く異なります:最初のグループ(最上位のコンポーネントに相当する)要素は補助的な機能以上のものを持っています。それを「helpers」と呼びましょう。2番目の要素はより独立しているので「standalone」と呼ぶことにします。それ自身では意味を成しません。ここには、このグループの典型的な例が、いくつかあります。典型的なヘルパーです。要素はそれ自身の中で「生き残り」ます。それは自分自身の独立したコンテンツと機能の構成として参照されます。ここまでは理解できます。他のインターフェイスの要素をサポートします。自己完結型で、自分自身に依存しています。?しかしながら、多くの要素がその中間の何処かに存在します。中間に落ちたものは、主にふたつの要因(コンテンツと文脈)により、理論的にはどちらかのグループに属します。コンテンツと文脈はもちろん変化する対象で、それらの要素を分類するのを難しくしています。ように見えます(かなり複雑な要素で多くのコンテンツを含んでいます)。自己完結していません。days)」とありますが、どのコースが2日後にはじまるのか、明確ではありません。我々がコンテンツを変更し、より意味のあるタイトルをつけ、コースのタイトルを参照したと想像してください。このモジュールは自立できるようになります。我々のインターフェイスはこのような要素にあふれています。取り組んで一年たっても、インターフェイスの要素をどのように分類するかについてチーム内で未だに明快に理解が共有されていません。物事を分類し整理する「正しい」方法が常にあるとは限りません。我々が学んだことのひとつは、モジュールがどのグループに属するかを決めるに当たっては、より柔軟であるべきということです。どちらになるのか最終的に決めるべきです。残りのメンバーは、強くそして事実に基づいた異議がなければ、その決定を受け入れるべきです。モジュールとして見なすことを助けます。取り組むなら、ぜひあなたの考えを聞かせてください。下のコメント欄に書き込んでください。原著者の許諾を得て翻訳・掲載しています。海外で話題の記事を翻訳して届けるエンジニアのためのメディアです。