00:07
9月18日日曜日、地獄は朝9時を回りました。
えー、台風がやっぱり近づいているということで、東京も今かなり曇っていますね。
雨もちょっとちらついている感じです。
はい、おはようございます。ひめめのkeethことくわはらです。
えーと、本日も朝活を始めていきたいと思います。
ちょっと遅くなってしまいました。大変申し訳ないですけど、はい。
9時30分ですね。
だから今日はちょっと、はい、えー、開始していきたいなと思います。
で、えーとですね、今日は、えー、昨日に引き続きですね、タイトルにある通り、
えー、4 Design Patterns、えー、スペル間違っている気がしますね。
うん、間違ってますね、っていう。
That Violate Back Button UX Expectations
あー、カミカミです、すいません。
をダラダラ読んでいきましょうと。
まあ、要は、えー、タイトルの通りですけど、
まあ、戻るボタンのその4つのデザインパターンですけど、
まあ、良くないデザインパターンですね。
あの、UX待機が良くないっていうもののデザインパターンをやっていこうというところでした。
で、昨日、えー、そのうちの2つまで入りましたね。
オーバーレイとか、えーと、ライトボックスっていうのが、あの、
全世界の中で37%の、あの、この、えー、記事の筆者の中が、えー、調査した全部のウェブサイトの中から
37%のサイトが、そのオーバーレイとか、あの、ライトボックスについて
この辺を考慮してないとか、実装してないみたいなのがありました。
で、もう1個が、えーと、フィルタリングとかソーティング、ソードですね。
はい。こちらも、えーと、全世界のサイトの中で27%のサイトが
フィルタとかソートについて、その考慮とか実装ができない。
もしくは、そのモドルボタンによる挙動が、まあ、よろしくないよねっていうところを指摘されてました。
はい。で、今日はその3つ目で、えーと、アコーディオンチェックアウトというところから
ちょっと入っていこうかなと思っております。
はい。
えーと、視聴優先さんですね。おはようございます。ご参加いただきありがとうございます。
まあ、タイトルの通り、えー、モドルボタンのUX待機が悪いっていう4つのデザインパターン
っていうところを今、読んでいこうと思ってます。はい。
では、いきましょう。3つ目、アコーディオンチェックアウトですね。
えー、こちらもまた今回は、えっと、画像が貼られてますね。
あの、フィッシャーの方が、どこから持ってきた画像だと思いますけど、
まあ、それについて、まあ、これバッドパターンだよねっていうところを、
具体例が入ってからいきたいと思います。はい。
えーと、まあ、その画像を見ながら、これも完全にユーザー的なコメントですけど、
あー、ダメだと。やり直しになるのか?私はもう既に怒ってます。
えー、既に私のものが入っているのではと。
まあ、そこに何か入力した住所とかカード情報とか入力をしてるんですけど、
はい。そのままで戻ってしまって、もう、あれー、
状態がクリアになってしまっていると。戻るボタンで。
もう、こんなもんやってられんってところで、もう、あのー、帰りますっていうところですね。
はい。でも、そのモバイルのチェックアウトのデストラウンドで、
まあ、フットルッカーのユーザーっていうのが支払いステップで必要な情報全て入力して、
進んだ後に戻るボタンをクリックしてしまったっていうような状況です。
で、まあ、情報を入力して戻るボタンをクリックしたんですけど、
カートに戻されてしまってですね、入力フォームに戻らなかったんですね。
03:00
いきなりカート画面に戻っちゃったらしいです。
で、この引用文がそれを全て物語っていますよってことでした。
まあ、ありましたよね。商品を購入するときに、いろいろ画面的なSPAで進んでいくんですけど、
戻るってやると、入力とかその1個前の状態の画面に戻るかと思いきや、
URL的にはですね、1つの画面に戻るからカート画面に戻ってしまって、
また全部一回やり直しっていうところですね。
これは確かに待機が良くないよねっていうのはありますけど。
はい。がありますと。はい。っていうところです。
で、じゃあアコーディオンチェックアウトのところの本文に入りましょう。
1ページで複数のセッションが折りたたまれたチェックアウトとして認識されているわけではないと。
アコーディオンチェックアウトっていうなんですね。
はい。むしろ大半のユーザーはそのサマリー付きのマルチステッププロセスとして認識しています。
はい。一応アコーディオンチェックのユーザー認識について詳しくはこちらっていうところで、
記事内にまたリンクがあるんでそこも見てみてください。
これはアコーディオンのステップが技術的に1つのURLで1つのページとして実装されているサイトでは、
ユーザーが前のチェックアウト、いわゆるステップに戻りたい場合、
例えば以前に入力した情報を編集する場合とかは、そのカートに戻ってしまう問題が生じます。
そのためアコーディオンチェックではブラウザの戻るボタンで、
前のステップに戻ることができるようにすることが重要ですよねってことでした。
はい。これって当たり前っちゃ当たり前なんですけど、
意外とできないことが多いし、昨日見たオーバーレイとかと結構似た事象かなと思いますね。
オーバーレイで、昨日の説明の中であったのはオーバーレイとかに、
オーバーレイとかモーダルでもいいんですけど、画面のほぼほぼ大半を奪ってしまうような、
変化があるというところですね。見た目上に画面に大きな変化がある場合、
ユーザーっていうのはそれを新しいページにアクセスしたという風に見出すんですね。
けど、システムとかアプリケーション的には単にオーバーレイとかモーダルを背景グレーにして、
上にかぶせて表示しているだけなので別にページ遷移はしていないと。
そのオーバーレイとかモーダルに閉じるボタンとか右上にあるじゃないですか、×ボタンが。
これがあまり強調されてなかったり見えてなかったりするので、
ユーザーは画面の下の方を見に行って閉じたいときに左、だいたい分かっている人は左か、
もしくはグレーのボタンがあったりすると、これが閉じるのねって何とかわかるじゃないですか。
そこに戻るっていう風に書いてあるんです。戻るボタンを配置してるんですよ。
なぜか知らないけど。
ユーザー的には多分そのボタンを押すとオーバーレイとかモーダルが閉じてほしいんですけど、
システム的には戻るなので一つ前の画面に戻っちゃうんですよね。
オーバーレイが表示される前に戻れます。
こういうのは商品の詳細画面とかに行ったときに、
画像の詳細を見たいときにタップして出たりするじゃないですか。
モーダルとかポップアップみたいな感じで。
それで戻るボタンを押すと商品リストに戻っちゃうんですよ。
それで体験悪いでしょみたいなところがありますけど、それと似たような話ですね。
アコーディオンチェックアウトも同じような感じです。
06:01
購入フローずっと進んでいって、一つ前の例えば入力フォームの画面に戻りたいのにカート画面に戻っちまうみたいな。
こういうのは体験がものすごく悪いし、僕も多分そういうの触った瞬間、
サイトで商品買いたくないって思っちゃうので、
これはほんまよろしくないですよねっていうのがその話でした。
今のが3つ目ですね。
最後4つ目のパターンですね。
商品ページから製品一覧に戻ってしまうっていうところですね。
これもさっき言ったお話と結構似てると思いますけども。
こちらもちょっと画像があるんですけど、説明がかなり高等文的な感じになるので、
一回割愛して本文に戻りたいと思います。
では行きましょう。
商品ページから商品リストに戻ってしまうっていうところですね。
多くのユーザーっていうのは探している商品を見つけるために、
商品一覧と商品詳細ページの間を行ったり来たりして、
広大な数の商品に目を通します。
例えばその商品一覧の一番上ではなく真ん中に戻るなど、
その商品一覧で前にいた場所に戻れないユーザーっていうのは、
最後にいた場所を探し出すという面倒な作業をしなければなりません。
いわゆるスクロール位置まで保存しておいて、
戻った時にそこに戻ってくれたらいいですよねっていう話ですね。
特にモバイルユーザーにとってはスクロールが面倒なため、
このような現象が発生することが確認されています。
商品ページにアクセスする前にいた場所ではなく、
商品リストの一番上に移動した場合、ユーザーは混乱し、
商品リストのどこにいたのか探し直すわけにもなりません。
また、商品ページを訪れる前にいた場所を正確に覚えていくことも
困難にはなりますよねってことです。
例えば商品リストが似ているが同じではないスタイリングの、
例えば青いドレスとか似たような外観のオフィスチェアの
セクションである場合など、これはかなりきついですね。
似たようなカテゴリーの商品で比較をしたい時とかに、
このUXはかなりイライラするでしょうね。
戻るボタンを使うとすぐに最初に戻ってしまいます。
むしろ中断したところから始まるんですよねってことですね。
商品リストの最上部に連れて来られたユーザーっていうのは、
リスト内で正しい場所を見つけるまで、
多くのアイテムをスクロールしてなければならないかもしれません。
サイトの商品ローディングスキーマによって商品を探し出す困難さは、
中から大になる、もしくは極度になる可能性もあります。
どのような商品ローディングスキーマを使用しているかにもかかわらず、
商品リストの中から正しい場所を探し出すプロセスが、
あまりにも時間と手間がかかるものであれば、
ユーザーは諦めてしまうかもしれません。
結構離れると思いますね、これは確実に。
しかしそれだけは終わらないです。
上記の4つの例っていうのは、ユーザーがあることを期待しているのに、
サイトが別のことを引き起こすような実装になっていることが多い、
という典型的なミスマッチになります。
しかしこのようなミスマッチは、これらの一般的な例に留まりません。
一般的にはユーザーによって開設された新しいビューの状態が、
別のページのように見えたり、概念的に感じられたりする場合に注意する必要があります。
オーバーレイ、フィルタリング、ソートに関しては、
09:00
ユーザーがモドルボタンに期待する動作は一貫しています。
例えば、フィルターとかソートもそうですけど、
条件を付けて検索し直すじゃないですか。
検索し直したときにモドルボタンを押したら、
フィルターとかソートの設定前の商品リストに戻ってほしいんですよね。
なんですけど、たまにその商品リストの前のページに戻ってしまうという時があるので、
それは良くないよねって感じです。
オーバーレイ、フィルタリング、ソートに関しては、
一般的なユーザーがモドルボタンに期待するという動作は、
大体認識とかも一致していて、
そのモドルをクリックした後にユーザーに表示されるべきものである
ものは明確であることがテストによって既に示されています。
しかし、モドルボタンをクリックした後に何を表示されるべきかというのは、
それほど明確では実はないんですよねってことでした。
ユーザーが製品を見つけるために探索する際に遭遇する他のビューがあります。
ここではそのうちの5つを紹介していこうと思います。
ユーザーが製品を見つけ、探索する際に遭遇する他のビューというのがあると。
その5つのパターンを今後は見ていこうということですね。
5. Affected by Browser Back Button Issues
ブラウザーバックですね、ここで来ました。
画面内に意図的に配置されているモドルボタンと別のブラウザーバックですね。
モドルボタンですね。
いわゆるブラウザーバックという問題です。
こっちで確かに戻っちゃう人っていうのが多分かなり多いんじゃないかなと思いますね。
僕もブラウザーアクセスしてECサイトを見ているとき、
モドルボタンじゃなくてブラウザーバックをしてしまう可能性の方が高いと思います。
そっちの方が画面的にモドルボタンって画面の一番上、トップの左側にちょっと表示される。
いわゆるパンクズリストのような感じで表示されるか、
だいたいその画面の一番下に戻るというようなボタンが配置されるじゃないですか。
なのでどっちかに必ずスクロールしなきゃいけなかったりすることがあるので、
面倒くさくてブラウザーバックを表示してしまう方が早いんですよね。
という時があるので、これは確かに仕方ないと思いますね。
そもそもモドルボタンを押すという、
タップする体験って実はユーザー以外に使ってないんじゃないかなと思ったり僕はしていますが、
僕は明らかにWebAの理解、ディテーラシーは他の人よりは、
他のっていうのは一般的な同じ業界じゃない人よりは高いと思うので、
そういうことをしてしまうかもしれないですね。
他の人はちょっとわからないです。
はい、で戻りますね。本文に戻ります。
オーバーレイとかフィルタリング、ソート、アコーディオンチェックアウト、
商品ページから商品リストへの戻りなどは、
そのユーザーが戻るボタンに期待する動作ってのはやっぱり一貫していて、
戻るボタンをクリックした後にユーザーに表示される内容は明確であることはテストにわかっています。
2度目ですねこれ。
しかしユーザーが商品の探索、サーチとかをする前に、
する際にか、遭遇する戻るボタンをクリックした後に何を表示すべきかっていうのは
それほど明確でないビューも存在していて、
その5つを紹介するという、改めて書いてますね。
12:02
注意ですね、このリストっていうのは全てを網羅しているものではなくて、
戻るボタンが特定のコンテキストでどのように機能するかについて
特別な配慮が必要なそのグレーな領域を説明するものですよっていう風に言ってます。
はい、了解です。
じゃあ5つですね、先にガッとリストだけ述べましょう。
1つ目ですね、ページ内の多段階の処理です。
2つ目、コンテンツの拡大ですね。
拡大って言ってるけどエクスパンディングだから、
アコーディオンの開閉の可能性もちょっとあるかなと思いました。
3つ目がアンカーリンクですね。
4つ目、切り捨てられたコンテンツ。
トランケティッドコンテンツ、何だろう。
最後5つ目、製品ページのバリエーションですね。
っていうところです。
それら一個一個見ていきましょうと。
1つ目がマルチステッププロセッシブウィズンアップページですね。
多段階のページってことですね。
ちょっと翻訳が時間がかかっているので少々お待ちください。
5つ目です、多段階のやつですね。
ページ内での多段階の処理です。
以前、SaaSというウェブサイトですね。
海外のそういうECサイトがあるんですけど、
行ったテストでは、とあるユーザーが商品ページの配送オプションボックスにある
多段階の配送見積もりとやり取りをしていました。
そのユーザーはいくつかのステップを経て、
村瀬さんの戻るボタンを一度クリックしてしまいました。
しかし期待した通り、送料見積もりの前のステップに移動するのではなく、
ページの一番上までスクロールされただけでした。
あ、なるほどね。
戻るとかではなくて、ページの一番上にスクロールしちゃったんですね。
はいはいはい。
まあでも、そういう実装になっている可能性はありますからね。
はい。
で、ここでサイトが提供するモドルリンクをクリックしたところ、
出荷見積もりプロセスを逆戻りさせることができました。
例えば、出荷見積もりとか商品検索ウィザード、アンケートなど、
ページ内に組み込まれた複数のステップのプロセスをユーザーが操作する場合、
モドルボタンをクリックした後に何を表示するかというのは、
しばしば判断に迷うところです。
前のページに移動すると考えるユーザーもいれば、
そのプロセスの前のステップに移動するという考えるユーザーももちろんいます。
組み込みプロセス自体の設計というのは、
ユーザーの期待に大きく影響する可能性があります。
例えば、プロセスがインターフェースの50%以上を占める場合ですね。
モバイルではまあまあよくあることですけど、
多くのユーザーというのはそのモドルをクリックした後、
前のページではなくプロセスの前のステップが表示されると予想します。
確かにモバイルだったら前のステップに戻るというのは考えられますよね。
しかしここではプロセスの長さも重要な要素だと言っています。
例えばその3ステップのプロセスだとしましょう。
その場合は、モドルボタンで前のページに戻ると思っていたとしても、
ユーザーがクリックして戻ることは難しいことではありません。
したがって全てのユーザーにこの操作を強いることは、
それほど重大な結果をもたらさないという話があります。
一方、プロセスが長い場合ですね。
例えば7ステップに進むようなプロセスの場合。
例えばユーザーが最終的に元のページに戻るために、
6つの別々のビューをクリックして戻らなければならない場合、
15:02
クリックバックという行為はより退屈になります。
それはそうよ。
7つのステップまで行くんだったら最初から本当にトップに戻るというか、
ステップの1に戻るみたいな別のUXとかを考えた方がいいんじゃないかと思ったりしますね。
最後に戻るボタンが使用されたときに埋め込まれたウィザードというのが、
ユーザーが入力したデータを大量に失うとしたら、
ユーザーを前のステップに戻さないことの影響も非常に大きくなります。
したがって組み込みプロセスのサイズと目立ち方、
プロセスの長さ及びユーザーが提供した大量のデータの潜在的な損失というのは、
プロセスの各ステップがそれ自身の個別のURLを持つべきか、
ユーザーのプロセスの各ステップをクリックして戻ることを要求すべきか、
持たないべきか、
ユーザーがプロセスのいくつかのステップにいる場合でも、
戻るをクリックして前のページに戻るか、
代わりにプロセスから終了させる的なことを決定する際に考慮すべき事項ですよね、
というふうにおっしゃっています。
これはでも要は答えはあるわけではないということですね。
コンテキストだったりユーザーの使っている端末の画面のサイトだったりとか、
そのプロセスのステップ数だったりするのでまちまちなんですけど、
その都度その都度ちゃんと考慮したものを実装してくださいねということだそうですね。
共通して言えることは別に戻ったときに何を残して何をクリアさせるかというのは結構重要だと思っていますね。
プロセス途中に戻させるんだったら必ずデータ保持しておかなきゃいけなくて、
セッションで持つのもいいですし、
全部APIとかにぶん投げて都度都度APIからデータを取ってくるでもいいですし、
少なくともユーザーが何の中のセッション的な一連のステップを踏んでいるときに
データをしっかり持っておくことが結構重要だと思いますので、
戻った瞬間に消えた瞬間にユーザーが離れる可能性が多いので。
というところです。これが一つ目でした。
では続いて二つ目、エキスパンディングコンテンツですね。
コンテンツの拡張とか拡大とかですかね。
というところです。翻訳していきましょう。
コンテンツを拡大するというところですね。
ナビゲーションの最初のテストの一つで、
とあるユーザーが、今回はIKEAですね。
IKEAのシーティングソリューションで、
シーティングソリューションというページがあるんですね。
画像のサムネイルを探っていただくことです。
各サムネイルをクリックするとページ幅がいっぱいに展開されました。
最初のサムネイル、いわゆる、
今、僕の画面上には3枚画像が貼ってあるんですけど、
最初の画像を展開したときですね。
ユーザーは別のサムネイルを展開したんですけど、
最初の画像に戻りたくなり、
ブラウザの戻るボタンをクリックしてしまいました。
いわゆる1枚目の画像に戻りたかったのに、
2枚目の戻るボタンを押したら、
展開した最初の画像ではなく、
メインカテゴリーのページに戻ってしまいました。
そんなやつですね。
本当に拡大というか、
オーバーレイに近いような感覚ですね。
コンテンツの拡張には、
サムネイルがより大きな画像に拡張されたりとか、
18:02
テキストの量が段落に拡張されたりするような要素が
含まれる可能性があります。
しかし、拡張コンテンツというのは、
そのページの背景が薄暗くなったり、
あるページが別のページに重なっていることが
はっきりとわかるオーバーレイのように、
エンドユーザーには表示されません。
したがって、コンテンツを拡大すると、
ユーザーは拡大されたコンテンツを新しいビューとして、
または単に同じビューで、
いくつかのコンテンツが変更されたものとして、
合理的に解釈することができますよね。
コンテンツの拡大を使用せず、
代わりにオーバーレイに切り替えて、
ユーザーが戻るボタンをクリックしたときに、
何に移動するのかが明確である。
つまり、オーバーレイから終了して、
元のページに戻るということは、
両方のUIタイプが同様に魅力的に使用できる場合、
文脈によっては最も簡単な解決策となる場合があります。
それ以外の場合は、
ページに埋め込まれたマルチステップ処理と同様に、
拡大するコンテンツがどの程度目立つかに大きく依存します。
もしそれがインターフェースの大部分を占めているのであれば、
多くのユーザーはそれを別のページとして解釈するでしょうから、
各コンテンツはそれ自身の個別のURLを持つべきです。
というふうに仰っていますね。
オーバーレイならわかりやすいんですけど、
単にちょっと拡大するとか、
いわゆる商品画像がたくさんあって、
サムネイルをクリックするとその画像だけボッと、
画面の幅をかなり締めて表示されるだけだった場合。
よくありますよね。
でかいサムネイルとその下にちっちゃいサムネイルがいくつか
バーッとさらなるような画像があると思いますけど、
そういうやつが出たときに戻るを押すと、
一つ前の画像のURL、URLじゃないですね、
サムネイル画像の表示に戻るか、
それともページごと戻ってしまうかどうですけどね。
これは難しいですね。
というか昨日も言いましたけど、
そもそも戻るボタンっていう文言を変えたらいいんじゃないですかね。
そもそも戻るっていうボタン、
名前を変えるのが本当はいいんじゃないですかね。
前のページに戻るとかちょっと長くてもいいから、
ちゃんと説明するか、
もしくはもうちゃんと戻る、
そもそもオーバーレイとか拡張したポップアップみたいなところに
戻るじゃなくて閉じるっていうのが正解な気はしますけどね。
そもそもの話をすると。
以上、今のが二つ目の拡張コンテンツでした。
続いてアンカーリンクですね。
アンカーリンクですが、これは長いな。
画像の説明は今回かなり口頭的なので、
ちょっと端折ります今回は。
続いてアンカーリンクですね。いきましょう。
アンカーリンクの場合はリンクがタップされたときに、
ユーザーがすぐにページの下にジャンプするか、
スムーズにページの新しい位置にスクロールするかによって
多くの違いが生じます。
ジャンプするか、いわゆるスムーズに動くかによって実は変わる。
テストによるとユーザーがページの下にジャンプした場合、
戻るをタップするとページの前の位置に戻ることが分かりました。
あー、なるほどですね。
21:01
ジャンプすると、それは画面遷移じゃなくて厳密に言うと
場所を変えただけなんだけど、
戻るをタップするとページの前の位置に戻るということですね。
それは期待するかもしれないですね。
厳密には多分ページ内にハッシュタグを
ページのURL的にハッシュタグのところに移動しているだけですから
ヒストリーAPI的にはハッシュが付く前のところに戻る
というのが多分正しいので、これはそうかもしれないですね。
例えば商品ページの上部にあるレビューの星の平均値をタップした場合、
レビューのセクションにジャンプした場合ですね。
タップした後にレビューのセクションにジャンプした場合
戻るをタップすると商品ページの上部に戻るはずですと。
上部にあるレビューの星をタップしたら
レビューのセクションにジャンプしたんですね。
また戻ると、その上部に戻るというのが期待値ですと。
はい、わかりました。そんな気がしますね。
これはユーザーがページの下にジャンプしたときに
ジャンプ後の位置がわからなくなるため
また新しいページに来たと勘違いしてしまうことがあるためですと。
はいはいはい。実はページ内にちゃんとそのセクションがあって
そこに移動しただけだと思うんですけど
ジャンプしてしまったので
全く依存なんだけど
日本語が出てこない。個別のページという風に
ユーザーが認識をしてしまう可能性があるということですね。
特に覚えるではそういうことがあると。
お前らってそうかもしれないですね。
画面が全体的にパッと切り替わっているように見えるから。
そこで戻るをタップしたときに元の位置に戻すことで
ユーザーは迷わせないようにしていますと。
しかしユーザーがスムーズにページをスクロールしている場合は
そうはいきません。ユーザーはページを下にスクロールしているため
新しい場所に行っても元の場所の位置を把握することができてしまいます。
要は連続的なページ移動をしているので
さっきの理算的なページの移動とは違うので
ユーザーはページ遷移をしていないということが
認識できているということですね。
そのためページの下にジャンプしているユーザーと比較して
全体像を完全に失う可能性が遥かに低くなります。
そのためスムーズにスクロールしてきたユーザーが
戻るをタップしてもページが戻らず元の位置に戻ってしまうと
期待に応えられないと感じることがあります。
これもまたでも難しいですよね。
単純に元の位置に戻りたいがためにタップする人も全然いるんじゃないかと思います。
少なくともリティラシーある人はそう思っちゃう気がするので
ここは結構難しいなと思いましたね。
でもまだ大半の人は
元の位置じゃなくて前の画面に戻るということを
期待するかもしれないですね。
上にスクロールしようと思えば
スクロールさえすれば簡単にできてしまいますが
戻るをタップすることで代わりに1ページ戻るという意思表示をすることになります。
アンカーリンクをタップするときは
ジャンプではなく常にスムーズにスクロールさせることが推奨されています。
24:00
したがってユーザーがアンカーリンクをタップした後
スムーズにスクロールされた後に戻るボタンがタップされる
という特定のコンテキストを公表する必要があります。
モバイルサイトにおいてユーザーが非常に長い商品ページを
閲覧しており
トップに戻るオプションがない場合戻るボタンをタップすると
ユーザーは1ページ戻るのでなくタップしたアンカーリンクに移動するのが
良いと考えられます。
コンテンツの長さによってもスムーズにスクロールしたとしても
タップすると元の位置に戻ってくれるということが
期待される可能性もあると。
またページ内に多くのアンカーリンクがあればいい
つまり多くのアンカーリンクがタップされた場合戻るボタンを
タップするとユーザーはしばらくページをただいましに
される可能性があります。
またページの高さがあまりない場合はアンカーリンクに戻ることは
可能になるため、代わりに前のページに戻すほうが良い場合が
ありますということでした。
アンカーリンク1つ取っても確かに考慮すべきことは
本当にいっぱいありますね。
UXってこういうところをちゃんと考えていかなきゃいけない
というのが難しいところでもあるし、逆に言うと
職人としては腕の見せるところを見ないところはありますね。
続いて4つ目
トランケピルコンテンツですね。
ユーザーがリンクやボタンをタップしたときに
展開される切り捨てられたコンテンツというのは
戻るをタップしたときにユーザーが再訪問する
別のURLであってはなりません。
例えばモバイル向けの商品ページでは
数行のテキストや商品説明の段落を提供し
残りを詳細リンクの後ろに隠してしまうということがよくあります。
別にECでもあると思います。
ありますけど、モバイルでは本当にこっちの方が多いですね。
商品ページをより見やすくするためのものではありますが
ユーザーが戻るをタップしたときに
前のコンテンツに戻るのではなく、前のページに戻るようにする必要があります。
切り捨てられたコンテンツを拡大しても
切り捨てられたコンテンツってのはあるか。
例えば3.0リーターとかで隠したやつとか
アコーディオン的なやつとかいっぱいあると思いますけど
そういうコンテンツを拡大しても戻るをタップしたときに
そのページに戻されることを期待するようなビューの変更としては十分でありません。
新しいコンテンツをスムーズに展開することで
タップしてコンテンツを展開したときにユーザーがどこにいるのか
というのをより外観できるようにすることも
検討してくださいと。例として
突然新しいコンテンツにジャンプするのではなくて
コンテンツを優雅に展開するということですね。
これは大体のユーザーは似てると思いますけどね。
トランケッティッドコンテンツか。
戻ると閉じた状態ですね。
拡張される前の状態で戻るのがいいんじゃないのと
僕も思ったりしますけどね。
理想としては開いたままだった場合ですね。
開いてからどっかに行った場合は戻ったときに開いた状態で
表示される方が
ベストだと思いますけどそこまでしなくてもいい気がしますね。
ラストですね。
Violations on the product pageですね。
27:01
僕の家の
ネットワークが朝からすでに重いので
翻訳が時間がかかっています。
製品のバリエーションですね。
一つの製品リストアイテムにまとめる必要があります。
そうすればユーザーは製品ページでバリエーションを探索することができます。
しかしこれらのバリエーションが
別々のURLを持つべきかどうかっていうのは
つまりユーザーが戻るをタップしたときに
すでに探索した前のバリエーションをステップバックするかどうか
やっぱり文脈とかコンテキストによって決まります。
ユーザーが検討すべき製品のバリエーション、特に色なのが多いそうですね。
サイズはユーザーによってほぼ決まっているので
あとは色だと。
それが一般に少ない場合はそれらを別のURLにする
ということは最良の選択かもしれません。
ほとんどのユーザーは実際の前のページ、多くの場合は製品リスト
または検索結果ページに到達するために
戻るを数回以上タップする必要はないでしょうから。
前のページに戻るために2、3回タップしなければならないことに
少しイライラするユーザーもいますが
前に見たバリエーションに移動するために戻るをタップしても
代わりに製品ページから完全に追い出されたとしたら
深刻なイライラを感じるユーザーもいることでしょう。
例えば製品リストで前にいた場所に戻れず
直前に見ていた製品を再度探すことを強いられると
より困難した待機になりかねません。
なるほどね。
しかし、各バリエーションがそれぞれ別のURLを持っている場合は
戻るボタンをタップするたびに製品画像が変化することが重要です。
そうしないとユーザーは
たとえ技術的には異なるURLを見ていたとしても
インターフェースで何が起こっていることを示すことなく
戻るボタンをタップすることになります。
ほとんどのユーザーは
サイトが動かないと思い込むのか
自分の行動がなぜ影響を及ぼしていないように見えるか
不明確になります。
これは災いの元となります。
しかし、例えば口紅の色だと
何十種類ものバリエーションがある場合
ユーザーが前にいたページに戻るために
何十種類ものページを遡らなければならず
連続的にタップして色を比較して戻りたいときに
今の状態でずっと戻る戻るを繰り返さないといけない。
それを代わりにユーザーが
製品リストのどこにいたのか
製品を簡単に見つけることができるように戻すことが重要です。
単に戻すのではなく、どこに戻すかも重要です。
また、最近見た商品のリストも便利ですよねと言っています。
最近見た商品のリストという
繊維のリンクを貼っておいて
そこに促すというのも確かに一つありかもしれません。
なるほど。
今まで以上5つでした。
ラストですね。
長く読んできましたが、ソリューションのところを読んで
この記事は終了したいと思います。
もう30分も切れちまったので
30:02
最後ざっと読んで終わりにしていきたいと思います。
The Solution 解決策ですね。
HTML5では、HTML5ヒストリーAPIという
比較的簡単なソリューションが提供されているのが良い点です。
ヒストリーAPIの実装はかなり
助かるというかありがたい機能だと思います。
つまり、ブラウザーの戻るボタンの動作を
ユーザーの期待に沿うように調整することが
これを使うことができるようになりました。
逆もまた可能です。ユーザーの履歴エントリーを呼び出すことなく
URLを変更することもできます。
つまり、例えばOverlayを開いたときに
ブラウザーの履歴の変更を呼び起こして
ユーザーがブラウザーの戻るボタンを使って
もちろんこれはユーザーが起動するOverlayやLitebox
またAJAXページのPaginationとか
リストのフィルタリングや相当アコーディオンチェックアウトなど
ユーザーがブラウザー履歴を呼び出していると期待するものの
技術的には呼び出していない要素全てに当てはまります。
したがってHistory.PushStateというのを使って
ユーザーが新しいページと認識するViewですね。
つまり視覚的とかもしくは概念的に十分に異なるViewですね。
ユーザーが新しいという風に認識してしまうViewについては
ユーザーのブラウザ履歴に新しいエントリーを作成します。
こうすることでサイトの動作とユーザーの期待値というのを
一致させることができます。まとめると
要はHistory.PushStateを使ってユーザーの期待に沿った
戻るボタンの動作をさせるようにします。
特にユーザーが新しいページとして認識する視覚的な変化があるのであれば
それが技術的に新しいページであるかどうかというのには関わらず
閲覧履歴に追加されるようにします。
これには以下が含まれますがこれらに限定されるべきものではありません。
以下というのは4つですね。
OverlayとかLightbox、選択項目のフィルタリングとか相当、
Accordionのチェックアウトステップ、
最後商品リストの位置ですね。
スクロールしてきたところの位置です。
さらにいくつかの新しいViewというのはグレーゾーンであり
新しいViewを新しいページとして実装するかどうかを決定する際には
Viewの目立ち度とかその他の要因を考慮する必要があります。
以下はその例です。
要は読んできたところですね。
ページ内の多段階の処理だったり拡大するコンテンツだったり
拡張するコンテンツだったりアンカーリンクだったり
その製品ページのバリエーションだったりというところです。
一般に切り捨てられたコンテンツはHistory.apps.stateを使って
新しいページとして実装してはいけませんよということに
注意してくださいということですね。
それはそうでしょう。コンテンツレベルって分かりきっているんだからそうですね。
ある要素が新しいウェブページであるか新しいページで
少し変更された要素であるかを判断するとき
その要素のビジュアルコンテキストもしくは
以前のサイトの経験に依存してしまいます。
そのためユーザーの戻るボタンへの期待に応え
意図しない回り道や変更を避けることが重要です。
テストではしばしば放棄の直接的な原因となりました。
放棄っていうのはこのサイトを使うかどうかってところですね。
この問題の深刻さと簡単な解決策に関わらず
59%のサイトが4つの戻るボタンへの期待値のうち
33:01
少なくとも1つをサポートしないと。
そのうち1個でもサポートしていなくて
ユーザーがその1個のボタンにハマってしまった瞬間
ユーザーが戻ってしまう可能性は結構高くなってしまう。
結局全部やらなきゃいけないってことですね。
そこに注意してくださいってことでした。
本記事はベリマードプレミアムに含まれる
600以上のUXガイドラインのうちの
1つから得られた調査結果を紹介して
今回の記事は書かれていますよってことで
この記事は終了となりました。
ただこの記事自体が2020年の7月20日に書かれたものなので
ちょっと古いので
データ自体も古いかもしれないんですけど
現代においても全然通じる話だったと思いますし
この辺はしっかりUXは考慮していかなきゃいけないなと思いました。
またもう1個全然別件なんですけど
フロントエンドエンジニアってやっぱりデザインをするかどうかっていう
別の議論があると思っていて
フロントエンドエンジニアはUXまでいかないにしても
UIについてはちゃんと意見ができるようにするのが
今後のエンジニアとしては
マストまでいくと言葉強いですけど
割と強めに持っておいた方がいいという風に僕は思ったりしています。
エンジニアとしても結局
設計とかデザインされたものを
具現化するだけがエンジニアではなくはないと思っていて
あくまでやっぱり技術的に本来の課題とか問題解決を
やっていくのがエンジニアなので
そのためにやっぱり必要なものはUI UX
ビジネスサイドとか要件によったお話ですので
そこがやっぱりできるようになるのが
良いエンジニアになるためのステップなんじゃないかなと僕は思ったりしていました。
今日の話とか今回のこの記事の内容自体も
やっぱりフロントエンドエンジニアならばさすがに
今後のプロジェクトとか開発において
その辺の知見というか観点を
意見できるようになった方がいいんじゃないかなと思ったりはしました。
ただやっぱり英語の記事だったりしたので
なかなか翻訳とかニュアンスの違いがあって
読んでてこれどうなんだろうって思うところはありますし
僕が英語がわからなかったので結局DeepLに頼り切って
しまったというのはちょっとあれなんですけど
改めて皆さんの方でも読んでみていただけたらいいんじゃないかなと思います。
基本的には結構いい記事だったと思ったりしてましたので。
ではちょっとオーバーしましたけど
今日の朝活動は以上にしたいと思います。
日曜日も関わらずご参加いただきありがとうございました。
ちょっと天気も悪いのでお出かけする方もいらっしゃると思いますけど
足元気をつけてください。
家でのんびりされる方はのんびりしていただければと思います。
また来週はシルバーウィークなので
お休みされる方も結構いらっしゃると思いますので
のんびり休んでいただければと思います。
ちなみに僕はカレンダー通り仕事しますけど
まだメンバーがいないのでわりとのんびりかつ
ミーティングラッシュかけらもないというのがすごく
幸せな時間な気がするので仕事進むような気がします。
余談でした。じゃあ終了したいと思います。
お疲れ様でした。
