Web Design Process for The Future

5,882 views

Published on

WCAF vol.10 こもり資料

0 Comments
81 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,882
On SlideShare
0
From Embeds
0
Number of Embeds
201
Actions
Shares
0
Downloads
0
Comments
0
Likes
81
Embeds 0
No embeds

No notes for slide

Web Design Process for The Future

  1. 1. Web Design Process for The Future2013.05.18 こもりまさあきWCAF vol.10
  2. 2. 簡単に自己紹介こもりまさあき1972年生まれのフリーランス。90年代前半から都内のDTP系デザイン会社にてアルバイトをはじめ、大学卒業後そのまま正社員に。入出力業務、デザイン業務、ネットワーク関連業務に並行して従事後、2001年会社を退職しフリーランスの道へ。業務内容や立ち位置が異なるので、職域的な肩書きはなし近著に『基礎から覚える、深く理解できる。 Webデザインの新しい教科書』『レスポンシブ・ウェブデザイン標準ガイド』、などTwitter:@cipher/@proteanbmInstagram:@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 Dayhttp://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 andgrowth is universality. ••• And it should be accessible from anykind of hardware that can connect to the Internet: stationary ormobile, 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-webby 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 contentautomatically 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
  21. 21. 接続するデバイスが増え、利用する状況も人それぞれ
  22. 22. 複数のデバイスをシーケンシャルに使う人たちもいる
  23. 23. PCとそれ以外でコンテンツに相違があったら困ることも
  24. 24. ©Brad Frosthttp://bradfrostweb.com/
  25. 25. ©Brad Frosthttp://bradfrostweb.com/
  26. 26. ©Brad Frosthttp://bradfrostweb.com/
  27. 27. デバイスを基準に最適化するのではなく、何で見ても大丈夫にした方が良いのでは?
  28. 28. 利用状況にあわせた柔軟な配信ができたら…
  29. 29. その答えのひとつが、Responsive Web Design
  30. 30. Responsiveだと、コンテンツが…画像がさ…って、それって表面的なとこしかみてないからじゃないの?
  31. 31. 解決策はある。もっと違う部分に目を向けよう
  32. 32. Content ChoreographyContent Choreograpyhttp://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 designhttp://uk.rimmellondon.com/
  39. 39. この他にもいろいろな技術がどんどん採り入れられている
  40. 40. Webサイトの表示スピードも大事だし
  41. 41. 世界のWebサイトは、全然先に進んでるから
  42. 42. TIMEhttp://time.com/time/
  43. 43. Delicioushttp://deliciuos.com/
  44. 44. Microsofthttp://www.microsoft.com/en-us/default.aspx
  45. 45. glooplehttp://www.gloople.co.uk/
  46. 46. RIMMELhttp://uk.rimmellondon.com/
  47. 47. Atmosphere Mapshttp://www.atmospheremaps.com/
  48. 48. ただレイアウトが切り替わる手法じゃないのよ
  49. 49. もう少し本質的なところを見た方がいいね
  50. 50. さて、未来の話をしましょう
  51. 51. Google Glasshttp://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 ?StandardRetina
  63. 63. Retinaとか高解像度のデバイスが出てきてる
  64. 64. “Photoshop is repeating yourself. Ok, so you’ve spent 3 days on amockup in Photoshop. Now what? Now I have to make it all overagain 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, thenspend 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-photoshopby Jason Fried
  65. 65. Dont 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 canproduce minor discrepancies between comps of the same page atdifferent breakpoints.Case Study: Responsive Design for Time.comhttp://appendto.com/case-study/responsive-design-time-comby 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 Choreographyhttp://trentwalton.com/2011/07/14/content-choreography/
  93. 93. “We’ve found that the best way forward is to pull all members of ateam together to design, build, test and then evaluate in multiplequick rounds.Content Choreographyhttp://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. Susyhttp://susy.oddbird.net/
  113. 113. Bootstraphttp://twitter.github.io/bootstrap/
  114. 114. Foundation 4http://foundation.zurb.com/
  115. 115. 使ってみたいけど、うまく使える自信がない?
  116. 116. ピクセルベースのカンプを再現するフローには向かない
  117. 117. 動くかどうかわからない図面より、先に動くものを作る
  118. 118. 話はそれからだ。実装サイドが頑張れば済むものでもない
  119. 119. デザインやレイアウトのためのCSSは、どんどん複雑に
  120. 120. 効率よく管理、実装するためにCSSプリプロセッサを使う
  121. 121. LESShttp://lesscss.org/
  122. 122. Sasshttp://sass-lang.com/
  123. 123. Stylushttp://learnboost.github.io/stylus/
  124. 124. 変数や数式を使って、複雑化するCSSも効率よく管理
  125. 125. Scalable and Modular Architecture for CSShttp://smacss.com/
  126. 126. <a class="btn btn-primary btn-large">Learn more </a>ボタンの基本スタイルボタン青くしてボタン大きくして
  127. 127. サイトの規模が大きくなっても、問題ないような設計を
  128. 128. Dont Repeat Yourself
  129. 129. そして、いずれかのタイミングでStyle Guideを
  130. 130. Pearshttp://pea.rs/
  131. 131. Style Guideに則れば、決まりを守るだけで同じになる
  132. 132. KSShttp://warpspire.com/kss/styleguides/
  133. 133. StyleDoccohttp://jacobrask.github.io/styledocco/
  134. 134. Kaleihttp://kaleistyleguide.com/
  135. 135. 最初の設計とドキュメンテーションが大事
  136. 136. さらに、何でもCMSで作れば効率が良いわけでもない
  137. 137. DBからデータを引っ張らなくてもいいような案件
  138. 138. Static Site Generatorを使った方が、はるかに楽…
  139. 139. Jekyllhttp://jekyllrb.com/
  140. 140. Servehttp://get-serve.com/
  141. 141. DocPadhttp://docpad.org/
  142. 142. rootshttp://roots.cx/
  143. 143. コンテンツは、MarkdownやJSONで用意して
  144. 144. Static Site Generator側でウォッチ、ビルド&デプロイ
  145. 145. FTPクライアントってなんでしたっけ?
  146. 146. そのベースとなるHTMLは、テンプレートエンジンで
  147. 147. Hamlhttp://haml.info/
  148. 148. Jadehttp://jade-lang.com/
  149. 149. Handlebars.jshttp://handlebarsjs.com/
  150. 150. HTMLですら、変数を定義して自動的に生成させる
  151. 151. 実は、ここまでのいろいろを覚えると良いことがある
  152. 152. Webが動的になるにつれ、さらに注目されるJavaScript
  153. 153. AngularJShttp://angularjs.org/
  154. 154. Backbone.jshttp://backbonejs.org/
  155. 155. Knockouthttp://knockoutjs.com/
  156. 156. JSフレームワークを使って、Webアプリも簡単に
  157. 157. ここでもHTMLテンプレートやプリプロセッサが活躍
  158. 158. エンジニアの使うフレームワークにも構造的に似てる
  159. 159. いまから慣れておいた方が仕事の幅も拡がるでしょう
  160. 160. Delicioushttps://delicious.com/
  161. 161. Deliciousは、Backbone.js + Bootstrap
  162. 162. Pitchforkhttp://pitchfork.com/
  163. 163. Pitchforkは、Backbone.js + WordPress
  164. 164. スクリーンショットだって、制作の合間にJavaScriptで
  165. 165. CasperJShttp://casperjs.org/
  166. 166. そうすれば、デザインカンプとかいらなくない?
  167. 167. 必要な技術を適宜組み合わせて、最良の結果を得る
  168. 168. そんな制作に必要なツールは、パッケージで管理する時代
  169. 169. npmhttp://npmjs.org/
  170. 170. Bundlerhttp://gembundler.com/
  171. 171. Composerhttp://getcomposer.org/
  172. 172. Bowerhttp://bower.io/
  173. 173. 面倒なタスクは、コンピュータにお願いしてしまう
  174. 174. Grunthttp://gruntjs.com/
  175. 175. サイト制作の箱作りの段階から、自動化することもできる
  176. 176. Yeomanhttp://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. PLTTShttp://pltts.me/
  191. 191. “From Pencil to finished Product in 8 hoursFrom Pencil to finished Product in 8 hourshttp://vslck.im/articles/pencil-to-productby Dominik Schmidt
  192. 192. 最新の技術やワークフローであればできるってこと
  193. 193. そのためにはどうすればいい?
  194. 194. 本日のまとめ•増え続けるデバイスへの対応を考えたら当たり前•いまあるワークフローが適切か、変えられるか•これまでの無駄をなくし、これからの仕事をスムーズに
  195. 195. 本日はありがとうございました

×