🙆🏽 👨🏽 🎚️ Webインターフェース：開発またはその逆？ ✏️ ⛴️ 🌼

もちろん、ユーザーインターフェイスとその開発の低下についての考えは長年にわたって紡がれてきました。今日、それらを共有したいと思います。多くの人々は、スパース機能と限られたユーザビリティを備えた古いテキストモードの疑似グラフィックインターフェイスを覚えています。その後、グラフィカルモードのウィンドウインターフェイスに置き換えられ、現在はWebインターフェイスになりました。しかし、アプリケーションの消費者、ユーザー、入力オペレーターの速度は向上していますか？画面とレポートの開発速度は向上しましたか？多くの人があなたにしっかりと「いいえ」と言うでしょう-プログラマーとユーザーの平均的な生産性は、テクノロジーの新しい一歩が進むごとに減少しました。そして、これには多くの客観的な理由があります。それらに加えて、生産性を向上させる方法について今日停止します。

テキストモード

テキストインターフェイスの欠点については説明しませんが、明らかです。しかし、テキストモードでは、否定できない利点がありました。

画面を完全に制御します 。画面全体がアプリケーションプログラムインターフェイスで完全に覆われており、パンやフリルの余地はありませんでした。実行中のプログラム、コミュニケーターのポップアップウィンドウ、オープンソーシャルネットワークを備えたブラウザーは数十もありませんでした。

キーボードの使用率が高い 。特殊なパッケージでは、キーの組み合わせの知識がなければ不可能であることは誰もが知っています。しかし、マウスの出現により、ユーザーはホットキーやカーソルさえも学習せず、多くのプログラマーはキーボードを使用してアプリケーションのフルコントロールの実装を学習しませんでした。

行動の曖昧さ 。通常、各時点でテキストモードのアクションの数は非常に限られているため、プログラム、その開発およびテストを簡単に操作できます。異なる機能は実際には重複せず、改善中に何かが壊れるという事実に関する問題ははるかに少なくなります。

ウィンドウインターフェース

グラフィカルユーザーインターフェイス、OOPとウィンドウシステムの使用、ビジュアルコントロール間のメッセージ送信、マウスとタッチスクリーンの使用に基づいて、多くのことができましたが、さらに時間がかかりました。

ウィンドウアプリケーションの利点：

ユーザーアプリケーションのインターフェイスのコンテキストは、オブジェクトモデル、ステートマシン、サービスデータ構造を拡張してプロセス（キャッシュ、インデックス、または連想配列、ツリーなど）を高速化するのに十分な長さです。クライアントサーバーアプリケーションの場合、サーバーを犠牲にして同じことが言えます。
ハードウェアアクセラレーションを使用してリッチグラフィックスを表示し、マウスを使用して画面上でグラフィックオブジェクトを直接移動することにより、グラフィックオブジェクトを管理することができます。これはグラフィックスプログラムやゲームには不可欠ですが、データベースアプリケーションの場合は過剰です。
画面には、より多くの情報を配置し、視覚的な要素（色、フォント、ピクトグラムなどを使用）でグループ化して強調表示できます。ツールチップ、コンテキストメニュー、検証中のフィールドのグラフィックマーカーなど、さまざまな動的効果を使用できます。
テーブルははるかに便利になりました。列の幅の変更、複数選択、セル内のコントロール、スクロール、タイトルをクリックして並べ替え、さらにはテーブルにツリーを表示する機能もあります。これの一部はテキストモードで使用できましたが、GUIには、OSまたは開発ツールレベルで実装されたすべての既成のソリューションがあります。

今批判：

マウスの右手（および左手などの入力）。したがって、右手はマウスとキーボードの間を常に移動しています。たとえば、F4キーまたはキーの組み合わせを押す代わりに、マウスを画面全体に移動してツールバーに移動し、そこで小さな画面ボタンをクリックします。
開発とテストはより複雑になり、多くの非同期イベント、タイマー、サーバー、他のウィンドウやアプリケーションからの信号がありました。情報システムの環境（環境）の安定性と予測可能性は低下しています。
プログラムコードは多くの場合、インターフェイスに「結び付けられる」ようになりました。OOPでは、サブジェクトエリアのロジックと視覚化のロジックでシステム機能に混乱が生じました。機会が増え、実装手段の自由度が大幅に向上し、アプローチとアーキテクチャの形成が遅れています。

もちろん、経験豊富な開発者ははるかに優れたインターフェイスを作成し始めましたが、ほとんどの開発者とユーザーはリラックスして異端に夢中になりました。

結論： 過度の自由は大衆にとって破壊的です。

Webアプリケーション

そして、すべての人に幸福が訪れました。ユーザーにコンピューターにクライアントをインストールする必要がなくなり、DLLバージョン、.NETバージョン、およびコンピューターの多くの設定を心配する必要がなくなり、ユーザーコンピューター上のソフトウェアの競合を処理する必要がなくなりました。すべてはブラウザで行われ、現在でも標準はすべてのブラウザでかなり許容範囲内でサポートされています。ソフトウェアを更新する必要はありません。データセキュリティの側面：すべてがサーバーに保存され、一元的にバックアップおよび保護されます。プロトコルに関しては、心配する必要はありません。HTTPSとJSONがあり、すべてが便利で保護されています。不正なバージョンのアプリケーションソフトウェアは使用できません。コンピューターにはインストールされませんが、ネットワーク上のSaaSモデルで使用されます。

しかし、すべてがとても良いですか？

ネットワークが存在しない場合、私たちは仕事をすることができません。まあ、それはどういうわけか耐えられます。ネットワークは常にあるべきです。そうでなければ、グループワークやコミュニケーションはありません。入力中に何かがフリーズしたり、ネットワークが失われた場合-入力されたデータが失われ、ネットワーク経由で送信することはできませんが、ローカルに保存する場所はありません（ローカルストーリーとWeb SQLはまだどこでも利用できません）。 RESTイデオロギーの封印、状態の完全な欠如。資金不足さまざまなブラウザとその機能には、追加のテストとデバッグが必要です。メイクアップはIE用に個別に行われることもあります（他のブラウザ用のバージョンはあまりありません）が、これには非常に注意が必要なマークアップがあります。

ウィンドウインターフェイスから何が継承されますか？

マウスの優位性が悪化しました。
気晴らしが大量に追加されました。
OOPの原則は継承されますが、Webについて再考する必要があります。

OOPとパターンをほんの少しだけ再考しましたが、他の人は考えずに取りました。ただし、Webの特異性は、サーバーアプリケーションが1秒未満でライブを行うことです。一方、サーバーアプリケーションはステートレスであり、ユーザーインターフェイスはページの更新時にその状態（フォーム、変数、オブジェクトの値）を保持しません。一般的に、RESTは私たちのやり方ではありません。ユーザーインターフェイスやデータベースアプリケーションでは、空気のような状態が必要です。また、多くの人が解決策を見つけています。セッションメカニズムとCookieサーバー側のキーバリューDBMSであるHTML5のローカルストレージとWeb SQL。

Web開発のトレンド

すべての問題と新しい機会を考慮に入れて、ネットワークの高度な部分全体によって積極的にサポートされている主流が現れました。

ミニマリズムとシンプルさ -そして、サイトとアプリケーションは内部ではより複雑になり、外部ではより簡単になります。これは、すべての上級プレイヤーが教えてくれていることです。ユーザーは、必要な結果を得るために最小限のアクションと選択を実行する必要があります。
対話性と非同期性 -インターフェースは動的になり、ページのリロードと画面の変更は消え、ロードは断片的に徐々に行われます。アプリケーションは画面を徐々に変更し、ユーザーのアクションに応答します。
コンテキスト -操作を呼び出すための情報出力とコントロールは、論理的に予想される場所に表示され、必要な場合にのみ表示されます。画面とユーザーの注意を保存します。
同期と彗星 -サーバーが独自のイニシアチブでイベントを生成するアプリケーションが増えています。これにより、ユーザーの画面をデータベースまたはサーバーのメモリ内のデータの現在の状態と同期させることができます。
フルスクリーンレイアウト-Web全体ではなく、つまりWebアプリケーションでは、解像度に応じてインターフェイス要素間のサイズと境界線を再配布することで画面を最大化する傾向があります。
簡素化されたモバイルインターフェース -通常のブラウザを搭載したモバイルデバイスの急増に伴い、低解像度およびタッチスクリーンサポート用のインターフェースを個別に開発する必要があります。
標準のサポート -新しい機能と仕様を使用して問題を解決する方法ですが、たとえばhtml5を介してサウンドとビデオを再生したいが、フラッシュは私たちを保証しますが、ローカルストレージがない場合はサーバーに状態を保存します。古いブラウザで表示すると視覚化も簡素化されますが、アプリケーションは引き続き機能しますが、見た目は簡単です。

視覚的なコントロールとソリューションをさらに詳しく考えてみましょう。

スクロールゾーン -コントロールのあるすべてのコンテンツが1つのトラックバーを右に（または右から左に左に）一度にスクロールする場合、典型的なスクロールは全画面表示です。ただし、Webアプリケーションの場合、これは便利ではなく、より適切な解決策は「パネルの接続」の原則です（ウィンドウアプリケーションで通常行われます）。たとえば、ツールはブラウザウィンドウの上部の境界に接続され、全幅に引き伸ばされるパネルに配置されます。左側には、動的にロードされたツリーがウィンドウの左端に接着されたパネルがあり、下部にはステータスバーがあり、右側にはコンテキストタスクがあるパネルがあり、画面の中央部分全体がドキュメント、マップ、テーブル、画像などの作業オブジェクトで占められています各ゾーンには独自のスクロールがあります。もちろん、中央部分のゾーンのみがスクロールし、他のすべてのパネルはスクロールしないか、トラックバーではなく、1つの軸に沿ってのみスクロールが実行されることが理想的です。

スプリッター。 ウィンドウアプリケーションの場合、マウスでドラッグできるパネル間の動的なセパレータが一般的です。また、Webインターフェース用に実装されましたが、あまり使用されておらず、スプリッターはモバイルアプリケーションではすでにまったく適用できません。いくつかの解決策があります。複数の状態を持ち、コントロール要素をクリックすると状態を切り替える「離散スプリッター」。「スマートスプリッター」-解像度と接続のためにパネルのサイズを調整します。マウスでドラッグすることは非常にまれです。「フローティングスプリッター」-パネルが長時間非アクティブの場合、パネルが非表示になり、マウスを上げると元に戻りますが、タッチスクリーンに問題があり、マウスカーソルがありません。

グリッド -テーブルおよびより複雑な複合グリッド。それらには多くの問題があります：

テーブルがページ全体とは別にスクロールしている場合、つまり、スクロール中にスクロールしていることがわかります。これはtextareaにも当てはまります。
各グリッド線のアクションボタンの複製は 、すべての旧世代のWebインターフェースに共通する問題です-それは目に波打っています。
アクションのあるボタンが終了します 。GMailのように、つまり、ツールバーと一緒にグリッドとすべてを同時にスクロールする共通のスクロールがページにあることを説明します。中央のグリッドをスクロールし、中央の行で何かをしたいので、ツールバーにアクセスするには、画面を上下に回転させる必要があります（Habr記事エディターのように）。
そして、 ページング （彼らに私を責めさせてください、しかし私はそれについて私が考えるすべてを言うでしょう）-3番目のページを超える人はほとんどいません。ユーザーが長いリストを閲覧することはありません。どこかで整理して、それらをより詳細にフィルタリングするだけでは意味がありません。ページング時にページ全体がリロードされるときに特に楽しいです。ソートは必ずしも便利ではありません。すべてのDBMSがページング用のデータを選択するために最適化されているわけではありません。大規模なデータセットを使用すると、サーバーの負荷が増大します。代わりに何ですか？仮想グリッド-以下を参照してください。

グリッドに入れたいもの：

グリッドの仮想化 -スクロールはすぐに（レコードの数だけ）大きくなり、表示されているものだけが読み込まれるか、マージンがまったくないか、わずかです（先読み）。オプションがあり、スクロールして古いブロックを削除しながら、データセット全体がクライアントにポンプされるか、100-200レコードの特定のバッファがプリエンプティブラインロードで割り当てられるまで、古いレコードを保存できます。
サーバー側またはブラウザ側での形成 -この問題を永遠に解決し、根本的に不可能です。誰かがAJAXを介してJSONデータを送信し、それをクライアント上の準備されたグリッドに出力することに慣れている一方で、誰かがAJAXを介してHTMLに直接レコードを送信することに慣れている。事前に入力されたグリッドには別のオプションがあります（これは、レコードが多くない場合に正当化されます）。それは正しいです-それはタスクの詳細によって決定され、優れたグリッドは3つすべてのオプションを実装する必要があります。
キーボードでの作業 -彼らはすでにこれについて多くのことを話しましたが、すべての最新のWebアプリケーションでは、キーボードでの本格的な作業が本当に不足しています。これは代替方法ですが、カーソルナビゲーションとホットキーとファンクションキーが必要です。
インライン編集 -つまり、AJAX / JSONでフォームを呼び出したり、編集した値をサーバーに送信したり、バッファーを蓄積したり、「保存」をクリックするとすぐにバンドル全体を送信したりせずに、値を編集します。

ツリー -完全な幸福のために、ツリーはグリッドとほぼ同じリストを満たす必要があります：動的にロードする、マウスとキーボードで制御する、その場で編集するなど

メインメニュー -悪夢のように忘れてください！ Web上のウィンドウアプリケーションからのこのアタビズムには、生命権はありません。

ツールバー -ボタンとコンボボックスをダンプする代わりに、ツールバーは徐々に適応性のあるコンテキストになり、アプリケーションの現在の状態またはフォーカスされている要素に適用できる機能のみが表示されます。

Combobox-標準のhtmlコンボボックスは、完全に再定義できないデザインと機能の両方でひどいものであり、行の単なるドロップダウンリストに制限されています。多くのモードとインクリメンタル検索を備えたコンボボックスが必要です。これにより、大きなディレクトリから選択できるようになり、複数の値を選択できるようになり、グループ、写真（および通常、リッチHTML + CSSデザインの要素）を使用できるようになります。

おわりに

私たちのチームは、私たち自身だけでなく、Webアプリケーションのコントロールのセットを形成し、一部を作成し、一部を取得し、一部を購入します（これは時間がない場合のみです）が、使用済みおよびテスト済みのセットを常に拡張しています。この記事はレビューに過ぎません。誰かが興味を持っている場合は、空き時間にベストプラクティスについて簡単に公開できます。たとえば、最近、いくつかのコントロールと欠落した曲線を使用してjQuery UIを完成させました。また、概要を示したアプローチ、優れたコントロール、デモ、スクリーンショット、およびアプリケーションへのリンクについて、ご意見をお寄せいただきありがとうございます。

追加：瞑想のために写真を削除しました。あなたはそれが気に入らないと思います。

近日中にイラストの収集を試みます。

図1：GMailの例でツールバーを残すのがいかに面倒か