Enterprise: Modal: Support draggable modal with no lightbox

[jamie-norman]

Description:
Support for draggable/floating action forms where the user can drag the action form to another part of the screen. In addition, remove the lightboxing so the user can clearly see details on the screen behind modal.

There are often cases where referencing info on the current screen is necessary to populate the action form.

Related to LMCLIENT ticket: https://jira.lawson.com/browse/LMCLIENT-27266

[tmcconechy]

The way i would do this is
1) Add a setting https://github.com/infor-design/enterprise/issues/2975 to control the opacity (set to zero for this case)
2) Add the ability to drag the modal around by changing the cursor on the title. Note that this was done by @deep7102 in toast
3) Do we save the position like toast?

[jamie-norman]

1. I think saving the position would be a good idea; probably expected by the user as long as it's open.

I think there may be an opportunity to explore a dockable option for a "notes" kind of modal from the use case in the LMCLIENT ticket. I can see that having utility.

[tmcconechy]

Ok we dont have anything like that but maybe by remembering the position it could serve the purpose if they move it to the side when dragging.

[adinenno]

I agree with remembering the position where you drug it if you leave the screen and come back in.

[EdwardCoyle]

Per @jamie-norman's comment:

I think there may be an opportunity to explore a dockable option for a "notes" kind of modal from the use case in the LMCLIENT ticket. I can see that having utility.

To me, this sounds pretty similar to how the email composition was in Google Inbox, or how the messaging system in webapps like LinkedIn or Facebook works, where:

• There's a "taskbar" kind of element on one edge of the page that serves as the dockable area.
• The user can establish multiple windows that have different visible states. There's always one that currently "working" or "in use", while the rest are "minimized". They would also be dismissible
• The "in-use" window can be expanded or shrunk with pre-defined degrees of size to get a look at the information behind it, if necessary (in the context of Inbox, this was to get a look at the conversation. On LinkedIn, it may be to read an article or a profile before you message someone). This means that by default, there is no opacity overlay in this type of UI.

This solution sounds better to me than draggable dialog windows. Soho/IDS has avoided implementing these on purpose in the past, largely to stay away from creating environments where multiple, forms heavy dialogs could be opened at once. Draggable windows also don't work well in mobile or mobile/desktop hybrid environments, where screen real-estate may not be present to handle them. I'd propose building out something like this over changing our Modal, which by definition would no longer be "modal" with the proposed changes.

[jamie-norman]

I like your thoughts Ed. I also think it could potentially lead us down a slippery slope with lots of action forms moving to a minimizable, docking component. We will have to think about use cases and some guidelines for when it's advisable and when UX would suffer.

[adinenno]

I think the key to the use case I put in the LMCLIENT JIRA is that the user wants to go to other locations in the application while writing the note to do research relevant to writing the note.

[tmcconechy]

Yeah if thats the actual use case having a draggable modal doesnt solve much and in fact if you navigate away the modal will close y the angular router. So we would need something more at the application level with a special area that stays put. Not sure how this would look. Maybe a new page pattern. If it works on any page that could get pretty complicated.

[jamie-norman]

Another place for this to live—the notes example anyway—would be a contextual app piece in mingle

[tmcconechy]

Yeah that makes more sense to me. Just dragging the modal around would only let you access things on that page under the modal.

[adinenno]

Jamie just showed me how this would work and I think that this approach could definitely work and accomplish this use case. It's a more innovative approach too.

[tmcconechy]

Ok, i'll keep this issue open for adding drag to the modal as that has been an ask. Although not this exact use case.

[adinenno]

okay can someone send me the new number?

[tmcconechy]

Sounds like what you will do is add a widget in a contextual app piece in mingle. If so thats something your team will have to do. And nothing that needs to go in the components. You would just build out an contextual widget and work with the mingle team on how to do that.

So no issue for us.

[adinenno]

Oh, so Mary Pat's application development team does this?

[tmcconechy]

I guess. Whoever does mingle widgets for your team? Not this team tho.

[tmcconechy]

I decided we should close this for now. As its not solving any issue for the requesting team.
Also we previously decided not to add dragging to modals as its working around UX issues with a bad usability. And will not work on mobile.

[tmcconechy]

See some additional comments here https://jira.infor.com/browse/UXD-2349?focusedCommentId=7500444&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-7500444