Android Bazaar and Conference 2011 Winterのメモと感想(1)
Android Bazaar and Conference 2011 Winter
http://www.android-group.jp/abc2011w/
をustで見ました。実は、開催を知ったのが当日で現地に行けなかったため、しかたなくustで見ていました。
現地は相当盛り上がっていたようで、立ち見すらできないところもあったようで結果的にはustでよかったかなと思ったりしました。ただ、現地での雰囲気、熱気を感じることができずに少し残念でもあります。
さて、今回ustで見ていたのは以下の4つです。他にも見ようと思いますので今のところこれだけというところです。
- Webサイトのスマホ対応Tips
- 矢野りんさん(パンダ)、高橋純さん(うさぎ)、山本麻美さん(トラ)
- ここまで出来る!Androidアプリケーション開発 with Adobe Flex
- 轟啓介さん(アドビ システムズ 株式会社 マーケティング本部 デベロッパーマーケティングスペシャリスト)
- HTML5によるリッチクライアント開発手法についてあれこれ
- 白石俊平さん(html5-developers-jp管理人)
- Android・ウェブアプリケーション連携術
- 渡辺博文さん (cho45)(株式会社はてな アプリケーションエンジニア)
今日から、何回かに分けて私が残したメモと簡単に感想、検証したものを混ぜて公開したいと思います。
まず今回は、最初ののセッションについてになります。
ustのアーカイブに残っているため以下の4つをご覧いただければ、実際の講演内容を見ることができます。
- http://www.ustream.tv/recorded/11903478
- http://www.ustream.tv/recorded/11903832
- http://www.ustream.tv/recorded/11903916
- http://www.ustream.tv/recorded/11903990
2011-01-10 13:06:27追加。
資料が公開されていましたので、資料はこちらをご覧ください。
http://dl.dropbox.com/u/8536753/Web_Tips.key.pdf
2011-01-10 14:44:11追加。
ust含め発表資料等へのリンクを含め以下のサイトでまとめられています。素晴らしい!!
You are here:TAKA@P.P.R.S TECH!!!! > Information > 【Android】『ABC 2011 Winter』USTアーカイブまとめ。【 #abc2011w 】
http://takapprs.net/tech/archives/2011/01/abc2011winter_ustream/
2011-01-12 20:10:17追加。
うさぎさんが、自らまとめを書かれていましたので、そちらも参考に。
ABC 2011 Winter デザインセッションまとめ「スマートフォン・リデザインコーディング」
http://www.ermine.jp/android/abc-2011-winter-design-session/
Webサイトのスマホ対応Tips
内容以前に驚いたのはまさかのパンダ、うさぎ、トラの着ぐるみでの発表でしたww
可愛い動きでもてもて動いている様は、Androidのセミナーとは思えないなんとも言えない面白さがありましたw
さて肝心の内容に移ります。途中ustが何度か途切れたため、抜け等あるかもしれませんが、その辺はご容赦ください。
アジェンダ
- スマフォ対応で必要な作業をひととおり把握する
- スマフォというハードにあったデザインの指針を知る
- コーディングに加える工夫をチェック
ということでスタートしました。
すでにPCサイトは持っていて、スマートフォンサイトも作ってくれというオーダーが多いということでした。
去年辺りから、大きな会社からスマートフォン対応してくれというオーダーが増えてきたそうです。
UIの再設計
基本指針
- 小さい解像度でもちゃんと見えること
- 大きい解像度ではちょっと大きくなってより見やすくなること
- できればレイアウトは固定せず、右側の余白が解像度の変化で可変するような作りを採用すること
- 基本1段組のカラムの構成に収めるよう設計すること
機器ごとの表示サイズの違いに考慮しましょう
最初の、「小さい解像度でもちゃんと見えること」というのは、物理的な解像度ということではなく画面サイズの小ささに対応するということです。スマホでも解像度は結構高い(960×640等)ものがあります。解像度は高くても、画面のサイズが物理的に小さいので文字を大きめにして見やすくする。このあたりはなんとなく分かっていることかなと思います。
PCサイトは3段組が多いが、基本的には段組は使えないと思ったほうが良いということでした。実際にYahooやはてな、Googleなどスマホ向けのサイトを見ても1段組のサイトばかりなので、このあたりはある程度パターンとして開発者の間では定着してきている印象を受けます。
コンテンツの取捨選択
PCと同じ情報量は収まらない。
そこで
- ローカルナビゲーション
- 関連ナビゲーション
- 機能ナビゲーション
は表示しなくても使えるページ設計を考える。
理想は「小で大を兼ねる」
スマホは標準でPCと同じサイトが見られるようにはなっている(ピッチイン、ピッチアウト)が、スマホ用に作成したほうが使い勝手としてはよくなるそうです。
画面遷移の場所を確保するために、リスト化したメニューを右側に置いてある場合があるが外してしまったほうがよい、つまりはスマホ用に最適化した画面にしたほうが良いそうです。
具体的には以下のような例を挙げて説明されていました。ダイレクトナビゲーションは一番上のmenu1〜menu3。ステップナビゲーションは、一番下のようなもので次へ次へというように順を追って画面遷移するようなもの(PCのサイトではあまり使われない。)。パンくずリストは、「ホーム>解説」のように階層構造を表示し、どのように画面遷移してきたか、またパンくずリストをアンカーにしてダイレクトに前のページに戻れるようにすることで使いやすくするということでした。
menu1 menu2 menu3 ホーム>解説 < 1 2 3 4 5 6 7 8 >
コンテンツの取捨選択
気をつけたい落とし穴
情報を削り過ぎると...
- ケータイサイトはすでにあるので差別化を計りたい
- PCと同じコンテンツが閲覧できるというのがスマホのウリなんじゃないの?
のように制作依頼側がだんだん心配してきます。
コンテンツの取捨選択で特に印象に残ったのは、「小で大を兼ねる」で、これはまさにそのとおりという発想と感じました。ただ、まだスマホ用のノウハウは出切っていない感じもします。Yahooやはてなをスマホで見ると、自動でスマホ用のサイトに飛ばされるのですが、使い慣れていないため結局PCサイトのほうを見ているということが個人的には多くあります。そのため、スマホ用サイトでもいかに違和感なく使ってもらえるかが課題でもあるのかと感じます。
表示の最適化
最適化を考えるときのポイント
- 文字サイズ
- 画像サイズ
に対する指針を考える
文字サイズの指針
スマートフォンで文字サイズは4種類程度のサイズを使い分ける。
イニシャルスケール「1」を前提に考えると利用しやすいサイズ設定値は、
- X-large
- large
- medium
- small
- x-small
文字サイズの指針
サイズ 用途 1 X-large 見出し、表題 2 large 中くらいの見出しUI文字表記 3 medium 本文 4 small キャプション 注意書き 5 x-small 注意書き 注:Xperiaの場合1.6、2.1共に日本語でボールドの設定は無効。英語は有効。
スマートフォンの文字サイズは数字で指定するより、largeやmediumのような相対的なサイズのほうが良いそうです。見えるか見えないかはブラウザに任せたほうが良いということでした。このへんはノウハウがないと試行錯誤が必要ですので非常に参考になりました。
画像サイズの指針
- 主要スマートフォンの幅サイズが320pxを目安に
- 画像そのものに文字を入れると読めなくなる可能性が高いので入れない
画像が小さくなると文字が小さくなる、そのため画像には文字を入れないほうがいいということです。
この辺は、感覚的にも分かる部分があり画像だと拡大しないと場合によっては文字が読めなくなるのは当然です。
本件の前提条件
- PCサイトが存在する
- PCサイトに影響が出ないようにコーディングする
PCサイトが存在する上で、どのようにコーディングしてスマホサイトを構築するかという前提でのおはなしということでした。
この2画面対応というのがPCと違って独特です。
1. 画面サイズ対応
JavaScriptでPortraitとLandscape画面の状態を取得する
は以下の方法で画面の状態を検知する
- window.onorientationchange
- ユーザが画面を傾けた状態変化を検出してイベントを通知する「onorientationchange」
- window.onresize
- ウィンドウのサイズが変更された後に発生するイベントを取得し指定メソッドを実行する「onresize」
- window.orientation
- 「orientation」プロパティで傾きの角度を取得。戻り値は[0][90][-90]のパターン。
傾きが0だと縦画面。0以外たと横画面ということがわかるため、縦横の判定により画像を切り替える処理を行うといいとのこと。実際にabcサイト(http://www.android-group.jp/abc2011w/android/bazaar/index.html)では縦横の検知を行っているそうなので実機(GALAXY S)にて確認してみました。まず、縦だと以下のように表示されています。
次に、横にすると以下のように画像が横向きになりました。
もう一つJavaScriptでorientationの検証をしました。onresizeは一般的に使われているため、ここでは詳細な説明はしません。onorientationchangeメソッドだけ確認できるサイトを以下に作成しました。
http://kuwalab.net/html5/orientation.html
実際に動かすと以下のようになりました。スマートフォンを縦にしたり横にしたりすることで、傾きが検知できるのがわかります。ここでは以下に説明されているviewportやHoly Grailハック、また角丸の例も入れています。
記述したソースは簡単なもので以下になります。onorientationchangeイベントを受け取るとdiv#resultにその具体的な値を表示しているだけとなります。
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, maximum-scale=0.6667"> <title>傾きの検知</title> <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script> <script type="text/javascript"> $(function() { window.onorientationchange = function() { $('#result').text('orientation=' + window.orientation); } }); </script> <style type="text/css"> div { background: -webkit-gradient(linear, left top, left bottom, from(#aab7ca), to(#7189a4)); color: #ffffff; padding: 6px; font-size: X-large; font-weight: bold; text-align: center; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px; } </style> </head> <body> <div id="result">傾き表示</div> </body> </html>
2. CSS3の活用
CSS3で角丸画像を表現するクラス定義
.radius { border-radius: 5px; -webkit-border-radius: 5px; -moz-border-radius: 5px; }CSS3でドロップシャドウを実現するクラス定義
.shadow { -moz-box-shadow: 1px 2px 3px #999; -webkit-box-shadow: 1px 2px 3px #999; }
ブラウザの進化で昔は使えなかった、角丸やドロップシャドウをスマホではCSS3に対応しているので使用できるようになりました。PCサイトでは画像で行わざるを得なかったものが、CSSだけでできるようになったためページサイズも小さくなります。3G回線でも遅くはないのですが、ユーザーの利便性・サイトの反応の良さを考えるとファイルサイズは小さいほうがいいため、画像を使わなくてもCSSでできるのであれば、そちらを使えばいいということでした。
(ここでウサギさんの首がもげたのはないしょですw)
border-radiusの仕様としては、以下のW3Cの仕様を見るのが一番です。
The 'border-radius' properties
http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-radius
また、box-shadowについても、W3Cのサイトを確認するのがいいかと思います。
The ‘box-shadow’ property
http://www.w3.org/TR/css3-background/#box-shadow
3. 表の最適化
PCサイトのテーブルでは、情報量を詰め込んだ状態となっているため、スマートフォンサイトで最適化する場合には画面サイズの問題場、情報量を削る必要がどうしても発生してきます。
Colorboxは9kbとサイズも小さいのでおすすめということでした。
ただ、実際にGALAXY Sで動かしてみましたが、動きませんでした。
動かすとテーブルは表示できるのですが、
アンカーをクリックすると以下のように表示途中で止まってしまいました。
一応、エミュレータで動かすと以下のようになったので動かないことはなさそうですが、細かいことは確認していません。
画面遷移や、ダイアログを表示せずに単純に画面上に詳細情報を表示する方法としてはアリだと感じました。
lightboxのjQueryプラグインは http://leandrovieira.com/projects/jquery/lightbox/ にありました。exampleで具体的なサンプルを確認することもできます。
基本的には、判定した後にスマホ用のサイトへリダイレクトさせます。
4. スマホアクセス判定
スマートフォンのユーザエージェント一例
iPhoneやAndroidといった文字列を探して、もしそれらの文字列があればスマホ用のサイトへリダイレクトする。iPadは解像度が高いため、PCサイトへ移動させている。
Androidタブレットが多く出てきた際には、解像度によって分類する等考慮が必要になる。
- JavaScriptでの対応のデメリット
JavaScriptのオフでアクセス判定ができないため、通常のPCサイトが表示される。ただし、通常は問題には奈良にあ。
- JavaScriptでの対応のメリット
クライアントサイドで完結、実装が容易。。
5. Viewportを使ったハック「Holy Grail」
デフォルトのブラウザでPCサイトを閲覧したときに、縮小されて文字が小さく、拡大しないとサイトを閲覧することができないといった経験ありませんか?
5. Viewportを使ったハック「Holy Grail」
こういった場合には、viewportを設定することでスマートフォンの解像度に最適に表示される。
5. Viewportを使ったハック「Holy Grail」
ViewportとはHTMLのヘッダ内に記述するmetaタグのひとつで、開いたウィンドウの中で実際に描画が行われる領域の事を言います。
[記述例]<meta name="viewport" content="width=device-width, maximum-scale=2">viewportのデフォルト値が横場は980pxとして設定されているため、PCサイトを表示すると文字がとても小さく表示されます。
補足:Viewportで指定できるプロパティ
width ビューポートの幅。デフォルト値 980
200から10000までの横幅を指定可能。
[device-width]を指定可能height ビューポートの高さ。
デフォルト値は横幅とアスペクト比から計算される値。
233から100000までの範囲を指定できる。
[device-height]を指定可能。initial-scale 倍率の初期値。デフォルトはサイトを可読エリアにフィットさせる設定。 minimum-scale 倍率の最小値。デフォルトは0.25。 maximum-scale 倍率の最大値。デフォルトは1.6。 user-scalable ユーザーが拡大・縮小操作を出来るかどうかをyes/noで指定する。デフォルトはyes。
device-widthを指定すると、アクセスした端末に合わせた解像度を自動で設定できるため基本的にはdevice-widthでいいのかと思います。
5. Viewportを使用したハック「Holy Grail」
縦画面から横画面に表示を変更すると画面が動的に拡大されてしまい、ユーザが閲覧するためにページを縮小する必要がでてくる。
5. Viewportを使用したハック「Holy Grail」
[Holy Grail]とは
maximum-scaleに0.6667という値を設定すると、端末をPortrait(縦向き)にしてもLandscape(横向きに)にしても、文字サイズが変わらないという知る人ぞ知る伝承のハックです。(嘘です。たぶん有名です!)[記述例]
<meta name="viewport" content="width=device-width, maximum-scale=0.6667">
5. Viewportを使用したハック「Holy Grail」
※補足説明 - 0.6668について。
480*0.6667=320.016
また
480÷0.6667=719.964
という計算でPortraitとLandscapeの、どちらのモードでも表示領域上の幅が画面にフィットした形で表示されます。
5. Viewportを使用したハック「Holy Grail」
!!HolyGrailを使用する場合の注意点!!
maximum-scaleの設定が1以下のため、user-scalableを許可した場合でもユーザ任意で拡大することができなくなってしまいます。
ユーザビリティを考慮して、拡大も出来たほうが閲覧するユーザとしてはいいですよね。
表組みのように表示が崩れては可読性が著しく低下する、といった状況の回避策としてコンテンツ内容に合わせて仕様を検討してください。
ようするに、拡大ができないため文字が読めないということが起こる可能性があるということのようです。ただ、意外とYahooとかのスマホサイトも拡大が当たり前のようにできないので、ある程度以上の字の大きさを確保したらいいのかなと感じます。
PC用は画像一枚でヘッダ部分を作った。
スマホ用は、画像1枚と背景青のdivとテキストを重ねている。
それで、縦にした場合も横にした場合もほぼ同じように表示される。
まとめ
- ナビゲーションは芋ズル式に単純に。レイアウトは1カラム基本でこれまた単純に
- 将来的にはPCサイトをダイエット/単純化して管理しやすく保つとよいよ
- ユーザーエージェント判定とか縦横判定なJSの活用はひっすだよ
個人的にもPCサイトをダイエット/単純化するというのに賛成です。必要な情報をシンプルに伝えていくのが必要かと思います。最近は特に情報がありすぎていて逆に見づらい状態になっているサイトもあります。スマホ向けに整理したサイトの場合には今までより使いやすい、見やすいサイトになるということも考えられます。
セッション通じての感想としては、全体的に実際のサイトの構築経験を活かして、実際に考慮しなければいけないこと、ハマリどころを具体的に説明していただいてスマホ向けサイトのノウハウという面で非常に有用な内容でした。