横スクロールWebアプリ
新しいWebアプリを開発しています。アプリのコアは、主にビジネスデータを管理するためのシステムです。
また、管理するフィールドが多数あるため（リスト、表示、編集、削除、整理など）、縦ではなく横にスクロールするWebアプリを作成することを考えていました。ページを変更してedit formを単一ページとしてロードする代わりに、list viewがedit formの横にポップアップします。
それを説明しましょう： 
この画像は、右にポップアップするメニューの1つのレベルのみを示していますが、横にポップアップする複数のメニューを使用して、水平バーを大幅に小さくし、12000 px x 900 pxのような大きなワイド画面を生成できます。
第二に、このアプリは、モバイルデバイス（IOS、Android、Windows Mobile）用の独自のバージョンを備えている可能性があり、モバイルブラウザーでアクセスできます。
だから私が求めているのは、ナビゲーションの主な方法が水平であるWebアプリを使用するユーザーエクスペリエンスのprosおよびconsとは何ですか？
[〜＃〜]更新[〜＃〜]
複数のメニューを隣り合ってポップする目的は、一貫したラインを維持して（会社のプロジェクトの1つから開始して）ルートをスローし、サブプロジェクト、タスク、およびアクションの階層を下降してスローすることです。
その構造の1つは次のようになります。
dashboard->すべてのプロジェクトのリストselectsプロジェクトA->opensプロジェクトAのすべてのサブプロジェクトのリストselectsサブプロジェクトC->opensサブプロジェクトCの最近のすべてのアクティビティのリストselectsタスクの管理->opensすべてのタスクのリストselectsタスクX->opensタスクXに関連するすべてのアクティビティのリストselectsタスクXのメモの管理->opensタスクXに割り当てられたすべてのメモのリストselectsノートYを編集->opensフォームを編集してノートYを更新
デフォルトの垂直方向の動作を水平方向の動作で上書きできない場合を除いて、私がすぐに目にする欠点はマウスホイールの使用です。
更新：
同じことがPage UpキーとPage Downキーに有効です。 Windowsエクスプローラのリストモードのように動作させたい場合があります。
私は主な長所を、ユーザーがアプリ内で向きを維持していると考えています。例に示されているように編集フィールドが切り替えられたときに水平スクロールがリストの一部を表示し続ける場合、リストに戻る方法をユーザーに明確にする必要があります（スワイプジェスチャー、[戻る]ボタン、または[キャンセル] 'ボタンをクリックすると、編集アクションがキャンセルされます）。ユーザーが編集を完了せずにリストビューに戻ることができるインターフェイスオプションは、非常に明確にすべきです。
主な欠点は、特にモバイルデバイスで、使用可能な水平画面の領域がないことです。スマートフォンまたは小型タブレットで縦向きでアプリを表示していて、編集ウィンドウを開いた場合、最終的なインターフェースの実装によっては、垂直スクロールせずにすべての編集フィールドを垂直スペースに収めることが困難になる場合があります。これにより、編集を完了するためにリスト項目の下にスクロールすると混乱が生じ、スクロール、スワイプ、キャンセルなどの間でジェスチャーが混乱する可能性があります。
また、人々は垂直スクロールに慣れています。アプリ内を水平方向にスクロールすることには潜在的な利点があるように見えますが、追加の認知的負荷がかかる場合があります。
あなたの投稿を確認するにあたり、いくつか質問がありました。
各アイテムのすべての編集可能なデータがリストビュー内に表示されている場合、編集ボタンで静的テキストを切り替えて編集可能にすることができますか？縦方向の拡張から離れる方向への言及について説明しましたが、編集ボタンでリスト項目を縦方向に拡張して、「編集」ページを開くのではなくインライン編集を許可できますか？
あなたはまた言及しました：
隣り合ってポップアップする複数のメニュー
複数のメニューの目的/使用例について詳しく説明していただけますか？
水平方向のナビゲーションは非常に優れていますが、ユーザーが実際に画面をスワイプするときのみです。これを言い換えると、ハンドヘルドタッチデバイスに適しています。 Webアプリは、本当に賢明な方法で作成されない限り、水平方向のナビゲーションには適さない可能性があります。
これで、アプリの動作を理解する方法から、写真の右側にあるイラストは、より良い方法に似ています。ユーザーがクリックすると、編集画面が画面全体に表示されることなく、画面がアニメーション化されて左にスクロールし、編集画面に対応します。これにより、ユーザーは両方のビューにアクセスできるようになり、リストビュー画面に簡単に戻ることができます。また、ユーザーは自分が作業していた行を記憶する必要もありません。これは良いUXだと思います。しかし、私はスクロールをあなたが言及するほど長く延ばすことを本当にお勧めしません。
また、ここでの問題は、長い水平スクロール（または垂直スクロールでさえ）がある場合、人々はページの上部にあるものを忘れがちです。覚えて考えようとすることは、彼らの認知的負荷に追加されるかもしれません-「今、私はそれをどこで見ましたか？」
水平スクロールに関するNNグループからの興味深い読み物です。これは、横スクロールを考えているときに役立ちました。ここで見つける
http://www.nngroup.com/articles/horizontal-scrolling/
ほとんどのマウスは垂直スクロールのみをサポートしています。 Mac OSでは、Shiftキーを押したまま（ウィンドウでも可能でしょうか？）スクロールホイールを水平にすることができますが、平均的なユーザーがそれを知っているとは思わないでください。ただし、タブレットを使用すれば、水平スクロールは問題になりません。
ビジネスデータはどのように整理されていますか？列数が多くなる可能性のあるExcelのようなテーブルビューである場合、水平スクロールは絶対に避けたいと思います。問題は、ユーザーがテーブルビューに何を配置するのか、そもそもそれがどのくらいの幅でなければならないのか、特に小さな画面で表示する場合は決して分からないことです。テーブルの幅が広すぎると、これまでにスクロールしなければならないのは本当に面倒です（テーブルの下にすべての編集プロパティがあり、ある日は1000行の長さの場合と同じ問題です）。
私はPodioをかなり頻繁に使用しました。これは主に素晴らしいですが、私がそれについて嫌いなことの1つは、テーブルビューの右側に「インスペクター」ビューがあることです。このインスペクターを非表示にすることはできません。幅の広いテーブルや高解像度のディスプレイがある場合、これは大きな問題です。