実践 大都会式 プロトタイピング&フロントエンド 2014
DESCRIPTION
オープンセミナー2014@岡山 / 2014年5月17日(土) 久保木 博・前川 昌幸 スライド見てもわけわからないかもしれませんが。が。TRANSCRIPT
アウトライン
•自己紹介 •プロトタイピング •サーバサイド •UIデザイン •フロントエンド •まとめ
自己紹介:前川
•Web制作会社勤務(6月末まで以後未定) •マークアップ> フロントエンド> サーバーサイド
最近は本書いたりしてます
自己紹介:久保木
•某Sler勤務 •デザイン>マークアップ>フロントエンド
これは私も参加してます→
コトのはじめ
“こちら側”を知ってもらうには どうすればいいか
何かを作ってその過程を紹介するのはどうか
んじゃ、何か作ってみるか !
アイデア出し
実務ではあまりできないこと
AngularJS Node.JSSketch 3
Grunt
nginx
Express
Jade
Bootstrap-sassMongoDB
Paper PrototypingGithub POPSVG
Web Font
流行ものをつかった何か
•iPhone向け •ソーシャル連携 •ユーザー入力がある
体重記録ウェブアプリ
ソーシャルのアカウント連動して体重を記録する
ザックリフロー
アイデア出し
ペーパープロトタイピング
サーバーサイドUIデザイン
実装
ペーパープロトタイピング
文字通り、紙を使ったプロトタイピング
•パッと書いて共有し、修正もしやすい •イメージを共有するには最適 •いきなりExcelより省コスト
ペーパープロトタイピングパッド
ウェブアプリは動きがある
紙だけでは分かりづらい
POPで紙芝居にしてみる
•画面移動をシミュレート •動かして初めて気付くこともあるPOP
サーバーサイド
nginx(エンジンエックス)
•HTTPDサーバー •処理性能・並行性・メモリ利用の小ささに焦点
nginxとApache
•どちらでもいいかと •メモリ利用量の小ささは魅力に見えるが、ならサーバーを… •nginxは後発な分設定はシンプル
Node.js
•サーバーサイドJavaScript •イベントベース •ノンブロッキングI/O
•たまたまI/Oの概念が無い言語だったのでJavaScriptを採用
•JavaScriptしかもV8(Chromeのエンジン)ということでフロント系技術者のおもちゃ(?)に
express
•Node.js製Webアプリケーションフレームワーク •最近4系がリリース •HTTPDの機能もあるので 今回はアプリケーション・サーバーとして利用
構成
静的ファイル
Express
アプリケーション
リバースプロキシ
Passport
•Node.js製のOpenID/OAuthライブラリ
Jade
•Node.js製テンプレートエンジン
MongoDB
•NoSQL •柔軟で高速 •結合などSQLで便利なことは結構できない •インターフェースはMongoose
UIデザイン
プロトをベースにデザイン
今回はSketchを使用
依頼する場合
•イメージしているモノがあれば事前に伝えておく •サンプルがあると齟齬が少なくなる
フロントエンド実装
•HTML5 / CSS3 •SVG / Web Font •AngularJS •フロント最適化
HTML5
http://www.slideshare.net/dynamis/toward-firefox-os/26# より
•大人の事情でいろいろと解釈が…
今回はHTML5 Formsだけ
Range Number
CSS3
角丸 ドロップシャドウ
画像を使わず表現が豊かに
Bootstrap-sass
•Twitter社謹製のCSSフレームワーク •クラスを付与するだけでそれなりのデザインに
Sass (CSS Preprocessor)
変数や構文などが使えるCSS
@for $i from 1 through 3 { .item-#{$i} { width: 2em * $i; }}
LESS Stylus
SVG / Web Font
画面の高密度化
2倍のピクセルが必要
従来 これから
SVGならスケーラブル
! ! !
大きさや色などの変更がCSSで可能に
"∠
Font Awesome IcoMoon
AngularJS
•Googleが開発しているフロントエンドJavaScript MVWフレームワーク
MVWフレームワーク?
•WはWhatever •MV※の※に議論するのも無駄だからなんでもいいじゃん!の意
•フロントエンドJavaScriptフレームワークではいま一番関心度が高い
•いわゆるシングルページWebアプリケーションに強い •インタラクションは弱め
フロントの最適化
•バックエンドに比べて関心が低い領域
•バックエンドのミリセカンド単位の努力が水の泡になりかねない
フロントの最適化
•DNS問い合わせ •gzip圧縮転送 •リバースプロクシ
DNS問い合わせ
•TTLの調整 •上位への問い合わせが頻繁に→オーバーヘッド •短いままで放置しない
gzip圧縮転送
•Apache/nginxではモジュールあり •転送量が大幅に減少 •負荷には注意
リバースプロクシ
•静的ファイルのリクエストにアプリケーションサーバーのスレッド使わなくて良くね?
フロントの最適化
•リクエスト数の削減 •キャッシュの活用 •ファイルのミニファイ
リクエスト数の削減
•CSS/JavaScriptなどをなるべくまとめる •ページ単独の記述はHTMLに
リクエスト数の削減
•CSS Sprites •DataURI
CSS Sprites
•複数の画像パーツを一枚の画像に入れてCSSで表示する
•リクエスト数の削減には有用 •アクセシビリティに問題
•やり過ぎ注意、本当に注意 •見えなくても意味が通るものなどが基本
•一枚30KB以内に収めるのが目安 •それ以上はリクエストしたほうがマシ
DataURI
•画像データ等をバイナリ文字列で •リクエスト発生しない
•PC向けブラウザで対応していない物があるのでスマートフォン専用などで
•データ量は約1.3倍 •gzip圧縮転送すれば画像時とデータ量が変わらなくなる
•管理は面倒に •レンダリングをブロックするので大きくても数KB単位のもので
キャッシュの活用
•CDNの利用 •Expiresヘッダで更新の無いファイルのキャッシュを長期に指定
ファイルのミニファイ
•画像は効果が大きい •CSS/JavaScriptは「やったった」感でるけど実は言うほどの…
•ツールで自動化が基本 •ソースと成果物の分離 •コンパイルという考え方
で、タスクランナー
Gruntだとgrunt-contrib-connect grunt-contrib-watch grunt-contrib-concat grunt-contrib-compass
grunt-csso grunt-csscomb
grunt-combine-media-queries grunt-autoprefixer grunt-contrib-jshint grunt-contrib-uglify grunt-contrib-imagemin
あくまで 適材適所
ケースバイケース
実際の作業
•各自で適当に作業 •GitHubにPushして、ある程度したらMerge
•ルールを明確にしておく •HTMLのid/class属性の使い方など •今回はng-*を消さないぐらいで緩め
•スムーズにやるには、お互いの領域の理解が必要
まとめ (無理矢理)
UI視点から
•上流から参加できると、いろいろと提案しやすい •デザインするために経緯や過程を知りたい •方眼エクセルはデザイナーのやる気をそぎます
システム視点から
•少なくともプロトタイピングの段階で参加しておく •その段階で放置すると大怪我が待ってる
ありがとうございました !