WordPressのresponsive previewは画面幅を替えるだけでなくmenuとformを操作する

responsive previewでは、mobile、tablet、desktopの幅でsiteの見え方を確かめられます。ただし、画像が収まっているだけでは十分ではありません。menuを開き、本文を読み、formへ入力し、buttonを押せることまで確認します。

WordPress 4.5 Beta 1の公式案内は、Customizerでsiteをmobile、tablet、desktopのcontextで見てから外観を変更できるresponsive previewを紹介しています。この版は開発中であり、本番siteへ入れずtest siteで試すよう案内されています。

responsive previewでまず見つけるのは、どの画面幅でlayoutが変わるかです。文字が折り返す位置、二列が一列になる位置、画像が切り取られる位置を確認できます。しかし、幅を変えた画面は、実際の利用者がmenuを開いたり、入力欄へ文字を入れたりした結果までは示しません。表示の確認と操作の確認を続けて行い、片方だけで公開を決めないようにします。

Customzierの画面で外観を変える前にpreviewを見るのは、変更の前後を比べるためです。先に画面の状態を見ずに色、余白、画像をいくつも変えると、どの変更でmenuやformが崩れたかを追えません。変更する項目を一つにし、同じ代表pageを同じ順に開きます。見た目がよくなったとしても、操作ができなくなっていれば、その変更は採用できません。

画面幅と操作を別に確認する

画面幅を変えると、文字の折り返し、画像の切り取り、columnの並び方は見つけられます。しかし、menuが開くか、formの入力欄が隠れないか、buttonが押せるかは、見ているだけでは分かりません。

特にmobileでは、desktopの二列が一列になると、説明とbuttonの距離が変わります。画面に収まっていても、利用者が条件を読む前にbuttonだけを見る状態なら、順番を直します。

menuも、閉じた状態のiconだけを見て終えません。開いたときにlinkが最後まで読めるか、長いメニューが画面の下で切れないか、menuの外へ戻れるかを操作します。階層があるmenuなら、親項目を押したときに移動するのか、子項目を開くのかも確認します。desktopでhoverして出るものが、mobileでどう開くかは同じとは限りません。画面幅を替えたら、操作の入口も替わっていないかを見ます。

formでは、入力欄が横にはみ出さないことに加え、keyboardが出たときに送信buttonが見えるかを確認します。必須項目を空にした場合の案内、入力内容が長い場合の折り返し、送信後にどこへ戻るかも、利用者の操作に関わります。画面にformが表示されていても、最後まで送信できなければ問い合わせの入口として機能していません。確認用の内容で一件送り、送信画面と受信先を分けて確かめます。

代表pageを決めて同じ順序で試す

すべてのURLを最初から確認しようとすると、作業が止まります。まず、siteの構造が違うpageを三つから五つ選びます。トップpage、記事page、一覧page、問い合わせpageがあれば、その組み合わせで十分です。

代表pageを選ぶときは、見た目が違うだけでなく、使うtemplateや操作が違うものを選びます。トップpageは大きな画像やmenuを、記事pageは長い本文や画像を、一覧pageは繰り返すcardやpage送りを、問い合わせpageは入力と送信を確認できます。同じtemplateのURLを何本も開くより、違う構造を一件ずつ選ぶ方が、限られた確認時間で問題を見つけやすくなります。

確認表には、URL、画面幅、見る場所、操作、期待する結果、実際の結果を書きます。たとえば「問い合わせpage、mobile、送信button、入力して送信、完了案内と受信を確認」という形です。崩れた画面を見つけたとき、URLだけでは再現できません。どの幅で、menuを開いた後か、どの文字を入れた後かまで残せば、CSSやtemplateを直す人も同じ状態を作れます。

1. Customizerのpreviewをmobileへ切り替え、各代表pageを開く。
2. menu、本文、画像、buttonを上から確認する。
3. formがあるpageは、入力から送信後の案内まで操作する。
4. tabletとdesktopでも同じpageを開き、layoutだけでなく操作の順番を比べる。
5. 崩れた場所は、URL、画面幅、操作内容を記録してからCSSやtemplateを直す。

previewは変更前に確かめる道具です。確認せずに外観を保存すると、どの変更で崩れたか分からなくなります。変更を一つ行い、同じpageと操作をもう一度試します。

一つの変更を確認する間に、menu構造、画像、formの項目までまとめて変えないことも必要です。画面幅で崩れた原因がCSSなのか、画像の寸法なのか、HTMLの順番なのかを分けられなくなります。修正は小さく行い、直した箇所と確認した画面を対応させます。見た目の問題と送信の問題を同じ修正として扱わない方が、戻す場合にも範囲を絞れます。

previewを実機確認の代わりにしない

Customizerのpreviewで問題が見つからなくても、実際のmobile browserでの表示と操作は別に確認します。previewは確認範囲を絞るために使い、公開前の操作確認をなくす理由にはしません。

実機では、指でmenuを押す、本文をscrollする、入力欄へ文字を入れる、外部linkを開いて戻るという流れを通します。利用者が使う端末をすべて再現できなくても、少なくとも主要な画面で、画面を縮めただけでは分からない操作を確認できます。previewと実機で結果が違った場合は、どちらかを正しいと決めつけず、幅、browser、操作を記録して、どの条件で起きるかを調べます。

最初の一手は、問い合わせpageをmobile幅で開き、menuを閉じた状態から送信完了まで操作することです。そこに問題がなければ、ほかの代表pageへ広げます。