Another interesting item has crossed my path once again and is worth writing about… The mobile modal.
Try saying that 10 times fast.
A modal is similar to a pop-up, a light-box, or an alert that flashes on the screen, but often contains the ability to do further work so that displaying the contents directly on the UI is not a requirement. For the sake of this writing, I am actually referring to all types of popups on a mobile device, though I will continue to use modal for consistency. But if you want more information on some differences, there is a plethora of information out there.
The difficulty with a mobile modal lies in the
INTERACTION with the modal while using.
I went on a purchasing spree the other day on Home Depot’s website, and there are a handful of modals that open additional information such as the images, the reviews, Q&A section, and most importantly, add to cart and checkout.
The biggest problem I found was that as I was scrolling down the modal, the background was also scrolling, causing confusion when I returned to the UI and realizing that I am now near the bottom of the page. I also found that one of the modals didn’t scroll, while the page background continued to scroll without issues. Obviously this continued to be a problem.
A solution to the problem is easy, lock down the background UI when interacting with a modal. If you’re testing software with a modal, and the background continues to scroll, chances are you are going to have an issue on mobile. This is often due to the condensed width of the pages.
Any modal needs to be closed, and often the solution is to click outside of the modal to accomplish this. However, some modals may require you to click an actual button for the modal to close and data to be transferred back to your UI.
The problem that I see most is a lack of button presence. Often on a mobile device. the modals open nearly full screen, so the ability to close the modal by clicking outside of it, isn’t really a great option. Thus, the buttons need to be clear enough to close the modal, and not be hidden behind the mobile device’s default display structure. Unfortunately each mobile device and it’s corresponding browsers all have built in things that display on scroll, or other action like tap, and drag, so if your button is in the wrong spot, it may never fully display.
It’s important to know this is a possibility, and test it. A possible solution could be placing a button on both the top and bottom of your modals, or adding some padding to the buttons so they don’t hug the bottom of the modal, and therefore the bottom of the screen.
I got into a conversation the other day with a co-worker about wizard modals, and that multiple actions will be taken in a single modal to complete a wizard. I took some time to think about some downfalls of this, as it relates to some websites I frequently visit, and my only real concern is modal loading lag time.
Sometimes modals require an extra second or so to load some important information. While this isn’t usually a big deal because we can fill that time with some form of loading display, the concern I would have is if a modal had to close and re-open in between steps. This type of behavior opens up so many doors to problems, with a modal taking too long in between steps, or a modal just randomly deciding not to load. The user would then have the ability to adjust their normal UI between modals, and could end up with multiple modals open at the same time, or changes that we would never want to deal with.
If you test this type of scenario, test it thoroughly so those modals load smoothly!
While I’m in favor of the modal for some scenarios, and it makes sense to load another subset of information that isn’t immediately pertinent, it does offer opportunity for bugs that we as testers need to be highly aware. Test, test, test!