「バーガーデザイン」による統一：コンテンツプロジェクトのMail.Ruグループフレームワーク

Mail.Ru Group製品ラインの統一に関する講演の最初の部分では、モバイルWebのソリューションである発射物への最初のアプローチについて説明しました 。 多数のサービスのインターフェースの統一されたスタイルと原則の作成に加えて、フレームワークに基づいて、各画面の従来の「プロトタイプ→レイアウト→レイアウト→コード」からより効率的でモダンな設計プロセスを再構築することができました。 後半では、より複雑で大規模なサイトの同じテクノロジーへの移行について説明します-「ステロイドのブートストラップ」がさらに強力になった方法。





ポスター 、 自動車 、 健康 、 星占い 、 テレビ 、 不動産 、 レディ 、 ハイテク 、 天気



2012年の春に、自動車、ポスター、星占い、子供、健康、女性、モト、ニュース、天気、スポーツ、テレビなど、11のコンテンツプロジェクトがメールおよびポータル部門に提出されました。 彼らの多くはRunetのニッチのリーダーです。 しかし、誰もが独自の作成と開発の歴史を持っているため、設計は独自の方法で行われ、一般的なアプローチとソリューションの体系化と開発なしに、しばしば外部委託されました。



外観と作業ロジックをチームに発注することは、主要なタスクの1つになりました。 そして後で-設計へのアプローチを統一する必要性。 シンプルで明確なソリューション-製品ライン全体のインターフェースとビジュアルのガイドライン。 ユーザーの作業を理解しやすく、予測可能にする必要があります。ユーザーがサイト間を切り替えて、新しい相互作用のパターンを理解するのは簡単です。 また、ブランドを強化します。 また、嬉しいボーナスとして、製品チームのサービスの開発とサポートを促進します。

デザイン+テクノロジー

しかし、私たちの経験が示しているように、インターフェイスの静的な仕様では十分ではありません 。

• 「仕様→設計→レイアウト→実装」という連鎖が発生し、 各遷移で詳細が失われ、妨害がポップアップします。
• デザイナーは、開発者はドキュメントを読まないと言います。 しかし、率直に言って、デザイナー自身は、もし何人かの人々が同期しなければならないなら、愛しています。
• 仕様による設計は、一度に複数の製品に対して行われる場合、100％を実装することは困難です。 まず、 仕様自体に定期的な更新が必要です。新しいパターンが表示され、既存のパターンに対してより成功したソリューションが見つかります。 第二に、再設計中、彼らは何かを実装する時間がないかもしれず、サービスは「ほぼ洗練された」状態で起動します。 そして、製品ライン全体は「ほぼ同じ」です。 そして、参照設計とは何ですか？ もちろん、リファクタリングを実行することもできますが、結果として高価になることが判明しました。製品ごとに絶えず実行し、多かれ少なかれ目立った更新を行う必要があります。
• これにはすべて、実装の品質を制御するための多大な労力と設計者の多大な時間が必要です。 これは高価で疲れる。
• 設計の更新により問題が強化されます。 やり直しが必要です-やり直して制御、やり直して制御...

技術的な解決策は不可欠です。 リファレンスデザインを静的ドキュメントから実装レベルに転送することによってのみ、チェーンを「仕様=設計=レイアウト→実装」に短縮できます。 これは、製品の実装、改善、サポートのためにhemoの束を取り除くことを意味します。

小さなブートストラップまたはコンポーネントシステム

多くの大企業はすでにこの方向に向かっています。これにより、生活が大幅に簡素化され、ビジネス開発で手を自由に使えるようになります。 優れた設計は、手早く実現することは不可能であり、安価かつ迅速に入手できます。 この技術的な解決策は何でしょうか？ 2つのオプションがあります。「 小さなブートストラップ 」を作成すると簡単になり、コンポーネントの完全なシステムを作成することでより複雑になります 。



最初のオプションは、作成が安価で高速です-簡単なサポート、低コストの設計実験、簡単なプロトタイピングからすでに利益を得ています。 本質的には、実際の製品で使用すると壊れる可能性があるHTML / CSSスタイルのセットを使用します。 過去数年にわたって、この主題に関する多くの先見の明のある記事がありました。たとえば、 Mark OttoやDave Rupertからで、 多くの企業がこの原則に取り組んでいます 。



https://speakerdeck.com/mdo/build-your-own-bootstrap



2番目のオプションは作成するのにより費用がかかりますが、出力では、設計実装の品質が保証され、製品の更新が簡単であるというすべての利点があります。 Mail.Ru Groupの私たちはこの方法を採用しました。 このアプローチには、5つの成熟度レベルがあります。

1. 一般的な設計原則は、CSSで定義および保護されています。
2. すべての製品は、単一のコンポーネントに基づいて動作します。
3. これらのコンポーネントと一般的な設計原則を説明するライブガイドラインがあります。 スクリーンショットではなく、最終的な実装を示しています。
4. ライブガイドラインに基づいてページのプロトタイプを作成できます。
5. さまざまなアプローチを比較するためのコンポーネント設計実験が可能です。

完成したコンポーネントの道を進む企業は多くありませんが、IntuitのHarmonyエコシステム、Rizzoフレームワークに基づくLonely Planetソリューション 、そしてもちろん、マテリアルデザインを実装するGoogleのPolymer Projectの非常に強力な例があります。

製品チャレンジ

歴史的に、ポータルとしての多くのMail.Ru Groupサービスは、主にサードパーティプロジェクトのコンテンツのアグリゲーターでした。 人気のある製品（メール、メインページ、インスタントメッセンジャー）をバンドルすることで、多くの視聴者を獲得しています。 また、彼女はもっとニッチなことに興味があります-例えば、車、家族、都市の出来事に関するニュース。 同時に、それらのいくつかのメインエントリポイントはMail.Ruメインページです。1日に数回更新される特に人気のある資料のリストがあり、ユーザーはここからニュースを読むことができます。





Mail.Ruホーム



その結果、ユーザーは製品のメインページをバイパスしてすぐにニュースにアクセスします。 そして、しばしばそれを閉じて、メインのMail.Ruに戻ります。 さらに、多くの場合、サービス間の違いを認識していません-彼にとってこれはすべてニュースです。



したがって、コンテンツプロジェクトを部門に移行した後の主要な製品タスクの1つは、各プロジェクトのメインページへの依存を減らすことでした。 視聴者を獲得するために、製品は独自のコンテンツの作成を強制し、ポジショニングとアイデンティティ、SEOおよびSMMを操作しました。 そして、それは顕著な効果をもたらしました。



ニュースページからサイトへのユーザーのパスを拡張する必要もありました。 そして、メインのMail.Ruからのトラフィック、SEO、およびSMMの場合-これが最初に取得される場所です。 出力は、関連するコンテンツの多数のバインディングでした。たとえば、ポスターの映画や俳優、健康に関する病気や相談、自動車の中古車の発表などです。 もちろん、視界深度やその他の指標を増やす問題も解決する必要があります。





関連コンテンツのバインディング





ナビゲーショントラックチャート

プロセス：設計

2012年末に新しいポスターの作業を開始し、「バーガー」アプローチを基礎として採用しました。 これは一連の「ベルト」、「ライン」、「カット」、または「コンテナ」であり、現代のプロモーションサイトで積極的に使用されており、モバイルもほぼ同じ原理に基づいて構築されています。 当時、このアプローチは現在ほど大規模ではなかったため、新鮮なものであったはずです。





ポスターMail.Ru、2013年春



コンテンツが「ガラス」に絞り込まれている通常の柱状構造とは異なり、「ハンバーガー」を使用すると、多くの空きスペース、大きなフォント、イラストを備えたより効果的な雑誌デザインを得ることができます。 各「ベルト」には独自のレイアウトがあり、コンテンツの表示を多様化できます。





バーガーの作り方



しかし、最良の部分は、 そのような構造の職場での利便性です 。 ベルトは簡単にページに追加したり、ページから取り外したり、交換したりできます。 または、隣接する列を考慮せずに複数のページで繰り返し使用します（いくつかの注意事項はありますが、一部のページではこの問題をまだ解決できていません）。 特別なプロジェクトと新しいページを組み立てるのは簡単です-ハンバーガーのように、ロールの間にコンポーネントを入れるだけです。 キャップとフッター。 素晴らしいボーナスは、マネージャーが「このブロックを列に追加しよう」のようにチートできなくなり、優先順位付けを避けようとすることです。 高いほど重要です。



インフォメーションアーキテクトの コンスタンティンワイスは、 コンテナ主義の概念におけるバーガーデザインの利点について説明しています。 その用語では、レイヤーまたはベルトはコンテナです：

1. 「ベルト」の無限のスタック 。 グリッドを壊すリスクなしに追加および削除できます。
2. 簡単な優先順位付け 。 グリッドを壊すリスクなしに、必要に応じてスタック内で移動できます。
3. コンテナはページで複製して再利用できます 。 これらは、グリッドに関連付けられたパターンです。
4. 開発として- 一度に複数のページで使用します 。
5. 複数のページで使用されるコンテナには 、それぞれのページに微妙な表示が含まれている場合があります。
6. 一度に複数のサイトで使用できます。 このために、そのようなパターンを記述するための言語が使用されます。

「コンテナ」のイデオロギー



適応性はシンプルになります-列の流れの複雑なロジックを考える必要はありません。 ビッグウェブとモバイルの「ベルト」の順序は同じです。フレーム内の要素の数が変わるだけで、水平スクロールのブロックはしばしば古典的なリストに変わります。 タブレットでは、変更はまったく簡単です。



確かに、問題があります：

• ページは非常に長くなり、ユーザーはページを最後までスピンする必要がなくなる場合があります。
• スペースを完全に無料で使用すると、小型モニターでの有用な情報量が減少します 。
• 豊富な色彩、色の斑点は、広告の効果を低下させる可能性があります。

今後の調査のためにこれらすべてを注意深く記録し、検証のための最初の作業バージョンを待ち始めました。



会社の戦略的タスクの1つは、すべての製品を1つのビューにまとめることです。 同時に、Mail.Ruホームページからのトラフィックへの依存をさらに減らすために、製品自体が自分の顔を持ち、ブランドの認知度と価値を高めることが重要です。 インターフェースが常にユーザーに馴染み、理解できるように両方の要件を満たす方法はありますが、サービスはポータルの単なる付属物になりませんか？ 適切な解決策を見つけましたが、すぐには見つかりませんでした。

背景

「バーガー」形式は、コンテンツプロジェクトの統合に対する2番目のアプローチです。 2012年春のニュースの再設計からすべてが始まりました。これは、1日あたり450万人のユニークビジターがいる主要な製品です。 インターフェイスには、テーマ、アフィリエイト、広告のスカートがたくさんあり、メニューが重複していました。 作業は2つの面で行われました。





Mail.Ruニュース、2011年初頭： メイン 、 ニュース



まず、メインのランディングページであり、すべての訪問者の中で最も訪問者が多いニュースページです。 左の列を取り除くことが重要でした。それにより、最初に目が材料の内容を見て、二次的なボディキットが見えないようになりました。 メインコンテンツ、関連資料、広告、アフィリエイトリンクを明確に区別したかったのです。これは当時のニュースサイトにとって大きな問題であり、現在もそうです。





Mail.Ru News：ニュースページ



解決策は「1 + 2」レイアウトでした。コンテンツに対して最も見やすく最大の領域が与えられ、右側に広告とアフィリエイトブロックの二重列があります。 これにより、ユーザーは基本情報に集中し、関連するすべてのものがきれいに並んで収集されます。 広告スポットのコストが増加したため、ボディキットの一部を取り除くことができました。 また、スクロール中にコラムを貼り付けると、ニュースの高さが異なるために生じる穴を削除するのに役立ちました。 ページの最後には、その日のテーマと別の「スワップ」を含む標準化されたフッターがあります。





ゾーニング情報



第二に、 メインページと見出しページ -ここではより多くの自由があります。 メインのスクリーンは、他のスクリーンよりも1桁小さいサイズでアクセスされるため、ボディキットの一部を犠牲にして、プロジェクトの顔を壮観にすることができます。 列に対して戦争を宣言しました-原則として、これはページのレイアウトを制限して台無しにするものの倉庫です。 これにより、主なものは「小文字」になりました。 彼女はより集められたように見え、彼女と一緒に仕事をする方が便利です。 おそらく、そこから私たちの将来の「ハンバーガー」アプローチが来ました。 ルブリックはより複雑です-そこにはより多くのトラフィックがあり、「1 + 2」アプローチを終了する必要がありました。





Mail.Ru News：ホーム



ニュースの立ち上げには問題がなかったわけではなく、重要な指標を完了する必要がありました-多くのブロックが期待どおりに機能しませんでした。 しかし、同じガイドラインに基づいてSportが発売されたとき、ナビゲーション要素の1つだけで問題が発生しました。 ルールはうまくいきました！



コンテンツプロジェクトのスタイリングをすぐに考えました。カラースキーム、フォント、装飾要素を使用して、テーマと視聴者に適応する単一のインターフェイスソリューションが必要でした。 そして、彼らはすでに他の製品をそれに移し始めました-スポーツ、子供。 確かに、構造は近く、視覚的に一貫しているものの、プロジェクトの作成とサポートのアプローチは異なります。 さらに、タブレットでの作業時に問題が表面化しました。「1 + 2」レイアウトでは、個別のバージョンが必要でした。ポートレートモードでは3つのスピーカー用のスペースがなく、水平スクロールが表示されたため また、不必要な不一致を厳しく制限する技術的な解決策も必要でした。





スポーツと子供のMail.Ru



統一デザインの長所と短所を理解した上で、ポスターを取り上げました...

プロセス：テクニカルソリューション

私たちはすでにモバイルWeb向けにこの方法を採用しています。私たちが考案した開発者と一緒に、 設計と技術のフレームワークを作成しました。 2013年の終わりまでに、それに関する多数のコンテンツプロジェクトが開始されたため、アプローチはロールバックされました。



確かに、モバイルと大規模なWebサイトに同じ技術を使用することは、まったく同じことではありません 。 少なくとも多くの違いとニュアンスがあります-少なくとも、モバイルにはリストの表示が2種類（イラストとハードセットサイズのリストとスライダー）しかないという事実と、大きなウェブでははるかに多様性があります。 しかし、再度、開発チームを称賛します。この困難でありながら非常に重要で興味深いプロジェクトに適合するように、実装からの課題と可能な利益を評価しました。



当初、フレームワークは次のように編成されていました。

1. PhotoshopおよびInDesign のパターンのライブラリ 。プロジェクトで使用されるすべてのソリューションが含まれます。 また、設計の基本原則を説明するガイドライン。 静的なドキュメントから、レイアウトの代わりに既製のコードを使用するライブガイドラインに移行する計画です。 これにより、チェーンが短縮され、不要なアーティファクトから保護されます。
2. インターフェイスパターンを実装する単一のコードベース 。 ページ要素は完全に独立したレイアウトブロックで構成され、コードはBEM手法（block-element-modifier）から取られたスタイル命名の原則を使用します。 同じインターフェイスブロックが異なるページで使用されます-それらのデザインは、何が起こっているかに依存しません。 ブロックが各ページに正しく表示されたかどうかを毎回再確認する必要はありません。
3. ユーザーのブラウザでサイトページを表示するためのテンプレートエンジン 。 彼は、個別にレイアウトされたブロック、グラフィック、スタイル、およびスクリプトから最終的なレイアウトをその場で収集します。 すべてのタイプのページについて、それらのアセンブリのルールが決定されます-つまり ブロックのセット、そのシーケンスおよびコンテンツ。 BEMに接続されているものの代わりに、独自の技術が使用されます。

古いブロックまたはコンポーネント（たとえば、新しいタイプのフォトギャラリー）の新しいソリューションが見つかった場合、単一のコードベースで変更されます。 その後、 各プロジェクトは、独自の共有リポジトリから更新します （強力な変更により、受信コンテンツもファイナライズされます）。 この場合、設計者は各サービスを追跡するのではなく、単一のコードベースで1つの実装のみをチェックする必要があります。 また、実装された設計の品質を確認できます。 同僚と私は、この記事の第3部でフレームワークについて詳しく説明します。



モバイル版はサーバーとクライアントに同じページテンプレートを使用し、V8を使用してユーザーのブラウザーで最終的なHTMLが生成されます。 このモデルは、歴史的にプロジェクトが異なるプログラミング言語で書かれているという事実にもかかわらず機能します。 しかし、大規模なウェブでは、ストーリーはより複雑です- 最終的なHTMLをブラウザーに出力することが重要です 。 サーバー側で生成します。 そのため、開発チームは、各プログラミング言語の「スタンドアロン」v8デーモンに連絡する方法を見つける必要がありました。 私の同僚は、別の記事で技術的な部分を詳細に説明します。



これは簡単なプロジェクトではありません。 ただし、 設計を技術的な実装レベルに変換するアプローチは、設計者と会社の両方にとって重要です。

• 90％の設計の統一は、開発アプローチによって保証されます。すべての既製のブロックと要素は、単一のコードベースからのみ取得されます。 さらに10％-既成のソリューションを使用するときの注意と思いやり。
• インターフェースの関連性を常に維持するために、数年ごとに英雄的な再設計を避ける。 再起動には多くのエネルギーが必要であり、長い間開発に費やされた何千もの小さな開発が失われます。
• 他の製品は、特定の製品の改善から恩恵を受けます。 たとえば、トピックのニュースブロックがAutoの表示回数を増やした場合、このソリューションはすぐに他のサービスに分類されます。
• より少ないレイアウトを描画する必要があります。 既製のブロックからページを組み立てることができ、将来的にはPhotoshopをまったく起動することなく組み立てることができます。 同じことがさまざまな特別なプロジェクトにも当てはまります。

手ではなく、デザイナーの頭を使いたい。 ルーチンの削減により、焦点を製品タスクに移し、目立たないが重要な設計上の問題を解決することができます。 基本的な測定基準、快適なアニメーション、適応性の微妙なニュアンスの増加、人間の形での広告の提供-無限のストリームでは、常に十分な時間がありませんでした。



同社も黒字です。 プラットフォームに製品を転送するための投入価格を差し引くと、製品の効率を改善し、市場での新機能の立ち上げを加速し、設計の統一を保証する体系的なアプローチを受け取ります。 共通の言語を話すことができるため、経営陣にフレームワークへの投資を説得するのに役立ちました。その作成のイニシアチブは以下から来ました。 この言語を見つける方法については、UX戦略に関する記事に書きました。

打ち上げ

2014年の秋までに、4つの実行中のサービスと別の一連の作業を思い付きました。 最初の波は自動車、ポスター、健康と天気に当たり、後に星占い、不動産、テレビ、女性が登場しました。 私たちは仕事をうまくやりましたか？



一連のユーザビリティテストを実施し、分析データを徹底的に掘り下げました。 起動後は常に問題が発生するため、最も重大な問題をできるだけ早く解決したいと考えています。 「ハンバーガー」アプローチが機能するかどうか、そしてそのリスクに伴って何があったのかを理解することはさらに興味深いものでした。まず、長いページをスクロールしますか？ 一般に、はい。ただし、ニュアンスと予約が必要です。



メインページと主要なセクションのスクロールファンネルは、ユーザーがすぐに辞めたり、適度に落ちたりすることを示しました。





ページファンネル（数値を示す）



ページにほぼ均一なコンテンツ（たとえば、映画のリスト）が含まれている場合、カットは壊滅的です-ユーザーはページが終了したと考えて去ります。 同じ理由で、病気のページの共有のストリップが有用なコンテンツの終わりとして認識されましたが、以下に本当に価値のある追加がたくさんありました。





対照的なベルトのさまざまな効果



同時に、純粋に集約されたページは問題なく機能します。たとえば、ほぼ完全に断片で構成される映画に関する情報などです。 メインコンテンツが何であるかについては期待していないようです。 アンカーリンクも大いに役立ちます。ユーザーはページのコンテンツ全体をさらに積極的に使用します。







Poster Mail.Ru：集約ページの例としての映画



問題ページの切り込みの高さとコントラストに取り組みました-均一な流れを妨げないことが重要です。 これは、主要な製品タスクの1つに特に重要なねじれの問題を解決するのに役立ちます-テーマ別インセットのおかげでユーザーをログインページにさらに誘導します。



近い将来、見つかった問題を解決し、フレームワーク自体を磨きます 。 どこかで、ポスターのように、私たちは聴衆の一部で初期バージョンを立ち上げ、半戦闘モードで設計ソリューションをチェックする機会がありました。 Autoのように、どこかで広告契約に縛られ、できるだけ早く開始することになっていた。 しかし、ソリューションの体系的な性質により、この蓄積された知識は製品ライン全体に利益をもたらし、単に「メモ」レポートの結果のままではありません。 そのため、これらの問題なしにエンジンの新しいサービスが開始されます。



繰り返しますが、フレームワークのおかげでワークフローがどのように変化したかについてのいくつかの図と事実：

• 設計の開始から開発への移行までの速度が大幅に向上しました 。 たとえば、最新のサービスの1つを使用して、1月末に設計作業を開始し、3月中旬に開発に着手しました。 大規模なプロジェクトの場合、これは社内の記録です。少なくとも6か月かかる前です。 何を節約しましたか？ スタイルの調整、単一のコードベースでのパターンとコンポーネントの作成、多くのレイアウトの拒否-すでに実装されているソリューション、多くの場合ページ全体を採用します。
• 設計の調整が大幅に容易になります。 これは、マネージャー、編集者、開発者によって一度承認されています。 次に、サービスの製品タスクをどのように解決するかを考え、スタイルと一般的な方向性のために戦うことはしません。 もちろん、これはデザイナーを少し制限しますが、あなたの創造性を伸ばすことができる努力のアプリケーションのポイントがまだあります-アニメーション、広告フォーマット、使用シナリオのより良い仕事、分析と実験の仕事。
• 新しい設計イデオロギーの最初の製品リリースには、いくつかの指標に欠点があります 。 しかし、それらを修正すると、その後の起動のパフォーマンスが向上します。 これは、スケーリングのアイデアが機能することを示しています-問題は完全に修正されています。
• モバイルと大規模なWebは同じエンジンで動作し、同じ方法でデータを準備し、多くの共有ライブラリを使用します。 最初の部分では、基本バージョンがやり直されるまで純粋な適応性は実現できないという事実について話しました。 実用的な必要性はまだありませんが、今ではより現実的になっています。 バージョンなどはユーザーにとってほぼ同一です-統一されたURL、コンテンツとサービスの偶然。 さらに、新しいページまたは機能を追加するときに、大規模なモバイルWebで同時に開発および実装されます。
• テンプレートエンジン自体の動作は、大規模なモバイルWebでも同じです。 ただし、電話バージョンでは、ビルディングブロックが少なく、情報を出力するためのロジックが単純なので、不一致の特別な理由はありません。 同時に、ビッグウェブにはさらに多くのバリエーションがあります。 さらに、ページレイアウトの幅広いセットで、複数の解像度がサポートされています。 これにより、さまざまな専門家間の調整が特に重要になります。
• プロジェクト間のチームのローテーションは簡単です。プロジェクトの内部は互いに非常に似ているためです。 新しい主要機能を再設計または起動した時点で、1つのプロジェクトのフレームワーク内で異なる実行者間でタスクを並列化することがはるかに簡単になりました。 別の開発者を接続するコストは大幅に低下したため、2人で実際に1つのタスクをほぼ2倍速く完了することができます。
• 標準ソリューションは大いに役立ちます 。 以前は、ただの混乱がありました-各プロジェクトには独自のものがあります。 フォトギャラリーを新しいプロジェクトに転送するには、初めて作成するのと同じくらい時間がかかりました。 マネージャーは合理的に不満を言いました-なぜ私たちは別のプロジェクトから既製のソリューションを取り、それを実装できないのですか？！ これで動作しますが、ワークフローにはまだデバッグが必要です。
• 各マネージャーの標準的なソリューションに松葉杖を切る必要はもうありません 。 この問題は、設計自体の標準化へのアプローチによって解決されました-それからの逸脱はより高価です。
• バックエンド側では、このアプローチによりプロジェクトをクリーンアップし、正しいMVCモデルに導きました。
• - — , , , . — , , . . CSS- ( Stylus) .

- .

, .









, .









, , . .









.

. , — , (Windows 8, Windows 7, Windows XP). Roboto : Windows, MacOS Arial Windows XP.





( )



, . , - , . 2013 , . , — .





Windows

. .. — « », .. . , , InDesign — .

, , «» . , .

, , . , , . , . , , .





-



, , .









. . . , . , Behance Dribbble. , .





Mail.Ru:

40/20

«» , - «1+2». — , .





40/20



, , 4- ( 8-). — . , . , — . , , .

. — 4:3, 16:9 1:1, . — ( -), - ( ).

, . . -, . , « » .

. , — . — . , - .

計画

, . , . ; , ; .



. - , , , . - , - , - .



— , : , - -. , , — , , . «» -; , . , «/» , «/». - ; - . - , . - - . .

- , . , , . , , . - .

. , . - CSS . , .

, - CMS — . - — — . , - .





: , ,



, - Vox Media Look at Media . CMS - , . , . .





Vox Media Look at Media

Mail.Ru Group , , , . -, -, e-commerce, , . . -, . «» — productivity, -, e-commerce. , 10 40 .



しかし、もちろん、少なくとも私の部署のポストとポータルの枠組みの中で、さらに統一を続けたいと思っています。ますます多くのサービスを単一のフレームワークに移行することで、製品および技術面からこれに近づくことができます。クラスターの視覚的表現の収束に関する並列作業-設計と。おそらくすぐに、次の実装段階についてのストーリーでデザインの統一に関する一連の記事を続ける機会があるでしょう。

結論

多くのプラットフォームの長所：

• 新製品の機能の市場投入の加速。
• 統一された設計を得るための保証された方法。
• 他の製品は、特定の製品の改善から恩恵を受けます。
• デザイナーは手ではなく頭で作業します。

しかし、最も重要なことは、 我々は英雄的な再設計から絶えず最新のインターフェースに移行しているということです 。 したがって、無限の設計サービスではなく、製品の作業により多くの時間を割くことができます。 そして、スペシャリスト自身がモックアップで考えるのをやめて、Photoshopを超える製品デザイナーになります。



PSデザイナーと開発者のチーム全体に感謝します。 デザイン面から-ゲヴォルグ・グレチャン、エフゲニー・ドルゴフ、ミティア・オサドチュク、アルテム・グラドコフ、パベル・スクリプキン、アレクセイ・カンダウロフ、エフゲニー・フェルレフ、スヴェタ・ソロヴィヨワ、アレクセイ・セルゲイエフ、I 開発側から-Stas Mikhalsky、Konstantin Vorojeykin、Alexander Bekbulatov、Sergey Nozhkin、Andrey Kusimov、Dmitry Belyaev、Evgeny Ivanov、Anton Poleshchuk、Vitaliy Vasin、Maxim Trusov、Boris Rebrov すべてのマネージャーと編集者、そして私たちを信じていたアナトリー・ロジコフに。





Smashing Magazineの記事の英語版を参照してください 。