2015年4月1日（最終更新日：2015年4月4日）

モバイル対応しました。 – デザイン編

この度、Sheepen.netのデザインをモバイルに対応させました。
もともとレスポンシブデザインで構想して組んでいたのですが「とりあえずアップロードしてから…」と思い、モバイル用にメニューを作るなどのユーザビリティ部分を考慮した本質的なモバイル対応を後回しにしていたのです。
基本的には内容・ターゲット的にスマホで見るようなブログではないんですけど、Webデザイナーのブログがしっかりモバイル対応してないってどうなの？　って話ですもんね。

今回やっと基礎部分の対応が出来たので、その内容と実際のコーディング部分を記録しておきます。まとめると長くなるので今回はデザイン編です。
※まだ開設後まもないので、ちょくちょく変わる可能性が高いです。

【別記事はこちら】

デザイン編
コーディング編

デザイン

まず以下がモバイル対応させるにあたって頭に浮かんだ点です。

画面幅が狭くなるのでカラム構成を変える。
フォントサイズの調整。
リンク部分のタップのしやすさ。
シグニファイアの意識。
モバイル用メニューを作る。

備忘録的な感覚でそれぞれ簡単に説明していきます。

１カラム構成に。

これはそのままです。Sheepen.netでは２カラムデザインを採用していて、サイドバーを利用しています。これがスマホ等のモバイル機器では画面の大きさが小さくなるので、見づらくって仕方ないという話です。

つまりサイドバーを下に落とすなりして１カラムにしてしまえば良いのですが、ここで少し悩んだのがiPad等のタブレット端末について。
今回はCSSでメディアクエリーを使ってPC用・タブレット用・スマホ用と３段階にデザインを組んでいくわけですが、タブレットって結構サイズも大きくてそもそもがPCと同じように使うように出来てるんじゃないかっていう。画面タッチで感覚的に扱えるパソコンという立ち位置なのではないか。つまりタブレット用にデザインを変えるのって余計なのかな？　ということです。

そこで決め手になったのが画面のアスペクト比（縦横比）です。
PCの場合だいたいが横長のモニタで見ますが、タブレットとかスマホのモバイル機器って縦長の方向ににも使えるようになってますよね。むしろ大半の人が縦長の方向に持つのを標準としているんじゃないでしょうか。
（この画面の向きですが一般的に縦向きをPortrait、横向きをLandscapeと呼びます。それぞれ直訳で肖像（画）、景色（画）という意味です。おそらく絵画のキャンバスの向きに由来しているのでしょう。）

で当たり前なのですが、そもそもなんで２カラム以上だとそれぞれが小さくて見づらいかというと画面の横幅が狭いからなんですね。タブレットで代表的なiPadの中で一番画面サイズの小さいiPad miniを例に取ります。
iPad miniの解像度は縦向きで横 × 縦 = 768 × 1024です。
そして横向きではその逆で横 × 縦 = 1024 × 768です。
つまり、横向きに使えばすこし古いPCモニタくらいの解像度なんですね。だったら横向きではPC用のデザインを表示した方が良いんじゃないかと思いまして。

ではこの「iPad mini（初代iPadも同じ解像度）の縦向き」を基準にデザインを分けよう。ということでメディアクエリのブレイクポイントを768pxとし、それ以下では１カラム構成とすることにしました。

ちなみに

※ゴチャゴチャしたくない方はこの節を読み飛ばしてください。
ちなみに画面の大きさと解像度は別物ですが、今回のようにメディアクエリーを考慮する際は解像度で考えればだいたい大丈夫です。
デバイスにはそれぞ物理的な解像度とは別の解像度が設定されています。正確な名称があるのかわかりませんが、ブラウザ解像度とかCSS解像度とか呼ばれていますね。これがうまいことユーザーの目の距離なんかとあいまって画面のサイズ感とリンクしてるんです。（と、僕は思っています。）

これについて詳しく書くと軽く１記事出来てしまうボリュームになるのでまたの機会にということで。
Retinaディスプレイなんかを考えると混乱してくるかもしれませんが、とりあえずはmetaタグでviewportの設定をdevice-width, initial-scale=1にしていれば大丈夫。（initial-scale=1だけでもOK）

なんだか誤解を招く表現になっているような気もしますが…。

フォントサイズ・タップ領域の大きさ・シグニファイア

この３つに関してはWebデザインと言えばという感じでよく出てくるのですが、正直あまり意識はしていません。
例えばAppleでは「アプリケーション内のタップ可能な要素には、約44 x 44ポイントのターゲット領域を割り当てる。」というガイドラインを設けていますが、これってどうしたらモバイル端末でも閲覧・巡回しやすいかなって考えていれば、主にタップして欲しい部分に関しては自然とそうなるんですよね。ここで重要だと思うのが「タップして欲しい部分に関しては」ということ。
僕がこれらの要素について考えすぎたくないのは、例えば全てのリンク要素をこのサイズ以上にしたら逆にUXの質を下げることになるんじゃないかって考えがあるからなんです。

別にタップしてほしくもないリンクは小さくていいんです。読まなくていいけど形式上置いておきたい文章だってあります。その部分のフォントサイズを大きくして他の文字とのコントラストを下げたら元も子もないです。

次にシグニファイア。
知らない人用に簡単に説明すると、シグニファイアっていうのは「要素そのものが表す性質」みたいな感じです。「ボタンみたいなデザインだから押せるんだろうな」「右向きの三角形だから再生ボタンか」みたいな。
これはWeb上ではとても重要です。たまにボタンみたいなデザインだけど押せないんかーい！　みたいなデザインのサイトもあって、それに出くわすとかなりストレスが溜まります。

モバイルではホバー効果が使えないので、押せるとこは押せますよってデザインにしたり自然とユーザーを誘導することが大事なんです。…大事なんですけど、これも意識しすぎるとUXの向上といったそもそもの目的から外れてしまうので、純粋にどうしたらユーザーにとって自然に使えるかを考えて設計するのが一番だと思うんです。

今回のデザインを例に挙げます。

これは新着記事一覧ページですが、「続きを読む」をここを押してねって具合にフラットなボタンらしくしています。で、このボタンデザインを作ればハイ完成なのかというとそれだけでは本質を見失っていて、今回の場合「記事のタイトル」「アイキャッチ画像」「抜粋文」どれをタップしても記事ページに飛ぶようになっています。その記事に関する部分のどこかをタップすればその記事のページに飛ぶ。こういった自然な流れがUXにとって重要なのかなと。
じゃあこの「続きを読む」ボタン要らなくない？　って人もいるかもしれないですが、極端に言えばこのボタンがないと記事に続きがあるってことがわかりづらいので続きがあるよっていう目印的な役割をしています。
※誤解を生みそうですが、記事のタイトル・アイキャッチ・抜粋文にリンクを貼ったのはモバイル対応ではなく最初の段階からです。

なのでこれら「フォントサイズ」「タップ領域のサイズ」「シグニファイア」なんかの要素はデザイン時点で絶対条件として取り入れるのではなく、あくまでチェック項目であったり、迷った時の判断材料にしたほうがいい物が出来るんじゃないかなっていう素人なりの持論でした。自然な流れは自然なデザインからって感じですかね。UI設計の専門家となればこの考え方はダメでしょうけどね。
本末転倒は避けたいところです。

モバイル用メニュー

これは色々考えました。単純にロゴの下にキレイに並ぶようにしたり、ハンバーガーボタンをタップしたらそこから出てくるようにしたり、画面を横にスワイプしたら出てくるようにしたり。実際にコーディングまでしたけどボツにした案もあります。最終的に今回採用したのは「画面下固定表示のメニュー」です。

理由としては多くの人に馴染みのあるアプリライクなメニューにしたかったのと、スマホで見るとどうしてもページが縦長になってしまってメニューを使うのにわざわざページの端まで行くのが面倒だからです。（TOPに戻るボタンがあったとしても）
個人的には横スワイプが好きなんですけど、認識できない人がいそう（文言なりアイコンで示しても記事を読んでいる内に存在を忘れそう）なのと、僕のスキルではスワイプでメニューを出すのはプラグイン無しでは無理そうだからです。
なにかと手作りで出来るものはしたい性分なんです。

上でなくて下に固定な理由は、ページの最上部に行った時にしっくり来るデザインが浮かばなかったのと、上だと親指が届きづらいからです。下は下で誤タップの懸念が残るんですけどね。
あと、テキストフォームにフォーカスした時邪魔なんですよねー。どうしたもんか。

考慮したポイントとしては、タップしやすいサイズ、広告などではなくブログの一部だとわかるデザイン(色)、topに戻るボタンと検索フォームを組み込むってとこです。
色はサイトのメインカラーを使ったんですが、少しだけ透明にすることでまだコンテンツが下にあるよってわかるようにしました。不透明だとファーストビュー等でキリのいいところ（続きを読むボタンの直後とか）にメニューが来た場合、そこでページが終わりだと判断されかねないからです。あと少しだけ圧迫感がなくなるのもよかったです。

TOPに戻るボタンと検索フォームを入れているので自ずと２層構造になっています。
それに、こうすれば固定ページが増えてもボタンが小さくならないで済みますね。