このブログシリーズの最初の部分では, 整然とした明確な構造を持つユーザーインターフェースの設計に焦点を当てました. 今日は, ワークフローとユーザー体験を強化したアプリを設計するためのヒントについて説明します. 構造, 情報を提供するツールヒントや警告メッセージなどを通じて, シミュレーションアプリのユーザーワークフローを改善する方法について学習します.
直感的なワークフローパスを構築する
前回のブログ で述べたように, アプリの構造は, アプリの使用方法と理由を示す必要があります. アプリのユーザーインターフェース (UI) 構造は, タスクの順序も示唆する必要があります. 1つのタスクが完了すると, デザインは次のステップを暗黙的に示唆する必要があります (またはウィザードの場合は, 次のステップを明示的に示唆します). たとえば, アプリのメインツールバーには, まずジオメトリを更新し, メッシュを作成し, 計算 ボタンをクリックして, シミュレーションレポートを生成することが示されています. 入力と結果 フォームコレクションには, まずジオメトリ入力と動作条件を定義し, その後 (計算 の後), 結果を調べることができることが示されています.
このような構造は, シンプルなアプリでは簡単に実現できますが, COMSOL Multiphysics® ソフトウェアのユーザーインターフェースは, シミュレーションプロセスで同じワークフローパス (左から右, 上から下) に従うことに注意してください. これは, 西洋の言語の読み方と一致しています. COMSOL ソフトウェアが, 西洋のソフトウェアに触れずにアラビア語圏の国で作成されていた場合, ワークフローは右から左になっていた可能性があります.
図 1. メインワークフローパスは左から右, 上から下に移動します.
アプリユーザーのコントロールと集中力を高める
UI デザインは, ユーザーをシミュレーションアプリに誘導すると同時に, モデリングプロセスをコントロールしていると感じられるようにする必要があります. 入力またはコマンドの影響は明確である必要があり, 入力の変更によってシミュレーションの他の部分が予期しない変更を受けることはありません.
同時に, ユーザーはシミュレーションアプリの操作にヘルプを必要とする場合があります. このブログで例示されているヘリカルスタティックミキサーアプリとヒートシンクアプリでは, すべての入力フィールドにチェックが装備されているため, ユーザー入力にタイプミスがあった場合, すぐにユーザーに伝えられます. さらに, 各入力フィールドにはツールヒントがあるため, ユーザーは後で煩わしいエラーメッセージを読む必要がなくなり, さまざまな入力の制限についてサポートを受けることができます.
図 2. ヘリカルスタティックミキサーアプリの入力フィールドには, アプリに埋め込まれたモデルの制限と有効性をユーザーに伝えるツールヒントが含まれています. ここでは, ツールヒントがミキサー内のヘリカルブレードの数の有効期間をユーザーに伝えています.
モデリングプロセスを問題なく進めたアプリで, 計算 を選択すると, プロセスのかなり早い段階で入力したタイプミスに関するエラーメッセージが表示されることがあります. 入力エラーがある場合はすぐにユーザーに伝える方がよいでしょう. そうすれば, ユーザーは 計算 ボタンをクリックするときに, 不安を感じることなく, コントロールできていると感じられます. アドレナリンラッシュはスキー旅行や急流ラフティング旅行のために取っておきましょう.
図 3. アプリユーザーは, 計算 ボタンをクリックするときに不安を感じるべきではありません. これは, ユーザー体験が良好であることを示す兆候ではない可能性があります.
また, 図4 の シミュレーション情報 セクションに示されているように, 計算 ボタンをクリックしたときに何が起こるかをユーザーが把握できるように, 予想される計算時間についてユーザーに通知することもお勧めします.
アプリは, 入力の状態と計算結果についてもユーザーに通知する必要があります. ユーザーが入力を変更して表示される結果に影響する場合は, 通知する必要があります. 非常に明確な方法の1つは, アイコンと色を使用することです. たとえば, ヘリカルスタティックミキサーアプリでは, 下の図に示すように, シミュレーション結果が入力と同期していない場合に, 赤い警告メッセージがユーザーに通知されます. これは煩わしいので, 好みに応じて, 目立たない警告メッセージを検討する必要があります. いずれにしても, ユーザーがこの種の問題を知ることが重要です.
同様に, 入力と出力が同期していないときにレポートを作成しようとすると, アプリはエラーメッセージを発行します. このエラーメッセージが表示される理由は, アプリが入力の二重記録を実行できないため, 計算 後に入力を変更すると, レポートに間違った数値と結果が生成されるためです.
警告メッセージと色, 特に赤色を使用する場合は, 非常に注意する必要があります. 警告や色が多すぎると, シミュレーションアプリに混乱が生じます.
図 4. 計算が入力と同期していないことを示す警告メッセージ. ここでは, 入力でらせん状のブレードの数が5から4に変更されましたが, ジオメトリもシミュレーション結果も更新されていません. 予想される計算時間もアプリの UI に表示されます.
ユーザーが入力を変更して, ウィンドウの位置が突然移動するなど予期しない結果になった場合, ユーザーは気が散ったり, シミュレーションをコントロールできているという感覚を失ったりする可能性があります. 入力フォームを変更する場合 (たとえば, コンボボックスを使用して), さまざまなフォームのサイズと構造を可能な限り類似させる必要があります. こうすることで, コンボボックスで異なる選択によって行われた変更のみが強調表示され, ユーザーの注意が集中します. たとえば, 下の図の ヒートシンクタイプ コンボボックスを変更すると, 入力フィールドの説明が変更され, 方向 コンボボックスが追加されるだけです. 残りの入力と説明はまったく同じ場所にあります. フィンジオメトリ フォーム全体も, ヒートシンクタイプの変更中はそのサイズを維持します. このような詳細を見落としていると, サイズの変更によってウィンドウ全体の位置が移動し, すぐにユーザーが混乱し, 意図したタスク以外の何かが変更されたと誤解することになります. 
図 5. ヒートシンクタイプコンボボックスで変更すると, 関連する入力フォームのみが変更されます. その他はすべてまったく同じ位置のままです. これにより, 変更が強調表示され, ユーザーの注意をそらすことがなくなります.
アプリ UI を対象プラットフォームに適応させる
ほとんどのマルチフィジックスモデリングおよびシミュレーションアプリは, デスクトップコンピューターおよびラップトップコンピューターの Windows® オペレーティングシステム, Mac OS, または Linux® オペレーティングシステムで使用するように設計されています. これらのオペレーティングシステムの画面サイズと解像度は, 特にプロジェクターを使用してアプリを実行する予定の場合は大幅に異なる場合があります. したがって, アプリを設計するときは, 常にさまざまな画面サイズと解像度を考慮する必要があります.
アプリウィンドウはサイズ変更可能で, 低解像度の画面ではスクロールバーを利用できる必要があります. ただし, アプリウィンドウのサイズを変更するときに, 数値やテキストの入力フォームまたは出力フォームのフォントサイズを変更したり, 行と列の距離を変更したりすることは望ましくありません (列の幅は変更できますが, 列間の距離は変更できません). 注意して, 必要なフォームのみのサイズを変更する必要があります. グラフィックス出力フォームと表の列幅のサイズを変更できる機能も役立つ場合があります.
ユーザーがアプリウィンドウのサイズを制御できるようにすることは重要ですが, アプリは見た目が美しく, ユーザーに制御感を与える必要があることに注意してください. ユーザーインターフェースコンポーネントは, 意図されていない限り, 再グループ化や再配置を行わないでください. ウィンドウのサイズを変更するときに, 無関係な変更によってユーザーの注意が散漫になることはありません.
図 6. アプリケーションビルダーを使用すると, サイズ変更可能なフォームとフォーム列を指定できます.
シミュレーション結果を常に確認する
優れたアプリには, 埋め込まれたモデルが正しく定義され, 数値モデル方程式が望ましい精度で解かれることが必要です. 有用なアプリを構築するには, 常に次の点に注意する必要があります.
- 数学モデル方程式の検証
- 方程式がモデル内で正しく定義されているか
- 数値モデル方程式の解の検証
- 解は, 説明しようとしている現象を説明しているか
- モデルが有効でなくなる場合
- 解の精度の推定
- メッシュ収束解析から得られるヒント
世界最高のシミュレーションアプリを設計できたとしても, 上記の要件を満たさなければ, そのアプリは役に立ちません.
シミュレーションアプリ設計のワークフローを最適化するためのチェックリスト
このブログシリーズのパート1と2で説明したガイドラインを, 独自のアプリ作成プロセス用のシンプルなチェックリストにまとめることができます.
- グラフィックス結果を除き, フォントと色は最小限に抑えます. セリフフォントは使用しないでください.
- 対象のオペレーティングシステムの外観と操作性に従います.
- UI コンポーネント, ウィジェット, ボタンのサイズは標準外にしないでください.
- ユーザーインターフェースコンポーネントとウィジェットは, ユーザーが見つけやすい場所に配置します. たとえば, メインツールバーはウィンドウの上部に水平に配置します.
- モデリングとシミュレーションのプロセスの流れがわかる UI 構造を作成します.
- 乱雑にならないようにし, タブ付きのフォームコレクションとコンボボックスを使用して, アプリウィンドウが過負荷にならないようにします. タブやフォームを変更するために, ボタンやその他の非標準ウィジェットを使用しないでください.
- コンポーネントとウィジェットの間隔と位置は慎重に検討して決めてください.
- ユーザーインターフェースコンポーネントを垂直方向と水平方向に揃えます.
- フォームとウィジェットグループの周囲に区切り線とフレームを使用して構造を伝えます.
- 予想される計算時間, 実際の計算時間, および入力と結果のステータス (同期または非同期) に関する情報を含めます.
- 入力フィールドとコマンドの背後に安全な入出力制御を含めます. 入力フィールドの境界チェックを含めて, 問題が発生したときにユーザーにすぐに通知し, レポートを生成しないようにします.
- ツールヒントとヘルプオプションを含めます.
- 目的のプラットフォームと画面解像度でアプリをテストし, 必要に応じてアプリウィンドウを一貫した方法でサイズ変更できるようにします.
- COMSOL Server™ 製品で使用するためにサムネイルと説明を使用します.
他の資料
- ブログシリーズのパート1, シミュレーションアプリの設計と構造を改善するためのヒント を読んでさらに学びましょう
- ブログ アプリケーションビルダーと COMSOL Server™ を使用する7つの方法 をご覧ください
- お住まいの地域で開催される 今後のワークショップ を見つけて, シミュレーションアプリの設計スキルをさらに磨いてください
Windows は, 米国およびその他の国における Microsoft Corporation の登録商標または商標です.
Mac OS は, 米国およびその他の国で登録された Apple Inc. の商標です.
Linux は Linus Torvalds の登録商標です.
コメント (0)