CSS Nite ginza 48 [レベニューシェア] めも
鷹野さん前説
iPadプレゼンだ…
カッコ悪くないですよー
本編:増永玲(バドーゾ)「利益分配型サイト制作はこんなに面白い」
バドーゾという社名は濁点多くて強そうだと思ってつけた(笑)
ウェブサービスをいろいろ運営している
「名前をつけてやる」ロシアドメイン.ru!
Amazonからとってきたジャケに勝手に名前をつけるだけ
趣味です!
ついったボット作成がさいきん多い
時報ボット
笑っていいともゲストお知らせボット #便利そう♪
ブログ「頭ん中」
ビジネスホテル紹介記事を書いた…らはてブが1000ついて今回予約できないよ!
問「ウェブってどうなの?」
この3つはどれも0にはならない、が
…先細り?
5年先10年先、これらで発展は難しい
なぜこうなった?
- そもそもお金がない
- 払うだけの価値があるのか? #うむうむ
- めんどくさい 何もしたくない、更新イヤ、ネット触りたくない
「で、儲 か る の ?」この疑問にキッチり答えられていない
本日のお話の流れ
- レベニューシェアって何だ
- 実例を見てみよう
- 運営にはどんなタイプがあるか?(3パターン)
- こんなところが魅力的
- こんなところに気をつけたい
レベニューシェアって何だ
(レベニュー)を(シェア)すること
revenue「製品やサービスを売って得たお金を」
share「複数の人で分配すること」
→要するに「山分け」
運営の形態は無数にあるが、今回は
「商品を直接扱う人」⇔「WEBを担当する人」
2者の共同作業を右視点からお話する
※注:「いくら儲かってんの?」という質問はナシ
例1:ニシナ屋珈琲
- 輸入経路とか営業年数の古さが大事な世界
- 高級珈琲専門店
- コピ・ルアック #麝香猫!へー!!
- 200g1.3万!! 高いので送料無料〜
- 「いい商品であること」(単価高い粗利大きい)はレベニューシェアで大事
- →売上の○%をもらってる
例2:社労道
運営タイプ
- システム提供
- 共同プロジェクト
- 販売支援
1.システム提供「ニシナ屋珈琲」
- 専用にシステムを作っている
- ネットで商品を得るための仕組みを提供
- →徹底的にユーザーサポートをしたかったのでオリジナルシステムにした(Web側の立場)
- 「商品を直接扱う」側は通常業務の「延長」。量がふえるが新しい業務は発生しない
2.共同プロジェクト
- 新規事業としてウェブサービスを立ち上げる
- 手間がかかる!!
- 参加メンバーが各自の役割を果たす
- メルマガという入り口があった
- 成功には「システム」・「コンテンツ」・「チャネル」の3つが揃うことが必要
- →最初から揃っていたのでいけると思っていた
- 珈琲もおなじ(集客はSEM&リピーター)
3.販売支援「2時間でわかる本」
- 商品販売をネットを使って支援
- 流通している商品を扱うので売り上げ増加に伴う追加業務なし
レベニューシェアのこんなところが魅力的
商品・サービス提供側にとって
- 初期費用がかからない(または少額)
- 「他店が成功しててもうちが売れるかどうかわからない」から売れるまで払いたくない
- 継続的にサイトが改善されていく
- 「作る側」「お願いする側」の作業量のかけひきがない #おお!!
- 相談しながらサイトを運用できる
- 「発注」「受注」の(対立的)立場ではない
- コンサルティング料が不要
WEB制作側
- 継続的に利益を得ることができる
- →システムができあがればずーっと入金がある(いまこの瞬間も)
- パートナーとして提案がしやすい #おうおう!!!!
- 対等なパートナー
- 仕事のやりがい →利害が一致してくる?
- 最初から完成図を提案しなくてもいい
- 「試しにやってみる」に取り組みやすくなる
いちばんの魅力
「利益を生み出せるサービス」=「誰かがお金を払っている」
=ユーザにとって「よいサービス」を追求できる
WEB担当者とか社長とかに向きあわなくてよい!
こんなところに気をつけたい
お店側
- そもそものイメージがわかない。ここのハードルが高い!
- どの程度のことをやってくれるかわからないのに売り上げを持っていかれる(サギっぽい)
- 将来にわたって利益を分配し続けることになる
WEB制作側
- 制作コストが無駄になる可能性
- 継続的な改善のための作業が必要
- 終わらない制作、デスマーチっぽくなる
- 売上が落ちたら継続的な赤字を生む可能性、サーバ代など
お互いの疑念「ちゃんとやってくれるのか」 #ここのPPTがいい♪
→マイナスのスパイラル
これがない状態でスタートする
綺麗事でも何でもなく「信 頼 関 係」
契約書について:甲乙レベルまで作っていない
予想外のことがおきた場合
信頼関係で解決するか契約書で解決するか
→このさき信頼関係だけで大きくしていくのは難しい
「頼まれたから」ではなく「一緒によいサービスを作り上げていく意識」
→利益(=ユーザの幸福)を生み出す仕組み
→画面の向こうの人の生活を豊かにする「価値」
訪れたひとにお金を払うだけの価値を提供できるところまで
やっときたのでは
質疑応答
ちなみに今回(わかりにくいテーマで)久しぶりに事前登録が満席にならなかったんだけど、来たひとは得したねーいい話きいたねー(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年前)Mozilla、Opera、Safari、、、?
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をランダムにしている
JavaScriptとCSSアニメーション
jQueryでもアニメーションできるし… :箱が横に移動する
→じつは裏では原始的に1pxずつCSSをずらしている →重くなりやすい
単純にかけるけど裏ではいろいろがんばってる
CSSとJS両方書かないといけない
キーフレームアニメーションは大変
長いスクリプトの中にアニメーションがあると複雑さ増大
CSSアニメーションなら、一時停止や再生も簡単
→CSS3で自由で管理性のたかいアニメーションが可能
アニメーションとのつきあいかた
「でしゃばらないアニメーション」unobtrusive animation
Eメールのバリデーションアニメ:間違っているとぶるぶるっとふるえる「通知」の意味
現実には一瞬で切り替わる事物はない
素敵なUIを素敵なCSSアニメーションで
<感想>
Flashでいいだろー!と思ってたけど、CSS3便利!(ChromeとSafariでしか見られないけど。。)
アニメーションの動きの計算原理は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サイトの使いやすさを考える
- ちょっとした気遣い・優しさ
- 誰が使うのかを考える
プラグイン導入時
よく確認してから案件に適用しよう!
動作チェック
- ブラウザ
- ページをもどしたとき
- JSOFF
- 画面サイズ
質問
コンフリクトなどの検証方法は?
→一番使いたいバージョンに対応しているかどうかの確認
→FireBugでチェック
→じぶんで直す
<感想>
実例ベースの説明で、いろんな制作例を説明されているのが参考になりました。前のセッションとあわせてjQueryは充実した内容だなー。
Coding with jQuery
徳田 和規(とくだ・かずのり)
マインドフリー株式会社
ディレクター
5509運営
.coder(勉強会)やってる
いまさらきけないjQueryまとめ
jQueryが担う分野
javascriptでできることはもちろんできるが…
- クロスブラウザ:実装の違いを簡単に吸収
ウツなコーダーも元気に出社☆
- 最小限のコードでいろいろできる ex.スライドダウン→わずか1行でOK
#PPT右上にデモリンクがあるのがいい
自分好みのUIを作ってみよう
JavaScriptはユーザにプラスに働くとは限らない ※注意
なんのための実装?
- ユーザビリティをプラス(便利にする)
- 動的な書き換えで一歩踏み込んだ情報提供
- ユーザの利益を第一に考える
- JSOFF環境にやさしく
- でしゃばらない
- 後方互換性
ex1.iPhone検索ボックスのクエリ削除ボタンみたいなもの
- 仕様を考える
- フォームに入力したら×ボタンが表示される
- ×ボタンを押したら、文字を消す
- HTMLを用意する
※元のHTML以外はjQueryで追加する ;でしゃばらない
- 動作の追加:クリックしたら消える
- INPUTが空なら表示しない
- 一文字以上表示されたらボタン表示
- ボタンを押されたら、文字をクリア
ライブコーディング(省略)
Case2:セレクトボックスの置き換え
セレクトボックスの使いにくさをなんとかしたい
(都道府県一覧が長い!)
jQuerytable →みやすく展開(沖縄のひとがうれしい!)
◇ポイント
「使いにくいなら置き換えてしまえばいい」
- Ajaxばりばりサンプル
ex.都道府県:市郡:詳細住所の置き換え 「ZAQ」
ページ遷移することなる動的レスポンスが可能
クロスドメイン上の制約
TwitterAPIを利用
- TwitterアカウントにHoverするとつぶやきがフロートする
- カーソルをあわせたユーザーの情報を取得
- 取得したHTMLをいれる
- もとのHTMLは
XHTML&CSS超高速コーディング術 LIVE!
株式会社スキルパートナーズ
大藤 幹&大杉 充
- 会社ロゴは沖縄だからってゴーヤじゃないよ!
- 通称「スキル大杉」と呼ばれている
- おすすめ本:「7つの習慣」
- 今までで一番影響をうけた本
- きこりのエピソード。「歯を研ぐ時間がないために能率が落ちている」
きょうのなかみ
- コーディング作業が長引く原因と情報の管理
- コーディング作業の流れとポイント
- スキル大杉のコーディング逆Tips
コーディング作業が長引く原因と情報の管理
- はやくコーディングするには?
- 速度をあげる
- ムダな作業をはぶく
→2番が非常に大事
- 作業が長引く原因
- 仕様構成の変更
- 原稿素材の変更
- 情報の管理方法が不適切
- 作業手順が不適切
- スキルが低い
→「手戻りを最小限におさえる」Minimizing Reworking
[サイト管理ファイルの活用]
- 1案件1エクセルで管理しきる!! へー!!
- 作業工程一覧
- 終わったら丸をつけてカウントして、進捗状況を集計する
- 担当者別に色分け
- より共通する部分から先につくる
- テンプレート作成
- ページテンプレートの作成
- 基本的テキスト要素のCSS設定
- パーツテンプレートの作成
- 各ページ作成
- ページテンプレートからファイルを作成
- パーツテンプレートを組み込む
- テンプレート化されていない部分を作成
- テキスト・画像の流し込み
#わかっちゃいるけどこれが上手くいかないのよ
- ShadowCording (大杉さんの造語)車道でコーディング!
→実際に始める前に脳内で一度コーディングする
「すべてのものは2度作られる by7つの習慣」
デモ:9ページのサイト
- パーツテンプレート作成デモ
- パーツの割り出し:共通のパーツを割り出す
- シャドーコーディングとスライス
- コーディング
- チェック
コーディング作業の流れとポイント
スキル大杉のコーディング逆Tips
- classはふたつつけるな class="classA classB"
.classA {}
.classA .classB{}
のときにIE6で.classBしか認識されない
- div要素を無理に減らすな
きょうのポイント
- きちんと記録してわかるように示す
- より共通する部分から順に作る
- シャドーコーディングをする
設計が大事で、ZenCordingなんかで打つスピードだけあげてもだめ
質疑応答
- EXCELの共有について
→共有設定、GoogleDocumentなどを使いましょう
<まとめ>
FWで数字を決めて一気にCSSを組むべし。
<感想>
コーディングを実演してくれたのがとても参考になりました。で、思ったほど高速じゃない!(笑)。このくらいできれば「コーディング専門のプロ集団」「高速コーディング」を名乗っていいのか〜とコーディング能力に自信のない私も安心しました。
スライスはFWにおまかせ!は素晴らしい…けど、後からこまごまPSD修正が入るときどうするのかなあ。
デモで制作したのがごくベーシックなサイトでまだダミーテキスト&画像という例なのが、ややがっかり。そのレベルならどうやってもそう苦労なくコーディングできるやん…。地模様あり透過ありとかハミダシデザインとか、デザインで気をきかせたら超めんどくさくなるときの高速コーディング術が知りたかったです。