webアプリのマークアップ、どうすればいいの？

Webアプリのマークアップ、どうすればいいの？

2013/03/19(火) html5nagoya#2

13年3月23日土曜日

今日しない話


今日しない話

•ネイティブアプリから見たWebアプリの話


今日しない話


• Webアプリの厳密な定義の話


今日しない話


• Webアプリの厳密な定義の話

•聞くだけで簡単に作れるようになる魔法のメソッドの話


今日はWebサイト中心に作って来た人向けの話



• 最近Webアプリってよく聞くけど作ったことない




• JavaScriptとかまだまだ勉強中だし




• JavaScriptとかまだまだ勉強中だし

•どう考えればいいの？Webサイトと何が違うの？


今日言いたいことは、


これからのマークアップは


マークアップエンジニアだけでは

なかなかに難しい


各工程で常に機能単位で考え、イメージの共有をし、


小さく保ちながら作っていくことが


(少なくともWebアプリには)

求められるのでは？


と、思ったので、考えてみました

　　　　　　・・・という話です


Webアプリのマークアップ、どうすればいいの？

2013/03/19(火) html5nagoya#2


目次

1.WebサイトとWebアプリの違うところを、色んな切り口で見てみる

2.協業前提の考え方

3.押さえたいポイント

4.まとめ


※ 初はつまらない話なのでちょっと我慢してね


WebサイトとWebアプリの違うところを、色んな切り口で見てみる


終成果物(production)

• 例：Webサイトの中にGoogle Maps API を埋め込む例

• http://www.e-quakes.pref.shizuoka.jp/shiraberu/map/maps.html

• Googleのユーザー事例に載っていたので引用

• http://www.google.co.jp/enterprise/case_studies/shizuoka.html


http://www.e-quakes.pref.shizuoka.jp/shiraberu/map/maps.html




http://www.google.co.jp/enterprise/case_studies/shizuoka.html





•どちらもHTML, CSS, JavaScript中心に作られている



•どちらもHTML, CSS, JavaScript中心に作られている

• WebサイトもWebアプリも、構成要素はほぼ同じ


役割(role)


役割(role)

• Webサイト


役割(role)

• Webサイト

•情報提供、開示、リアルへの導線、窓口など


役割(role)

• Webサイト


•存在しているのが今やもう当たり前


役割(role)

• Webサイト


•存在しているのが今やもう当たり前

•情報の網羅性


役割(role)


役割(role)

• Webアプリ


役割(role)

• Webアプリ

•目的に特化


役割(role)

• Webアプリ

•目的に特化

•（疑似）体験させるコンテンツなど


役割(role)

• Webアプリ

•目的に特化


•インタラクティブ


役割(role)

• Webアプリ

•目的に特化


•インタラクティブ

•やりたいことを実現するために、リアクションを返してくれる


役割(role)


役割(role)

• 求められているものの違い（どちらも重要）


役割(role)


•「これからはWebサイトよりもWebアプリだー」という話ではない


役割(role)


•「これからはWebサイトよりもWebアプリだー」という話ではない

• Webアプリの方は、リアクションを返す分だけ、画面内の変化が激しい(そうでないものも、もちろんある）


技術視点(technology)



• Webサイトが立ち並び始めたころはWebで出来ることは限られていた




•ブラウザの進化によって出来ることが格段に増えた




•ブラウザの進化によって出来ることが格段に増えた

•（割と良くある話）


終成果物• 今までと同じ HTML, CSS, JavaScript

役割• 目的に特化

→リアクション多くなる、画面内の変化

技術視点• 現実的にWebアプリ作れるように

なりつつある

色んな切り口


じゃ、いつやるか？


いやいや、できるところから

少しずつやりましょうよ...


目次




4.まとめ


協業前提の考え方

•じゃあ、いつも通り設計、

•デザイン、

•マークアップ...


•じゃあ、いつも通り設計、

•デザイン、

•マークアップ...


いつも通りやってたらはまっちゃうよ！



• Webサイトは、制作フローがある程度決まってたので問題なかった




•出来ること増えたので、Webアプリを『1人で全部』は難しい場面も出てくる




•出来ること増えたので、Webアプリを『1人で全部』は難しい場面も出てくる

•協業前提で上手くやれる方法を考える


Webサイト脳を少し切り替えてみる


機能単位の考え方



•まず機能単位で考えるところから




•各工程において、要素を小さく切り分ける、小さく保つ




•各工程において、要素を小さく切り分ける、小さく保つ

•小さく保って依存関係を極力減らす



• Webサイト構築のスキルがある人が、Webアプリになると出来なくなるの？




•→そんなことない！





•最終的に出来るものはざっくり同じなので、出来るところたくさんある！





•最終的に出来るものはざっくり同じなので、出来るところたくさんある！

•出来ない機能は、出来る人にお願いする



•じゃあ、機能単位で進めていくにはどう考えていけばいいの？？


目次




4.まとめ


目次



3.押さえたいポイント（本題）

4.まとめ


押さえたいポイント



1.用件定義・設計フェーズ




2.デザインフェーズ





3.マークアップフェーズ





3.マークアップフェーズ

4.フロント側の実装フェーズ（※今日は触れません）


用件定義・設計フェーズ



•ページ単位≠機能単位




•機能単位で考えるくせをつける(実際に手を動かさない役割の人でも)





• せめて何で出来てるかくらいは知っておく





• せめて何で出来てるかくらいは知っておく

•常日頃から、開発者ツールで調べるくせをつける



極端な例で申し訳ありません・・・



• JavaScriptとか書かなかったとしてもどんな機能で構成されているか（大雑把でもいいので）列挙する




•先は長いけど、まずは機能を知るところから




•先は長いけど、まずは機能を知るところから

•あとはその道の詳しい人に任せよう


デザインフェーズ



•Webサイトの一枚絵の考え方を捨てる



•Webサイトの一枚絵の考え方を捨てる

• 後のマークアップにダイレクトに響く


Photoshopの例


Photoshopの例

• 1枚絵のWebサイトでは、ぶっちゃけどの方法を用いても問題なかった


Photoshopの例

• 1枚絵のWebサイトでは、ぶっちゃけどの方法を用いても問題なかった

•ここに、画面内変化が入ってくると話が劇的に変わってくる


Photoshopの例


Photoshopの例

• 上に乗ってる丸いオブジェクトが背景によらず半透明であるべきなら、一番右はダメ (ifの話)


Photoshopの例

• 上に乗ってる丸いオブジェクトが背景によらず半透明であるべきなら、一番右はダメ (ifの話)

• じゃあ、左と真ん中ならOK？


Photoshopの例


Photoshopの例

• 依存関係を無くす


Photoshopの例


•すでに『乗算』というエフェクトを使っている時点で下のオブジェクトに依存してる


Photoshopの例


•すでに『乗算』というエフェクトを使っている時点で下のオブジェクトに依存してる

•別々に変化させる前提なら、まず『乗算』使ってる真ん中はアウト(ifの話)



•デザイン工程で依存関係だらけだと、その後のマークアップに相当響く




•だからこそ、イメージの共有が必要





•背景が変化しただけでもこれだけバリエーションがある





•背景が変化しただけでもこれだけバリエーションがある

• 1枚絵（ページ単位）ではなく、機能単位で考えて小さく保つ



• Q. どうやってイメージの共有する？




• A. スマホUIなら、ワイヤーフレーム書きまくるとか





• A. アニメーション多いなら、絵コンテ書きまくるとか





• A. アニメーション多いなら、絵コンテ書きまくるとか

•一番共有しやすい方法で！


マークアップフェーズ



• 逆に前工程へ働きかけて、イメージの共有を図り、依存関係がないようにする



• 逆に前工程へ働きかけて、イメージの共有を図り、依存関係がないようにする

•ページ単位のマークアップの考え方を捨てる


ページ単位のスタイル


ページ単位のスタイル↓

小単位にバラバラにする



小単位にバラバラにする↓

同じものを共通化



小単位にバラバラにする↓

同じものを共通化↓

機能単位のスタイル



• 常日頃から、『共通部分は？違う部分は？』と問い続ける




• SassとかLESSとか、ツール使えば解決する話じゃない




• SassとかLESSとか、ツール使えば解決する話じゃない

•逆に、前段上手く出来ていれば機能単位は、HTML&CSSの1まとまりの単位になる



•おまけ1

• CSSのセレクタの最初に必ずIDがつくのは、ページ単位で考えてる可能性がある...かも

•バラバラにして共通化してたら、それはきっとclass名になるはず(csslintではWarning出ます）



•おまけ2

• CSSのセレクタがずらずら並ぶのは、要素を小さく保ててないから...かも

•ひょっとして依存してる？

•何か複数の要素で構成されてないか考えてみる、分解してみる


目次




4.まとめ


まとめ


まとめ

•（Webアプリに限らず）Web制作はこれから複雑化するので、予め各工程で要素を小さく保つ


まとめ


•ページ単位ではなく、機能単位で考える


まとめ


•ページ単位ではなく、機能単位で考える

•依存関係を極力減らすために、イメージの共有をする


今、出来る部分がそんなに多くなくても


出来るところをちょっとずつ増やしていこう！


ご清聴ありがとうございました！


webアプリのマークアップ、どうすればいいの？

Technology