Successfully reported this slideshow.

More Related Content

Viewers also liked

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Web Design Process for The Future

  1. 1. Web Design Process for The Future 2013.05.18 こもりまさあき WCAF vol.10
  2. 2. 簡単に自己紹介 こもりまさあき 1972年生まれのフリーランス。90年代前半から都内のDTP系 デザイン会社にてアルバイトをはじめ、大学卒業後そのまま正 社員に。入出力業務、デザイン業務、ネットワーク関連業務に 並行して従事後、2001年会社を退職しフリーランスの道へ。業 務内容や立ち位置が異なるので、職域的な肩書きはなし 近著に『基礎から覚える、深く理解できる。 Webデザインの新 しい教科書』『レスポンシブ・ウェブデザイン標準ガイド』、 など Twitter:@cipher/@proteanbm Instagram:@cipher
  3. 3. 今日お話しすること •Responsiveって実際のところどうなの? •未来を考えるとワークフローはどうなる? •そして、次世代のWebデザインプロセスへ
  4. 4. refactoring プログラムの外部から見た動作を変えずに、 将来の仕様変更に柔軟に対応できるよう、 ソースコードの内部構造を整理しなおすこと 【リファクタリング】
  5. 5. Responsive Web?
  6. 6. Optimization ?、Responsive ?
  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. 携帯電話コンテンツ制作と同じ轍を踏まなくても…
  14. 14. OSの種類とブラウザ、デバイス毎の差異、バグ…
  15. 15. 新規制作にかかるコスト、メンテナンスの効率…
  16. 16. 最適化という選択肢は、現実的に可能だろうか?
  17. 17. IE6が…とか言ってる場合じゃないよ?
  18. 18. そもそもWebってどういうのだろう?
  19. 19. “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
  20. 20. “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
  21. 21. 接続するデバイスが増え、利用する状況も人それぞれ
  22. 22. 複数のデバイスをシーケンシャルに使う人たちもいる
  23. 23. PCとそれ以外でコンテンツに相違があったら困ることも
  24. 24. ©Brad Frost http://bradfrostweb.com/
  25. 25. ©Brad Frost http://bradfrostweb.com/
  26. 26. ©Brad Frost http://bradfrostweb.com/
  27. 27. デバイスを基準に最適化するのではなく、 何で見ても大丈夫にした方が良いのでは?
  28. 28. 利用状況にあわせた柔軟な配信ができたら…
  29. 29. その答えのひとつが、Responsive Web Design
  30. 30. Responsiveだと、コンテンツが…画像がさ…って、 それって表面的なとこしかみてないからじゃないの?
  31. 31. 解決策はある。もっと違う部分に目を向けよう
  32. 32. Content Choreography Content Choreograpy http://trentwalton.com/2011/07/14/content-choreography/ Choreography: バレエやダンスの振り付け
  33. 33. コンテンツの立ち振る舞いを考える
  34. 34. たとえば、こういう情報構造のコンテンツ
  35. 35. スマートフォンでそのまま表示すると
  36. 36. それをこういう風にできたとしたら?
  37. 37. 閲覧状況を考えて、よりわかりやすく、使いやすくする
  38. 38. A technique for re-arranging layouts using CSS in responsive web design http://uk.rimmellondon.com/
  39. 39. この他にもいろいろな技術がどんどん採り入れられている
  40. 40. Webサイトの表示スピードも大事だし
  41. 41. 世界のWebサイトは、全然先に進んでるから
  42. 42. TIME http://time.com/time/
  43. 43. Delicious http://deliciuos.com/
  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. Atmosphere Maps http://www.atmospheremaps.com/
  48. 48. ただレイアウトが切り替わる手法じゃないのよ
  49. 49. もう少し本質的なところを見た方がいいね
  50. 50. さて、未来の話をしましょう
  51. 51. Google Glass http://www.google.com/glass/start/what-it-does/
  52. 52. ここまでくると、CSSのTipsとかどうでもよくない?
  53. 53. それよりも、この先情報配信の形がどうなっていくか?
  54. 54. その未来を想像して、僕たちが今できることは何か?、と
  55. 55. refactoring
  56. 56. Rethinking Workflow
  57. 57. そんな未来が押し寄せようとしている現代のWeb
  58. 58. いまのワークフローは、これからの時代に対応できるか
  59. 59. Photoshopでカンプを作って、HTML/CSSで再構成?
  60. 60. デバイスがこれだけ増えて、考えること一杯なのに?
  61. 61. そろそろ「ピクセル」って概念すらあやういのに?
  62. 62. 1px 1px ? Standard Retina
  63. 63. Retinaとか高解像度のデバイスが出てきてる
  64. 64. “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
  65. 65. Don't Repeat Yourself
  66. 66. 時間は上手に使わないと。やることばっかり増えちゃう
  67. 67. 固定サイズ、ピクセルパーフェクトという呪縛からの解放
  68. 68. 紙の置き換え的発想は、Web制作にあってないのだから
  69. 69. refactoring
  70. 70. 「リーン・…」とかよく見かける今のご時世
  71. 71. さまざまな環境を考えながら、スムーズに制作するには?
  72. 72. “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
  73. 73. 膨大なページ、さまざまなサイズのPSDで作るなんて無理
  74. 74. スケッチでざっくりワイヤー、そしてモックアップへ
  75. 75. Designing in The Browser
  76. 76. ブラウザで作り上げるのが、いきなり無理だったら
  77. 77. Deciding in The Browser
  78. 78. 動かない画面じゃなく、動くモノを見ながら決めていく
  79. 79. 視覚表現も大事だけど、先に考えるのはコンテンツのこと
  80. 80. 情報をどうやって組み込んで、どういう形で届けるのか
  81. 81. そういうところをまず最初に考えよう
  82. 82. refactoring
  83. 83. あと、過度な分業体制も考えもの
  84. 84. 決して分業が悪いわけではない
  85. 85. スペシャリストの存在があって完成する仕事もある
  86. 86. 誰かがやってるからって、自分にすっぽりあてはめない
  87. 87. 右へならえ文化もほどほどに
  88. 88. 僕たちは、同じ形の車を大量生産してるわけではない
  89. 89. サイトの規模や種類、作るコンテンツ、それぞれ違うもの
  90. 90. 参考にしつつ、アレンジするぐらいの柔らかさで
  91. 91. 自分たちにあったこれからのワークフローを考えよう
  92. 92. Content Choreography http://trentwalton.com/2011/07/14/content-choreography/
  93. 93. “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
  94. 94. 関係者全員の協力が必要。意識改革ができるか
  95. 95. refactoring
  96. 96. The Future Design Process
  97. 97. Webコンテンツ制作・配信の手法は多岐にわたる
  98. 98. もはや、ソフトもオールインワンで済まない
  99. 99. 昔はこれだけでもどうにかなった
  100. 100. でも、いまは制作するものにあわせて柔軟に切り替える
  101. 101. Web制作のツールは、日に日に便利になっていく
  102. 102. 年に1回のアップデートじゃなく、週に1回ぐらいでw
  103. 103. 最新の手法は、だいたいコマンドラインから
  104. 104. 怖がってる場合じゃないし、怖くない
  105. 105. 数百もあるPhotoshopの機能を覚えてる方が怖いw
  106. 106. GUIのツールが出る頃は、膨大な時間を費やした後かも
  107. 107. 3日かかった仕事が3時間で終われば、別のことができる
  108. 108. 単純作業はコンピュータにまかせ、生産的なことをしようよ
  109. 109. Webを作るといっても、どんどん複雑化している
  110. 110. ざっくりとコンテンツを入れてモックアップを作るとか
  111. 111. そういう時には、CSSフレームワークを活用するのも手
  112. 112. Susy http://susy.oddbird.net/
  113. 113. Bootstrap http://twitter.github.io/bootstrap/
  114. 114. Foundation 4 http://foundation.zurb.com/
  115. 115. 使ってみたいけど、うまく使える自信がない?
  116. 116. ピクセルベースのカンプを再現するフローには向かない
  117. 117. 動くかどうかわからない図面より、先に動くものを作る
  118. 118. 話はそれからだ。実装サイドが頑張れば済むものでもない
  119. 119. デザインやレイアウトのためのCSSは、どんどん複雑に
  120. 120. 効率よく管理、実装するためにCSSプリプロセッサを使う
  121. 121. LESS http://lesscss.org/
  122. 122. Sass http://sass-lang.com/
  123. 123. Stylus http://learnboost.github.io/stylus/
  124. 124. 変数や数式を使って、複雑化するCSSも効率よく管理
  125. 125. Scalable and Modular Architecture for CSS http://smacss.com/
  126. 126. <a class="btn btn-primary btn-large">Learn more </a> ボタンの基本スタイル ボタン青くして ボタン大きくして
  127. 127. サイトの規模が大きくなっても、問題ないような設計を
  128. 128. Don't Repeat Yourself
  129. 129. そして、いずれかのタイミングでStyle Guideを
  130. 130. Pears http://pea.rs/
  131. 131. Style Guideに則れば、決まりを守るだけで同じになる
  132. 132. KSS http://warpspire.com/kss/styleguides/
  133. 133. StyleDocco http://jacobrask.github.io/styledocco/
  134. 134. Kalei http://kaleistyleguide.com/
  135. 135. 最初の設計とドキュメンテーションが大事
  136. 136. さらに、何でもCMSで作れば効率が良いわけでもない
  137. 137. DBからデータを引っ張らなくてもいいような案件
  138. 138. Static Site Generatorを使った方が、はるかに楽…
  139. 139. Jekyll http://jekyllrb.com/
  140. 140. Serve http://get-serve.com/
  141. 141. DocPad http://docpad.org/
  142. 142. roots http://roots.cx/
  143. 143. コンテンツは、MarkdownやJSONで用意して
  144. 144. Static Site Generator側でウォッチ、ビルド&デプロイ
  145. 145. FTPクライアントってなんでしたっけ?
  146. 146. そのベースとなるHTMLは、テンプレートエンジンで
  147. 147. Haml http://haml.info/
  148. 148. Jade http://jade-lang.com/
  149. 149. Handlebars.js http://handlebarsjs.com/
  150. 150. HTMLですら、変数を定義して自動的に生成させる
  151. 151. 実は、ここまでのいろいろを覚えると良いことがある
  152. 152. Webが動的になるにつれ、さらに注目されるJavaScript
  153. 153. AngularJS http://angularjs.org/
  154. 154. Backbone.js http://backbonejs.org/
  155. 155. Knockout http://knockoutjs.com/
  156. 156. JSフレームワークを使って、Webアプリも簡単に
  157. 157. ここでもHTMLテンプレートやプリプロセッサが活躍
  158. 158. エンジニアの使うフレームワークにも構造的に似てる
  159. 159. いまから慣れておいた方が仕事の幅も拡がるでしょう
  160. 160. Delicious https://delicious.com/
  161. 161. Deliciousは、Backbone.js + Bootstrap
  162. 162. Pitchfork http://pitchfork.com/
  163. 163. Pitchforkは、Backbone.js + WordPress
  164. 164. スクリーンショットだって、制作の合間にJavaScriptで
  165. 165. CasperJS http://casperjs.org/
  166. 166. そうすれば、デザインカンプとかいらなくない?
  167. 167. 必要な技術を適宜組み合わせて、最良の結果を得る
  168. 168. そんな制作に必要なツールは、パッケージで管理する時代
  169. 169. npm http://npmjs.org/
  170. 170. Bundler http://gembundler.com/
  171. 171. Composer http://getcomposer.org/
  172. 172. Bower http://bower.io/
  173. 173. 面倒なタスクは、コンピュータにお願いしてしまう
  174. 174. Grunt http://gruntjs.com/
  175. 175. サイト制作の箱作りの段階から、自動化することもできる
  176. 176. Yeoman http://yeoman.io/
  177. 177. コマンドを実行するだけで必要なものが全部揃う
  178. 178. そうすれば、コンテンツを作るだけに専念できる
  179. 179. 時間は有効に。繰り返しの作業はしない
  180. 180. 20130518wcaf最新_03_new2.zip?
  181. 181. どれが最新ファイル?
  182. 182. あと、ファイルの先祖返り…。誰だー!
  183. 183. 無駄
  184. 184. バージョン管理システムの導入を本気で考えよう
  185. 185. どれが最新?先祖返り?そんなトラブルともさようなら
  186. 186. Gitぐらい使えないと、この先協業もままならない
  187. 187. 制作手法もワークフローもどんどん変わっている
  188. 188. ネットワークや技術の発展は、仕事相手の距離さえ縮める
  189. 189. 東京だから…地方だから…、は関係なく、誰とでもできる
  190. 190. PLTTS http://pltts.me/
  191. 191. “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
  192. 192. 最新の技術やワークフローであればできるってこと
  193. 193. そのためにはどうすればいい?
  194. 194. 本日のまとめ •増え続けるデバイスへの対応を考えたら当たり前 •いまあるワークフローが適切か、変えられるか •これまでの無駄をなくし、これからの仕事をスムーズに
  195. 195. 本日はありがとうございました

×