Enterprise: モーダル:ライトボックスのないドラッグ可能なモーダルをサポート

作成日 2019年10月15日  ·  18コメント  ·  ソース: infor-design/enterprise

説明:
ユーザーがアクションフォームを画面の別の部分にドラッグできるドラッグ可能/フローティングアクションフォームのサポート。 さらに、ライトボックスを削除して、ユーザーがモーダルの背後にある画面の詳細をはっきりと確認できるようにします。

アクションフォームに入力するために、現在の画面の情報を参照する必要がある場合がよくあります。

LMCLIENTチケットに関連: https ://jira.lawson.com/browse/LMCLIENT-27266

[5] status landmark type

最も参考になるコメント

@ jamie-normanのコメントによると:

LMCLIENTチケットのユースケースから、「メモ」のようなモーダルのドッキング可能なオプションを検討する機会があると思います。 私はそれが実用性を持っているのを見ることができます。

私には、これはGoogle Inboxでのメールの構成や、LinkedInやFacebookなどのWebアプリのメッセージングシステムの動作と非常によく似ています。

  • ページの一方の端には、ドッキング可能な領域として機能する「タスクバー」のような要素があります。
  • ユーザーは、表示状態が異なる複数のウィンドウを確立できます。 現在「動​​作中」または「使用中」のものが常にあり、残りは「最小化」されています。 彼らはまた解雇されるでしょう
  • 「使用中」ウィンドウは、事前定義されたサイズで拡大または縮小して、必要に応じてその背後にある情報を確認できます(Inboxのコンテキストでは、これは会話を確認するためのものでした。LinkedInで、誰かにメッセージを送る前に記事やプロフィールを読むことかもしれません)。 これは、デフォルトでは、このタイプのUIに不透明度オーバーレイがないことを意味します。

このソリューションは、ドラッグ可能なダイアログウィンドウよりも私にはよく聞こえます。 Soho / IDSは、これまで意図的にこれらを実装することを避けてきました。これは主に、複数のフォームの重いダイアログを一度に開くことができる環境を作成することを避けるためです。 ドラッグ可能なウィンドウは、モバイルまたはモバイル/デスクトップのハイブリッド環境でもうまく機能しません。モバイルまたはモバイル/デスクトップのハイブリッド環境では、ウィンドウを処理するための画面領域が存在しない場合があります。 モーダルを変更するよりも、このようなものを構築することを提案します。これは、定義上、提案された変更では「モーダル」ではなくなります。

全てのコメント18件

私がこれを行う方法は
1)不透明度を制御するための設定https://github.com/infor-design/enterprise/issues/2975を追加します(この場合はゼロに設定します)
2)タイトルのカーソルを変更して、モーダルをドラッグする機能を追加します。 これはトーストで@ deep7102によって行われたことに注意してください
3)トーストのように位置を保存しますか?

  1. ポジションを保存するのは良い考えだと思います。 それが開いている限り、おそらくユーザーによって期待されます。

LMCLIENTチケットのユースケースから、「メモ」のようなモーダルのドッキング可能なオプションを検討する機会があると思います。 私はそれが実用性を持っているのを見ることができます。

そのようなものはありませんが、ドラッグするときに横に動かせば、その位置を覚えておけば目的を果たすことができるかもしれません。

画面を離れて戻ってきたときに薬を飲んだ位置を覚えていることに同意します。

@ jamie-normanのコメントによると:

LMCLIENTチケットのユースケースから、「メモ」のようなモーダルのドッキング可能なオプションを検討する機会があると思います。 私はそれが実用性を持っているのを見ることができます。

私には、これはGoogle Inboxでのメールの構成や、LinkedInやFacebookなどのWebアプリのメッセージングシステムの動作と非常によく似ています。

  • ページの一方の端には、ドッキング可能な領域として機能する「タスクバー」のような要素があります。
  • ユーザーは、表示状態が異なる複数のウィンドウを確立できます。 現在「動​​作中」または「使用中」のものが常にあり、残りは「最小化」されています。 彼らはまた解雇されるでしょう
  • 「使用中」ウィンドウは、事前定義されたサイズで拡大または縮小して、必要に応じてその背後にある情報を確認できます(Inboxのコンテキストでは、これは会話を確認するためのものでした。LinkedInで、誰かにメッセージを送る前に記事やプロフィールを読むことかもしれません)。 これは、デフォルトでは、このタイプのUIに不透明度オーバーレイがないことを意味します。

このソリューションは、ドラッグ可能なダイアログウィンドウよりも私にはよく聞こえます。 Soho / IDSは、これまで意図的にこれらを実装することを避けてきました。これは主に、複数のフォームの重いダイアログを一度に開くことができる環境を作成することを避けるためです。 ドラッグ可能なウィンドウは、モバイルまたはモバイル/デスクトップのハイブリッド環境でもうまく機能しません。モバイルまたはモバイル/デスクトップのハイブリッド環境では、ウィンドウを処理するための画面領域が存在しない場合があります。 モーダルを変更するよりも、このようなものを構築することを提案します。これは、定義上、提案された変更では「モーダル」ではなくなります。

私はあなたの考えが好きですエド。 また、多くのアクションフォームが最小化可能なドッキングコンポーネントに移動することで、滑りやすい坂を下る可能性があると思います。 ユースケースと、それが推奨される場合とUXが低下する場合のガイドラインについて検討する必要があります。

私がLMCLIENTJIRAに入れたユースケースの鍵は、ユーザーがメモを書きながらアプリケーションの他の場所に移動して、メモの作成に関連する調査を行うことです。

ええ、それがドラッグ可能なモーダルを持つ実際のユースケースではあまり解決されません。実際、モーダルから離れると、角度ルーターが閉じます。 そのため、アプリケーションレベルで、特別な領域を維持したまま、さらに何かが必要になります。 これがどのように見えるかわからない。 たぶん新しいページパターン。 かなり複雑になる可能性のあるページで機能する場合。

これが存在するもう1つの場所(とにかくメモの例)は、混ざり合ったコンテキストアプリのピースになります

ええ、それは私にとってもっと理にかなっています。 モーダルをドラッグするだけで、そのページのモーダルの下にあるものにのみアクセスできます。

ジェイミーはこれがどのように機能するかを私に示したばかりであり、このアプローチは間違いなく機能し、このユースケースを達成できると思います。 これもより革新的なアプローチです。

わかりました。モーダルにドラッグを追加するために、この問題を開いたままにしておきます。 この正確なユースケースではありませんが。

誰かが私に新しい番号を送ってもらえますか?

あなたがすることのように聞こえますが、ウィジェットをコンテキストアプリに追加します。 もしそうなら、それはあなたのチームがしなければならないことです。 そして、コンポーネントに入れる必要のあるものは何もありません。 コンテキストウィジェットを作成し、それを行う方法についてMingleチームと協力するだけです。

だから私たちにとって問題はありません。

ああ、それでメアリーパットのアプリケーション開発チームはこれをしますか?

私は推測する。 チームのウィジェットを混ぜるのは誰ですか? このチームではありません。

とりあえずこれを閉じることにしました。 要求側のチームの問題を解決していないため。
また、以前は、使い勝手が悪いUXの問題を回避するため、モーダルにドラッグを追加しないことを決定しました。 そして、モバイルでは動作しません。

このページは役に立ちましたか?
0 / 5 - 0 評価