高速ユーザーインターフェイスインターフェイスを設計するための3つのルール

この投稿では、最適化の計算とレンダリングに頼ることなく、ナビゲーションとインターフェイスとのユーザー対話の速度を上げる方法について説明します。 推奨事項は、サーバーがデータの受信にのみ使用され、すべてのインターフェイスロジックがアプリケーション自体にあるアプリケーションに関連しています。 このエントリは、ロジック、プレゼンテーション、およびデータが十分に分離されていないアプリケーションに対するクライアントアプリケーションの利点に関するものです。



特に重要な推奨事項は、サーバーからのデータがあまりにも早く到着せず、頻繁にアクセスできない場合に、インターフェイスを開発または設計する必要がある人向けであることがわかります。



アプリケーションとの高速ユーザーインタラクションを整理するためのルールは、次のように定式化できます。

1. 計算は、インターフェースとそのレンダリングとの相互作用をブロックするべきではありません-ユーザーは常に自分の興味の焦点を示すことができるはずです。
2. ユーザーがアクセスしたオブジェクトのページは、オブジェクトがロードする必要があるデータを待たずに、すぐに表示される必要があります。
3. ネットワークへのリクエストは、1つの大きなグループにまとめて送信されるべきではなく、すぐに送信されるべきではありません。 少し遅れて、必要に応じて折りたたんで優先順位を付ける必要があります。

このノートに記載されている情報は、音楽seesu.meを検索して聴くためのアプリケーションのインターフェイスを設計および開発した私の実際の経験です 。 last.fm、VKontakte、ex.fm、hypem.com、soundcloud.com、discogs.com、youtube.comなどの異種サービスからの巨大なデータ層が調和して組み合わされたアプリケーション









パフォーマンスを改善せずにフィードバックを改善することに関連する推奨事項が、instagramアプリケーションの操作について公開されました。 しかし、推奨事項は、ナビゲーションまたはデータの受信のいずれにも関連していませんでしたが、むしろ、送信に関連しています。

speakerdeck.com/mikeyk/secrets-to-lightning-fast-mobile-design





これらの原則を使用するアプリケーションを見たことはありません。 ただし、これらのルールの要件をシステムレベルでシステムに実装し、アプリケーションの新しい部分とのやり取りを設計する際にそれらを考慮すると、これらのルールを順守することで、アプリケーションとのやり取りの速度に対するユーザーの印象を劇的に改善できると確信できます。



私は、「インスタントフィードバック」の原則を一貫して順守し、自分の邪魔になる技術的制限の条件の下で行動し、実施した実験の結果としてこれらのルールに到達しました。



インスタントフィードバックは、私が固守するいくつかの基本原則の1つにすぎません。 音楽を聴くためのアプリケーションのインターフェイスを設計するとき、Jeff Raskin氏の著書「インターフェイス：コンピュータシステムの設計における新しい方向性」に記載されている原則とアイデアに導かれます。 彼のアイデアの結論と結果だけでなく。



Jeff Raskinはコンピューターインターフェースの専門家であり、ユーザビリティに関する記事の著者であり、70年代後半にMacintoshプロジェクトを開始したことで最もよく知られているApple Computerの従業員であるThe Humane Interface（31号）の著者です。



簡単に言えば、私が本から作成する主な論文は次のように定式化できます。

• 情報の提示は、スケーラブルな構造の形式で実装する必要があります。
• 瞬時のフィードバック、最小限のデータ入力で最大限の構造化情報を発行。
• 追加のユーザー入力に対するコンテキスト要件のみ。 追加のデータがすぐに必要なときのみ。
• インターフェイスの効率性の尺度としての「直感性」、「クリック数」、「クリック数」の拒否。
• 新しいユーザー習慣の形成。
• モーダルウィンドウの完全な拒否。

そこで、2000年に初めて出版された本からのインスタントフィードバックの原則に従って、Googleがインスタント検索を開始する半年前にhabrahabr.ru/post/88494インスタント検索を開始しました 。 en.wikipedia.org/wiki/Google_Search#Instant_Search



ユーザーがインターフェイスをすばやく操作できるようにするために必要な各ルールの詳細：

1. アプリケーションで何が起きても、計算がどれほど忙しくても、ユーザーはいつでも必要なものを指定できます。 javascriptで記述されたアプリケーションでは、setTimeoutを使用してインターフェイスのロックを解除します（setImmediate、requestAnimationFrameも使用する予定です-レンダリングは、長時間クリックする機能をブロックしないなど）。
2. すぐに、オブジェクトを埋めるデータをロードする前でも、空白の画面ではなく、オブジェクト自体のページだけでなく、その構造全体が表示されます。 ビジュアルブロックは、ネットワークからまだ受信されていないデータに何らかの形で依存します。 さらに、このオブジェクトにネストされているオブジェクトのすべてのブロックも表示されます。 データが到着すると、表示されているブロックがいっぱいになります。 これにより、ユーザーはダウンロードが完了するのを待たずに、すぐにページの構造を分析し、別のオブジェクトへの移動について決定することができます。
3. オブジェクトからオブジェクトに移動するとき、ユーザーは関心のある焦点を明確にします。 まず、ユーザーのランディングページに対するデータリクエストを完了する必要があります。 残りのリクエストは、後で実行するか、ユーザーが残したページに対する未処理のリクエストなど、完全にキャンセルすることができます。 オブジェクトは他のオブジェクトにネストされ、独自のクエリを持つことができます。 クエリの一部は、ユーザーの関心のコンテキストでデータを表示するために必要な場合がありますが、そうでない場合もあります。 さらに、そのような要求の優先順位も、ページでデータが使用される順序、したがって、ネストされたオブジェクトの表現が宣言される順序で変更する必要があります。 （つまり、多くの要素とネストされたオブジェクトで構成されるページは、データが上から下に到着すると補充されます）。

アーティストのページにアクセスすると、ページ構造全体がすぐに表示されます。







アーティストに関する情報が完全にダウンロードされるのを待たずに、ユーザーはすぐにアーティストの最高の構成に移動できます。 この移行後、まず最初に、最高の曲のリストがダウンロードされ、そのアーティストのみに関する情報が受信されます。







アーティストのページを完全に表示し、最小限の入力データで最大限の構造化情報を提供する要件を遵守するため、seesuはlast.fmで3つのリクエスト、hypem.comで3つのリクエスト、discogs.comで2つのリクエスト、soundcloud.comで2つのリクエストを実行します







また、アーティストのページの任意の部分に移動するために、どのリクエストでもデータがロードされるのを待つ必要はありません。



seesu.me/o#/catalog/Pixelord/_に移動して、異なる構成をすばやく切り替えて、最後に選択した曲のデータができるだけ早くダウンロードされるようにすることができます。 そして、次のコンポジションのデータと前のコンポジションのデータがロードされます。



また、（実験として）ユーザーhttp://seesu.me/o#/users/lfm:yodapunk/tracksのlast.fm曲リストリストページを開くこともできます。ここでは、要素が上から下にロードされます。 ダウンロードしたものから最新のアイテムを選択し、それがロードされていることを確認してください。その後すぐに戻って、選択したリストが順番にロードされていないことを確認できます。













これら3つのアプローチと、視覚ブロックの比較的固定された位置、高さ、幅の組み合わせにより、アプリケーション内での快適で非常に高速な動きが可能になり、習慣が形成されます。 レンダリングを高速化し、コンピューティングを行い、サーバーから応答を得るまでの時間を短縮すると、アプリケーションが高速になり、ページ間の遷移の控えめなアニメーションにより、ネットワーク要求を行う際の遅延の印象が滑らかになります（Seesuでは120ミリ秒続くアニメーションを使用しています）。

これらのルールにどのように到達したかについて

（読めません）



技術的な問題について言及したとき、私は使用するサービスのネットワーク要求に対する制限と、ブラウザーの制限および負荷の両方を意味していました。

たとえば、VKontakteは1秒に複数のリクエストを送信することを禁じています。



（曲のファイルを検索する）リクエストを毎秒送信するキューを実装すると、キュー全体が非常に長い時間遅延することがわかりました。 キューは十分に速く形成されます。いくつかの異なるコンポジションをクリックするだけです。 最後に選択した曲の再生が始まるまで待つのは、特にファイルが選択した曲ではなく、再生を拒否したファイルを検索していることがわかったときに不快になります。 まず、現在選択されているコンポジションのファイルを見つける必要があることが明らかになりました。



最小限の入力で最大限の構造化された情報を表示するという原則を少し考えた後、ページの構造を表示し始めました。 クライアント側には、テンプレートがあります-ページの視覚的構造、そのスケルトンに関する情報。 なぜ表示しないのですか？ テンプレートと、そのページではなく、そのページで使用できるデータを即座に表示することは、本を読んで自分で策定した原則の1つに直接従うことです。

-最小限のユーザー入力で最大限の構造化情報を表示する、即時フィードバックの原則。



last.fmサービスのlast.fm APIにはリクエストの数に制限はありませんが、ページからページにすばやく移動する場合、同時に実行されるリクエストの数は6（6）を超える場合があります。 1つのドメインへの6つを超える接続を開くブラウザーはありません。 多数のリクエストがあると、その負荷が顕著になります。 要求に応じてデータを受信する前に、ユーザーが気を変えて別のページに移動できるという事実に注目しました。 この観察により、要求を即座に送信しても、ユーザーが必要な情報を受信するまでの待機時間は短縮されないが、逆に増加するという事実が明らかになります。 これを実現するために、すべてのネットワーク要求を破棄して優先順位を付けることにしました。



初期段階でのリクエストの初期化は、コンポジションのリストを持つページ専用に実装されました。 その後、last.fm apiを使用して新しいデータソースを接続することに積極的になったとき、すべてのAPIのすべてのページに優先順位付けとリクエストのディスチャージを実装しました。 現在、ページからページに移動するとき、既存のキューに新しいリクエストを追加するときに、現在のページと必要なリクエストを考慮して、優先度が自動的に再カウント、変更されます。 残りの要求は、追加の逆の順序で実行されます（完了しません）。



サーバー側を慎重に処理する必要がある場合と同様に、サーバー側に影響を与える方法がない場合、要求を放電することは非常に役立ちます。



聞いた？

-「サーバーへの大きな負荷がかかります！」



2010年9月に送信の延期、要求の延期、および即時フィードバックの助けを借りて、 rossomachinと私は、ドメインshop.masterhost.ru/templates/default/domainsをチェックする最もクールな形式を実行しました 。 技術的な制限とサーバー開発者による私たちの願いの限られた実装にもかかわらず。

インターフェース開発の将来について

（読めません）



現代のインターフェースに囲まれたい場合、少なくとも14年前に策定されたインターフェースの要件を考慮したツール、インターフェースの記述方法、プログラミング言語が必要です。 インターフェイスの作成効率は大幅に向上するはずです。



インスタントフィードバックの利点は、まだ誰にも明らかではありません。 誰かは、この原則と、それを尊重するインターフェースとのやり取りから得られる生産性に触発されています。 たとえば、入力されたデータの即時解釈を提供するインターフェイスを使用する場合：











同時に、インスタントフィードバックを備えたアプリケーションの最小限の存在については、そのようなアプリケーションの実装に手を携えていた人はほとんどいないと結論付けることができます。 これについての説明を見つけることは難しくありません-そのような原則の実装は本当に面倒なプロセスです。



システムに実装された瞬間フィードバックの原則を一貫して体系的に遵守するには、追加のプログラミング、追加のインターフェイス状態の設計に時間がかかりました。



私の場合、アプリケーションのすべてのページは、データをダウンロードせずに表示できるように設計する必要があります。 ページを埋める必要があることを考慮して、データが到着すると再描画されます。 技術的な実装の観点から、このような要件は、DOMへのアトミックな変更の助けを借りて、ブラウザに負荷をかけることなく行われるべきでした。 または、巨大な視覚ブロックを再描画すると、ブラウザに負担がかかります。 読み込まれたブラウザでは、ユーザーがすばやく対話することはできません。 ディスプレイの部分的な再描画の実装は、最初に各ページの手動、半自動の方法で時間がかかります。 自動再描画のためのシステムの作成に時間が費やされた後、この時間は後で最小化されます。 リクエストの数は多く、管理されていないブラウザ読み込みキューを形成するため、リクエストの優先順位付けは関係を考慮して実装する必要があります。



この原則の一貫した遵守に加えて、私はジェフ・ラスキンの本から他の原則を一貫して実施しています。 たとえば、モーダルウィンドウの欠如、スケーラブルな構造でのデータの表示。 原則は、アプリケーションの外観だけでなく、アプリケーションコードの記述方法も決定します。 もちろん、原則は、アプリケーションの開発に費やす時間を決定します。



巨大なデータレイヤーで単独でアプリケーションを実行する、複雑な要件を満たし、狂気に陥らないコードを整理するために、私は自己記述フレームワークとテンプレートエンジンを使用します。 このコードは、オブジェクトの複雑な関係、それらの状態の関係、ページの構造を記述しています。 スケーラブルな構造でのデータ表示、オブジェクトの優先順位付け、便利なテンプレート、MVCへの分離の原則の要件を満たします。 上記の要件をすべて満たす新しいインターフェイスの構築に対処できると確信しています。独自のツールを組み合わせて使用​​することは、市場に存在する他のツールを使用するよりもはるかに効果的です。 私のツールの有効性は向上する可能性がありますが、改善後でも、幅広い開発者向けの最新のインターフェースを構築できるツールになることはできません。 他のライブラリがそのようなツールではないように。 さらに、そのようなツールの存在が可能であることは私には明らかです。