Web Design Process for The Future
2013.07.27 こもりまさあき
Re:Creator's Seminar Vol. 14
簡単に自己紹介
こもりまさあき
1972年生まれのフリーランス。90年代前半から都内のDTP系
デザイン会社にてアルバイトをはじめ、大学卒業後そのまま正
社員に。入出力業務、デザイン業務、ネットワーク関連業務に
並行して従事後、2001年会社を...
今日お話しすること
•レスポンシブ?デバイス最適化?どっち?
•未来を考えるとワークフローはどうなる?
•そして、次世代のWebデザインプロセスへ
refactoring
プログラムの外部から見た動作を変えずに、
将来の仕様変更に柔軟に対応できるよう、
ソースコードの内部構造を整理しなおすこと
【リファクタリング】
Responsive? or Optimization?
レスポンシブなのか?、デバイス最適化なのか?
最適な配信形態は、コンテンツによって違うもの
アプリって話もある。どっちが良いとか悪いではない
でも、日本はどうも携帯コンテンツ文化を引きずり…ry
“7,000 different device types are used to access Facebook each day.
VP Mike Schroepfer: 7,000 Different Types Of Mobile De...
7,000different device types
次から次に発売されるデバイス、進まない機種変…
Androidめ…
という声も聞かれる昨今
OSのバージョン、ブラウザ、デバイス毎の差異やバグ…
携帯電話コンテンツ制作と同じ轍を踏まなくても…
新規制作にかかるコスト、メンテナンス効率
各々のデバイスに最適化って、現実的に可能なの?
IE6が…とか言ってる場合じゃないよ?
7,000different device types
そもそもWebってどういうものか考えよう
“The primary design principle underlying the Web’s usefulness and
growth is universality. ••• And it should be accessible ...
“If you think about it, responsive layout is not a new thing.
Open a simple HTML file in a web browser, and the content
au...
接続するデバイスが増え、利用する状況も人それぞれ
複数のデバイスをシーケンシャルに使う時代に
PCとそれ以外でコンテンツに相違があったら困ることも
©Brad Frost
http://bradfrostweb.com/
そろそろ過去のモノ
©Brad Frost
http://bradfrostweb.com/
©Brad Frost
http://bradfrostweb.com/
いろいろなデバイスが接続されるようになるだろう
そんな利用状況にあわせた柔軟なコンテンツ配信を
Responsive Web Designというか、Future Friendlyに
Responsiveだと、コンテンツが…画像がさ…
かわいそうに。「皮相の見」ですね…
解決策を知らないだけでいろいろ言わない
Content Choreography
Content Choreograpy
http://trentwalton.com/2011/07/14/content-choreography/
Choreography: バレエやダンスの振り付け
閲覧環境に応じてコンテンツの振る舞いを考える
A technique for re-arranging layouts using CSS in responsive web design
http://www.jordanm.co.uk/lab/contentchoreography
閲覧環境を考えて、よりわかりやすく、より使いやすく
Webサイトの表示スピードも大事
世界のWebサイトは、もっと先を見ながら進んでる最中
TIME
http://time.com/time/
Microsoft
http://www.microsoft.com/en-us/default.aspx
gloople
http://www.gloople.co.uk/
RIMMEL
http://uk.rimmellondon.com/
あるWebサイトで実際に使われている技術や仕組み
Requirejs
LESS
Bower
Node.js
PhantomJS
Web Fonts
Grunt
Responsive Images
Style Guide
JShint
localStorage
Jasmine
Curljs
いろいろな技術がどんどん採り入れられている
Media QueryとかFluid Layoutだけの話じゃないの
使えるものは、総動員すればいいだけ
もう少し本質的なところから考えた方がいい
さて、未来の話をしましょう
Google Glass
http://www.google.com/glass/start/what-it-does/
NYTimes for Leap Motion
https://airspace.leapmotion.com/apps/nytimes-for-leap-motion/
ここまでくると、CSSのTipsとかどうでもよくない?
それよりも、この先情報配信の形がどうなっていくか?
USA Today
http://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.es
http://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...
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 pa...
無理、無理(笑)
スケッチでざっくりワイヤー、そしてモックアップへ
Designing in The Browser
ブラウザで作り上げるのが、いきなり無理だったら
Deciding in The Browser
動かない画面じゃなく、動くモノを見ながら決めていく
視覚表現も大事だけど、先に考えるのはコンテンツのこと
情報をどうやって組み込んで、どういう形で届けるのか
そういうところをまず最初に考えた方がいいよね?
refactoring
そこでひっかかるのが、区分けされすぎた分業体制
決して分業が悪いわけではない
スペシャリストの存在があって完成する仕事ではある
サイトの規模や種類、作るコンテンツ、それぞれ違うもの
右へならえ文化もほどほどに
参考にしつつ、アレンジするぐらいの柔らかさで
自分たちにあったワークフローを考えよう
Content Choreography
http://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 ...
関係者全員の協力が必要。意識改革ができるか
きっとあるはず、必要のないやりとりや時間が
refactoring
The Future Design Process
Webコンテンツ制作・配信の手法は多岐にわたる
定番の幕の内弁当
幕の内弁当って、いらなかったり足りなかったり
足りないままガマンするのがいいのか?
Web制作のツールは、日に日に便利に
年に1回のアップデートじゃなく、週に1回ぐらいでねw
残念ながら、最新のツールはコマンドラインから
コマンドラインを怖がってる場合じゃないし、怖くない
数百もあるPhotoshopの機能を覚えてる方が怖いw
GUIのツールが出るのは、膨大な時間を費やした後
3日かかった仕事が3時間で終われば、別のことができる
単純作業はコンピュータに。人間はアタマを使うことを
refactoring
複雑化しているWeb制作の現場
いきなり作り始めた方が早いこともある
ざっくりとコンテンツを入れてモックアップを作る
そういう時、頼りになるのはフレームワーク
Bootstrap
http://twitter.github.io/bootstrap/
Foundation 4
http://foundation.zurb.com/
Pure
http://purecss.io/
Furatto
icalialabs.github.io/furatto/
Twittstrap
twittstrap.com/twittstrap/
使ってみたけど、うまく扱えなかった?
たぶん、それわかってない
カンプを再構築するフローだと、かえって厄介
動くかどうかわからない図面より、先に動くものを作る
話はそれから。もう実装サイドが頑張れば済む話じゃない
そんな中、CSSの記述はどんどん複雑に…
効率よく管理、実装するためにCSSプリプロセッサを使う
LESS
http://lesscss.org/
Sass
http://sass-lang.com/
Compass
http://compass-style.org/
Stylus
http://learnboost.github.io/stylus/
Roole
http://roole.org/
変数や数式を使って、複雑化するCSSも効率よく管理
Scalable and Modular Architecture for CSS
http://smacss.com/
<a class="btn btn-primary btn-large">Learn more </a>
ボタンの基本スタイル
ボタン青くして
ボタン大きくして
サイトの規模が大きくなっても、問題ないような設計を
Don't Repeat Yourself
そして、どこかのタイミングでStyle Guideを作っておく
Pears
http://pea.rs/
Style Guideに則れば、決まりを守るだけで同じになる
KSS
http://warpspire.com/kss/styleguides/
StyleDocco
http://jacobrask.github.io/styledocco/
Kalei
http://kaleistyleguide.com/
Style Guide Boilerplate
http://bjankord.github.io/Style-Guide-Boilerplate/
最初の設計とドキュメンテーションが大事
DAUX.IO
http://daux.io/
CMSの存在はありがたい。でも、機能過多だったり…
DBからデータを引っ張らなくてもいいような案件
Static Site Generatorを使った方が楽なこともある
Jekyll
http://jekyllrb.com/
Serve
http://get-serve.com/
DocPad
http://docpad.org/
roots
http://roots.cx/
コンテンツは、MarkdownやJSONで用意して
Static Site Generatorでウォッチ、ビルド&デプロイ
えっと、FTPクライアントってなんでしたっけ?
ベースとなるHTMLは、テンプレートエンジンで変換
Haml
http://haml.info/
Slim
http://slim-lang.com/
Jade
http://jade-lang.com/
Handlebars.js
http://handlebarsjs.com/
HTMLですら、変数を定義して自動的に生成させる
世の中には「適材適所」という言葉がある
でも、やっぱりコマンドラインなんでしょ…?
あるよ
Hammer
http://hammerformac.com/
そして、ずっと虐げられてたWindows環境にも朗報
Mixture
http://mixture.io/
Prepros
http://alphapixels.com/prepros/
実は、ここまでのいろいろを覚えると良いことがある
Webが動的になるにつれ、さらに注目されるJavaScript
AngularJS
http://angularjs.org/
Backbone.js
http://backbonejs.org/
Knockout
http://knockoutjs.com/
JavaScriptフレームワークを使ったWeb制作
ここでもHTMLテンプレートやプリプロセッサが活躍
エンジニアの使うフレームワークにも構造的に似てる
Delicious
https://delicious.com/
Deliciousは、Backbone.js + Bootstrap
Pitchfork
http://pitchfork.com/
Pitchforkは、Backbone.js + WordPress
いまから慣れておいた方が仕事の幅も拡がるのでは?
こういうのも形になりつつあるし
Polymer
http://www.polymer-project.org/
<polymer-element name="tk-element-databinding-color">
<template>
This is a <strong>{{owner}}</strong>'s tk-element.
{{owne...
といった感じで、別々のモノがいろいろと繋がる
デバイス幅ごとのスクリーンショットだって簡単に
CasperJS
http://casperjs.org/
$ casperjs screenshots.js http://demosite.dev/
デザインカンプみたいなのが必要なら、途中で撮れば良い
必要な技術を適宜組み合わせて、最良の結果を得る
もうフロントエンドのツールもパッケージで管理
必要なものを必要に応じて、インストール&アップデート
npm
http://npmjs.org/
Bundler
http://gembundler.com/
Composer
http://getcomposer.org/
Bower
http://bower.io/
面倒なタスクは、コンピュータにお願いしてしまう
Grunt
http://gruntjs.com/
ModJS
http://madscript.com/modjs/readme.html
もっと前の箱作りの段階から、自動化することもできる
Automation
http://indigounited.com/automaton/
YEOMAN
http://yeoman.io/
YEOMAN GENERATORS
http://yeoman.io/community-generators.html
コマンドを実行するだけで必要なものが全部揃う
コーヒーでも入れてれば準備完了。あとは作るだけ
時間は有効に。繰り返しの作業はしない
20130727recre_komori_最新_02_new3.zip?
どれが最新ファイル?
あと、ファイルの先祖返り…。誰だー!
無駄
バージョン管理システムの導入を本気で考えよう
たとえ、ぼっち駆動開発(BDD)でも
Gitぐらい使えないと、この先協業もできない
Git
http://git-scm.com/
GitHub
https://github.com/
Bitbucket
https://bitbucket.org/
Beanstalk
http://beanstalkapp.com/
制作手法もワークフローもどんどん変わるもの
ネットワークや技術の発展は、仕事相手の距離さえ縮める
東京だから…地方だから…は関係なく、誰とでもできる
ホスティングだって、どんどん変わっている
Amazon Web Services
http://aws.amazon.com/
AWS S3 Hosting
http://www.awsmicrosite.jp/s3-hosting/
WordPress AMI
http://ja.megumi-cloud.com/
アプリケーションプラットフォームも瞬時に
Heroku
https://www.heroku.com/
Engine Yard
https://www.engineyard.com/
もはや、インフラのことすら気にしない
PLTTS
http://pltts.me/
“From Pencil to finished Product in 8 hours
From Pencil to finished Product in 8 hours
http://vslck.im/articles/pencil-to-...
最新の技術やワークフローであればできるってこと
先にやったもん勝ち
そのためにはどうすればいい?
力の入れどころを間違えないように
はてブとか見てないで、Speaker Deckでもどうぞ
あとね、英語やったほうがいいね
本日のまとめ
•増え続けるデバイスへの対応を考えたら当たり前
•いまあるワークフローが適切か、変えられるか
•これまでの無駄をなくし、これからの仕事をスムーズに
本日はありがとうございました
Re:Cre Vol.14 | Web design process for the future
Re:Cre Vol.14 | Web design process for the future
Upcoming SlideShare
Loading in …5
×

Re:Cre Vol.14 | Web design process for the future

7,256 views

Published on

第14回リクリセミナー「Web制作の未来、あなたの未来」最終版

Published in: Design
0 Comments
75 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,256
On SlideShare
0
From Embeds
0
Number of Embeds
1,241
Actions
Shares
0
Downloads
85
Comments
0
Likes
75
Embeds 0
No embeds

No notes for slide

Re:Cre Vol.14 | Web design process for the future

  1. 1. Web Design Process for The Future 2013.07.27 こもりまさあき Re:Creator's Seminar Vol. 14
  2. 2. 簡単に自己紹介 こもりまさあき 1972年生まれのフリーランス。90年代前半から都内のDTP系 デザイン会社にてアルバイトをはじめ、大学卒業後そのまま正 社員に。入出力業務、デザイン業務、ネットワーク関連業務に 並行して従事後、2001年会社を退職しフリーランスの道へ。業 務内容や立ち位置が異なるので、職域的な肩書きはなし 近著に『基礎から覚える、深く理解できる。 Webデザインの新 しい教科書』『レスポンシブ・ウェブデザイン標準ガイド』、 など Twitter:@cipher/@proteanbm Instagram:@cipher
  3. 3. 今日お話しすること •レスポンシブ?デバイス最適化?どっち? •未来を考えるとワークフローはどうなる? •そして、次世代のWebデザインプロセスへ
  4. 4. refactoring プログラムの外部から見た動作を変えずに、 将来の仕様変更に柔軟に対応できるよう、 ソースコードの内部構造を整理しなおすこと 【リファクタリング】
  5. 5. Responsive? or Optimization?
  6. 6. レスポンシブなのか?、デバイス最適化なのか?
  7. 7. 最適な配信形態は、コンテンツによって違うもの
  8. 8. アプリって話もある。どっちが良いとか悪いではない
  9. 9. でも、日本はどうも携帯コンテンツ文化を引きずり…ry
  10. 10. “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 Day http://techcrunch.com/2012/08/03/vp-mike-schroepfer-7000-different-mobile-devices-access-facebook-every-day/
  11. 11. 7,000different device types
  12. 12. 次から次に発売されるデバイス、進まない機種変…
  13. 13. Androidめ…
  14. 14. という声も聞かれる昨今
  15. 15. OSのバージョン、ブラウザ、デバイス毎の差異やバグ…
  16. 16. 携帯電話コンテンツ制作と同じ轍を踏まなくても…
  17. 17. 新規制作にかかるコスト、メンテナンス効率
  18. 18. 各々のデバイスに最適化って、現実的に可能なの?
  19. 19. IE6が…とか言ってる場合じゃないよ?
  20. 20. 7,000different device types
  21. 21. そもそもWebってどういうものか考えよう
  22. 22. “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 American http://www.scientificamerican.com/article.cfm?id=long-live-the-web by Tim Berners-Lee
  23. 23. “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 default http://blog.andyhume.net/responsive-by-default/ by Andy Hume
  24. 24. 接続するデバイスが増え、利用する状況も人それぞれ
  25. 25. 複数のデバイスをシーケンシャルに使う時代に
  26. 26. PCとそれ以外でコンテンツに相違があったら困ることも
  27. 27. ©Brad Frost http://bradfrostweb.com/
  28. 28. そろそろ過去のモノ
  29. 29. ©Brad Frost http://bradfrostweb.com/
  30. 30. ©Brad Frost http://bradfrostweb.com/
  31. 31. いろいろなデバイスが接続されるようになるだろう
  32. 32. そんな利用状況にあわせた柔軟なコンテンツ配信を
  33. 33. Responsive Web Designというか、Future Friendlyに
  34. 34. Responsiveだと、コンテンツが…画像がさ…
  35. 35. かわいそうに。「皮相の見」ですね…
  36. 36. 解決策を知らないだけでいろいろ言わない
  37. 37. Content Choreography Content Choreograpy http://trentwalton.com/2011/07/14/content-choreography/ Choreography: バレエやダンスの振り付け
  38. 38. 閲覧環境に応じてコンテンツの振る舞いを考える
  39. 39. A technique for re-arranging layouts using CSS in responsive web design http://www.jordanm.co.uk/lab/contentchoreography
  40. 40. 閲覧環境を考えて、よりわかりやすく、より使いやすく
  41. 41. Webサイトの表示スピードも大事
  42. 42. 世界のWebサイトは、もっと先を見ながら進んでる最中
  43. 43. TIME http://time.com/time/
  44. 44. Microsoft http://www.microsoft.com/en-us/default.aspx
  45. 45. gloople http://www.gloople.co.uk/
  46. 46. RIMMEL http://uk.rimmellondon.com/
  47. 47. あるWebサイトで実際に使われている技術や仕組み
  48. 48. Requirejs LESS Bower Node.js PhantomJS Web Fonts Grunt Responsive Images Style Guide JShint localStorage Jasmine Curljs
  49. 49. いろいろな技術がどんどん採り入れられている
  50. 50. Media QueryとかFluid Layoutだけの話じゃないの
  51. 51. 使えるものは、総動員すればいいだけ
  52. 52. もう少し本質的なところから考えた方がいい
  53. 53. さて、未来の話をしましょう
  54. 54. Google Glass http://www.google.com/glass/start/what-it-does/
  55. 55. NYTimes for Leap Motion https://airspace.leapmotion.com/apps/nytimes-for-leap-motion/
  56. 56. ここまでくると、CSSのTipsとかどうでもよくない?
  57. 57. それよりも、この先情報配信の形がどうなっていくか?
  58. 58. USA Today http://usatoday.com/
  59. 59. Is This The Future Of The Airline Website? http://www.f-i.com/fi/airlines/
  60. 60. その未来を想像して、僕たちが今できることは何か?、と
  61. 61. これまでのWebに対する考えを
  62. 62. refactoring
  63. 63. Rethinking Workflow
  64. 64. そんな未来が押し寄せようとしている現代のWeb
  65. 65. いまのワークフローは、これからの時代に対応できるか
  66. 66. 対応するものが増えれば、それだけ制約も増える
  67. 67. 制約がある中で問題解決するのも仕事
  68. 68. Photoshopでカンプを作って、HTML & CSSで再構築?
  69. 69. アタマで思い描いたことが、必ず形にできるわけじゃない
  70. 70. まだ「1px」にこだわったりしてる?
  71. 71. 1pxが1pxじゃないようなこの時代に?
  72. 72. 1px 1px ? Standard Retina
  73. 73. Screensiz.es http://screensiz.es/
  74. 74. “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 37signals http://37signals.com/svn/posts/1061-why-we-skip-photoshop by Jason Fried
  75. 75. Don't Repeat Yourself
  76. 76. 時間は上手に使わないと。やることばっかり増えちゃう
  77. 77. 固定サイズ、ピクセルパーフェクトという呪縛からの解放
  78. 78. 「ページ」という概念ですら、どうなることやら
  79. 79. 紙の置き換え的発想は、Web制作にあってないのだから
  80. 80. refactoring
  81. 81. 「リーン・ホニャララ」とかよく見かける今のご時世
  82. 82. さまざまな環境を視野に入れて、スムーズに制作するには?
  83. 83. 必要なだけ、デバイスサイズにわけたPSDで管理する?
  84. 84. “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.com http://appendto.com/case-study/responsive-design-time-com by appendTo
  85. 85. 無理、無理(笑)
  86. 86. スケッチでざっくりワイヤー、そしてモックアップへ
  87. 87. Designing in The Browser
  88. 88. ブラウザで作り上げるのが、いきなり無理だったら
  89. 89. Deciding in The Browser
  90. 90. 動かない画面じゃなく、動くモノを見ながら決めていく
  91. 91. 視覚表現も大事だけど、先に考えるのはコンテンツのこと
  92. 92. 情報をどうやって組み込んで、どういう形で届けるのか
  93. 93. そういうところをまず最初に考えた方がいいよね?
  94. 94. refactoring
  95. 95. そこでひっかかるのが、区分けされすぎた分業体制
  96. 96. 決して分業が悪いわけではない
  97. 97. スペシャリストの存在があって完成する仕事ではある
  98. 98. サイトの規模や種類、作るコンテンツ、それぞれ違うもの
  99. 99. 右へならえ文化もほどほどに
  100. 100. 参考にしつつ、アレンジするぐらいの柔らかさで
  101. 101. 自分たちにあったワークフローを考えよう
  102. 102. Content Choreography http://trentwalton.com/2011/07/14/content-choreography/
  103. 103. “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 Choreography http://trentwalton.com/2011/07/14/content-choreography/ by Trent Walton
  104. 104. 関係者全員の協力が必要。意識改革ができるか
  105. 105. きっとあるはず、必要のないやりとりや時間が
  106. 106. refactoring
  107. 107. The Future Design Process
  108. 108. Webコンテンツ制作・配信の手法は多岐にわたる
  109. 109. 定番の幕の内弁当
  110. 110. 幕の内弁当って、いらなかったり足りなかったり
  111. 111. 足りないままガマンするのがいいのか?
  112. 112. Web制作のツールは、日に日に便利に
  113. 113. 年に1回のアップデートじゃなく、週に1回ぐらいでねw
  114. 114. 残念ながら、最新のツールはコマンドラインから
  115. 115. コマンドラインを怖がってる場合じゃないし、怖くない
  116. 116. 数百もあるPhotoshopの機能を覚えてる方が怖いw
  117. 117. GUIのツールが出るのは、膨大な時間を費やした後
  118. 118. 3日かかった仕事が3時間で終われば、別のことができる
  119. 119. 単純作業はコンピュータに。人間はアタマを使うことを
  120. 120. refactoring
  121. 121. 複雑化しているWeb制作の現場
  122. 122. いきなり作り始めた方が早いこともある
  123. 123. ざっくりとコンテンツを入れてモックアップを作る
  124. 124. そういう時、頼りになるのはフレームワーク
  125. 125. Bootstrap http://twitter.github.io/bootstrap/
  126. 126. Foundation 4 http://foundation.zurb.com/
  127. 127. Pure http://purecss.io/
  128. 128. Furatto icalialabs.github.io/furatto/
  129. 129. Twittstrap twittstrap.com/twittstrap/
  130. 130. 使ってみたけど、うまく扱えなかった?
  131. 131. たぶん、それわかってない
  132. 132. カンプを再構築するフローだと、かえって厄介
  133. 133. 動くかどうかわからない図面より、先に動くものを作る
  134. 134. 話はそれから。もう実装サイドが頑張れば済む話じゃない
  135. 135. そんな中、CSSの記述はどんどん複雑に…
  136. 136. 効率よく管理、実装するためにCSSプリプロセッサを使う
  137. 137. LESS http://lesscss.org/
  138. 138. Sass http://sass-lang.com/
  139. 139. Compass http://compass-style.org/
  140. 140. Stylus http://learnboost.github.io/stylus/
  141. 141. Roole http://roole.org/
  142. 142. 変数や数式を使って、複雑化するCSSも効率よく管理
  143. 143. Scalable and Modular Architecture for CSS http://smacss.com/
  144. 144. <a class="btn btn-primary btn-large">Learn more </a> ボタンの基本スタイル ボタン青くして ボタン大きくして
  145. 145. サイトの規模が大きくなっても、問題ないような設計を
  146. 146. Don't Repeat Yourself
  147. 147. そして、どこかのタイミングでStyle Guideを作っておく
  148. 148. Pears http://pea.rs/
  149. 149. Style Guideに則れば、決まりを守るだけで同じになる
  150. 150. KSS http://warpspire.com/kss/styleguides/
  151. 151. StyleDocco http://jacobrask.github.io/styledocco/
  152. 152. Kalei http://kaleistyleguide.com/
  153. 153. Style Guide Boilerplate http://bjankord.github.io/Style-Guide-Boilerplate/
  154. 154. 最初の設計とドキュメンテーションが大事
  155. 155. DAUX.IO http://daux.io/
  156. 156. CMSの存在はありがたい。でも、機能過多だったり…
  157. 157. DBからデータを引っ張らなくてもいいような案件
  158. 158. Static Site Generatorを使った方が楽なこともある
  159. 159. Jekyll http://jekyllrb.com/
  160. 160. Serve http://get-serve.com/
  161. 161. DocPad http://docpad.org/
  162. 162. roots http://roots.cx/
  163. 163. コンテンツは、MarkdownやJSONで用意して
  164. 164. Static Site Generatorでウォッチ、ビルド&デプロイ
  165. 165. えっと、FTPクライアントってなんでしたっけ?
  166. 166. ベースとなるHTMLは、テンプレートエンジンで変換
  167. 167. Haml http://haml.info/
  168. 168. Slim http://slim-lang.com/
  169. 169. Jade http://jade-lang.com/
  170. 170. Handlebars.js http://handlebarsjs.com/
  171. 171. HTMLですら、変数を定義して自動的に生成させる
  172. 172. 世の中には「適材適所」という言葉がある
  173. 173. でも、やっぱりコマンドラインなんでしょ…?
  174. 174. あるよ
  175. 175. Hammer http://hammerformac.com/
  176. 176. そして、ずっと虐げられてたWindows環境にも朗報
  177. 177. Mixture http://mixture.io/
  178. 178. Prepros http://alphapixels.com/prepros/
  179. 179. 実は、ここまでのいろいろを覚えると良いことがある
  180. 180. Webが動的になるにつれ、さらに注目されるJavaScript
  181. 181. AngularJS http://angularjs.org/
  182. 182. Backbone.js http://backbonejs.org/
  183. 183. Knockout http://knockoutjs.com/
  184. 184. JavaScriptフレームワークを使ったWeb制作
  185. 185. ここでもHTMLテンプレートやプリプロセッサが活躍
  186. 186. エンジニアの使うフレームワークにも構造的に似てる
  187. 187. Delicious https://delicious.com/
  188. 188. Deliciousは、Backbone.js + Bootstrap
  189. 189. Pitchfork http://pitchfork.com/
  190. 190. Pitchforkは、Backbone.js + WordPress
  191. 191. いまから慣れておいた方が仕事の幅も拡がるのでは?
  192. 192. こういうのも形になりつつあるし
  193. 193. Polymer http://www.polymer-project.org/
  194. 194. <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
  195. 195. といった感じで、別々のモノがいろいろと繋がる
  196. 196. デバイス幅ごとのスクリーンショットだって簡単に
  197. 197. CasperJS http://casperjs.org/
  198. 198. $ casperjs screenshots.js http://demosite.dev/
  199. 199. デザインカンプみたいなのが必要なら、途中で撮れば良い
  200. 200. 必要な技術を適宜組み合わせて、最良の結果を得る
  201. 201. もうフロントエンドのツールもパッケージで管理
  202. 202. 必要なものを必要に応じて、インストール&アップデート
  203. 203. npm http://npmjs.org/
  204. 204. Bundler http://gembundler.com/
  205. 205. Composer http://getcomposer.org/
  206. 206. Bower http://bower.io/
  207. 207. 面倒なタスクは、コンピュータにお願いしてしまう
  208. 208. Grunt http://gruntjs.com/
  209. 209. ModJS http://madscript.com/modjs/readme.html
  210. 210. もっと前の箱作りの段階から、自動化することもできる
  211. 211. Automation http://indigounited.com/automaton/
  212. 212. YEOMAN http://yeoman.io/
  213. 213. YEOMAN GENERATORS http://yeoman.io/community-generators.html
  214. 214. コマンドを実行するだけで必要なものが全部揃う
  215. 215. コーヒーでも入れてれば準備完了。あとは作るだけ
  216. 216. 時間は有効に。繰り返しの作業はしない
  217. 217. 20130727recre_komori_最新_02_new3.zip?
  218. 218. どれが最新ファイル?
  219. 219. あと、ファイルの先祖返り…。誰だー!
  220. 220. 無駄
  221. 221. バージョン管理システムの導入を本気で考えよう
  222. 222. たとえ、ぼっち駆動開発(BDD)でも
  223. 223. Gitぐらい使えないと、この先協業もできない
  224. 224. Git http://git-scm.com/
  225. 225. GitHub https://github.com/
  226. 226. Bitbucket https://bitbucket.org/
  227. 227. Beanstalk http://beanstalkapp.com/
  228. 228. 制作手法もワークフローもどんどん変わるもの
  229. 229. ネットワークや技術の発展は、仕事相手の距離さえ縮める
  230. 230. 東京だから…地方だから…は関係なく、誰とでもできる
  231. 231. ホスティングだって、どんどん変わっている
  232. 232. Amazon Web Services http://aws.amazon.com/
  233. 233. AWS S3 Hosting http://www.awsmicrosite.jp/s3-hosting/
  234. 234. WordPress AMI http://ja.megumi-cloud.com/
  235. 235. アプリケーションプラットフォームも瞬時に
  236. 236. Heroku https://www.heroku.com/
  237. 237. Engine Yard https://www.engineyard.com/
  238. 238. もはや、インフラのことすら気にしない
  239. 239. PLTTS http://pltts.me/
  240. 240. “From Pencil to finished Product in 8 hours From Pencil to finished Product in 8 hours http://vslck.im/articles/pencil-to-product by Dominik Schmidt
  241. 241. 最新の技術やワークフローであればできるってこと
  242. 242. 先にやったもん勝ち
  243. 243. そのためにはどうすればいい?
  244. 244. 力の入れどころを間違えないように
  245. 245. はてブとか見てないで、Speaker Deckでもどうぞ
  246. 246. あとね、英語やったほうがいいね
  247. 247. 本日のまとめ •増え続けるデバイスへの対応を考えたら当たり前 •いまあるワークフローが適切か、変えられるか •これまでの無駄をなくし、これからの仕事をスムーズに
  248. 248. 本日はありがとうございました

×