frontend nagoya 参加メモ
Frontend Nagoya に参加してきたのでメモ。
おすすめのES6構文
ES6 modulesとは
import/exportとか便利な構文
最近のブラウザだとトランスパイルせずとも直で動作することができる。
- Google Chrome Canary
- 既存のnpmパッケージは動かない(パスを参照することができない?)
コーディングガイドラインの策定メリット
ガイドラインがないときは自分用を作っておこう
なぜ?
- 作業時間の短縮
- 堅牢なソースを書くため(品質の向上)
- Webサイトの運用をラクにする
ガイドラインを効率的に運用していくには
- ルールを守ること自体を目的としない
- 定期的にルールをアップデートする
命名規則やスニペットをあらかじめ用意しておくことで効率よく作業することができる。
制作チームだと
- エディタの設定を統一しておく
- ベースのファイルセットを用意しておく
既存のもの
- google starter kit
Fluent Design System
Microsoftがリリースした新しいデザインシステム
読み方は「ふるーえんと」
デザインシステム?
- マテリアルデザイン
- ヒューマンインターフェースデザイン
- ライトニングデザインシステム
スタイルガイドとの違い
- 概念を明文化する
ユビキタスコンピューティング
- 2Dだけでなく3D/VRなどの発達
クリエイティビティの再考 - ビジュアルやストーリーを持ったコミュニュケーションの発達
- みんなが発信する時代になった
他のデザインシステムとの大きな違い
多次元のデザインを扱うことができる
詳しくは動画で!
- Light/Depth
- いろいろなUIの関係性を活かす
- Material(素材を活かす)
- モーションを活かす(意味のあるアニメーション)
- スケール
実際の所
- これから取り入れていくのでまだ実例は乏しい
- フィードバックを得て、段階的にガイドラインなどが作り上げられていく
インクルシブデザイン
潜在的なニーズも含めてデザインしていこう
静的サイトジェネレータのすすめ
静的HTMLの作成について
html/css/jsをいかに効率よく作業するか
静的HTMLを作り→システムに渡すようにしている
静的HTMLの共通部
共通部 = デザイン・役割的に共通の部分
- 最初にデザインから切り分けられそうなところを探す
- SSIは面倒(サーバーで動かない、環境が必要)
- PHPはhtmlに戻すのが面倒
- 確認できる環境が必要
↓
静的ファイルは最強
静的サイトジェネレータとは
static gen https://www.staticgen.com/ を見よう
- Jekyll(要ruby)
- middleman(要ruby)
- gulp + metalsmith
- hexo
- harp http://harpjs.com/
環境さえ作ってしまえばあとは使いまわすことができる
テンプレート
書き方は違えど流れは同じ
- Liquid(rubyのエンジン)
- Jinja(Python)
- swig
- Nunjucks https://mozilla.github.io/nunjucks/
- EJS
- Pug
自分にあった環境を作ろう
- 共通部を再確認
- 各自似合うジェネレータを
- テンプレートエンジンも自分にあうものをを使おう
Webの利用しやすさについてのお話
ユーザビリティエンジニアリング
アクセシビリティ
- 知覚
- 操作
- 視界
- 互換性
つまり、利用しやすいWebサイト
ウェブサイトの利用状況
デスクトップとモバイルどちらが多い?
http://gs.statcounter.com/
去年11月でモバイルがデスクトップを抜いている
Chromeが圧倒的に利用ユーザーが多い。
Safari(iOS)が強い
UC browser … 中国のブラウザ
OSはWindowのシェアをAndroidのシェアが抜いている
= モバイルが一般的
- 国内は 60-70%はデスクトップであると思われる
- IEのシェアは20%ほど
- Windowsシェアは60%
- インターネットの普及率は85%
自分の生活を振り返る
- ネイティブアプリを使っていないか?
- その延長線でブラウザを使う
- デスクトップ=腰を据えるイメージ
- PCを開く当面倒臭さ
実態としてのモバイルファーストはすぐそこまで来ている
きっと国内も淘汰される
SEO
- モバイル向けページが優先される
- URLが別の場合も危険
ユーザー体験について
UX = ユーザーの主観的満足度が高い
例えば女子高生
- モバイルデバイスを主軸に
- 通信料に気を配る
- 片手で操作することを前提に
タッチできない = アクセシブルではない
UX 利用しやすさ
体験が重視される
互換性
ブラウザは前方互換である
- Web標準に則る必要はある
- jsは時折破壊的な処理が行われる
後方互換を考えよう
- 答えはない
- サービスによりけり
- IEはどこまで?
Google Apps前提のアプリなら、Google基準がサポート対象になる
指標となるのは
- 利用率
- ブラウザ間で齟齬のないユーザービリティを担保できるもの
エンジニアとの関係
意識できない部分
- キーボードで使えるか
- エラーをユーザーが認識できるか
- 満足しているパフォーマンスをが発揮できているか
エンジニアでも忘れがち
- デザインで表現されない
- ネガティブケースである
- パフォーマンスレベルの提案
受け身でない積極的な介入が形作るもの
目に見えない部分にこそ本質がある
webを取り巻く現状
- Webは一般的なものになり、モバイルに移りつつある
- さまざまなひとが様々なシチュエーションで使っている
- 製品として守らなければいけない品質の最低ラインは上がっている
利用しやすさとUIは非等価
- エンジニアは技術如何によってサービスを容易に殺す
- 必要なのは徹底したユーザー目線
- デザインレベルの良し悪しを図れる段階に持っていくことは案外難しい