「html5j Webプラットフォーム部 第20回勉強会」に参加してきました

• 2018/1/31
• https://html5j-webplat.connpass.com/event/76603/

Responsive Web Design もう一度

• Web Directions East 合同会社 代表／UX DAYS TOKYO 主宰／ノーマン・ニールセングループ UXマスター 菊池 崇 様
• https://speakerdeck.com/mantangs/responsive-web-design-mou-du

Responsive Web Design

• 2011年にできた
  • Fluid Image
  • Fluid Frid
  • Media Query
    • 使いすぎるとCSSが膨れ上がってしまうから注意

MediaQueryを使いすぎないようにする

• FontSizeから決めて考えるのがポイント
• remをrootに入れ込む
  • emをコンポーネントで使う
  • そうすればremをいじればほかも変わる
• https://medium.com/@simurai/sizing-web-components-8f433689736f

vw, vh vmin, vmax

• vh
  • viewport height
  • 画面の高さを100としたもの
• vw
  • viewport width
  • 画面の幅を100としたもの
• vmin
  • 縦横短い方の長さを100としたもの
• vmax
  • 縦横長い方の長さを100としたもの
• 最小幅 + xxx という書き方
• Fluid Type
  • 画面幅に応じてスムーズに文字サイズを変化させる
  • 最小と最大のフォントサイズを決めてその範囲でスムーズに切り替えさせる
  • 最小は16pxにすることが多い
  • 計算式がある
  • line-heightも同じ原理で変化させる

CSS Variables

• CSSで変数を定義できる
• logic fold
  • 色とかフォントを最初に定義しておく
• IEでは使えない？

表の幅はどう決まる

• 株式会社ピクセルグリッド　小原 司 様
• https://speakerdeck.com/saucerjp/biao-falsefu-hadoujue-maru

B2Bでのレスポンシブ

• B2CはモバイルファーストだけどB2BはPCが主流
  • モバイルで完結することは少ない
• エクセルとか資料と並べて見たりとか
• 権限で機能制御する
  • 同じ画面でも人によって表示量が違う

B2Cとの違い

• B2C
  • さまざまな人がそれぞれの端末でアクセス
• B2B
  • ひとりの人が複数の端末でアクセス
• 画面幅変えても使用感が変わらないようにしないといけない
  • 画面幅変えても想像しやすい変化をするように設計する
• 行と列が組み変わるパターン
  • 一覧性を犠牲にしやすい
  • 実装保守も大変になりがち
• テーブルの表組みは意外と思い通りにならないことが多い
• 内容が可変になることも多い

幅決定の仕組み

• 固定の仕様はない
• HTML4.01に推奨のアルゴリズムはある
• ブラウザごとの裁量
  • とはいえだいたい一緒
• table-layout
  • auto
    • セル自体、テーブル自体が広がる、遅い
    • https://jsfiddle.net/pLy2489z/3/
  • fixed
    • セル、テーブルの幅は固定で中身がはみ出す、速い
    • https://jsfiddle.net/rxfq8ee7/5/
• 各セルの内容の変化量に応じて幅は計算される
  • 日本語は最悪一行一文字でも表示できるので変化量がとても大きい

初体験で挑む！ぼっちのRWD対応

• 大道寺 寿文 様
• https://www.slideshare.net/ssuserc1257f/rwd-87171466
• https://juji-ya.jp/

PCサイトをレスポンシブ対応した話

• viewportを定義する
• MediaQueryを入れた
• sp/pc独自要素を入れる
• 地道なパーツ単位の調整

失敗したこと

• スマホ実機で見ておくべきだった
  • フォントサイズが全然違ったとか
• デザイナーともっと相談するべきだった
  • 愚直に再現しようとして複雑化した
• 保守しやすいCSSを考えるのをやめてしまった
  • 見通しの良いコード < 納期

どうすればよかったか

• DRY?
• コンポーネント設計?
• 見積もり甘かったんじゃないか?

やってよかったこと

• RWDはqiitaとか調べたらなんとかなった
  • もっと良い設計もあったかも
• やってみないとわかんないことがたくさん
  • PC版chromeのスマホビューは完璧じゃない

<デザイナー×エンジニア> RWDでステップアップLOVE

• html5j Webプラットフォーム部　eegozilla
• https://www.slideshare.net/hirokazuegashira/rwdlove

フロントエンドエンジニアとデザイナー両方やった経験から

エンジニア視点

• 想定デバイスを超えたサイズでどうするか考えるのを忘れがち
  • どうするか認識合わせておかないといけない
• ブレークポイントの境目のmargin(レスポンシブで見た目が変わる境目)
  • 切り替え寸前の時のレイアウトよく見ておかないといけない
• フォントサイズはいろんなデバイスで見ておいた方がよかった
  • vwとかcalcを使って対応できるように
  • 文字の見え方は予め決めておくこと
• 日本語 <-> 英語対応
  • 英語のほうが分量が多い
  • marginとかが微妙に違ってくる
  • 言語ごとにCSSを変えた
  • 2ヶ国語対応する時は工数かかることを事前に伝えておく

デザイナ視点

• PCとスマホを別々にマークアップしてくる
• アニメーション
  • 意図を伝えないと実装してもらえない
• ウィンドウサイズ指定したのにあわせてこない

まとめ

• デザイナはトレンドや勘所を把握してない
• エンジニアはインタラクションやレイアウトに対する意識が弱い
• それぞれがそれぞれの領域に入り込んでいって話せるようにならないと
  • 互いのボーダーを超えられることを恐れてはいけない