最新のインターフェース開発の主な問題

こんにちは、Habr！ Dan Abramov の 投稿 「UIエンジニアリングの要素」の翻訳を、優れたインターフェイスで解決する必要のある現代の問題とタスクについて紹介します。 著者は、インターフェースの開発における基本的な問題を検討します。既成のライブラリとフレームワークを使用せずに、フロントエンド開発の分野で市場のソリューションを深く理解できる解釈と解決策だけです。




前回の出版物で、自分の知識のギャップを認識することがいかに重要かについて書きました。 平凡であるために言い訳をしているように思えたかもしれません。 まったくない！ しかし実際には、私たちの知識は会話の広範なトピックです。

「すぐに」知識を始めることができ、特定の順序で技術（Web開発の技術スタック-約翻訳者）を勉強する必要はないと確信しています。 しかし、私はまた、選択した分野での経験と専門的スキルの蓄積が非常に重要だと考えています。 個人的に、私は常にユーザーインターフェイスの作成に最も興味を持っています。

そして、私は何を理解し、 何が重要であると思いますか？ もちろん、私はJavascriptやReactなどのテクノロジーに精通しています。 ただし、経験に伴う最も重要なことはとらえどころのないものであり、それらを正確に定式化しようとすると、通常は抜け落ちます。 私はそれらを言葉にしようとしませんでした。 これは、それらのいくつかを体系化して説明する最初の試みです。

---

今日、技術を学ぶための多くの異なる方法があります。 2019年に賭けるライブラリはどれですか？ そして2020年に？ VueまたはReactを学ぶ必要がありますか？ または角度？ ReduxまたはRxはどうですか？ アポロを学ぶ必要がありますか？ RESTまたはGraphQL？ ここで迷子になるのは簡単です！ さらに、作者も間違っている可能性があります。

認知における私の最大の成果は、特定の技術とは関係ありません。 特定のUI（ユーザーインターフェイス-約翻訳者）の問題を扱っていたとき、私はもっと理解し始めました。 同時に、問題を解決するのに役立つ他の人のライブラリとパターンを見つけることがありました。 そして時々、彼は彼自身の決定を書いた（善悪両方とも）。
問題の理解、 ツールの実験、さまざまなソリューションの適用で構成されるこの組み合わせは、私にとって最も価値のある経験とスキルを与えてくれました。 この投稿では、ユーザーインターフェイスの開発で対処した問題にのみ焦点を当てています。

---

ユーザーインターフェイスを開発している場合、直接またはライブラリを使用しているときに、これらの問題のいくつかに遭遇する可能性が高くなります。 どちらの場合も、ライブラリのない単純なアプリケーションで作業し、これらの問題を再現して解決することをお勧めします。 それらのいずれにも適切なソリューションはありません。 経験には、これらの問題を理解し、それぞれの長所と短所を考えて可能な解決策を検討することが含まれます。

一貫性

あなたはこの投稿が好きで、碑文が現れました：「あなたとあなたの3人の友人がそれを高く評価しました。」 「いいね」ボタンをもう一度クリックすると、碑文が消えました。 簡単ですね！ しかし、そのような碑文が画面上のいくつかの場所に存在する可能性があります。 同様の追加の視覚的表示（たとえば、ボタンの背景色）もあり、これも変更する必要があります。 また、以前にサーバーから受信し、マウスをポイントしたときに表示される「いいね」のリストに名前が含まれるようになりました。 また、別のセクションに移動したり、[戻る]ボタンをクリックした場合、投稿は自分の好みを「忘れる」ことはありません。 ご覧のとおり、1人のユーザーのローカル整合性でさえ、多くの困難なタスクを作成します。 同時に、他のユーザーもあなたに表示されているデータを操作できます（たとえば、表示中の投稿など）。 画面のさまざまな部分でデータの同期を維持するにはどうすればよいですか？ サーバーでローカルデータをいつどのように確認し、変更を送受信する必要がありますか？

応答性

人々は、非常に限られた時間だけ、自分の行動に対する視覚的なフィードバックの欠如を許可しています。 スクロールなどの継続的なユーザーアクションの場合、アプリケーションの反応の欠如は最短期間のみ可能です。 16ミリ秒の1フレームをスキップしても、すでにバグが多く、未完成に見えます。 一部の調査によると、クリックなどの個別の （1回限りの）アクションの場合、ユーザーは通常100ミリ秒未満の応答の遅延を認識します。 アクションに時間がかかる場合は、視覚的なインジケータを表示する必要があります。 ただし、いくつかの直感に反するタスクがあります。 ページテンプレートのシフトを引き起こすインジケータ、またはいくつかの交互の段階を経るインジケータは、アクションが実際よりも「感じるように」長く続く可能性があります。 同様に、アニメーションの1フレームをスキップすることによる20ミリ秒以内のアプリケーションの応答は、30ミリ秒以内の完全なアニメーションよりも「遅く感じる」ことがあります。 私たちの意識はベンチマークのように機能しません。 アプリの応答性を維持するにはどうすればよいですか？

応答時間（遅延）

ネットワークを介したコンピューターの計算とデータの送信には時間がかかります。 ユーザーのデバイスの応答性に影響しない場合は、計算時間を無視できる場合があります（ただし、古いデバイスと予算のあるデバイスでコードをテストしたことを確認してください）。 ただし、ネットワークを介したデータ送信時間の処理は避けられません-数秒で計算できます！ データまたはコードのロードを待機している間、アプリケーションを単に「ハング」させることはできません。 つまり、新しいデータ、コード、またはアセットを必要とするアクションは潜在的に非同期であり、そのロードの状態を処理する必要があります。 これは、ほとんどの画面と要素に当てはまります。 回転するスピナーや空の「穴」のカスケードをインターフェイスに表示せずに、データ送信の遅延を適切に処理する方法は？ ページレイアウトのシフトを避ける方法 そして、コードを絶えず書き換えることなく非同期の依存関係を変更する方法は？

ナビゲーション

インタラクションは、インタラクション時に「安定」していることを期待しています。 要素が突然消えてはいけません。 アプリケーションの内部（リンクなど）と外部（ブラウザーの[戻る]ボタンなど）の両方のナビゲーションも、この原則に従う必要があります。 たとえば、ユーザーセクションで/profile/likesと/profile/follows followingタブを切り替えても、このセクション外の検索フィールドの内容は無効になりません。 別の画面に切り替えても、別の部屋に歩いているように見えるはずです。 人々は、戻ってきたとき、彼らが残したすべてのものを見つけることを期待しています（そして、おそらく、新しいものに満足するでしょう）。 テープの真ん中にいて、プロファイルタブをクリックしてからテープに戻った場合は、テープを最初から再スクロールしたり、テープの過去の状態がロードされるまで待機したりしないでください。 重要なコンテキストを失うことなく、任意のユーザーナビゲーションを処理するアプリケーションを設計する方法は？

古さ

ローカルキャッシュをアプリケーションに追加することにより、[戻る]ボタンの実装を瞬時に行うことができます。 これを行うには、必要なデータをキャッシュに保存します（以前の状態からのデータ-約Translator）。 理論的にキャッシュを更新して、データを最新の状態に保つこともできます。 ただし、キャッシュの実装には新たな課題が伴います。 キャッシュが古くなっている可能性があります。 アバターを変更した場合は、キャッシュに含めて更新する必要があります。 新しい投稿を公開すると、すぐにキャッシュに表示されます。そうしないと、キャッシュが無効になります。 そのようなコードは、最終的に複雑になり、保守が困難になる場合があります。 公開プロセスが失敗した場合はどうなりますか？ メモリ内のキャッシュの長さはどれくらいですか？ データセットを再取得するとき、新しいデータを以前にキャッシュされたデータと結合しますか、それとも古いキャッシュを取り除き、セット全体を再度キャッシュしますか？ キャッシュでページネーションとソートをどのように表示する必要がありますか？

エントロピー

熱力学の第二法則は、おおよそ次のように読めます：「時間が経つにつれて、すべてが完全な混乱に変わります」（もちろん、逐語的ではありません）。 これは、ユーザーインターフェイスにも当てはまります。 特定のユーザーのアクションとその順序を予測することはできません。 いつでも、アプリケーションは膨大な（巨大な！）数の異なる状態のいずれかになります。 私たちは、デザインに従って結果を予測可能かつ制限できるように最善を尽くします。 バグのあるスクリーンショットを見て、「どうしてこうなったのか」と考えたくありません。可能な状態がNの場合、それらの間にN×（N – 1）の可能な遷移があります。 たとえば、ボタンに5つの異なる状態（通常、アクティブ、ホバー、ハイライト、無効）が可能な場合、ボタンの変更を担当するコードは5×4 = 20の可能な遷移に対して正しくなければなりません-またはそれらのいくつかを明示的に禁止します。 可能な状態の組み合わせの増加にどのように対処し、予測可能な視覚的出力を作成しますか？

優先順位

いくつかのものは他のものよりも重要です。 対話インターフェイスは、呼び出し元のボタンの厳密に「上」に表示され、親コンテナを超えている必要があります。 または、スケジュールされたばかりのタスク（つまり、クリックの結果）は、既に開始されている長時間実行されるタスクよりも重要な場合があります。 アプリケーションがズームインすると、さまざまな人またはチームによって作成されたさまざまな部分が、プロセッサの計算能力、ネットワークトラフィック、画面スペース、バンドルサイズなどの限られたリソースを奪い合います。 z-index CSSルールのように、単一の「重要度」スケールでアイテムを配布できる場合があります。 しかし、通常は良いもので終わるわけではありません 。 すべての開発者は、自分のコードを重要と考えています。 しかし、すべてが等しく重要である場合、それは意味する-何も重要ではありません。 限られたリソースのために戦うのではなく、アプリケーションの独立した部分をどのように相互作用させることができますか？

アクセシビリティ

障害のある人に適応していないサイトは、高度に専門化された問題ではありません。 たとえば、イギリスでは5人に1人のユーザーがこの問題に直面しています（視覚的なインフォグラフィックです）。 自分で感じました。 私はまだ26歳ですが、薄いフォントと不透明な配色のサイトはほとんど使用していません。 トラックパッドはあまり使用しないようにしていますが、キーボードに不適切なサイトを使用しなければならない日が怖いです。 障害のある人にとってアプリを悪夢に変えてはいけません-良いニュースは、それほど難しくないということです。 ソリューションとツールを調査することから始める必要があります。 さらに、設計者と開発者が正しい判断を下せるようにする必要があります。 アプリケーションの可用性がデフォルトで有効になり、最新のリビジョンにならないようにするにはどうすればよいですか？

国際化

私たちのアプリケーションは世界中で動作するはずです。 はい、人々はさまざまな言語を話しますが、これに加えて、右から左へ、そして開発者の最小限の労力で、書き込みのサポートが必要です。 アプリケーションの応答性と応答時間を失うことなく、異なる言語とスクリプトをどのようにサポートできますか？

配送

アプリケーションコードをエンドユーザーのコンピューターに配信する必要があります。 どのような送信方法とフォーマットを使用しますか？ この質問では、それぞれの答えはそれ自身の長所と短所のセットとの妥協になります。 たとえば、ネイティブアプリケーションは、サイズが大きいため、すべてのコードを事前にダウンロードする必要があります。 通常、Webアプリケーションの起動時間ははるかに短くなりますが、使用中に多くの遅延とダウンロードを処理する必要があります。 これらの2つのオプションからどのタイプの遅延を選択するかをどのように決定しますか？ ユーザー使用統計に基づいてどのように応答時間を最適化しますか？ 最良の決定を下すために必要なデータは何ですか？

柔軟性（弾力性）

自分のプログラムでバグに遭遇することを好む人はいません。 ただし、一部のバグは必然的に本番環境に移行します。 そして、何が起こるかは非常に重要です。 一部のバグは、正しくないが、厳密に定義され、事前定義された動作を引き起こします。 たとえば、コードは特定の条件に対して不適切な状態を示します。 しかし、バグの結果、アプリケーションがレンダリングを完全に停止した場合はどうでしょうか？ この場合、視覚的な出力が決定されないため、プログラムの意味のある実行を継続することはできません。 フィードから1つの投稿をレンダリングする際のエラーは、フィード全体のレンダリングを「中断」したり、アプリケーションを不安定な状態にしたりすることはありません。これにより、さらにエラーが発生します。 パーツの1つでデータをレンダリングまたは受信するときのエラーを分離し、残りのアプリケーションの正しい操作を継続するコードを作成するにはどうすればよいですか？ ユーザーインターフェイスを作成するとき、フォールトトレランスとはどういう意味ですか？

抽象化

小さなアプリケーションでは、額の上記の問題をすべてハードコーディングして解決できます。 しかし、アプリケーションは成長する傾向があります。 アプリケーションのさまざまな部分を再利用、分岐、統合し、他の人と一緒にできるようにしたいと考えています。 私たちは、作業の過程でしばしば変化し進化するため、異なる人々によって受け入れられる1つの全体の部分間の理解可能な境界を定義すると同時に、過度に厳格なロジックを避けたいと考えています。 UI実装の詳細を隠す抽象化をどのように作成しますか？ アプリケーションの成長に伴うこれらの問題の再発をどのように回避できますか？

---

もちろん、私が言及していない多くの問題があります。 このリストは決して完全または網羅的ではありません。 たとえば、設計と開発の間のコラボレーションのトピック、デバッグまたはテストのトピックには触れませんでした。 おそらく私たちはこの別の時間に戻るでしょう。

ソリューションとして、データを表示するための特定のフレームワーク、またはデータを受信するためのライブラリを念頭に置いて、これらの問題について読みたいと思います。 しかし、これらの解決策が存在しないことを想像して、もう一度読んでみることをお勧めします。 これらの問題をどのように解決しようとしますか？ シンプルなアプリケーションでアイデアを実現してください。 Githubで実験の結果を見ることができてうれしいです。 （ Twitterで Dan Abramovにタグを付け、リポジトリへのリンクを添付するだけです-約翻訳者）。

これらの問題で特に興味深いのは、それらのほとんどがあらゆる規模で現れることです。 ツールチップなどの小さなウィジェットで作業しているときや、TwitterやFacebookなどの巨大なアプリケーションで作業しているときに遭遇することがあります。

使用するアプリケーションの重要なユーザーインターフェイス要素について考え、上記の問題のリストをもう一度実行します。 開発者が行ったトレードオフについて説明できますか？ 同様の動作をゼロから再現してみてください！

優れたユーザーインターフェイスを開発し、サードパーティのライブラリとフレームワークを使用せずに小さなアプリケーションでこれらの問題を実験することについて多くのことに気付きました。 複雑なインターフェースを開発する際に、ソリューションとトレードオフを深く理解したい人にはこれをお勧めします。