プルトゥリフレッシュの背後にある当初の考えは、ユーザーがリストの上部または下部に新しいメッセージが表示されたかどうかを確認し、リストを更新してそこにあるかどうかを確認するために使用するスクロールモーションを利用することでした。新しい何か。
残念ながら、このパターンは、たとえばChromeページを更新するために)適用されなくなった場合に使用されており、あまり見つけられません。このジェスチャーに問題があるかどうかに関する調査はありますか? 、そして逆に、今更新されたすべてのアプリで期待されているかどうか。
プルトゥリフレッシュ機能に関する研究は公開されていないと思います。しかし、私はいくつかの同様の材料を合成し、自分の答えを思いつきました。
スワイプジェスチャーはより速く簡単ですが、多くの場合「非表示」と見なされます
Florian Weilのタッチスクリーンジェスチャーに関する研究 は、画面全体が手や腕全体ではなく親指とペアになっていると結論づけています。 (通常は親指で)引き下げると、お札が収まります。同様に Jianwei Laiの調査結果 スワイプはダブルタップよりも信頼性が高く、ユーザーにとってより高速であることを指摘します。 UserInsight タップとスワイプの間の一般的な長所と短所を比較 これは、質問の観察結果と一致します。
私たちの調査によると、多くの場合、スワイプを引き起こすのは、スワイプの慣例に関する知識だけです。 [...]スワイプの慣れに慣れていないユーザーは、インタラクションを完全に見落とし、そのために機能や機能を見逃す可能性があります。
十分言った:Twitter発明したプルトゥリフレッシュ、それでもボタンを提供する
この回答の最初のドラフトで、 Twitterがプルからリフレッシュへのジェスチャーを開拓した であることを指摘しました。今日ツイッターを使用すると、代わりの方法として提示されるボタンがあります。それにもかかわらず、ジェスチャーはAppleによって主流に吸収されました。ストリームに新しいツイートがある場合は、画面上部にタップできるボタンが表示されます。スクロールして下にスクロールするとボタンが下部に表示されます。これは非常に小さなボタンですが、プルトゥリフレッシュ機能が存在するため、それを実行する余裕があります。上部のボタンはまだ指示を与えます。 「プルトゥリフレッシュ」と書かれているので、ジェスチャーの操作方法がわかります。また、ジェスチャーの使用方法がわかったら、他に何も使用しない方がよいでしょう。 Twitterは、ボタンを必要とするユーザーを満足させることと、プルトゥリフレッシュが存在することを知らない可能性があるユーザーを教育することと、リマインダーUIを非常に小さくして、それがずっとそこにあると想定していたパワーユーザーを満足させることの間の微妙なバランスを釘付けにしました。エクスペリエンスへの影響はごくわずかです。
2013年のFast Co.Designの記事は、プルトゥリフレッシュ機能を駆使しています 革新的であるにもかかわらず、プルダウンアクションは至る所にあり、ページの更新以外の目的で使用されていました。
たとえば、ユーザーがJawboneのUpアプリを開くと、会社のコンパニオンアクティビティトラッキングリストバンドUP24と自動的に同期して更新されます。したがって、ユーザーがプルトゥリフレッシュを行うと、Jawboneは代わりに、プログラムが同期したときに転送されたばかりのデータについて、一口サイズのわかりやすい要約を表示します。
iOS 7のAppleのホーム画面で、プルダウンすると、ユーザーが検索ボックスにアクセスできるようになりました
あなたの場所を失うことは迷惑なので
HTML4の<Marquee>
は90年代後半にかなり人気がありました。ティッカーの問題は、Twitterの古いライブストリームと同じです。あなたが読んでいる間、テキストはあなたから遠ざかっています。より多くのアプリケーションがデータをストリーミングする方法を開発するにつれて、アプリケーションをリアクティブにする方法の技術的な問題を解明しようとする開発者の数が増えています。反応性とは、変更がどこかで行われるとすぐに、他のすべての場所に反映されることを意味します。2人以上のユーザーが同時に共有しているGoogleスプレッドシートを考えてみてください。ただし、他のユーザーからの変更を反映するようにUIを即座に更新すると、煩わしい場合があります。デザイナーは、ユーザーが混乱しないようにする必要があります。反応性が高すぎると混乱が生じるだけでなく、サーバー、ブラウザ、アプリ、ユーザーのデータプランなどにもコストがかかるため、反応性フレームワークをうまく活用する方法を理解しようとする人はたくさんいます。あなたが興味を持つかもしれない主題は「楽観的なUI」でしょう。理想的なoptimistic-uiの更新方法では、新しい投稿の準備が整い、コンテンツなどが表示されるので、静かに取得できます。次に、ユーザーが更新することを決定した場合、RAMに内容を即座に表示し、サーバーに何か他のことがないかを再確認します。見逃したものがあれば、もう一度更新して停止します。
無限のスクロールについて少し考えてみましょう。ユーザーにはコンテンツのバッチがあり、下にスクロールすると、次のバッチがフェッチされます。 Infinite Scrollの最良のケースでは、ユーザーはコンピュータがより多くのバッチをフェッチしていることに気付きません。通常、ユーザーがさらに過去に移動すると、スクロール方向は下になります。ストリームの最後は最も古いコンテンツであり、通常、ユーザーはスクロールを停止できると理解されています。
今、反対を考えてみましょう。未来に向かう上向きのスクロールはどのように見えますか?ほぼ同じですが、1つの注意点があります。ストリームの終わりに到達することです。ユーザーが現在に到達したとき-現在-どのように 彼らが見ている「現在」が実際には「現在」であることを知っていますか ?ユーザーが上にスクロールし続ける準備ができるまでユーザーが自分の場所を維持できるようにしながら、上向きに入力し続けるようにコンテンツを設計できます。そしてまったく同じように、あなたが彼らに健全性チェックを与えて、彼らが見ているものより新しい何かがあるかどうか彼らに命令で尋ねることができます。そして、さらにスクロールすることがすでに用意されている場合は...スクロールして更新するのは自然な道のように思えます。それが、プルトゥリフレッシュの考え方に私たち全員がとても満足している理由かもしれません。