入力フォームに関わるアーキテクチャ

入力フォームは、特にコンシューマ向けWebサイトにおいては、いかに使いやすくストレスのないフォームを作り込めるかが、CVR(コンバージョンレート)を向上させるための肝であります。 したがって必然的に入力フォームに関する要求は厳しくなりがちなので、事前にしっかり設計しておきましょう。

入力チェックのアーキテクチャに関しては別章で解説します。

文字の正規化

Context

  • 配送や名寄せなどバックオフィスのシステムで受け付ける文字が決まっている。
  • ユーザに余計な入力ストレスは与えたくない。

Force

  • 半角/全角文字はユーザに区別して入力してもらわなくても自動で揃えることができる。
  • ひらがな←→カタカナも同様に自動で揃えることができる。

Solutions

入力エラーにするのではなく、受け取ったシステム側で正規化する。

Examples

実装はICU4Jを使うのが一般的か?

使用可能文字以外の入力ブロック

Context

  • 入力できたくせにいざボタンを押すとエラーがでるのではユーザは離脱してしまう

Solutions

フィールドに入力可能な文字帯域を決めておき、違うものが入力されたらリアルタイムに削除することで、ユーザ。

※ これは乱用すると逆にコンバージョンを落としてしまう危険性があるので、数字のみくらいにとどめておくのがよい。

必須項目のカラーリング

Context

  • 必須項目であることを明示し、ユーザの入力ストレスを軽減したい。

Force

  • 入力項目が必須かどうかは、入力チェック属性の中でも取り立てて最重要なものである。

Solutions

必須をであることを分かりやすく明示する。入力されていないことがわかるように、フォームオブジェクトに赤系の背景色を加えるとさらに分かりやすくなる。

必須

ふりがな自動入力

Context

  • 漢字氏名を入力したのに、カナ氏名くらい自動で入らないの?

Force

Solutions

① 漢字氏名の入力のKeyPushイベントをとり

② 氏名辞書をもとにサーバサイドでカナ変換する

送信ボタンブロック

Context

  • 入力チェックエラーに辟易して離脱するユーザを減らしたい。

Force

  • フォームをサブミットしてからエラーが表示されたときの落胆たるや。

Solutions

送信前にクライアントサイドでバリデーションし、エラーがあるとフォームのサブミットイベントをキャンセルする。

validateError

郵便番号住所変換

Context

Solutions

3桁ほど入力したら候補を表示し、入力のたびにインクリメンタルサーチして絞り込む。

Examples

http://www.cedyna.co.jp/card/lineup/detail/omc/

プルダウンメニューの初期値

Context

  • 多くのユーザにとって選択を楽にできるようにしたい。

Force

  • アイテム数の多いプルダウンから目的のものを選択するのは苦痛である。

Solutions

サイトのユーザ層がもっとも多く選ぶ項目を初期値として表示しておく。

Examples

エバーライフ https://www.everlifegroup.jp/cash_register/cart_information

メールアドレスドメイン補完

文字カウンタ

Context

  • 特にテキストエリアの入力において、どれくらいの文字数を許容するのか明示したい。

Force

  • テキストエリアのmaxlengthはIE9では効かない。
  • そもそも字数を超えて入力し、校正する、というユーザの挙動を想定すると、制限数以上入力できなくするmaxlength指定は使いやすいUI足りえない。

Solutions

文字カウンタを設置する。

  • 制限数を超えた文字は赤くするなどして分かりやすくする。
  • Unicodeの場合、サロゲートペアは１文字として数える。(これはデータベースでサロゲートペアを１文字として扱う必要があることを意味する。)

サロゲートペアもJavascriptで正しく数えるには、Twtterのライブラリを使うとよい。 https://github.com/twitter/twitter-text

Examples

エラー項目のフォーカス

Context

  • エラーの箇所が分かりにくい。

Solutions

  • エラーになった箇所だけ入力フォームを表示し、正しく入力できた項目は非表示にする。

Examples

エバーライフ

入力ステップ表示

Context

  • ユーザの途中離脱を防ぎたい

Force

  • 終わりの見えない入力フォームは離脱の原因になる。

Solutions

ページ上部に、入力のステップを表示し、現在地もわかるようにする。

Examples

https://plus.cedyna.co.jp/register/sub.asp

ソフトウェアキーボード

Context

  • キーロガーの被害から守る。
  • 長い入力を補完させる。

Solutions

専用のソフトウェアキーボードを作る。

パラメータの自動トリム

Context

  • 空白だけの入力を許可したくない。
  • コピペ入力の場合、文字の前後に空白が入ることがあり、空気読んで前後の空白はトリムしてほしい。

Solutions

入力値の前後の空白文字を削除する。

Unicodeの世界では空白文字は、数多くあるのでこれを全部トリムしておいたほうが良い。

  • \u0009 HORIZONTAL TABULATION
  • \u000A LINE FEED
  • \u000B VERTICAL TABULATION
  • \u000C FORM FEED
  • \u000D CARRIAGE RETURN
  • \u001C FILE SEPARATOR
  • \u001D GROUP SEPARATOR
  • \u001E RECORD SEPARATOR
  • \u001F UNIT SEPARATOR
  • \u0020 SPACE
  • \u00A0 NO-BREAK SPACE
  • \u1680 OGHAM SPACE MARK
  • \u180E MONGOLIAN VOWEL SEPARATOR
  • \u2000 EN QUAD
  • \u2001 EM QUAD
  • \u2002 EN SPACE
  • \u2003 EM SPACE
  • \u2004 THREE-PER-EM SPACE
  • \u2005 FOUR-PER-EM SPACE
  • \u2006 SIX-PER-EM SPACE
  • \u2007 FIGURE SPACE
  • \u2008 PUNCTUATION SPACE
  • \u2009 THIN SPACE
  • \u200A HAIR SPACE
  • \u200B ZERO WIDTH SPACE
  • \u202F NARROW NO-BREAK SPACE
  • \u205F MEDIUM MATHEMATICAL SPACE
  • \u3000 IDEOGRAPHIC SPACE
  • \uFEFF ZERO WIDTH NO-BREAK SPACE

http://qiita.com/suin/items/1a878dd3c7e7a4b14039

クライアントサイドでバリデーションかける場合は、クライアントサイドでトリムする。

コラム

数値と数字の区別

入力フォームの設計で、数字型と数値型を区別せずに定義を誤ることが多い。HTML5から導入された<input type="number"/>は、数値の入力を表すもので、iOSやAndroidの場合はソフトウェアキーボードが数値入力専用のものに切り替わる。このキーボードの形だけみて、郵便番号のフィールドを<input type="number"/>で定義していたシステムがあった。郵便番号は0始まりのものもあるのだが、「0120123」のような入力はブラウザ側で「120123」として解釈され送信されることになる。