Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.having read a comment by snugug on using modals
kill all the modals. They’re terrible everywhere except large screen desktops
i skimmed through these issues
- #1889150: Simplify overlay look, *only use for contextual operations*
- #1260800: Kill the overlay for widths below 640 pixels
- #1829326: Convert Overlay to leverage core breakpoints and media queries to determine its presence and styling
- #1667742: Add abstracted dialog to core (resolves accessibility bug)
- #1909144: Allow #ajax['dialog'] to contain options other than 'modal'
i realize that i don't have an idea of our strategy for using modals / overlay patterns of drupal on mobile devices.
my perception so far is that we want to disable everything that doesn't work for mobile devices. how exactly will that work? everything that is shown in a modal on desktop will be a single page request on mobile? i would be glad if someone pointed me to an issue where the roadmap for this fundamental guideline is being discussed?
having features like overlay and modals by default and disabling them on mobile doesn't sound really intuitive to me. i'd prefer to establish functionality in a mobile-first way and then progressively enhance the interface based on device width and capabilities. given the state we are in the drupal 8 development cycle i don't really think this is the way we can go. but really, as stated above i'd like to know about the strategy for using modals on mobile devices.
thanks, dasjo
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | iphone-ipad-javascript-confirm-dialog.jpg | 51.72 KB | LewisNyman |
Comments
Comment #1
jessebeach CreditAttribution: jessebeach commentedThis is consistent with a progressive enhancement approach in that it works without JavaScript on any device because it follows RESTful principles. The modals and overlays are the enhancements.
Comment #2
LewisNymanLet's put this in context first, what Sam means when he says "modal" is "pop up window". A Modal is defined much broader than that:
It's a secondary conversation, like someone taking you aside, guiding you though a self-contained process, and bringing you back to the main task at hand. They can appear in many forms and in fact they do on iOS and many other mobile operating systems.
Modals do not suck on mobile, I don't agree. Maybe pop up windows do, but I'm not completely convinced that that particular pattern is bad. In some situations I'd much rather have something close to a Javascript dialog than a full page request:
Comment #3
dasjoyes, i agree with jessebeach in #1, those concepts are enhancements.
so maybe the confusion on my side just comes from the desktop-first approach that we are taking when discussing UX changes for drupal 8. i really think we should try to shift our thinking towards mobile-first.
for example the rich text inline editing feature of the Spark initiative will hardly work on mobile devices.
also, how to discover contextual links without a hover state on touch-enabled devices?
Comment #4
dasjoad #2: thanks for your clarification between the concept of modals vs. the their implementation of "pop up windows" LewisNyman.
in practical terms - within a website - i still believe that a "pop up window" will work well for adding a views filter on a desktop device while it can get cramped on a mobile device. where would you draw the line?
Comment #5
LewisNymanThere is definitely a width where a pop up window becomes counter productive when completing complex actions — In #1889150: Simplify overlay look, *only use for contextual operations* this is being considered on desktop as well — this doesn't mean a modal dialogs can not take another form that does not sacrifice the full width of the page. For a good example, open up any well designed mobile twitter client and open a link within a tweet, you'll see how the app allows you to perform a secondary action (check out a website) below allowing you to return to your previous place in your primary action (browsing tweets).
On most mobile UIs you'll see pop up dialogs used for simple 'one tap' actions that are secondary to the main task at hand. I think the native Javascript alerts referenced in my previous comment area good examples of this behaviour.
In #1260800: Kill the overlay for widths below 640 pixels we disabled the overlay completely because it was blocking all other mobile UX work. It was a quick fix, I was quite up for redesigning it in a different form on mobile.
Comment #6
dasjook, thanks for clarifying again.
i think i can close this as there doesn't seem to be this kind of strategy i was looking for. i guess thats just how the doocracy of drupal works and it has its good and bad sides :)
in terms of UX i think the process can be improved, but yeah thats easy to say for somebody like me who follows and participates from time to time but who doesn't commit a regular amount of time into drupal core.
Comment #7
jessebeach CreditAttribution: jessebeach commentedLewisNyman also addressed the issue of "hover" on touch devices for contextual links: #1138844: Add touch support to contextual links.
dasjo, I don't want you to end on what seems a discouraged comment! I think this is perfectly reasonable issue to keep open to solicit ideas against. I agree we have a desktop-centric approach to modals via the overlay right now. It's one of the underlying issues that's driving this meta issue #1882482: [meta] Unify editing approaches in Drupal.
As LewisNyman mentioned, we turn off the overlay right now on small screens (less than 640px). This approach is parallel to saying that folks who visit a restaurant site on a mobile phone don't want a huge image of a family eating pasta to fill up their screen, but folks who visit on a desktop want a giant header image! The analogy is, we're trying to work out what what types of enhancements we can offer with more real estate without simply using the space because we have it to waste on a desktop. If most folks will be admining their site and creating content on large-ish screens, what can we do to make those tasks easier and faster given more resources in terms of space and perhaps bandwidth.
Comment #8
dasjook, thanks for encouraging :)
i understand that we want to add goodies like overlay, modals for screens / devices where it is appropriate, but we always need to keep in mind that it is just an enhancement and if drupal core "commits" itself to be mobile-friendly we should always consider that when prototyping new features. from my point of view, mobile-first is just a methodology facilitates that process / ensures that you always come up with a solution that works for everybody first and then think about the enhancements.
maybe such a guideline is not necessary or already implemented partly. while i felt a lack of mobile considerations regarding modals and inline editing, i have already seen lots of ui component being converted to be responsive:
http://drupal.org/project/issues/search/drupal?version%5B%5D=8.x&issue_t...
this might also affect guidelines for #1804488: [meta] Introduce a Theme Component Library
Comment #9
andypostHey, mobile-first is frontend related and trying it to admin-tasks with wide tables is wrong same as makeing this tables shorter.
Are you really sure that you can edit a view on mobile? Or edit complex node with wysiwyg and put images into edit area?
Comment #10
dasjohey andypost,
yes, i want to be able to edit a view on mobile. if i i have to accomplish a certain task that involves editing a view and the only device at hand is a mobile phone, i will go and edit that view. i'm sure people do so already.
regarding complex wysiwyg and putting images into the edit area, that's a matter of taste and alternate approaches exist. for example creating sections of text and laying out the images separately. this is an entirely different story, but in the end such an approach naturally eases editing complex nodes on mobile devices.
i highly recommend the works of LukeW who has made an endless number of arguments on why you shouldn't restrict the capabilities of mobile users to interact with your website.
Comment #11
LewisNymanMy other comments weren't meant to discorage anyone, in fact I think there's still a lot of work to do!
Currently you can edit a view on mobile, the problem with removing the overlay is you loose that "jump in, jump out" modality the overlay gives you. This feature has value and I'd love to see a modal designed for small screens in #1889150: Simplify overlay look, *only use for contextual operations*
Comment #12
LewisNymanOverlay is out of core, and modal has mobile friendly styling, so I'm tempted just to close this. If you'd rather postpone it to look at again in 8.1 please do.