When you create a stack of overlays in a DPS article, which overlays take precedent over others? While the answer is complicated, it’s also logical. Before I go into which overlays win out in a stack, first I need to explain the concept of “inactive” vs. “active” overlays.
Inactive and Active Overlays
When we’re teaching the concept of interactive overlays, we like to explain that non-interactive content is added to the background image of the page while interactive overlays appear on top of this background image, which is why they’re called “overlays.” While that’s accurate, it doesn’t tell the whole story. It fails to take into account that some overlays can be active or inactive.
Let’s take a look at Colin’s image sequence of the Fremont Bridge in Seattle. You can experiment with this example in the Advanced Overlays issue of DPS Tips, or you can watch this quick 10-second video.
Notice what happens to the red arrow and the image sequence overlay. Tapping the image sequence hides the red arrow, which is part of the background image, and double-tapping the image sequence exposes the red arrow again. Why?
If DPS articles include memory-intensive overlays, you might run into trouble when viewing them on mobile device with obvious memory limitations. Sometimes the app becomes sluggish, sometimes it crashes, and sometimes it takes a PDF article too long to load.
How do you avoid these memory problems? If you go against guidance and do something like create a pan and zoom image with a 5000×5000-pixel PNG image or scale down a huge video, you’ll likely crash your app. However, in some cases, individual overlays that by themselves wouldn’t cause memory problems can be a problem when combined with other memory-intensive overlays on the same page or even on adjacent pages.
Whenever you turn to a page in an article, the DPS viewer loads each page above and below that article into memory, and it loads the current page of the next or previous article. This pre-loading improves the performance of articles and helps prevent crashing when users swipe quickly.
In this example, viewing page 2 of the third article loads the pages above and below it as well as the first page of the articles before and after.