Post on 06-May-2015
description
Web Design Process for The Future2013. 07. 27 こもりまさあき
Re:Creator's Seminar Vol. 14
簡単に自己紹介
こもりまさあき
1972年生まれのフリーランス。90年代前半から都内のDTP系デザイン会社にてアルバイトをはじめ、大学卒業後そのまま正社員に。入出力業務、デザイン業務、ネットワーク関連業務に並行して従事後、2001年会社を退職しフリーランスの道へ。業務内容や立ち位置が異なるので、職域的な肩書きはなし
近著に『基礎から覚える、深く理解できる。 Webデザインの新しい教科書』『レスポンシブ・ウェブデザイン標準ガイド』、など
Twitter: @cipher / @proteanbmInstagram: @cipher
今日お話しすること
•レスポンシブ？デバイス最適化？どっち？
•未来を考えるとワークフローはどうなる？
•そして、次世代のWebデザインプロセスへ
refactoringプログラムの外部から見た動作を変えずに、将来の仕様変更に柔軟に対応できるよう、ソースコードの内部構造を整理しなおすこと
【リファクタリング】
Responsive? or Optimization?
レスポンシブなのか？、デバイス最適化なのか？
最適な配信形態は、コンテンツによって違うもの
アプリって話もある。どっちが良いとか悪いではない
でも、日本はどうも携帯コンテンツ文化を引きずり…ｒｙ
“7,000 different device types are used to access Facebook each day.
VP Mike Schroepfer: 7,000 Different Types Of Mobile Devices Access Facebook Every Dayhttp://techcrunch.com/2012/08/03/vp-mike-schroepfer-7000-different-mobile-devices-access-facebook-every-day/
7,000 different device types
次から次に発売されるデバイス、進まない機種変…
Androidめ…
という声も聞かれる昨今
OSのバージョン、ブラウザ、デバイス毎の差異やバグ…
携帯電話コンテンツ制作と同じ轍を踏まなくても…
新規制作にかかるコスト、メンテナンス効率
各々のデバイスに最適化って、現実的に可能なの？
IE6が…とか言ってる場合じゃないよ？
7,000 different device types
そもそもWebってどういうものか考えよう
“The primary design principle underlying the Web’s usefulness and growth is universality. ••• And it should be accessible from any kind of hardware that can connect to the Internet: stationary or mobile, small screen or large.
Long Live the Web: A Call for Continued Open Standards and Neutrality: Scientific Americanhttp://www.scientificamerican.com/article.cfm?id=long-live-the-web
by Tim Berners-Lee
“If you think about it, responsive layout is not a new thing. Open a simple HTML file in a web browser, and the content automatically adapts to fit the width of that browser. The web is responsive on its own—by default.
Responsive by defaulthttp://blog.andyhume.net/responsive-by-default/
by Andy Hume
接続するデバイスが増え、利用する状況も人それぞれ
複数のデバイスをシーケンシャルに使う時代に
PCとそれ以外でコンテンツに相違があったら困ることも
そろそろ過去のモノ
いろいろなデバイスが接続されるようになるだろう
そんな利用状況にあわせた柔軟なコンテンツ配信を
Responsive Web Designというか、Future Friendlyに
Responsiveだと、コンテンツが…画像がさ…
かわいそうに。「皮相の見」ですね…
解決策を知らないだけでいろいろ言わない
Content Choreography
Content Choreograpyhttp://trentwalton.com/2011/07/14/content-choreography/
Choreography: バレエやダンスの振り付け
閲覧環境に応じてコンテンツの振る舞いを考える
A technique for re-arranging layouts using CSS in responsive web designhttp://www.jordanm.co.uk/lab/contentchoreography
閲覧環境を考えて、よりわかりやすく、より使いやすく
Webサイトの表示スピードも大事
世界のWebサイトは、もっと先を見ながら進んでる最中
Microsofthttp://www.microsoft.com/en-us/default.aspx
glooplehttp://www.gloople.co.uk/
RIMMELhttp://uk.rimmellondon.com/
あるWebサイトで実際に使われている技術や仕組み
Requirejs
LESS
BowerNode.js
PhantomJS
Web Fonts
Grunt
Responsive Images
Style Guide
JShint
localStorage
Jasmine
Curljs
いろいろな技術がどんどん採り入れられている
Media QueryとかFluid Layoutだけの話じゃないの
使えるものは、総動員すればいいだけ
もう少し本質的なところから考えた方がいい
さて、未来の話をしましょう
Google Glasshttp://www.google.com/glass/start/what-it-does/
NYTimes for Leap Motionhttps://airspace.leapmotion.com/apps/nytimes-for-leap-motion/
ここまでくると、CSSのTipsとかどうでもよくない？
それよりも、この先情報配信の形がどうなっていくか？
USA Todayhttp://usatoday.com/
Is This The Future Of The Airline Website?http://www.f-i.com/fi/airlines/
その未来を想像して、僕たちが今できることは何か？、と
これまでのWebに対する考えを
refactoring
Rethinking Workflow
そんな未来が押し寄せようとしている現代のWeb
いまのワークフローは、これからの時代に対応できるか
対応するものが増えれば、それだけ制約も増える
制約がある中で問題解決するのも仕事
Photoshopでカンプを作って、HTML & CSSで再構築？
アタマで思い描いたことが、必ず形にできるわけじゃない
まだ「1px」にこだわったりしてる？
1pxが1pxじゃないようなこの時代に？
1px 1px ?
Standard
Retina
Screensiz.eshttp://screensiz.es/
“Photoshop is repeating yourself. Ok, so you’ve spent 3 days on a mockup in Photoshop. Now what? Now I have to make it all over again in HTML/CSS. Wasted time.Just build it in HTML/CSS and spend that extra time iterating, not rebuilding. If you’re not fast enough in HTML/CSS, then spend the time learning how to create in HTML/CSS faster. It’s time well spent.
Why we skip Photoshop by Jason Fried of 37signalshttp://37signals.com/svn/posts/1061-why-we-skip-photoshop
by Jason Fried
Don't Repeat Yourself
時間は上手に使わないと。やることばっかり増えちゃう
固定サイズ、ピクセルパーフェクトという呪縛からの解放
「ページ」という概念ですら、どうなることやら
紙の置き換え的発想は、Web制作にあってないのだから
refactoring
「リーン・ホニャララ」とかよく見かける今のご時世
さまざまな環境を視野に入れて、スムーズに制作するには？
必要なだけ、デバイスサイズにわけたPSDで管理する？
“Managing more than 200 PSD files is not only tedious, but it can produce minor discrepancies between comps of the same page at different breakpoints.
Case Study: Responsive Design for Time.comhttp://appendto.com/case-study/responsive-design-time-com
by appendTo
無理、無理（笑）
スケッチでざっくりワイヤー、そしてモックアップへ
Designing in The Browser
ブラウザで作り上げるのが、いきなり無理だったら
Deciding in The Browser
動かない画面じゃなく、動くモノを見ながら決めていく
視覚表現も大事だけど、先に考えるのはコンテンツのこと
情報をどうやって組み込んで、どういう形で届けるのか
そういうところをまず最初に考えた方がいいよね？
refactoring
そこでひっかかるのが、区分けされすぎた分業体制
決して分業が悪いわけではない
スペシャリストの存在があって完成する仕事ではある
サイトの規模や種類、作るコンテンツ、それぞれ違うもの
右へならえ文化もほどほどに
参考にしつつ、アレンジするぐらいの柔らかさで
自分たちにあったワークフローを考えよう
Content Choreographyhttp://trentwalton.com/2011/07/14/content-choreography/
“We’ve found that the best way forward is to pull all members of a team together to design, build, test and then evaluate in multiple quick rounds.
Content Choreographyhttp://trentwalton.com/2011/07/14/content-choreography/
by Trent Walton
関係者全員の協力が必要。意識改革ができるか
きっとあるはず、必要のないやりとりや時間が
refactoring
The Future Design Process
Webコンテンツ制作・配信の手法は多岐にわたる
定番の幕の内弁当
幕の内弁当って、いらなかったり足りなかったり
足りないままガマンするのがいいのか？
Web制作のツールは、日に日に便利に
年に1回のアップデートじゃなく、週に1回ぐらいでねｗ
残念ながら、最新のツールはコマンドラインから
コマンドラインを怖がってる場合じゃないし、怖くない
数百もあるPhotoshopの機能を覚えてる方が怖いｗ
GUIのツールが出るのは、膨大な時間を費やした後
3日かかった仕事が3時間で終われば、別のことができる
単純作業はコンピュータに。人間はアタマを使うことを
refactoring
複雑化しているWeb制作の現場
いきなり作り始めた方が早いこともある
ざっくりとコンテンツを入れてモックアップを作る
そういう時、頼りになるのはフレームワーク
Bootstraphttp://twitter.github.io/bootstrap/
Foundation 4http://foundation.zurb.com/
Furattoicalialabs.github.io/furatto/
Twittstraptwittstrap.com/twittstrap/
使ってみたけど、うまく扱えなかった？
たぶん、それわかってない
カンプを再構築するフローだと、かえって厄介
動くかどうかわからない図面より、先に動くものを作る
話はそれから。もう実装サイドが頑張れば済む話じゃない
そんな中、CSSの記述はどんどん複雑に…
効率よく管理、実装するためにCSSプリプロセッサを使う
LESShttp://lesscss.org/
Sasshttp://sass-lang.com/
Stylushttp://learnboost.github.io/stylus/
変数や数式を使って、複雑化するCSSも効率よく管理
Scalable and Modular Architecture for CSShttp://smacss.com/
<a class="btn btn-primary btn-large">Learn more </a>ボタンの基本スタイル
ボタン青くして
ボタン大きくして
サイトの規模が大きくなっても、問題ないような設計を
Don't Repeat Yourself
そして、どこかのタイミングでStyle Guideを作っておく
Style Guideに則れば、決まりを守るだけで同じになる
KSShttp://warpspire.com/kss/styleguides/
StyleDoccohttp://jacobrask.github.io/styledocco/
Kaleihttp://kaleistyleguide.com/
Style Guide Boilerplatehttp://bjankord.github.io/Style-Guide-Boilerplate/
最初の設計とドキュメンテーションが大事
CMSの存在はありがたい。でも、機能過多だったり…
DBからデータを引っ張らなくてもいいような案件
Static Site Generatorを使った方が楽なこともある
Jekyllhttp://jekyllrb.com/
Servehttp://get-serve.com/
DocPadhttp://docpad.org/
コンテンツは、MarkdownやJSONで用意して
Static Site Generatorでウォッチ、ビルド＆デプロイ
えっと、FTPクライアントってなんでしたっけ？
ベースとなるHTMLは、テンプレートエンジンで変換
Slimhttp://slim-lang.com/
Jadehttp://jade-lang.com/
Handlebars.jshttp://handlebarsjs.com/
HTMLですら、変数を定義して自動的に生成させる
世の中には「適材適所」という言葉がある
でも、やっぱりコマンドラインなんでしょ…？
あるよ
Hammerhttp://hammerformac.com/
そして、ずっと虐げられてたWindows環境にも朗報
Mixturehttp://mixture.io/
Preproshttp://alphapixels.com/prepros/
実は、ここまでのいろいろを覚えると良いことがある
Webが動的になるにつれ、さらに注目されるJavaScript
AngularJShttp://angularjs.org/
Backbone.jshttp://backbonejs.org/
Knockouthttp://knockoutjs.com/
JavaScriptフレームワークを使ったWeb制作
ここでもHTMLテンプレートやプリプロセッサが活躍
エンジニアの使うフレームワークにも構造的に似てる
Delicioushttps://delicious.com/
Deliciousは、Backbone.js + Bootstrap
Pitchforkhttp://pitchfork.com/
Pitchforkは、Backbone.js + WordPress
いまから慣れておいた方が仕事の幅も拡がるのでは？
こういうのも形になりつつあるし
Polymerhttp://www.polymer-project.org/
<polymer-element name="tk-element-databinding-color"> <template> This is a <strong>{{owner}}</strong>'s tk-element. {{owner}} likes the color <span style="color: {{color}}">{{color}}</span>. </template> <script> Polymer('tk-element-databinding-color', { owner: "Daniel", color: "red" }); </script></polymer-element>
<!DOCTYPE html><html> <head> <script src="polymer-all/polymer/polymer.js"></script> <link rel="import" href="tk-element-databinding-color.html"> </head> <body> <tk-element-databinding-color></tk-element-databinding-color> </body></html>
index.html
tk-element-databinding-color.html
といった感じで、別々のモノがいろいろと繋がる
デバイス幅ごとのスクリーンショットだって簡単に
CasperJShttp://casperjs.org/
$ casperjs screenshots.js http://demosite.dev/
デザインカンプみたいなのが必要なら、途中で撮れば良い
必要な技術を適宜組み合わせて、最良の結果を得る
もうフロントエンドのツールもパッケージで管理
必要なものを必要に応じて、インストール＆アップデート
Bundlerhttp://gembundler.com/
Composerhttp://getcomposer.org/
面倒なタスクは、コンピュータにお願いしてしまう
Grunthttp://gruntjs.com/
ModJShttp://madscript.com/modjs/readme.html
もっと前の箱作りの段階から、自動化することもできる
Automationhttp://indigounited.com/automaton/
YEOMAN GENERATORShttp://yeoman.io/community-generators.html
コマンドを実行するだけで必要なものが全部揃う
コーヒーでも入れてれば準備完了。あとは作るだけ
時間は有効に。繰り返しの作業はしない
20130727recre_komori_最新_02_new3.zip？
どれが最新ファイル？
あと、ファイルの先祖返り…。誰だー！
無駄
バージョン管理システムの導入を本気で考えよう
たとえ、ぼっち駆動開発（BDD）でも
Gitぐらい使えないと、この先協業もできない
Githttp://git-scm.com/
GitHubhttps://github.com/
Bitbuckethttps://bitbucket.org/
Beanstalkhttp://beanstalkapp.com/
制作手法もワークフローもどんどん変わるもの
ネットワークや技術の発展は、仕事相手の距離さえ縮める
東京だから…地方だから…は関係なく、誰とでもできる
ホスティングだって、どんどん変わっている
AWS S3 Hostinghttp://www.awsmicrosite.jp/s3-hosting/
WordPress AMIhttp://ja.megumi-cloud.com/
アプリケーションプラットフォームも瞬時に
Herokuhttps://www.heroku.com/
Engine Yardhttps://www.engineyard.com/
もはや、インフラのことすら気にしない
“From Pencil to finished Product in 8 hours
From Pencil to finished Product in 8 hourshttp://vslck.im/articles/pencil-to-product
by Dominik Schmidt
最新の技術やワークフローであればできるってこと
先にやったもん勝ち
そのためにはどうすればいい？
力の入れどころを間違えないように
はてブとか見てないで、Speaker Deckでもどうぞ
あとね、英語やったほうがいいね
本日のまとめ
•増え続けるデバイスへの対応を考えたら当たり前
•いまあるワークフローが適切か、変えられるか
•これまでの無駄をなくし、これからの仕事をスムーズに
本日はありがとうございました