みなさんこんにちは！ 私の名前はDmitry Belyaevです。Mail.RuGroupのメディアプロジェクト部門でフロントエンド開発者として働いています。 チームとともに、さまざまなテーマの13の垂直プロジェクトを開発およびサポートしています。 最近まで、それらのそれぞれは、設計と使用されるテクノロジーの両方の点で、他のものとはまったく異なっていました。 今から同様の方向で開発しているので、マネージャーは「最近、プロジェクトの1つで機能Nが展開されました。来週/明日/昨日、プロジェクトのアナログを開始できますか？」という質問で私たちのところに来ました。次のプロジェクトのレイアウトでは、同じ問題を繰り返し解決したという事実を考慮せずに、新しい落とし穴につまずきます。 同様の状況により、全員に統一のアイデアが促され、プロジェクトの認知度が高まるだけでなく、作業の問題を​​解決する時間が短縮されます。



同時に、タッチデバイス用のプロジェクトのモバイルバージョンの開発が開始され、それら専用の開発への新しいアプローチを試みることが決定されました。 サイトのモバイルバージョンのページの構造は通常、デスクトップバージョンの同様のページよりもはるかに単純であるため、特定の問題を解決する方法を選択する際にエラーが発生した場合、修正にかかる時間は短くなります。 インターフェース設計部門が私たちのためにUIキットを用意しました。これには、個々のブロックのプロトタイプとレイアウト、ニュースリスト、記事、コメントなどの典型的なページのレイアウトが多数含まれていました。 さらに、たとえばLadyの処方ブロックやCoursesの計算機など、一部の個々のプロジェクトにのみ必要な固有のインターフェイス要素が描画されました。 彼らによると、私たちは、FestおよびStylusテンプレートエンジンと組み合わせて開発したBEMツールを使用して、BEM方法論に基づいてレイアウトされた独自のブロックライブラリを開発しました。



このようなブロックのライブラリを使用するアプローチは、それ自体が証明されています。 同じコードを何度も複製する必要がなくなり、人件費が大幅に削減されました。 また、各プロジェクトの各ブロックの設計の対応を追跡する必要がなくなったため、デザイナーを喜ばせました。現在、単一のリポジトリに格納されている共通ブロックの単一の実装が使用されているため、プロジェクトのブロックをチェックするだけで十分です。



新しいモバイルバージョンの発売に成功した後、デスクトップバージョンのプロジェクトの今後の再設計にこのアプローチを使用することにしました。 最初の起動後のブロックの統一されたスタイルと抽象的な実装のおかげで、各設計要素のレイアウトで詳細なレンダリングを行う必要なしに、設計プロトタイプに基づいてほとんどのページの作成を開始できました。 これは、設計者が費やすリソースの量を減らすことを意味していました。 このアプローチの実装に対するこのような刺激的な見通しに加えて、予期せぬ困難が待ち受けていました。 そして今日、私たちがそれらをどう克服するかについてお話したいと思います。

1.あまりにも多くのことができるブロック

UI-kitおよび関連する技術ソリューションの使用はモバイルバージョンで始まり、ほとんどの場合そのページは単純な要素で構成されているため、これらの要素の設計はよく似ていることがよくわかりました。 それらを1つの共通ブロックの形式で実装することは非常に理にかなっているようでした。これには、標準出力オプションと、さまざまな場合の修飾子のセットがあります。 当初、すべてが正常に機能していましたが、新しいプロジェクトの立ち上げにより、ブロックを使用するためのオプションの数は着実に増加し、既存のオプションのロジックはより複雑になりました。 そのようなブロックのサポートにより多くの時間が費やされました。 たとえば、一見単純なタスク-ユーザーが既に表示しているニュースリンクを強調表示するために、新しい修飾子が追加され、このブロックのすべてのニュースエンティティに書き込まれます。







このような状況では、これらのすべてのケースを別のブロックに分割するという決定が自然になりました。たとえそれらが類似した設計で互いに意味的に異なるとしてもです。 そうしないと、アプローチの主な機能の1つが失われる可能性があります。すべてのプロジェクトで簡単に適用およびサポートできる機能を備えたクジラデザインのシンプルなサポートです。 そのため、ニュース、コメント、相談、機関に関する情報などの出力を担当する個別のブロックを取得しました。

2.フォント

プロジェクトのデスクトップバージョン用の美しいフォントソリューションを探して、4つのRobotoフォントスタイルが最初に選択され、レイアウト作成時にフォントを使用するための標準オプションを含むフォントグリッドが描画されました。 実際、偶然にも、すでに標準化されたブロックのレイアウトに新しいモデルが登場したときに、人的要因の問題にすぐに遭遇しました。 このため、フォント設定を記述するための個別の構成を作成する必要が生じました。 最初に、それらの使用のためのすべてのオプションは、設定でセマンティックグループに分割されました：見出し、組版、小さな署名。 各サイズはキー名に対応していましたが、グリッド内の面の数は常に変化していました。 この形式でそれを維持することは問題となり、フォントに関する情報をスタイルに従ってグループに分けて共通のハッシュに保存することにしました。

$font['sets'] = defaults({ light: { _default: { font-weight: $font.weight.light }, '9': { font-size: 9px, line-height: 12px, _media: { font-size: 11px, line-height: 16px } }, '13': { font-size: 13px, line-height: 16px, _media: { font-size: 15px, line-height: 20px } }, '15': { font-size: 15px, line-height: 20px, _media: { font-size: 17px, line-height: 24px } }, ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この設定を使用するために、スタイラスで小さなミックスインが作成され、これを介してプロジェクトのすべてのフォントサイズが登録され始めました。 同時に、任意の要素に対して、適応型バージョンで呼び出すことができ、追加のパラメーターを渡します。これは、画面の解像度が大きくなるとサイズが大きくなります。

 set(hash, media = false) if (media) if ('_media' in hash && type(hash._media) is 'object') for $size in 'medium' 'large' +forScreen($size) for $attr-name, $attr-value in hash._media {$attr-name}: ($attr-value) for $attr-name, $attr-value in hash if ($attr-name != '_media') {$attr-name}: ($attr-value) .block__element set: $font.sets.light['15'] true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

将来、このソリューションは、UIキットを使用した最初のデスクトッププロジェクトの再設計中に、Windowsでのフォント表示に問題が発生した場合に非常に役立ちました。 それらのレンダリングはMac OSバージョンよりもはるかに遅れており、かなり薄いRoboto Lightを使用していたため、そのようにすることはできませんでした。 追加のcssファイルを使用することが決定されました。この場合、フォントスタイルはより太いものに置き換えられます。 さらに、ほとんどすぐに、いくつかのスタイルがまだよく見えるというデザイナーからのコメントがあり、現在のバージョンでは同じままにしておく必要があります。



構成のおかげで、追加のスタイラスファイルを作成するだけで十分です。このファイルでは、構成を検討し、設計条件を考慮して、すべてのスタイルを必要なスタイルに置き換えました。 コンパイル後、2つの個別のcssファイルを取得しました。1つはWindowsユーザー用で、もう1つは他のすべてのオペレーティングシステム用です。

3.彩色プロジェクト

プロジェクトは多くの同一のブロックを使用し始めたため、ユーザーにプロジェクトを相互に区別するための追加の要素を提供する必要がありました。 デザインでアクセントカラーを使用することで、この目標を達成しました。 これを行うために、カラーパレットの説明を含む個別のstylus-configが作成され、個々のプロジェクトごとに、対応する値が記録されました。 まず、2つのアクセントカラーとページ背景用のいくつかのカラーをその中に入れました。 時間が経つにつれて、彼はセマンティクスと色合いで分けられた標準の色オプションで大きくなりました。



これらの色のいずれかがブロックで使用された場合、スタイルではなく、個別のブロック構成で直接登録されました。 これにより、プロジェクトのブロックの色が変更されたときに、アセンブリ後に余分なコード行を取得することがなくなりました。

 $stepBlock = { default: { border: #d8d8d8, bg: #fff, color: #000, colorText: #000 }, states: { active: { bg: $color.primary.project, border: $color.secondary.project, color: #fff }, done: { border: $color.secondary.project, bg: #fff, color: #000 } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

背景、ボーダーボード、およびテキストにアクセントカラーを適用することに加えて、ほとんどすぐに、アイコンを再描画したり、アクセントカラーの明るさに応じて色相を変更する必要がある場合がありました（たとえば、アイコンがその上にある場合）。 さらに、色の変化をアニメーション化し、サイズを変更することが必要な場合がありました。



最初は、プロジェクトのすべてのアイコンがGruntタスクで個々のpngファイルからスプライトのセットに組み立てられましたが、そのようなケースが出現した後、それらの一部をフォントにすることにしました。 デザイナーにsvgでそれらを描画し、結果のファイルを別のユニットとしてリポジトリに配置するように依頼しました。 各プロジェクトは、必要なアイコンを選択し、Gruntを使用して、ページに自動的に接続されるアイコンを含むフォントを組み立てることができました。

4.フラットなデザイン

Mail.Ru Healthプロジェクトのデスクトップバージョンの再設計の開始時に、他の行とはスタイルが異なる設計が描かれましたが、ブロックとそのビジュアルコンポーネントの構造の大部分は標準ソリューションに類似していたため、同じ方法論を使用してこのプロジェクトを開発することが決定されました。 ほとんどの部分のヘルスレイアウトはフラットなデザインの標準に対応しており、したがって、多くのブロックがより明るく見え、シャドウやグラデーションがなくなったため、スタイルによる組版が容易になりました。 同時に、それらの一部は、より複雑なブロックで使用できます。たとえば、ボタンはページング、コメント、投票などのコンポーネントでした。







レイアウトを容易にするために、プロジェクトで書き換え可能な別のファイルにあるブロックの要素の一部を取り出して、不要なラッパーを取り除きました。 余分なスタイルをプロジェクトにドラッグしたくなかったので、デフォルトのスタイルはすべて_default修飾子に移動しました。これをオフにして、バージョンの使用を開始できます。 たとえば、クジラと単一プロジェクトのボタンブロックの次の依存関係実装：

 ({ mustDeps: [ { block: 'icon' }, { block: 'link' }, { mod: 'default' } ], shouldDeps: [ { elems: ['inner', 'text', 'loader', 'count'] }, { mods: ['large', 'font', 'color', 'loading', 'full', 'simple'] } ] }); ({ noDeps: [ { mods: ['default', 'search'] }, { elems: ['inner', 'text', 'count'] } ] })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

5.アダプティブグリッド

上記の段落のアダプティブフォントに加えて、コンテンツを異なる画面解像度に適応させることになっています。 標準ラバーを作成しないことにしましたが、ラッパーの幅が変更される3つの画面解像度に制限され、ブロックの表示の変更も可能になります。 アダプティブグリッドを実装するために、列サイズが設定された別の設定が作成されました。グリッドの構築を担当するブロックの標準インデント、メディアクエリのブレークポイント。 一部の場所ではページの外観を非常に強く変更する必要があったため、各ブレークポイントにはキーが割り当てられ、レイアウト適応性に関連するブロックおよびミックスインの修飾子を作成するときに使用し始めました。

 $layout['sizes'] = { small: { media: { max: 1279px }, cols: 1..47, wrapper: 940px }, medium: { media: { min: 1280px, max: 1339px }, cols: 1..59, wrapper: 1180px }, large: { media: { min: 1340px }, cols: 1..65, wrapper: 1300px } } mqForScreen($size, $sizes=$layout) $mq = screen for k in keys($sizes.sizes[$size].media) $mq = s('%s and (%s-width: %s)', $mq, s(k), $sizes.sizes[$size].media[k]) return $mq forScreen($size, $sizes=$layout) $mq = mqForScreen($size, $sizes) @media $mq {block} if $size == $layout.default .no-mq & {block}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべての列に対して、各解像度でサイズを設定する修飾子を追加しました。 たとえば、small_10 medium_20 large_percent-50修飾子を任意の列に渡すことができます。これにより、小さな画面解像度で幅10セル、平均20を占有し、大きなブロックで親ブロックの半分を引き伸ばします。 同時に、すべての可能なサイズが最初に同じ構成に登録され、mixinを使用してcssにデプロイされます。 同様に、必要に応じて他のブロックへの適応性が追加され、.hiddenなどのヘルパークラスにも追加され、必要な権限でブロックが非表示になります。

6.結論

クジラの設計作業が開始されてから過去2年間、ほぼすべてのプロジェクトでモバイルバージョンをリリースし、一部を新しい企業スタイルに更新することで、良い結果を達成しました。 プロジェクトのデスクトップバージョンでも同じアプローチが既に完全に使用されています。6つのプロジェクトが再設計され、この方向で積極的に作業を続けています。 この手法自体は、かなり複雑なコンポーネントを実装し、すべてのプロジェクトでそれらを実装するための人件費を大幅に削減するのに何度も役立ちました。



UIキット上に構築されたプロジェクトの開発での経験をコメントで共有していただければ、あなたが遭遇した問題について教えてください。