WEB用のマテリアルデザインコンポーネントについて – デザイナー VS 開発者

当記事はクリエイティブ・コモンズ・ライセンス(Creative Commons license / CC license)に基づいて翻訳・編集しています。

Mustafa(以下M): マテリアルデザインをウェブ上で公開したての頃の課題のひとつは、かなりの数の異なる実装が求められたことだと思います。単一の情報源(SSOT)として、Angular、PolymerそしてMDL(マテリアルデザインライト)がありましたよね。どのように「単一の情報源」というプラクティスという問題を解決したのでしょうか?

 

Lynn Mercier(以下L): そうですね。最初は、AngularとPolymer、そして他の全てのウェブフレームワークそれぞれに個別のディベロッパーチームを組み、それぞれのマテリアルデザインへの実装について構築していました。でも、その規模で継続していくことが難しいと考え、マテリアルデザインシステムでの反復を素早く進めることにして、他のコンポーネントライブラリでは単一の情報源を保つことができませんでした。JavaScriptを一度書くと、HTMLと相互作用する部分を抽出することで、DOMを直接参照することがなくなる技術の開発に取り掛かりました。そこから、そのJavaScriptをそれぞれの個別のコンポーネントライブラリに書き込みました。

それは完璧な解決方法ではありませんし、今でもより早くより良くするために取り組んでいるのですが、この方法によってコンポーネントがそれぞれのフレームワークに属しているように見えるようになり、どのフレームワークに携わっているディベロッパーでも、その環境の一部としてシームレスになったと感じています。

 

M: 僕たちがマテリアルデザインライトに関して苦戦したことのひとつに、DOMに多くの黒魔術が行われていたということです。そこで、あなた方がDeveloper Tools(開発者ツール)をチェックしてみたら、そういったランダムな要素があるわけです。それは、いわば考えがあっての決断だったと思うのですが、「これが基準であるべきだ」という考えをもつことが求められるような新しいフレームワークの開発に、ただコンポーネントやウィジェット、そういうものを機能させたいとだけ考えているディベロッパーの作業を邪魔することなく、どのように取り組んでいますか?

 

L: 黒魔術はできる限り避けようとしています。自分のチームが書いたどのコードをチェックしている時はいつでも、ちょっとでもハックになるようなものや、性能を向上させるようなものは避けるようにしています。

真実としてあるのは、もしマテリアルデザインシステムを進化させたいのであれば、コードの上に構築できる必要があります。コードの各層が重要なんです。だから、いろいろな黒魔術と距離を置くようにしつつ、できる限り全てのコンポーネントライブラリで機能する単一の情報源をもつということですね。

 

M: 既存のフレームワークに関する作業という点では、そこにどのような関係性がありますか?というのは、例えば、Reactなどがそうですが、既に実際の世界観があるわけで、WordPressもそうですよね。そこでは、その世界で作業をしていかなければなりません。その結果として、特定のことができたりできなかったり…ということがあると思います。

 

L: そうですね。

 

M: 例えば、Androidではないフレームワークを維持するなどというのは、単一のというか、ウェブのように異なるコード間の関係性が重要になると思います。そういったことを、どのように扱っているのですか?

 

L: とても扱うのが大変であり、とても面白いことでもあります。基本的にディベロッパーが今まで使用していたものを優先するようにしています。だからReactは最高の例ですね。Reactには元々、膨大な量のコードベースがあり、それらはとんでもなく人気があります。そこで、私たちはそれをまずは優先しました。だからこそMDC ReactライブラリをReact用として作ったんです。でも、そこからAngularやPolymerといった使用を開始したい他のライブラリもあります。その場合でも、まずはディベロッパーがそれまで使っているか、いないかに関わらず、そこで使われているベースを優先するようにしています。それら全てを機能させるという点で言うと「ひとつのフレームワークがあるやり方で進めたい」という一方で「別のフレームワークが別のやり方が良い」ということも時にはあります。常に妥協することが求められています。

例えば、Polymerチームのディベロッパーと一緒に仕事をしたり、Reactのコミュニティと話をしたり。その中で、問題を解決するための正しい方法を探ろうとしているんです。そこで正しい妥協点に辿りついて、落ち着くというような感じです。

ブラウザについても同じことです。例えば、まず初めにChromeでの開発から始めることが多いです。というのも、それがベストで良く機能するとわかっているので。ですが、SafariやFirefox、Edgeもサポートしなければなりません。Internet Explorerは一番最後にテストすることが多いんですが…。私たちとしては、IEでも機能するようにしたいと考えていますが、緩やかに手を引いているような状況であるのは確かです。それが注意深くかつ緩やかなやり方で行っている限りは、問題ないだろうと思います。それはプラットフォームにおいても同じことです。どのプラットフォームでも完璧に機能している状態ではありませんが、そういう状況下で緩やかにそのコンポーネントから距離を置いておけば、全体として機能するということです。

 

M: 確か、BBCは「cutting the mustard(求める基準を満たす)」という表現を使っていると思います。つまり、基本的に機能させなければならない基準ラインのようなものがあるということです。もしそれが機能していなかったり、その技術に対応していない場合、僕たちがデザインしているエクスペリエンスに到達しないということになりますよね。そのことについて、概念としてどのように感じていらっしゃいますか?

 

L: そうですね、私たちもその概念を使う必要がある場面がありました。マテリアルデザインのシェイプに新しいものを加えた時です。ウェブプラットフォームでは、どの技術を使っていて、どのウェブプラットフォーム、ブラウザにおいても、丸い角はとても簡単です。隅切りの角は不可、現状の技術では、とにかく不可ということです。

そこで、マテリアルデザインチームに対して、「聞いて。2018年の今、CSSのスペックをアップデートすることはできるし、ここから3年先、私たちのプロダクトの次世代版ではこの機能を搭載することになるだろうけど、それを今実装することはできない」と話しました。そんな感じで、いくつかの機能については線引きする必要があると考えています。コンテンツを煩雑化せずに、かつ、誰も使うことができないようなハックのようなものにならないように、機能を実装することはできないのです。

 

M: では、SVGについてはどうですか?アニメーションの場合、SVGの課題はパフォーマンスそのものだと思いますが…

 

L: SVGやそこに加えるシャドウ、それらのSVGのスクロールパフォーマンスは、ブラウザやコンポーネントの状況といったもの全てを転送させることで、あっという間に非常に混乱したものになってしまいます。

 

M: とても複雑なものですよね。

 

L: とても複雑です。

 

M: 非常に興味深いですね。ベルトコンベヤーですよね。デザイナーが作業をして、ディベロッパーがそれを受け取り、そしてディベロッパーは叫ぶ。そこに全く会話がないんですから。それが、ディベロッパーが直面する最大の課題のひとつだと思います。もし話しかけてくれれば、説明することができるんです。特にコーディングの経験がないデザイナーに対して思います。

前にもこうやってお話したことがありますが、その際にデザインのストレステストについて言及していましたよね。僕にとっては、全く新しい概念なんですが。

 

L: 私がもっている概念ですから。

 

M: デザインにおいてストレステストをするというのは、どのように機能するのですか?

 

L: Designer Toolsに全てのピクセルパーフェクトモックアップを強制するのには限界があると思うんです。素晴らしいことだし、そこから素晴らしいアセットを作り出すことができます。ただ、実世界のアプリケーションで必ずしも機能するわけではないのです。ディベロッパーの仕事は、実世界にあるアプリケーションで機能するものを作ることですよね?

私たちの仕事は、実際に作動するコーディングです。多くの問題は、デザインが特定の言語、特定のスクリーンサイズ、特定のコンテンツにおけるピクセルパーフェクトになっていることが起因になっています。実際にそれを構築してみると、ダミーサイトをすぐに作ることはできますが、実際のコンテンツを埋め込んでみると、いろいろな問題が発生し始めます。

ほとんどのデザイナーは、もしその人のところに行って「ねぇ、実はこういう問題があるんだけど」と声をかければ助けてくれます。どうやってデザインを変更するか、とかどのように微調整すれば良いかを教えてくれるでしょう。デザイナーはフィードバックに対して受容的で、自分のデザインをより良くしたいと思っています。

ただ、もし自分のデザイナーが誰なのかがわからない場合は問題ですよね。例えば「ドイツ語だと機能しないバグがあるんだけど、どうすれば良い?」みたいな。どうやって直せばいいのか見当がつかないんです。だから、そのベルトコンベアー的な問題、つまりデザイナーが何か作成して、そのデザインを構築する過程でディベロッパーと一緒に作業することなくプロジェクトを離れてしまうという状況は、ディベロッパーにとっては、時間をかけてプロダクトを改善していくことを非常に難しくしてしまいますね。

 

M: では、その関係性をより良くするために、実際デザイナーはどのようにプロセスを改善できると思いますか? 結局は最も当然ともいえることになるのでしょうか。プログラミングをペアで組んで進めるということでしょうか。実際に話しかけないといけない状態ですからね。それがやはり最善の方法なのでしょうか。

 

L: それが最善だと思いますね。ある意味とても難しいことかもしれません。ひとつひとつの機能に対して、デザイナーとディベロッパーを一人ずつ専任させるというのは、時間的にもリソース的にも難しいという場合があるでしょう。

その手前の中間点にあたる方法はあると思っていて、まずお互いの名前を必ず知っている状態にすることです。リモートで働いているのなら、自分が書いたコードをどのようにステージングに配置するかを確認し、デザイナーはモックの繰り返しなどを送信できる方法を確認することですね。

すぐにできる明白なことではありますが、もう一つは、デザイナーが国際化することだと思います。モックのテキストをGoogle 翻訳に貼り付けて、そしてまたモックに戻すという一瞬で終わるひと手間です。そうすれば、それがどれくらい酷く見えるかがわかるんです。

 

M: ドイツ語とか?

 

L: そう、ドイツ語ですよ!それかCJK言語でもなんでもいいので、ひとつ言語を選んでみたらいいんです。それが正しい翻訳かどうかなんて関係ありません。まず最初のステップとして、そのチェックをしておくんです。

というのも、後に幅とか高さといったディベロッパーが指摘するであろうあらゆる問題を対処していくことになるので。デザイナーにとって良いことじゃありませんか?そうすることで、プロダクトも良くなり、サポートが必要になる言語はどういうものかフィードバックを得ることもできるんですから。

 

M: ユーザー作成型のアプリのようなものでは特に重要ですよね。コンテンツが10ページくらいだったり、2行だったりするようなものなので。名前のあるモックが必ずしもあるわけではないのですが、アバターの名前は完璧だけど、その4語でおさまる名前にどんなものがあるの?となりますよね。ストレステストに関して、他にできることはありますか?

 

L: 国際化は大きなことだと思います。それと、ウェブ上のものであれば、少なくとも異なるスクリーンサイズを想定することも役立つでしょうね。明確なブレークポイントを確実に機能させつつ、小さいものと大きいものを想定するということです。

そして、話は戻ってしまいますが、ディベロッパーが実際に問題に直面した時に、ちゃんとそこにいて、問題修正のサポートをすることですね。ほとんどのディベロッパーは問題を修正したいと思うんです。それをコード化して、ヘッドフォンをつけて、問題修正するコードを書きたいんだと思います。

ただ、サイトをデザインし直す方法はわからないんですよね?もしそれを私たちがせずに、ディベロッパーにサイトのデザインの仕方を推測させるならば、かなり悪いものを推測するということになります。だから、ディベロッパーにはデザイナー目線でサポートしてもらいたいですね。

 

参照リンク : Material Design Components for web – Designer vs. Developer #22 – Google Chrome Developers CC BY 3.0)
当記事はクリエイティブ・コモンズ・ライセンス(Creative Commons license / CC license)に基づいて編集しています。

共感いただけましたら、いいね!シェアいただけますと幸いです。

ASOBO DESIGN™ とは

ASOBO DESIGN ロゴ

ASOBO DESIGN (アソボデザイン)へようこそ!デザインの制作に関わることは何でもご相談ください。

チラシ・ポスター・パンフレットや、名刺・ショップカード・DMなどの各種印刷物、看板・ロゴマーク・パッケージデザインまで幅広いグラフィック・広告デザインに対応いたします。デザイン制作だけでなく、印刷から納品まで一貫して対応(※)しており、展示会・キャンペーン・販促宣伝活動等に貢献致します。※一部媒体を除きます

お問い合わせ

デザインの見積もり・制作依頼

SSL カード決済対応 銀行振り込みの他、各種クレジットカードでのお支払いにも対応しています。 デザイン料金はクレジットカード対応

ピックアップNEWS

実用的な折チラシデザイン
書籍「実用的!折りチラシデザイン」に作成したチラシが掲載されました。

チラシデザインが書籍に掲載されました
書籍「タイトルまわりのデザイン表現」にチラシデザインが掲載されました。

チラシデザイン集に掲載されました
書籍「実用的なチラシデザイン」にデザインが掲載されました。

雑誌掲載事例
デザイン総合情報誌「MdN」にWEBサイトが掲載されました。

メディア掲載事例について
インディーズCDの制作ガイドに、デザイナーとしてのインタビュー記事が掲載されました。

インターナショナルファッション誌 "En Vie Fashion Magazine" 内にデザインが掲載されました。

Adobe MAX Japan にて制作デザインが展示されました。

NEWS&PRESS情報一覧

事業概要 / ご利用規約

平日11時〜18時は電話でのお問い合わせも承ります。
050-5243-3791
問い合わせ専用となります。具体的な依頼の進行はメールでのやり取りとなりますので、予めご了承ください。タイミングによっては営業時間内でも応対出来ない場合もございます。その際はお問い合わせフォームをご利用ください。

お問い合わせフォーム