読者です 読者をやめる 読者になる 読者になる

30億のデバイスで走るHonMarkHunt

JavaとJavaScriptと恐竜の絶滅について書いていきます。

Frontrend Vol.8 - 帰ってきたフロントレンド 行ってきたメモ

f:id:HonMarkHunt:20161205214825p:plain

はじめに

  • Frontrend Vol.8 - 帰ってきたフロントレンドに参加してきました!
  • 1年半ぶりの開催とのことでしたが初参加させていただきました!
  • ブログ絶対に書くマン枠にて参加させていただいたので、投稿させていただきます。

frontrend.connpass.com

開会の挨拶

  • frontrend久しぶりなのは社内のノウハウが枯渇しかけたから
  • 充電満タン
  • 1年くらいはfrontrendまた継続していきたい

発表アジェンダ

  • Design Systems as a Product プロダクトとしてのデザイン・システムについて
  • Lightning Talks
    • Introduction to Resource Hints
    • atomic designで助かった人たち
    • 祭りから半年たったプロジェクトにジョインしてみた
    • 最近のお仕事について
  • アメブロフロント刷新にみる ひかりとつらみ

Design Systems as a Product プロダクトとしてのデザイン・システムについて

  • 登壇者: @cssradar

デザイン・システムとは?

  • デザインや技術に関わる事柄、ユーザが利用するプロダクトに関わる全てを網羅するシステム
  • ex)
    • Bootstrap
    • Material design
    • ORIGAMI

なぜ必要なのか?

  • マルチデバイ
  • デザインの技術的負債
  • 使う側はそのサービスのどこに触れたとしても同じ体験ができる
  • 作る側も共通の言語(一つの真実)があることでぶれずに早く実装を進めることができる
  • 変化の激しいフロントエンドでカオスを管理する

構成要素

  • STYLE GUIDES
    • デザインに関わる材料やガイドライをドキュメント化する
      • BRAND IDENTITY
      • DESIGN ランゲージ
      • VOICE AND TONE
      • CODE STYLE
      • PATTERN ライブラリーす
      • And more...

導入

  • 技術的な難しさよりどう運営していくか

ゴール

  • デザイナーにとって
    • デザインをする際のビジュアルリファレンスになるパターンライブラリを作る
  • エンジニアにとって
  • デザイン・システムはプロジェクトではなくプロダクトによって作られたプロダクトである

必要な人材

  • デザインが成し遂げたい思想を理解している人
  • エンジニアがシステムを作る手段や方法を理解している人
  • その中間にたてるバランス感覚を持っている人
  • そんな人はいない、いたら連れてきてくれ(雇う)
  • つまりエンジニアとデザイナにはギャップがある

デザイン・システムはそのギャップを解決できる

  • デザイナとエンジニアの継続的コラボレーションとなる
  • デザイナとエンジニアは成し遂げたいゴールは同じなのに共通言語がない
    • デザイン・システムが共通言語となり得る

チームモデル

  • デザインシステムを作成(導入?)していくチームの体制

単性モデル

利点

  • ある一つのプロダクトだけのUIライブラリ集
  • mini bootstrapを作って使ってもらう
  • 確立されたパターンライブラリの存在は大きな利点

弱点

  • ある問題を解決するためにデザイン・システムが生まれてしまう

中央集権モデル

利点

  • どのチームにも属さずデザイン・システムを作成する
  • 様々なチームの要望を聞い作成する
  • 多くの人に受け入れてもらう(一般化)

弱点

  • 実際のプロダクトのつながりが弱い

連合モデル

利点

  • マテリアルデザイン
  • デザイナ, エンジニアが集まって意思決定する

弱点

  • 人材の管理が困難

どれがベストか?

  • 時と場合による
  • 会社の規模や、デザイン・システムがどれだけその規模を網羅するのか...

まとめ

  • デザイン・システムとはプロダクトである
    • プロジェクトは作り終えることがゴールになってしまう
    • システムが生き続けるには必要な運営を考えなければいけない
      • 必要なものはチーム
      • デザイナとエンジニアのギャップが一番小さくなる
      • デザインとエンジニアリング両方できる人はいない

Lightning Talks

  • Introduction to Resource Hints
  • atomic designで助かった人たち
  • 祭りから半年たったプロジェクトにジョインしてみた
  • 最近のお仕事について

Introduction to Resource Hints

atomic designで助かった人たち

  • 登壇者: @becyn

  • デザインを5つのコンポーネントに分割する

  • シンプルな考え
  • デザインが統一されやすい
  • デザイナと仲良くなれる

祭りから半年たったプロジェクトにジョインしてみた

  • 登壇者: @asukaleido

  • 辛いこと多い

  • コードの品質 != サービスの品質
  • なぜか
  • 思想が一貫する
  • フレームワークを使っていない => 思想が強制されない

UI実装の最高とa11y

  • 登壇者: @ahomu

  • 残念なデザインとは?

    • 色々あるがコードが残念toka
  • 使えないをなくしたい
    • 実装が貧弱
    • クライアントがプア
  • 使えない は 使いづらい の延長線上

アメブロフロント刷新にみる ひかりとつらみ

  • 登壇者: @kouhin @herablog

関連資料 developers.cyberagent.co.jp

なぜ

  • PVが落ちた
  • 特に月末
  • 表示速度が他に比べて遅い
  • バックエンドがAPI化されていた

ゴール

  • 表示速度を開演
  • システムのモダン
  • UXが今後10年戦えるUX
    • 表示速度はWebUXを支える最も重要
    • ダンなエコシステムは、いいアプリを作るために必要

表示速度改善

  • コンセプト決める

    • 速度を図る
    • SpeedCurve
  • HTMLのサイズ減らす

    • SSR(サーバーサイドレンドリング) SPA 共存
    • LazyLoad
      • HTML20%減
  • ReactのrenderToString() 遅い
    • キャッシュ最適化

 システムモダン

  • exampleアプリのように作る

    • 正しいものを正しくつかう
  • React with Redux

  • CSS Modules
    • css-loader
    • スコープが切れる
    • 影響範囲が絞れる
  • Atmic Design
    • 状態と処理を持つContainerと表示だけをするContainer
  • Babel
    • 決まっている未来は早めに試そう
    • async/await
  • ESLint/Stylelint
    • 好みはあるがルールを統一して一貫生を保つ
  • CI
    • CirculeCI
  • Docker
    • Node.jsのポータビリティー
    • Nodeのアップデートが観覧
      • Dockerfileを変えるだけ
      • 最新のNodeを使う
  • OSSっぽく開発
    • 外でもそのまま使える技術を

UX

  • No more ガタン
    • 誤タップはモバイルUXで最悪の出来事
  • コンテンツファースト
    • 横幅をMAXまで使う

つらみ

  • Reduxむずい
    • Action/Reducer理解するまで時間かかる
  • Lintがスパルタ
    • 最初はCIでエラー
  • アメブロモジュール多すぎ
  • 周辺技術多すぎ

結論

  • みんながんばろ

感想

今回は初参加させていただいたfrontrendですが、非常に濃い内容でLTも30分枠で聞きたい内容ばかりでした!

発表資料も今後アップされて行くと思いますが、FRESH!で生放送されていた動画があるようなので、是非ご覧になってみてください!私のまとめ記事の1000倍は内容があると思います!!

さて、勉強会のタイトルでもあるように自分なりに今日のお話を聞いて frontのtrend を感じました、それは

  • デザイン・システム
  • Atomic Design

です!

デザイン・システムは今までCSSの便利ライブラリくらいに捉えていたBootstrapがエンジニア、デザイナ間での共通言語として、どんな目的のために利用して行くべきなのか。自分の中で明確になりました。

また、LTで @asukaleido さんの仰っていた「コードの質とユーザビリティーは必ずとも一致しない。なぜならコードに統一された意思があるから。」というプロダクトのコードに統一された意思をもたらす面でも役立つのかなと思いました。

Atomic Designは画面のコンポーネントを最小単位から順に5つの大きさに分類する。というもので、コンポーネントの再利用性・デザインの向上などの恩恵もあるようでしたが、自分はデザイナとの共存が一番のメリットに感じました。

少し話は進んで、アメブロの @herablog さんのお話にもあったように、Atomic DesignをReactやVue, AngularといったJSライブラリ群とどう共存させるか。というのも興味が湧いて来ました。

乱暴な言い方ですが、デザイン・システムもAtomic Designも

  • デザイナ・エンジニアの共存性向上
  • UI/UXの改善
    • つまりエンドユーザーにより高い価値のものを届ける

という点においては、達成したいものは同じなように感じました。そしてこれが今の、ひいてはこれからのfrontendの課題なのではとも感じました。