web-dev-qa-db-ja.com

UWPアプリでのコマンドについて。どのような優れたアプローチが最適ですか？オフィスのような？、UWP？または古典的なwin32？

電気回路、設計、シミュレーションを作成するための、プラットフォームUWP-Windows 10-1903（ユニバーサルWindows）を備えたアプリを書いています。ユーザーは、抵抗器、発電機などを使用して画面上で設計を行い、時間および周波数領域でシミュレーションを実行します。それはプロの使用を目的としており、フリーではありません。

ターゲットデバイスはデスクトップ（キーボード+マウス）とタブレット（指タッチ）です。電話オプションを追加するのはいいかもしれませんが、Windows Phoneが死んだため、それは不可能でした。

ストアを使用してアプリを販売するためのインフラストラクチャが非常に役立つため、私はUWPプラットフォームでの開発を選択しました。マルチデバイスパラダイムも魅力的です。ユーザーはデスクトップで一生懸命作業し、バーでビールを飲みながらタブレットモードでいくつかのことを確認できます。

そうは言っても、私は指揮パターンを設計しようとしています。

アプリには、少なくとも50個のコマンドがあり、10個のメニューにグループ化されています。アプリはプロ用であることを忘れないでください。ユーザーが自分のデザインを作成するのに役立つ多くのツールとダイアログがあります。アプリは、エレクトロニクスの知識で充電されています。

（データを表示するために、ページナビゲーションを使用しません。SyncFusionウィンドウドッキングマネージャーを使用します。これは、データ、曲線、回路を含むウィンドウが多数存在する可能性があるためです。常に前後に移動するのは面倒です）

コマンドの可能なアプローチは次のとおりです。

  1. "win32のようなクラシック" MenuBar、メニュー項目のアイコンとテキスト。これには、ファイルメニューが含まれます。 Classic menu like win32
  2. UWP CommandBarが上部にあり、アイコンとメニューフライアウトがあります。素敵で魅力的なようです。 UWP CommandBar

  3. リボンメニューバー、およびBackstageビュー（ファイルコマンドメニュー用）。 MS Office 2016、2019などのように

    Office ribbon menuBackstage view full screen

私の質問は、どのアプローチを選ぶべきかということです。そしてなぜ？、私はためらっています。

さまざまなWindowsアプリとUWPアプリの多くの例を見ました。しかし、一貫性はなく、各アプリは独自の好みに従っているようです。

例：

  • 3Dペイント：上部にコマンドバーがありますが、「ファイルメニュー」コマンド用のBackstageビューがあります。
  • Win10-1903クラシックペイント：ホームグループとビューコマンドグループ用のリボンバーがありますが、Backstageビューはなく、左上にクラシックファイルメニューが表示されます。
  • Office 2019：完全なリボンメニュー、「古いファイルメニュー」のBackstageビュー。 Backstageビューの設定コマンド
  • Microsoft Edge：上部のコマンドバーがありますが、ほとんどのコマンドがセカンダリコマンドとしてグループ化されており、[...]ボタンのあるフライアウトメニューのようにポップアップ表示されます。
  • Win10-1903 3Dビューアアプリ：UWPメニューバー（アイコン+テキストアイテム）がありますが、ファイルコマンドはクラシック形式のシンプルなメニューにあります。 （Backstageビューで何が起こりましたか？）、もう1つの奇妙なことですが、設定（歯車のアイコン）コマンドは、ファイルメニューではなく、ヘルプメニューにあります。
  • （ストア）DrawingBoard-Pro：上部のコマンドバーがありますが、ファイルコマンドは下部のコマンドバーにあります。
  • Windows BuildCast UWPサンプル：左上隅にハンバーガーアイコンのあるナビゲーションパターン。ほとんどコマンドはありません。ナビゲーションウィンドウの下部にある[設定]コマンド。
  • Win10-1903ビデオエディタ：いくつかのプライマリコマンドといくつかのセカンダリコマンドを備えた上部のコマンドバーがあります。いい例です。

それらの異なる一貫性のない例のすべては、何をすべきかについて私に疑問を与えました。アプリにはどのようなアプローチを使用すればよいですか？たとえば、Backstageビューを配置する必要がありますか？

次に、非常に気になる問題を追加します。 MS-Storeのアプリの多くはおもちゃや安っぽいもののようで、真面目な仕事向けではないようです。 CorelDRAW、AutoCAD、Adobe Photoshop、Autodesk Eagleのような大きなアプリはありません。 Microsoft Storeにあるこれらの小さなアプリはすべて、UXは非常に優れていますが、機能は非常に制限されています（そして安価です）。そして、デスクトップに対応するUWPアプリは、それらのdekstopバージョンよりも劣っています。（VLCプレーヤーがその例です）、なぜこれがすべてですか。

つまり、ストアには、人体アトラスを表示するためのアプリ、化学周期表を調べるためのアプリ、物理法則をチェックするためのアプリ、分圧器の抵抗を計算するためのアプリ、ソーシャルネットワークなどのアプリ、音楽を聴くためのアプリなど、たくさんのアプリがあります、天気を確認するためのアプリ、映画を見る、ゲームをする、電子メール、カレンダーなど。使用パターンは、アプリを開く->アプリを使用->アプリを閉じるようなものです。

しかし、デザインパターンの古典的な使用法を持つアプリはほとんどありません。たとえば、新規または開いたファイル->ユーザーが自分のデザインを編集->ファイルを保存->共有または電子メールで送信するか、紙に印刷します。アプリはもはや「ファイル指向」ではないようですが、それは「旧式」ですか？

電気/電子設計を行うための本格的なアプリを開発するつもりなら、UWPとMS Storeは最善のアプローチでも選択肢でもありませんか？WPFで開発する必要がありますか？

よろしくお願いします。これを極端に長くしてしまいすみません。

gui-designinteraction-designmenudesktop-applicationapp
5
Leandro Alsina

私はとても嬉しいです、誰かがその質問をします。彼らがその矛盾した混乱を引き起こしたので、あなたがそんなに長い質問を書かなければならないのはマイクロソフトの責任です。

すべてがMicrosoftから始まりましたクロスプラットフォーム+タッチ入力を最優先 Windows 8および将来のWindowsリリース。それは私たちを驚かせた

  • windows Phoneと一貫性のあるWindowsエクスペリエンス（現時点では無関係）
  • したがって、マウス入力に適さないタッチフレンドリーなUI
    • タッチフレンドリーなUIでは、UIコンポーネントはさらに離れて配置され、指でターゲットを押すのが理にかなっています。ただし、マウスポインタがあるUIコンポーネントから別のUIコンポーネントに移動する距離が長くなります。フィッツの法則によれば、ターゲットが遠くにある場合、ターゲットにヒットするのに時間がかかるとされています。これが、UWPがマウス入力に対してひどい理由です。
  • アプリでピザ/ブラウジングマップ/消費メディアを注文するために機能する不完全なUWP設計ガイドですが、あなたが述べたように深刻なアプリケーションでは機能しません
  • 深刻なWin32アプリケーションの設計方法に関する最新のドキュメントがない

その結果、Microsoftアプリケーション（設定アプリ、ファイルエクスプローラー、オフィス：文書化されていない異なるスタイルガイドに従っている）の間でも、UIに大きな不整合が生じます。

私はあなたが今いるのとまったく同じ立場にいます。それで、それらは2019年10月の時点でいくつかの混乱を解決するための私のステップです。

結論：UWPは依然としてマルチプラットフォームタッチ指向のフレームワークであり、マウス入力に使用するのはひどいものです。 Microsoft OfficeがUWPを実装していないことが、デスクトップでUWPが失敗する最良の例です。多分build2020にマイクロソフトはUWPを落とし、まったく新しいデスクトップフレームワークを提案しますか？個人的には、私がbuild2020を待っていると思います。

アプリに固有：

  • おめでとうございます、あなたはタッチとマウス入力の両方を統合したい数少ない人の一人です。 UWPは、あなたに最適なフレームワークになるはずです...しかし、さらに深く見ていくと、UWPはデータを消費するように設計されていることがわかります;（
  • 「win32のようなクラシック」メニューバーのスクリーンショットは、多くの項目を示しています。マウスポインターにフォーカスしたUIでは、リボンで整理するのが最適です。
    • Yair A のアプリを確認してください。彼はタブとUWPスタイルのリボンのようなものを統合しました。しかし、彼がUWPガイドラインに正確に従っているかどうかはわかりません。
    • UWPリボンコントロールのショーケースアプリはOffice UWPである必要があります。 （しかし、 Office UWPが死んでいる ;）と思います）ただし、任意のプロジェクトでOffice Mobile UWPリボンコントロールを使用する製品を 提供する会社があります。

  • アプリの使用方法について市場調査を行います。実際に何人の人がWindowsタッチ対応デバイスを使用していますか？

    • 答えが「90％マウス入力」の場合

      • Fittの法則に従ってください！上で提案したばかりのUWPリボンコントロールは、Office 2007以降、私たちが知っているOfficeリボンと比較してパフォーマンスが劣ります。理由：UWPリボンのアイコンは1行だけです。古いリボンのようにうまくグループ化されません。
      • 多分タッチ入力の要件を落としますか？
      • 多分AndroidまたはiOSはタッチのためのより深刻なプラットフォームですか？

    • 答えが50/50の場合：2つのUIをコーディングする必要があります。ごめんなさい...

2
OneWorld