-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modal: Support draggable modal with no lightbox #2983
Comments
The way i would do this is
|
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. |
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. |
I agree with remembering the position where you drug it if you leave the screen and come back in. |
Per @jamie-norman's comment:
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:
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. |
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. |
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. |
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. |
Another place for this to live—the notes example anyway—would be a contextual app piece in mingle |
Yeah that makes more sense to me. Just dragging the modal around would only let you access things on that page under the modal. |
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. |
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. |
okay can someone send me the new number? |
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. |
Oh, so Mary Pat's application development team does this? |
I guess. Whoever does mingle widgets for your team? Not this team tho. |
I decided we should close this for now. As its not solving any issue for the requesting team. |
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
The text was updated successfully, but these errors were encountered: