🧊

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

ブログ絶対に書くマン枠、結局当日まで空きあったぽいのであえて席を譲ったブログ書くマンとして微妙な悲しみを感じています( ˘ω˘)

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

デザイン・システムとは

  • プロダクトを表すすべてのもの
    • レイアウト
    • グリッド
    • アイコン・色
    • コンポーネント
    • なんしかユーザーが触れるものすべて
  • 既に山ほど種類がある
    • Bootstrap, MaterialDesign, Origami, ...etc
  • UIを言語化してメンテしていくためのもの
    • 短い目で見ても立ち上げの足がかりに
    • 長い目で見ると、共通言語としての基盤となる
  • 利用する側も、開発する側もメリットがある
    • カオスを管理するものとも

どう運営していくかがカギ

  • コレ自体がプロダクトである
  • デザイナーとエンジニアをつなぐもの
    • 小さなデザインの破綻はシステムにも影響を与える
    • デザイナーがコードを学ぶのは実質不可能
  • デザイナーが想定するのはベストケース
  • エンジニアは現実的な実装をしがち
  • 表現しづらいビジュアルの言語化
  • デザインシステムを`Living`なものにするために
  • 自動化などの取り組みを

チームモデル

  • Solitary: 単性
  • Centralized: 中央集権
    • より多くの人のために
    • アクティブな貢献は期待できない
  • Federated: 連合
    • MaterialDesign
    • 各分野のエキスパートによる合議で意思決定
  • この3つだけではないし、どれが良いかはケースバイケース

まとめ

  • デザインシステムが売上に直結するわけではない
    • なぜこれを作り、運用するのかを明確に
  • いいものを作るにはチームで！
  • 大事なのはプロダクトに関する人である

Team Models for Scaling a Design System – EightShapes – Medium

Solitaryって単語で思い出したけど、この記事がベースなんかね？

Introduction to Resource Hints by @1000ch

  • Resource Hints
  • `link`要素で、これから必要になるものを投機的に取得する
    • dns-prefetch
    • preconnect
    • prefetch
    • prerender
  • それぞれコストとリターンがあるので利用ケースを見極めて
  • 今のところChromeでだけ実装されてる
    • chrome://net-internals/#prerender

Atomic Designで助かった人たち by @becyn

  • サーバー -> フロント転向したとき助かった！
  • Atomic Designは、デザインシステムを作っていくための考え方
  • まずはコンポーネントに分けて考えるというタスクから着手できる
  • 作りたいページは、だいたいの部品を組合せてエンジニアが先行して動ける
  • エンジニアとデザイナーとの共通言語として
  • デザインとしても部品から作るので統一される

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

  • 炎上ではないです祭りです
  • ジョインして思う
    • 同じものを表現してるのに別コンポーネントとか
    • 環境起動するとなんか2回ビルド走るとか
  • コードの品質 = サービスの品質ではない
  • AbemaTVではフレームワークを導入してない
  • タイトなスケジュールでブレる仕様の中でなんとかやりきるためには、フレームワークに縛られない方がよいのでは・・！

UI実装の再考とa11y by @ahomu

UI 実装の再考と a11y - Frontrend Vol.8 LT

  • 使えないUIがあるよね
    • マウスじゃないと操作できない`:hover`
    • キーボードで操作できない
    • 見えないアウトライン
  • 「使えない」を減らしたい
    • 実装品質と閲覧品質の両輪があること前提
  • ヒューマンリーダブル && マシンリーダブル
  • アクセシビリティ「対応」とか大層に言わない
  • プロセスとして継続的にやっていく
    • コードレビューの観点にする
    • ユーザーテスト
    • lint, QA, ...etc
  • WCAG Overview ◦ Web Accessibility Initiative ◦ W3C

アメブロフロント刷新にみる ひかりとつらみ by @kouhin / @herablog

何からやるか

  • モダンなエコシステムを使う
    • 時代にあったUX = 使いやすい
  • まず計測した
  • ブログというプロダクトはどうあるべきか
    • テキスト中心
    • SEO
    • 訪問者は一度に複数ページみる
  • SSR x SPA
    • 回遊性はあがった
  • LazyLoad
    • 初期表示に関係ないものは読まない
    • HTMLが20％くらい減量
  • 100ms以内に返したい
    • Reactの`renderToString()`が遅い問題
    • ブログなのでCacheがよく効いた

わかりやすいフロントエンド構成に

  • 使ったのはExampleアプリみたいな顔ぶれ
  • コンポーネント指向
    • Reactでなくても今後も使える
  • Reduxもあいまって純関数でわかりやすく
  • WebpackのCSS ModulesでBEMライクに
  • Atomic Design
  • SSRするのでIsomorphicに
  • Babel
    • ES2015からDecoratorsまで
  • ESLint, Stylelintをお硬く使う
  • CI
  • Docker
    • Node自体のアップデートも簡単

2016年のUX

  • ガタってなるやつやめよ
  • デザインも横100％に
  • アクセシビリティ
    • スクリーンリーダーで読ませてみて改善

取り組みの結果

  • SpeedCurveの指標は50％くらい改善
  • GA的な指標も向上！
  • これからやりたい
    • Desktop ver
    • Markup / a11yの改善
    • デザインシステム
    • http/2, ServiceWorker, ..etc

つらみ

  • Reduxが難しい
    • 学習コストが高い（2ヶ月くらいかかる
  • Lintがスパルタ仕様だった
  • アメブロはモジュールが多すぎる・・
  • モダンにしたけど周辺技術多すぎ

みんながんばりましょう！