Facebookの「いいね」ボタンのように偽装する必要がありますか？
ボタンのようにFacebookを押すと、瞬時に色が変化します。それは偽物です。しかし、アイコンのようなチューブは少し遅れて色が変わります（接続によって異なります）。ホテルアプリケーションの最終候補ボタンでも同様の状況です。偽物にするべきか？
サーバーに送信する必要のあるアクションを即座に実行するか、クライアント/インターフェイスが確認を受信するのを待って遅延した後に実行するかを尋ねています。
すぐに、または数秒後に発生する可能性のある何かを表示する前に、確認の返信が届くのを待つと、ユーザーは解釈しなければならない遅延に直面します。アプリケーションはフリーズしましたか？私もそれをクリックしましたか？
私の見解では、確認する必要があります...
- ユーザーのアクションには即座に視覚的なフィードバックがあります
- アクションが失敗した場合、ユーザーはエラーを認識します。ニールセンのヒューリスティックスの1つである「システムのステータス」を表示する必要があると主張する人もいるかもしれません。これは、アクションが「処理中」であることを示しますが、この場合の値は確信できませんが、私はとにかく、そのオプションをここに示します。
完了前の処理を表示
この例は、それがどのように見えるかを確認するためだけに作成しました。ここに処理状態が表示され、アクションが確実に発生すると、アクションが完了します。
ここでは、アプリと実行される特定のアクションについて考慮すべきいくつかの事項と、このオプションが適切でない場合がある理由を説明します。
- データが送信されると、多かれ少なかれすぐに送信されます-アクションが受信されない、確認が受信されない、または失敗する時間の割合はどれくらいですか？
- 失敗した場合、接続が改善されてからX分後にアクションが再送信されると、どのくらい問題になりますか？
- アプリの場合、ユーザーはローカルデータを操作するだけですか？データがサーバーに同期されていないことはどのくらい重要ですか？
即時完了-Twitterの「いいね！」ボタン
ここでは、ユーザーがハートのアイコンをクリックした直後にフィードバックが提供されます。約0.5秒後、サーバーからの実際の応答が、リツイート、いいね、コメントの更新されたカウントとともに受信されることがわかります。アクションが失敗した場合、アクションが失敗したことを示すメッセージを表示してハートが元の状態に戻るか、またはアクションが成功するまでバックグラウンドで再試行されることが期待されます。
