Aggregator

こんにちは。おざえりです。

Webサイトに必ずといってよいほど存在する入力フォーム。みなさんは、入力する際にストレスを感じたことはありませんか？

私は先日某サイトで個人情報を変更したのですが、入力を間違う度にページを戻され入力情報は消えるしイライライラ・・・すごい労力と時間を費やしてしまい、ネットって便利なはずなのに？と疑問に思ってしまいました。
というわけで、当サイトのフォームを例に「ストレスフリーなWeb入力フォーム」について調べてみると以下の3つが大事であることが分かりました。

• シンプルな要素構成
• Web入力フォームの最適化
• 目的を明確にし説明すること

マルチデバイスの普及が加速し、Webサイトのデザイン傾向としてミニマルでシンプルなものが求められるようになり、入力フォームの記入がより簡単になっています。これまでもユーザーは、個人情報の盛り込まれた長い入力フォームを避ける傾向にあり、今後はシンプルなフォーマットが増えていきます。また、多すぎる質問や記入欄はせっかく関心を持ってくれたユーザーを遠ざけてしまう原因になりかねません。不必要なものはなるべく削除し、シンプルなフォームを心がけましょう。

特に電話番号やプライバシーに関わる項目が必要な場合は、なぜその項目の記入が必要なのかきちんと説明するとよいでしょう。

入力条件を事前に伝える

入力条件は（例えば、パスワードの最小文字数を必要とするなど）は、フォームを送信する前に、フォームの中で記載しましょう。

プレースホルダーを使用し入力例を表示する

プレースホルダー（placeholder）とは、入力フォームの記入欄へ入力に関するヒントを示す仕組みです。入力フォームに何が入るかを明確にするのに役立ち、入力が促進されます。

注意点として、ユーザーが自分で入力した情報と勘違いしないように視覚的な工夫が必要です。また、入力し始めるとプレースホルダーの記述は消えてしまうのでラベル代わりに使用することは好ましくありません。

インラインバリテーションを使用しエラーをリアルタイムでチェックする

インラインバリデーション（Inline Validation）とは、フォームを入力する際にエラーをリアルタイムでチェックする仕組みです。入力ミスが発生した時点ですぐ通知してくれるので、Webページ内をスクロールしたり更新することで入力情報が消えてしまうというストレスがなくなります。
インラインバリデーションの仕組みはジェイクエリー（jQuery）で実装できるようです。

ユーザーが簡単に修正できるように、エラーメッセージは入力フィールドの隣へ配置しましょう。

必須項目と任意項目を分かりやすく区別する

入力が必須の項目と任意の項目をはっきり区別できるようにします。必須項目へマークを追加するなどの対応がわかりやすいでしょう。

適切なラベルを使う

ラベルは分かりやすく簡潔にし、ユーザーに安心感を与えます。また、ユーザーが全体を見渡せるように入力フィールドの横ではなく上に配置します。そうすることで視線を左右に動かすことなくスムーズに進むことができます。デザインにもよりますが、この配置は表示面積の小さいモバイル環境で最も有効的です。

一般的には視線の余分な動きが増えれば増えるほどコンバージョン率は下がる傾向にあります。配置を改善することで視線の無駄な動きと時間が軽減されます。

 分かりやすいボタン用テキストを使う

ボタンデザインは、クリックしたあとに何が起こるのか想定できるものにしましょう。漠然とした「Submit」などの表記は次のアクションが不明でユーザーにとっては不安要素となります。

Web入力フォームを完了してもらうことは、言い換えるとユーザーの信頼を得ることです。
なぜその情報が必要なのか、明確な理由を持ち説明することが重要です。またセキュリティーはコンバージョンの鍵といっても過言ではありません。個人情報の取扱についてもヘルプやガイドラインを一緒に提供しながら、シンプルに伝えるとよいでしょう。

Googleの研究レポートによると、上記を改善しユーザーテストした結果、Web入力フォームを完了するのに良い影響を与えたと報告しています。
また、Webユーザビリティの専門家であるルーク・ウロブルスキー（Luke Wroblewski）氏が行ったインラインバリテーションのユーザーテストによると、次のような結果が出たと報告しています。

• コンバージョンが22％増加
• 発生したエラー率は22％減少
• 満足度評価が31％増加
• フォーム入力完了までの時間が42％減少
• 視線が移動する回数が47％減少

詳しい内容は参考記事をご覧ください。

参考記事：

• Web Design Trends That Will Disappear in 2014
  2014年消えてゆくデザイントレンド
• Simple is better – Making your web forms easy to use pays off
  Googleレポート
• Inline Validation in Web Forms
  ルーク・ウロブルスキー（Luke Wroblewski）氏（モバイルファーストの提唱者）による検証

米Googleでは、Wikipediaのページが検索結果に表示される場合、検索クエリによってはそのクエリに関する“事実” (Fatcs) がスニペットの下に表示されるようになった。そのエンティティに関する事実を抽出するGoogleのセマンティック技術の発展を垣間見ることができるという点では興味深い機能と言えそうだ。

- 米Google、ウィキペディアからの検索結果に“事実”をスニペットに表示 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

2014年6月14日（土）ベルサール九段　イベントホールで開催したCSS Nite LP, Disk 35「マルチデバイス対応 2014」のフォローアップとして、秋葉 ちひろさん（ツクロア）、堀内 敬子さん（Flask）の『UI設計に役立つ！ 意外と知らないiOS/Androidの流儀』セッションのスライドなどをシェアします。

• スライド

フォローアップ

堀内敬子：

iOSの解説を担当しました堀内です。
長時間お付き合いいただき、ありがとうございました。
iOS/AndroidのUIを知るという、少し異色なセッションでしたが、モバイルで使いやすいUIを作るための基礎知識やヒントとしてご活用いただければ幸いです。

スライド中の参考資料にも書きましたが、WWDC 2014のセッションビデオは、デベロッパ以外にも公開されています。技術の話だけでなく、使いやすいUIを作るのに役立つ内容、Apple流のプロトタイピングの方法なども取り上げられていますし、新しいiOS/OS Xの世界がかいま見れて面白いです。英語ではありますが、聞き取りやすい英語で話してくれているので、比較的理解しやすいと思います。

セッション後の質問の「Androidのうらやましい点」についてですが、あらためて考えてみまして大きく以下の2点がありました。

1. ホーム画面
Androidではホーム画面をカスタマイズできるのがすばらしいと思います。iOSはほぼ何もできません。iOS 8から通知センターにウィジェットを置けるようにはなるものの、それでもAndroidほど自由さはありません。

2. Android Wear
Android WearとはウェアラブルデバイスのためのAndroid OSです。腕時計型のデバイスは早く使ってみたいです。

いただいた質問への回答

【質問】WebViewばっかりのアプリだとiOSの審査でリジェクトされると聞いたのですが、ハイブリッドだとどうなんでしょうね？

WebViewばかりであるのが問題というより、Webサイトをそのままクリッピングしたものであったり、アプリならではの機能がない場合などに、アプリである必要性がないと判断され、リジェクトされることがあります。 App Store Review Guidelinesの12.3と2.12が関連項目です。

秋葉ちひろ：

Androidの解説を担当しました秋葉です。
80分という長時間、アプリのデザインに馴染みのない方には少し長く感じられたかもしれませんが、最後までお聞きいただきありがとうございました。
懇親会では、アプリのUIがこーんなにもWebとは違って、しかもiOSとAndroidでそれぞれ違うなんて、全部やるのは大変ですねということが話題にあがりました。
ですが、今後は他にもいろいろなインターフェイスをもつデバイスが増えてくるはず、キャッチアップしておいて損はないと考えています。

公開したスライドにも各ガイドラインの情報はかなり詰まっていますが、それだけでもの足りない方は、ぜひガイドラインそのものを読んでみてください。
Web制作にも役に立つものも多いはずです。

セッション中に触れられなかったものの参考サイトを挙げておきます。

• 4. UI ガイドライン - ソフトウェア技術ドキュメントを勝手に翻訳

たにぐちさんの基調講演でも、Androidが伸びてくるだろうとお話がありましたが、どちらが優れているということは特になくて、それぞれ良い点とイマイチな点を持ち合わせていると思います。
安いSIMも出てきていますし、Androidをさわったことがない方も、1台SIMフリー版を買って持っておくといいと思います。仕事柄、両者を「使って」おくことは非常に重要です。

今回の少しマニアックなセッションが、少しでも今後の制作に役立ちそうと思っていただけましたら幸いです。ありがとうございました。

2014年6月14日（土）ベルサール九段　イベントホールで開催したCSS Nite LP, Disk 35「マルチデバイス対応 2014」のフォローアップを公開します。

• （1）たにぐちまことさん（エイチツーオー・スペース）
• （2）小川裕之さん（ツクリベ）
• （3）北岡恵子さん（NTTレゾナント）
• （4）松田直樹さん（まぼろし）
• （5）たにぐちまことさん（エイチツーオー・スペース）
• （6）宮崎洋史さん（環）
• （7）秋葉ちひろさん（ツクロア）、堀内敬子さん（Flask）
• （8）木村哲朗さん（まぼろし）、西畑一馬さん（まぼろし）

2014年6月14日（土）ベルサール九段　イベントホールで開催したCSS Nite LP, Disk 35「マルチデバイス対応 2014」のフォローアップとして、木村 哲朗さん（まぼろし）、西畑 一馬さん（まぼろし）の『トラブルシューティング 2014』セッションのスライドなどをシェアします。

• スライド

フォローアップ

「トラブルシューティング2014」のセッションを担当した西畑と木村です。

漫談形式を多くの方にご好評いただいたようでありがとうございます。

いくつかの質問をいただきましたので、ブログで解答を行なっております

• CSS Nite LP35「マルチデバイス対応 2014」終了しました。 - to-R

マルチデバイス対応では日々新しい端末やOSが登場しており、これまで当然のように利用できたことが利用できなくなることがあります。日々、情報をウォッチしておく必要があります。

これからも一緒に終わらない戦いに挑んでいきましょう！

最後になりましたが、参加された皆様、長時間おつかれさまでした&ありがとうございました。

2014年6月14日（土）ベルサール九段　イベントホールで開催したCSS Nite LP, Disk 35「マルチデバイス対応 2014」のフォローアップとして、北岡 恵子さん（NTTレゾナント）の『スマホの検証が10倍はかどる！Remote TestKitの紹介』セッションのスライドなどをシェアします。

• スライド

フォローアップ

Remote TestKitは、スマホに関わる皆様のお仕事を少しでもラクにできれば、というサービスです。今回ご紹介しきれなかった機能もたくさんありますので、是非実際にご利用してみてください。
http://appkitbox.com/testkit/

会場やアンケートで頂いたご質問

Q1. 誰かが端末を使っている間は、ほかの人はその端末を利用できないのか？
A1. 実機を利用しているため、誰かが利用している間はその端末を利用することはできません。ですが、一度のレンタルが30分単位ということもあり、端末の取り合いになるような事例はあまりありません。

Q2. セキュリティが心配なのですが…
A2. ご利用が終了すると、端末は自動で初期化されます。アプリケーションや入力したパスワードを入れたままにしておいても、次に使う方には初期化された状態でお渡しとなりますので、問題ありません。安心してご利用ください。

2014年6月14日（土）ベルサール九段　イベントホールで開催したCSS Nite LP, Disk 35「マルチデバイス対応 2014」のフォローアップとして、宮崎 洋史さん（環）のPRセッションのスライドなどをシェアします。

• スライド

フォローアップ

ユーザーにとって最高の体験を提供するにはデバイスや店舗は「異なった役割を担うべき」というのがメイシーズの考え。サイト制作の上流工程に携わるチャンスが巡ってきたときに参考にしていただけると幸いです。

2014年6月14日（土）ベルサール九段　イベントホールで開催したCSS Nite LP, Disk 35「マルチデバイス対応 2014」のフォローアップとして、たにぐち まことさん（エイチツーオー・スペース）の『スマートデバイス時代のJavaScript』セッションのスライドなどをシェアします。

• スライド

フォローアップ

このセッションでは、ディレクターやデザイナー、マークアップエンジニアといった「非プログラマー」の方でも、押さえておきたい JavaScriptのトピックスとして、紹介しました。

踏み込んだ内容までは盛り込まなかったため、物足りなく感じてしまったかも知れませんが、これを機会に興味を持って頂いたらまずは、AngularJSあたりから触ってみて、Hogan.jsを実践で利用してビューの概念などに慣れていくと良いでしょう。

また同時に、スマホ案件で jQueryを使うほどではないDOM操作の場合（要素を表示・非表示の制御など）には、Zepto.jsの利用も思い出して頂ければ幸いです。

参考リンクです。

• Zepto.js: the aerogel-weight jQuery-compatible JavaScript library
• Vanilla JS
• Welcome to TypeScript
• AngularJS ? Superheroic JavaScript MVW Framework
• Hogan.js

頂いた質問です

jQueryと Zepto.jsの比較表はありますか？

こちらにありました（まぼろし 西畑さんありがとうございます）
https://twitter.com/kazumanishihata/status/477712418244919296

2014年6月14日（土）ベルサール九段　イベントホールで開催したCSS Nite LP, Disk 35「マルチデバイス対応 2014」のフォローアップとして、松田 直樹さん（まぼろし）の『マルチデバイス対応な実案件で使う、Bootstrap のすゝめ』セッションのスライドなどをシェアします。

• スライド

フォローアップ

Bootstrap をはじめとした CSS フレームワークをプロジェクト内でどう活用するか、というテーマでお話させていただきました。アンケートにて「使ってみたくなった」という反応も多くいただきまして大変うれしく思っております。

コンポーネントデザイン・設計ルールとしての重要性をお伝えしましたが、実装におけるCSS フレームワークのメリットとしてはやはり「楽できる」という点です。実装を楽にすることで、サイトの「設計」フェーズにより時間をかけることができるようになります。

設計重視という傾向は、「Content is King」とも言われるように「サイトの本来の目的はコンテンツを伝える」ことを重視することに他なりません。Webデザインという範囲が、「広義のデザイン」を指すようなデザインの原点に還る傾向になってきているわけですね。

この観点から、フレームワークを用いればプロジェクトチームの全員が効率よく「設計」に寄与できる素地ができるのでは、と感じています。ぜひチーム内で Boostrap のスキルを共有してみてください。

「勉強する」という意気込みより、「楽したい！」という動機の方が素早く仲良くなれるかと思います。

ありがとうございました！

以下、アンケートにていただいたご質問への回答です。

Rails + Bootstrap では、使わないコンポーネントをコメントアウトできない？

たしかに、他のフレームワークに Bootstrap などの CSS フレームワークが包含されているケースではこのような疑問は湧きますね。「bootstrap.scss」「_variables.scss」、この2ファイルを自前の作業領域で使うように環境を作ればカスタマイズは問題ないかと考えています。

なぜ WebデザインをIllustratorでされているのか？

SVGが大好き、ということもあるのですが、やはり複数のアートボードを一度に俯瞰できる点がいいですね。特に RWD のカンプを作る際には重宝します。

よく使うコンポーネントは？

これと言って偏りはないのですが、nav コンポーネントなどは使うと楽でしょうね。スマホ表示時には勝手に折りたたんでくれますので。

自社内のみでフローが完結しない場合の利用方法論は？

内外部スタッフが混在している場合など、自社内でフローが完結しないケースでの方がフレームワークを使う意義があると考えています。やはり「ルール」が事前にあることは意思疎通の改善にも繋がります。

2014年6月14日（土）ベルサール九段　イベントホールで開催したCSS Nite LP, Disk 35「マルチデバイス対応 2014」のフォローアップとして、小川 裕之さん（ツクリベ）の『レスポンシブWebデザインのワークフロー』セッションのスライドなどをシェアします。

• スライド

フォローアップ

実例を交えてRWDをウォーターフォールのワークフローで進めるリスクと、それを改善したプロトタイプを中心としたワークフローの話をしました。

失敗例のように同じようなトラブルにあったという話は周りでもよく聞きます。これからレスポンシブWebデザインを始める方や、既に経験はあるけれど進め方に不安がある方は参考にしていただければ幸いです。また特に問題なく進められているという方も、その進め方にリスクが潜んでないか、これを機に見つめ直してみてください。

セッションの中でも話しましたが、ワークフローを変えるというのは簡単なことではありません。環境や立場上、変えたいと思っても難しいという話はよく耳にします。私もそういう時はあるのですが、その中でも他の立場の人に早めに情報を共有してもらうようにしております。それだけでもリスクに気がつく早さが変わってきます。

成功例のようなワークフローが浸透するにはまだ時間がかかるかも知れませんが、まずは取り入れられるところから実践してみてください。

ありがとうございました。

以下、アンケートでいただいたご質問に回答致します。

プロトタイプは全ページ作るのか？

大枠の構成が異なるページの数だけ作ります。従って、トップと下層のベースとなるフォーマットのみが多いです。その他、他と異なる構成のページ、または機能の実装を確認してもらいたいページがあれば作成します。
事例では、トップと2種の下層ページフォーマット、lightboxを使用したギャラリーページのプロトタイプを作成しました。

カンプを作るときはどのプロトタイプの後か？また全ページ作るのか？

カンプを作るのはプロトタイプの後です。失敗例でも取り上げましたが、先にカンプを作ってしまうと実装で苦労する可能性があります。また、カンプを作るケースで進めるときは基本全ページ作ります。

RWDのメリット・デメリットとクライアントへの説明

下記スライドの14Pにメリット・デメリットをまとめてますので参考にしてください。また、どうしてもモバイルとPCで構成や内容を大きく変えたい場合、想定されるユーザーの利用シーンが限定的である場合などは、RWDでは無理な設計になりがちなので専用サイトを作るなど提案をしております。
レスポンシブWebデザインの基礎

プロトタイプ作成に使ってるツールは？

今回の実例ではオリジナルのグリッドシステムをベースに作成しました。ただ、最近の案件ではCSSフレームワークを使用して作成してます。

CSSフレームワークの活用については松田さんの資料を参考にしていただければと思います。またディレクターであれば、同様に松田さんが取り上げてましたWebflow、Adobe Edge Reflowなどのツールの使用を提案致します。
Webflow
Edge Reflow CC