CSS Nite ginza 48 [レベニューシェア] めも

Appleストアより宣伝

iPadはぜひ直販店で買って☆早いよ入荷多いよ
迷ってるひとはとりあえず予約だけして要らなかったら取りに来なければOK(笑)

鷹野さん前説

iPadプレゼンだ…
カッコ悪くないですよー

本編:増永玲(バドーゾ)「利益分配型サイト制作はこんなに面白い」

バドーゾという社名は濁点多くて強そうだと思ってつけた(笑)

ウェブサービスをいろいろ運営している
「名前をつけてやる」ロシアドメイン.ru!
Amazonからとってきたジャケに勝手に名前をつけるだけ

趣味です!
ついったボット作成がさいきん多い
時報ボット
笑っていいともゲストお知らせボット #便利そう♪
ブログ「頭ん中」
ビジネスホテル紹介記事を書いた…らはてブが1000ついて今回予約できないよ!

問「ウェブってどうなの?」

  • 新規案件 → 増実感がない
  • リニューアル → Web0.7(笑)的98年に作ったようなサイトはなくなってきている。CMS化はまだまだある
  • 更新作業 → CMS化が進むと減る

この3つはどれも0にはならない、が

…先細り?
5年先10年先、これらで発展は難しい

なぜこうなった?

  • そもそもお金がない
  • 払うだけの価値があるのか? #うむうむ
  • めんどくさい 何もしたくない、更新イヤ、ネット触りたくない

「で、儲 か る の ?」この疑問にキッチり答えられていない

本日のお話の流れ
  1. レベニューシェアって何だ
  2. 実例を見てみよう
  3. 運営にはどんなタイプがあるか?(3パターン)
  4. こんなところが魅力的
  5. こんなところに気をつけたい

レベニューシェアって何だ

(レベニュー)を(シェア)すること
revenue「製品やサービスを売って得たお金を」
share「複数の人で分配すること」

→要するに「山分け」

運営の形態は無数にあるが、今回は
「商品を直接扱う人」⇔「WEBを担当する人」
2者の共同作業を右視点からお話する

※注:「いくら儲かってんの?」という質問はナシ

例1:ニシナ屋珈琲
  • 輸入経路とか営業年数の古さが大事な世界
  • 高級珈琲専門店
  • コピ・ルアック #麝香猫!へー!!
  • 200g1.3万!! 高いので送料無料〜
  • 「いい商品であること」(単価高い粗利大きい)はレベニューシェアで大事
  • →売上の○%をもらってる
例2:社労道
  • 社会保険労務士資格とはけっこう狭き門6%くらいの合格率
  • 専門学校講師とつくったeラーニングコンテンツ
  • 「入門レベル(無料)」と「本試験レベル」がある
  • 有料版は年間29,800円
  • 原価設定が難しい(制作労力のみなので)
  • →けっこうお買い得と思われている
  • フォーラムがあってプロ&合格者からアドバイスしてもらえる
  • ユーザ4600人(無料含む) #鷹野さんがいやらしく計算してた(笑)
  • 営業・広告ゼロ(理由は後述)
例3:社会保険本ブログ
  • 社会保険・年金のキモが2時間でわかる本ブログ
  • 2作目
  • ダンコガイに大絶賛されたのがきっかけでAmazonで7位(法律本なのに!)
  • 印税の○%をもらっている #へー! 増刷かかるまでいくのは結構大変では?

まとめると…

運営タイプ

  1. システム提供
  2. 共同プロジェクト
  3. 販売支援
1.システム提供「ニシナ屋珈琲」
  • 専用にシステムを作っている
  • ネットで商品を得るための仕組みを提供
  • →徹底的にユーザーサポートをしたかったのでオリジナルシステムにした(Web側の立場)
  • 「商品を直接扱う」側は通常業務の「延長」。量がふえるが新しい業務は発生しない
2.共同プロジェクト
  • 新規事業としてウェブサービスを立ち上げる
  • 手間がかかる!!
  • 参加メンバーが各自の役割を果たす
  • メルマガという入り口があった
  • 成功には「システム」・「コンテンツ」・「チャネル」の3つが揃うことが必要
  • →最初から揃っていたのでいけると思っていた
  • 珈琲もおなじ(集客はSEM&リピーター)
3.販売支援「2時間でわかる本」
  • 商品販売をネットを使って支援
  • 流通している商品を扱うので売り上げ増加に伴う追加業務なし

レベニューシェアのこんなところが魅力的

商品・サービス提供側にとって

  • 初期費用がかからない(または少額)
  • 「他店が成功しててもうちが売れるかどうかわからない」から売れるまで払いたくない
  • 継続的にサイトが改善されていく
  • 「作る側」「お願いする側」の作業量のかけひきがない #おお!!
  • 相談しながらサイトを運用できる
  • 「発注」「受注」の(対立的)立場ではない
  • コンサルティング料が不要

WEB制作側

  • 継続的に利益を得ることができる
  • →システムができあがればずーっと入金がある(いまこの瞬間も)
  • パートナーとして提案がしやすい #おうおう!!!!
  • 対等なパートナー
  • 仕事のやりがい →利害が一致してくる?
  • 最初から完成図を提案しなくてもいい
  • 「試しにやってみる」に取り組みやすくなる

いちばんの魅力
「利益を生み出せるサービス」=「誰かがお金を払っている」
ユーザにとって「よいサービス」を追求できる

WEB担当者とか社長とかに向きあわなくてよい!

こんなところに気をつけたい

お店側

  • そもそものイメージがわかない。ここのハードルが高い!
  • どの程度のことをやってくれるかわからないのに売り上げを持っていかれる(サギっぽい)
  • 将来にわたって利益を分配し続けることになる

WEB制作側

  • 制作コストが無駄になる可能性
  • 継続的な改善のための作業が必要
  • 終わらない制作、デスマーチっぽくなる
  • 売上が落ちたら継続的な赤字を生む可能性、サーバ代など

お互いの疑念「ちゃんとやってくれるのか」 #ここのPPTがいい♪
→マイナスのスパイラル
これがない状態でスタートする
綺麗事でも何でもなく「信 頼 関 係」

契約書について:甲乙レベルまで作っていない

予想外のことがおきた場合
信頼関係で解決するか契約書で解決するか
→このさき信頼関係だけで大きくしていくのは難しい

「頼まれたから」ではなく「一緒によいサービスを作り上げていく意識」
→利益(=ユーザの幸福)を生み出す仕組み
→画面の向こうの人の生活を豊かにする「価値」
訪れたひとにお金を払うだけの価値を提供できるところまで
やっときたのでは

問「ウェブってどうなの?」への答え

「ウェブはこれからです!」

紹介URL集 http://bit.ly/cssniteginza48
(本編おわり)

質疑応答

ちなみに今回(わかりにくいテーマで)久しぶりに事前登録が満席にならなかったんだけど、来たひとは得したねーいい話きいたねー(by鷹野さん)

Q.ドメインをおさえるなど切られない工夫
A.まだ始めたばかり。いまのところそういう話になったことがない
最古ので3年

Q.粗利が低い商品・サービスはしんどいか?
A.しんどい。数が売れないならむり
粗利が低いが手間が少ないでやっているものはある
レベニューシェアの一部をさらにレベニューシェアすることもしている

Q.共同プロジェクトでどうやってシェア率を決めるのか?
A.3者なので1/3ずつ
お互いにゼロからやったのがよかった
「あの人なんにもしれないよね」というのがそのうちでてくるかも
基本的に魅力的なひととやっている

Q.いずれ役割やバランスがかわってシェア率がかわるのでは?
A.派生プロジェクトのときに次のシェア率を変えるのがいいかも
いったん決めたものを「減らす」というのはあまりよくないので

増永さんの切り返しがうまい!(鷹野さん)
「こうなればみんな幸せだよね」という答え方
→その方が楽に稼げるとおもう

いままでの仕事は焼畑的(笑)
10年20年後に胸をはれるものがつくりたいよね!(鷹野さん)

感想

行ってよかった。鷹野さんも感動してました。私も蝶感動しました。WEB制作者が常に感じている「発注者」と「受注者」の対立、いいWEBを作りたいのに目の前のクライアントのWEB担当者や上の意思決定者に感じられる「壁」、なかなか本当のユーザのために全力を尽くせない不全感といったものに対する大きな試みとして刺激的でした。すぐにレベニューシェアに取り組めるというわけではないけれど、WEB制作者としていい仕事をするために重要なテーマであり、これからもじぶんなりに考えていきたいです。

CSS3 for tomorrow [ver.LP9] 2

福田泰雄(ふくだ・やすお)

株式会社AGN
マークアップエンジニア

テキスト装飾と実例

HTMLコーダ件プログラマ
サーバインストールからCGI作成まで
携帯サイトのバックエンド作成が多い

text-shadow

テキストについて影をつけることができる
色、X軸、Y軸 ぼかし を指定

「みやすくする」
背景色と文字色がおなじでも、影をつけるとよめる

たくさん影をつけることができる
重なり順:よくわからん Operaではあやしい

2色の暖色の影:ネオンっぽい装飾
3色でおおきくぼかす:レンズフレアっぽい
隆起させる
凹ませる:錯覚 拡大してよくみると隆起している

主な用途
コントラストをあげる→可読性の向上
立体感をだす→見出しを目立たせる

実例
BODYにすごく小さい値をつける:アンチエイリアスオフのときにエッジがなめらかにみえるおまけつき

DavidSeDandro:CSSを使った実験サイト
マウスオーバーで立体感のあるロゴがでてくる
マウスオーバーでサイズ拡大しながらでてくる

BEERCAMP
とびだす立体的なロゴ:30枚の影 影色を変えてニュアンスを出す
光があたっている影

SXSW Sesign WorkShop
aruk Ates:ProgressiveEnhanhment:MacWebKit IE8で比べるとよい

まとめ

CSS3利用ケース
特定のブラウザに限定できるとき
工数をあまりかけられないとき
+αぶぶんでさりげなく

例:プロトタイプ
社内案件の管理画面
シャドウだけ

めんどくさいところを、とりあえず簡単に実装できる

ProgressiveEnhanhment
先進的なブラウザで特に綺麗にみえるように
例:MOSe(4〜5年前)MozillaOperaSafari、、、?
cf IE6でみると「アナログ」とかグレー表示になる

IE9
IEということであきらめてほしくない(笑)
今のうちに意見をいおう!
希望をもって!

<感想>
タイポグラフィにしぼってわかりやすい話でした。
がんばってChromeで組んでも、数%のユーザだしなーと弱腰な私。

CSS3 for tomorrow [ver.LP9]

高津戸 壮(たかつど・たけし)

株式会社ピクセルグリッド
フロントエンドエンジニア

GoogleChromeのみ)
http://goo.gl/O9ua
http://goo.gl/TRbO

秀丸HTMLコーディングの話などが超ためになる
 http://gyauza.egoism.jp/clip のひとです。

HTMLCSSコーディングJSによるUI実装
#おお!

CSS TransitionsModule Lvel3
CSS 2D Transforms Modle Levwl3
Animation

アップルが提案しているものがほとんど
Chrome Safariでしかみられない

CSS内にweb-kit の独自実装を設定
スライドもCSSでつくる

Trainsition
「値の変化がおこるときにアニメーションをつけることができる」
例:マウスオーバーで背景色が変化 + transition
→「1秒かけて色がかわる」

classにも適用できる
画像サイズ変化:犬のダイエット

例:文字サイズセレクト
アニメーションでナチュラルに変化
「何がおこっているか」わかりやすい

サブメニューアコーディオン展開
・透明度0→1
・左位置:右へイン
・高さ:0から

CSSだけで手軽にアニメーション

Transforms
位置が移動する
倍率の変化
回転
平行四辺形変化

→transitionと組み合わせる
かんたんに超人ワザ!

JSもAS3もいらない

・本背表紙取り出しナビ
・かっこいい階段メニュー展開
・花咲ポップアップ

要素の配置が自由自在に

Animations

ハトがふるえている…!!
CSSでアニメーションを定義
定義したアニメーションを指定するだけ

Demo

fademenu:下からほんわり現れる
galally:JSで0.1秒おきにimg作成:使うときは読み込み済みをかくにんしてから
tagfall:つけっぱだとフリーズする バラバラになるようにアニメ時間をJSでdurationをランダムにしている

JavaScriptCSSアニメーション

jQueryでもアニメーションできるし… :箱が横に移動する
→じつは裏では原始的に1pxずつCSSをずらしている →重くなりやすい
単純にかけるけど裏ではいろいろがんばってる
CSSとJS両方書かないといけない
キーフレームアニメーションは大変
長いスクリプトの中にアニメーションがあると複雑さ増大
CSSアニメーションなら、一時停止や再生も簡単

→CSS3で自由で管理性のたかいアニメーションが可能

アニメーションとのつきあいかた
「でしゃばらないアニメーション」unobtrusive animation
Eメールのバリデーションアニメ:間違っているとぶるぶるっとふるえる「通知」の意味
現実には一瞬で切り替わる事物はない

素敵なUIを素敵なCSSアニメーションで

<感想>
Flashでいいだろー!と思ってたけど、CSS3便利!(ChromeSafariでしか見られないけど。。)
アニメーションの動きの計算原理はActionScriptと同じ感じ(残りの距離の半分ずつ近づく)ですね。

Webパフォーマンス最適化のためのコーディング手法

石本 光司(いしもと・こうじ)

株式会社ドーガ
コーディングもするウェブデザイナー
ECサイト運営更新が多い

GoogleRankingAlgorithmに反映
4/9アナウンス .comのみ

わかっている計測方法2つ
Adwords:品質スコアにページ表示速度が関連している
「HTML」(画像CSSなどはふくまない)の表示速度
→すでに取り組まなければいけない案件

GoogleWebMasterTools
「サイトのパフォーマンス」
上位20% 1.4秒

高速サイトがもたらすほかの利益
再訪問数の増加
セッションあたりのPV増加
コンバージョン率の改善
収益増加
顧客満足度の向上
サーバなどインフラコストの現象

「トーン&マナー」→耳がない
SEO」→重要視
→パフォーマンスを意識したコーディング
→会社内での存在意義が高まる

コーダー・デザイナーは忙しい
HTML5
・CSS3
・JS
アクセシビリティ
ユーザビリティ
アクセス解析
jQuery

最小限の対策で最大限の効果

パフォーマンスというみえないものをビジュアライズする

HttpWatch6.2 BasicEdition
ウォーターフォールチャート
→リクエストの各段階で色分けされる

例:ドーガのトップページ:「赤色」が目立つ!
ほとんどがサーバ待ち時間(WaitTime!)=かならずかかる税金のようなものでどうしようもない
ハンバーガーショップのイメージ
IE6とFireFox3.6では読み込まれ方が違う
→「HTTP/1.1ホスト名ごとの同時接続数(2つまで)IE67」のため ←いまだにシェアが多い
IE8、FireFOXなどは6つなげる
Blockingで接続待ち時間が長い = レジが2つしかない

HTTPリクエストはコストが高い

  • 改善事例:株式会社ドーガ

CSSスプライト
データURIスキーム
CSSJSファイルの結合

CSSスプライト
複数画像をまとめて、CSS背景+位置指定で表示する
1回の注文でチキンナゲット3つ

  • 150msの成果

HTTPリクエスト数:11→3

CSSスプライトのジレンマ
ページ数 保守性 最適化 3つぜんぶをとれない

データURIスキーム

画像をデータでそのままHTMLに埋め込む
base64データ

→最強? Ie5-7非対応☆
→ハックで分岐処理
サイズ制限 Opera7.2 4.1KBまで

HTTPリクエスト数:1→0

CSSJSファイルの結合

CSS1枚、JS1枚に変更
→メンテナンス性が下がる
なんとかかんとかで@importを擬似的に表現するとさらによい

6→2

CSS3プロパティ
画像を使わないと表現できなかったものを、CSSで表現

ドーガでは使ってない

どの方法も欠点や短所がある
考えた
ChangeDesign!

NicoleSullivanワークショップ

デザインを考え直してみる
SmoothScroll機能って必要?「Topへ戻る」コストをかけてまで使うことはない
ページ高のあるページ自体あまりない
月2万PV中の5回しかおされてなかった

検索画像ボタンって必要?
月5、6回→デフォルトSubmitボタンに変更

2→1

  • まとめ

HTTPリクエスト32→17
平均読み込み時間0.5秒
速度統計上位2%にランクイン

パフォーマンスに対するコスト意識

パフォーマンスを武器に効率良く対策すべし
リクエストを減らす簡単な方法はない
それは本当に必要なのか考える

<感想>
内容的にはオライリー本でよく知っているものと同じだけれど、実践したことと効果を詳細に説明してとても説得力がありました。また、なぜパフォーマンスのチューニングが必要なのかというコンセプト部分とコーダーの役割・意識についての説明がとてもよかった!基調講演として期待した内容はまさにこの石本さんの話のようなものでした。

Webパフォーマンス最適化のためのコーディング手法

(旧:コーディングから参加するUI設計)
長谷川 広武

自己紹介。おやばかさん!
運用系のWeb会社所属

  • コーディングから参加する

デザインができている段階で
「この機能JavaScriptでできる?」→えええー!

  • 実装前に決めておくこと
    • 動作:アニメーション、実行のタイミングなど
    • JSOFF対応IE6対応
    • 操作CSSを直接書くかわけるか
  • 制作例:フォームの入力確認:修正ボタンで前のページに戻るのが手間

→ページ切り替えなしの工夫

    • 「確認モーダルウィンドウ」
    • 「その場編集」

タブとナビゲーションの連動<失敗例>

  • タブとナビの選択状態が連動している
  • サブカテゴリの扱いもろもろでボツ

機能があってもいいけど、なくても特別便利になっていない

ex.タブ型の縦長コンテンツの連動ボタン
上に戻る手間→ならタブじゃなくていいのでは?
一番下に次のタブの最上部へのリンクがでている

ex.透明度を利用したロールオーバー
ちょっとうすくしてマウスオーバーを表現

  • 素材にロールオーバー画像がない!
  • 時間がない余裕がない
  • 写真で替えがない
  • ロゴで加工できない

などのときに!

THE HAM MEDIAで紹介中

  • コードが短い
  • ふわっとうすくなる

#おお便利だ!!

失敗談から学ぶ

  • テストと本番の差
  • heightLine.js:ボックスの高さがそろう
    • ボックス数が100ぐらいになり重くなる(30s〜1minかかる)

→一度に適用する量を減らす
実行するタイミングをずらして量を減らす(3〜10sに)

→仕組みを変更
全要素でなく必要な箇所だけを参照するようにする(1〜2s短縮)

子要素にもイベントが発生

  • 入れ子で、サブメニューをクリックしてもメニューが開閉する(??)

    プラグインの利用でも気をつけて
    同じ名前のidを作ってしまう(笑) ←idは1ページに1つ

    画面サイズに気をつけよう
    LP9サイトの左メニュー追随が下にズレる
    モーダルウィンドウのせいで下の閉じるボタンがみえない
    →ThickBox
    →画面サイズを取得して気をつける

    開閉パネル:リロードしたときに閉じているパネルが開いてしまう
    フォントサイズ
    →設定状態を保存しておく

    2度目の訪問時は設定した状態にしておく
    →クッキーを使う

    朝日新聞のサイトはよくできている

  • Ajaxコンテンツに工夫

    読み込みが遅いと、ボックスの中が空でユーザを待たせてしまう
    「読み込み中」ローティングイメージを入れる

    時間がかかっていることを視覚的に伝える

    JavaScriptOFF環境にやさしく
    タブの中身が一瞬みえる!
    →DOM完了前にCSSだけ準備する
    →JS操作用CSSを別途用意して、JSでCSSを読み込むタグを追加

    OFF環境の人への注意文

    OFFでは対応できない場合 例:地図が表示されない
    OFFの人にだけ見せる文章を用意しておく


    <まとめ>
    Webサイトの使いやすさを考える

    • ちょっとした気遣い・優しさ
    • 誰が使うのかを考える

    プラグイン導入時

    • HTML変更なしに導入できるか
    • ほかのプラグインCSSに影響がないか
    • 動作は大丈夫か?

    よく確認してから案件に適用しよう!

    動作チェック

    • ブラウザ
    • ページをもどしたとき
    • JSOFF
    • 画面サイズ

    質問
    コンフリクトなどの検証方法は?
    →一番使いたいバージョンに対応しているかどうかの確認
    FireBugでチェック
    →じぶんで直す

    <感想>
    実例ベースの説明で、いろんな制作例を説明されているのが参考になりました。前のセッションとあわせてjQueryは充実した内容だなー。

    Coding with jQuery

    徳田 和規(とくだ・かずのり)
    マインドフリー株式会社
    ディレクター
    5509運営
    .coder(勉強会)やってる

    いまさらきけないjQueryまとめ

    • jQueryの実行:jQuery(function($){実行内容})
    • メソッドチェーン:ドットでつないでいくだけ
    • セレクタCSSセレクタを使える。CSS3もOK! first-Childなど

    jQueryが担う分野

    javascriptでできることはもちろんできるが…

    ウツなコーダーも元気に出社☆

    • 最小限のコードでいろいろできる ex.スライドダウン→わずか1行でOK

    #PPT右上にデモリンクがあるのがいい

    自分好みのUIを作ってみよう

    JavaScriptはユーザにプラスに働くとは限らない ※注意
    なんのための実装?

    • ユーザビリティをプラス(便利にする)
    • 動的な書き換えで一歩踏み込んだ情報提供
    • ユーザの利益を第一に考える
    • JSOFF環境にやさしく
    • でしゃばらない
    • 後方互換

    ex1.iPhone検索ボックスのクエリ削除ボタンみたいなもの

    1. 仕様を考える
      1. フォームに入力したら×ボタンが表示される
      2. ×ボタンを押したら、文字を消す
    1. HTMLを用意する

    ※元のHTML以外はjQueryで追加する ;でしゃばらない

    1. 動作の追加:クリックしたら消える
    • INPUTが空なら表示しない
    • 一文字以上表示されたらボタン表示
    • ボタンを押されたら、文字をクリア

    ライブコーディング(省略)

    Case2:セレクトボックスの置き換え

    セレクトボックスの使いにくさをなんとかしたい
    都道府県一覧が長い!)
    jQuerytable →みやすく展開(沖縄のひとがうれしい!)

    • 流れを考える
    • 置き換えスクリプトをつくる
    • ループをつくる→optgroupをdd書き出し→各県名をdtで書く→CSS追加

    ◇ポイント
    「使いにくいなら置き換えてしまえばいい」

    jQueryで実践Ajax

    • Ajaxばりばりサンプル

    ex.都道府県:市郡:詳細住所の置き換え 「ZAQ
    ページ遷移することなる動的レスポンスが可能

    XMLHTTPRequest

    クロスドメイン上の制約

    TwitterAPIを利用

    • TwitterアカウントにHoverするとつぶやきがフロートする
    • カーソルをあわせたユーザーの情報を取得
    • 取得したHTMLをいれる
      • もとのHTMLは
        ひとつだけ
      • 取得したデータを表示する

    …ということで、かんたんにAjaxができた!
    クロスブラウザを気にしないでOK

    <まとめ>

    オススメ書籍:

    • jQueryデザイン入門、西畑一馬
    • DOMScripting標準ガイドブック

    <感想>
    テンポよく中身の濃いセッション!jQueryは既存のものの設置しかしたことがなかったけれど、帰ったらまっさきにやってみたいです。

    XHTML&CSS超高速コーディング術 LIVE!

    株式会社スキルパートナーズ
    大藤 幹&大杉 充

    • 会社ロゴは沖縄だからってゴーヤじゃないよ!
    • 通称「スキル大杉」と呼ばれている
    • おすすめ本:「7つの習慣」
      • 今までで一番影響をうけた本
      • きこりのエピソード。「歯を研ぐ時間がないために能率が落ちている」

    きょうのなかみ

    • コーディング作業が長引く原因と情報の管理
    • コーディング作業の流れとポイント
    • スキル大杉のコーディング逆Tips

    コーディング作業が長引く原因と情報の管理

    • はやくコーディングするには?
    1. 速度をあげる
    2. ムダな作業をはぶく

    →2番が非常に大事

    • 作業が長引く原因
    1. 仕様構成の変更
    2. 原稿素材の変更
    3. 情報の管理方法が不適切
    4. 作業手順が不適切
    5. スキルが低い

    →「手戻りを最小限におさえる」Minimizing Reworking

    [サイト管理ファイルの活用]

    • 1案件1エクセルで管理しきる!! へー!!
      • 作業工程一覧
      • 終わったら丸をつけてカウントして、進捗状況を集計する
      • 担当者別に色分け
    • より共通する部分から先につくる
    1. テンプレート作成
      1. ページテンプレートの作成
      2. 基本的テキスト要素のCSS設定
      3. パーツテンプレートの作成
    1. 各ページ作成
      1. ページテンプレートからファイルを作成
      2. パーツテンプレートを組み込む
      3. テンプレート化されていない部分を作成
      4. テキスト・画像の流し込み

    #わかっちゃいるけどこれが上手くいかないのよ

    • ShadowCording (大杉さんの造語)車道でコーディング!

    →実際に始める前に脳内で一度コーディングする

    「すべてのものは2度作られる by7つの習慣」

    デモ:9ページのサイト

    • パーツテンプレート作成デモ
    1. パーツの割り出し:共通のパーツを割り出す
      1. カンプPSDを1枚のpngにしてスライスして使う
      2. FireWorksで、共通するパーツをどれか1枚のパーツ一覧へ切り貼り移動していく
      3. スライスの色を使い分けて、マージンなどをメモっていく
      4. 通化してないパーツが各ページに残る
    1. シャドーコーディングとスライス
      1. 頭のなかで作って、実際に書くだけ #えー!
      2. 書いて、プレビューして、直して…とやらない
      3. どんどんスライスして数字を決めていく
      4. スライスにスライスを重ねてぜんぶ数字をきめる
      5. ex.左画像右テキストのフロート
      6. HTMLを書く→CSSを書く
      7. まずセレクタをぜんぶ書く。#contentsをつける
      8. FWのスライスを参照しながら、ががっと設定する
    1. コーディング
    2. チェック

    コーディング作業の流れとポイント

    スキル大杉のコーディング逆Tips

    1. classはふたつつけるな class="classA classB"

    .classA {}
    .classA .classB{}
    のときにIE6で.classBしか認識されない

    1. div要素を無理に減らすな

    きょうのポイント

    • きちんと記録してわかるように示す
    • より共通する部分から順に作る
    • シャドーコーディングをする

    設計が大事で、ZenCordingなんかで打つスピードだけあげてもだめ

    質疑応答

    • EXCELの共有について

    →共有設定、GoogleDocumentなどを使いましょう

    <まとめ>
    FWで数字を決めて一気にCSSを組むべし。

    <感想>
    コーディングを実演してくれたのがとても参考になりました。で、思ったほど高速じゃない!(笑)。このくらいできれば「コーディング専門のプロ集団」「高速コーディング」を名乗っていいのか〜とコーディング能力に自信のない私も安心しました。

    スライスはFWにおまかせ!は素晴らしい…けど、後からこまごまPSD修正が入るときどうするのかなあ。

    デモで制作したのがごくベーシックなサイトでまだダミーテキスト&画像という例なのが、ややがっかり。そのレベルならどうやってもそう苦労なくコーディングできるやん…。地模様あり透過ありとかハミダシデザインとか、デザインで気をきかせたら超めんどくさくなるときの高速コーディング術が知りたかったです。