最近、オプティミスティックUIの概念が人気を集めています。 私の意見では、その利点は非常に過大評価されており、欠点は隠されています。 この記事では、欠陥をより明確に実証し、現実的なUIと呼ばれる適切な代替手段も提供したいと思います。
TL; DR
→ リアルなUIコンセプトデモンストレーション
→ ソースコードリポジトリ
背景
Realistic UIに加えて、Webおよびモバイルのバックエンドとやり取りするための3つの方法を思い出すことができました。
1.「従来の」UI
AJAXを配布する前に、ほとんどすべてのアクションでページのリロードが必要であったため、UIは次のようになりました。
現在、このアプローチは非常に一般的ですが、最新のテクノロジーによりはるかに楽しいUXを実現できることは明らかです。
2.「世界をブロックする」UI
AJAXの配布後、開発者は、「従来のUI」の場合のように、個々の操作のためにブラウザーでページをリロードすることなく、一歩前進してリモート要求を実行する機能を実装できました。 ただし、そのようなWebアプリケーションは依然としてシンアーキテクチャクライアントであり、その状態を管理できませんでした。 したがって、別のページに切り替えるとリモート操作が中断される可能性があります。この問題の最善の解決策は、インターフェイスをブロックし、クライアント側でダウンロードインジケーターを表示することでした。
3.楽観的なUI
さらに、シングルページアプリケーションの概念の出現と普及により、「厚い」クライアントを開発し、アプリケーションの状態を管理することが可能になりました。 Optimistic UIは、操作の結果として何が起こるべきかを開発者が知っていることを前提としています。操作が成功したかのようにインターフェイスをすぐに更新し、同時にバックグラウンドで対応するAJAXリクエストを実行できます。 1〜3％の場合、操作は失敗し、エラーメッセージが表示されます。 オプティミスティックUIはFacebookによって積極的に推進されており、Relayなどのソリューションはデフォルトでこのメカニズムを使用しています。
楽観的なUIに対する批判
楽観的なUIは、新しくて新鮮なアイデアのように思えるかもしれませんが、詳しく調べると、その使用が正当化された場合、非常にまれであることが明らかになります。 次の問題に名前を付けることができます。
1.オペレーションを「重要」と「重要でない」に分ける
Optimistic UIは「重要な」操作には適していません。たとえば、映画のチケットを購入する場合、完了したかエラーが発生したかを100％知る必要があります。 また、オプティミスティックUIは、一意のトランザクション番号など、サーバーがクライアント側で予測できないデータの一部を形成する操作には適していません。
これにより、いくつかの問題が同時に発生します。 第一に、サービスにはほとんどの場合、いくつかの「重要な」操作が含まれます。それ以外の場合、原則として存在する理由はあまり明確ではありません。 これは、開発者がバックエンドと対話する2つの異なる方法を実装およびサポートする必要があることを意味します。「重要な」操作と「重要でない」操作では、より多くの時間と労力が必要です。 一方、ユーザーは、一部の操作が1つの方法で実行され、一部の操作が別の方法で実行されるという事実にも慣れる必要があります。 これは誤解や問題の原因になる可能性があり、それぞれユーザーサポートのコストが増加し、UXが低下する可能性があります。
第二に、どの操作が「重要」であり、どれが「重要でない」かを決定する人がいなければなりません。 決定は常に主観的です。 たとえば、「いいね」は「重要ではない」操作のように見えるかもしれませんが、実際、サービスの一部のユーザーにとっては、「いいね」の欠如は気分を損なう可能性があります。 そのような決定を行うためには非常に時間と労力が必要なので、開発者とユーザーの両方にとって、すべてのタイプの操作に使用できるユニバーサルソリューションがあればよいでしょう。
2.データ同期、トランザクション性、および競合解決の問題
理論的には楽観的なUIはオフラインモードでうまく機能します。 実際には、モバイル開発者になじみのある多くの問題があります。
最初はトランザクションです。
はい、メッセンジャーにとっては操作の順序は重要ではないかもしれませんが、他のタイプのアプリケーションにとってはそうではないことがよくあります。 これは、クライアント側とサーバーの両方で、操作の正しい順序を保証するメカニズムを考え出す必要があり、追加の労力と時間を必要とすることを意味します。
次に、クライアントが5つの異なる操作をオフラインで実行し、それらをサーバーと同期しようとしているとします。 最初の2つは成功し、3つ目はエラーで終了しました。 この状況で何をすべきですか？ 実行を停止しますか？ 最初の2つの成功した操作をロールバックしますか？ 4番目と5番目を完了してみてください？ そして、彼らが第三の実装に依存している場合はどうなりますか？ そして、ユーザーに問題を報告する方法は？
ご覧のように、多くの疑問が生じますが、それぞれに熟考と、多くの場合個別のアプローチが必要です。 そのようなソリューションは、複製されたソリューションや一連のベストプラクティスよりも最新技術であるため、サポートするのに非常に不十分であり、適切に拡張できません。 また、膨大な数の可能なユーザーアクションシーケンスがあり、さまざまな組み合わせのテストプロセスを地獄に変えます。
3.ユーザーの不正行為
実際にまだ実行されているにもかかわらず、ユーザーにアクションが成功したことをユーザーに示すと、失敗した場合にシステムが信頼できないという感覚が生まれます。
リアルなUI
免責事項
Realistic UIの概念を思いついて定義しましたが、私は発見者の発見者であると主張していません。 RESTの原則がインターネットが近代的な形で広く普及してから10年以上後に定義されたように、Realistic UIのアイデアは現在さまざまなプロジェクトに見られます。 特に、AzureとGoogle Cloud Platformのコントロールパネルは、Realistic UIの原則に従って実装されています。
現実的なUIの原則
ユーザーインターフェイスの一部のみがブロックされます。 たとえば、ユーザーがフォームに入力して[送信]ボタンをクリックすると、リモート操作が完了するまでフォームデータの変更が不可能であれば、誰も別のページに移動したり、別の独立したアクションを実行したりすることはできません。
UIには、すべてのアクティブな操作を表示するウィジェットが含まれています。 このウィジェットを使用すると、ユーザーは操作の現在のステータスを追跡したり、必要に応じて対応するページやページの一部に移動したりできます。
- UIには、失敗した操作を表示する別のウィジェットが含まれています。 このウィジェットから、ユーザーは失敗した操作を再開したり、対応するページやページの一部に移動したり、エラーを無視したりできます。
リアルなUIと 楽観的なUI
現実的なUIは、すべてのタイプの操作に単一のメカニズムを提供します。
現実的なUIはユーザーをだますことはありません。
現実的なUIを使用すると、複数の操作を同時に実行できますが、それらの実行が互いに独立して確実に実行されるため、競合を解決するプロセスが大幅に簡素化されます。
リアルなUIにより、ユーザーは実行および実行された操作の全体像を把握できます。
したがって、リアリスティックUIは、バックエンドと対話するためのすべてのアプローチから最高の機能を利用しますが、欠点のほとんどはありません。
おわりに
Optimistic UIの概念に関する既存の誇大宣伝の波が非常に心配であり、より客観的にその評価に近づくことができる議論を引き起こすことができることを望みます。
現実的なUIのアイデアを実際に示すために、リンクをクリックして表示できる概念実証を実装しました。
GitHubに投稿したデモのソースコード。
私の議論があなたを納得させるものであると思われる場合、私はリツイートとアスタリスクに非常に感謝します 。 Optimistic UIの既存の問題は、考えられるすべての困難を認識せずにそれらを実装することを決定したチームに大きな損害を与える可能性があるため、これらのアイデアを同僚に提供することは非常に重要だと思います。
もちろん、私はコメントでの異議と批判の両方を非常にうれしく思います。それはコンセプトをさらに良くするでしょう。