When you run an embedded application, screens are dynamic and change in response to data and animations. However, you can't see those dynamics during design time, so you're left with blank screens until you simulate or test the application on a device. If you've ever had to work with content that you could not see by default during the design process, you probably had to make that content visible while working with it, and then return it to its invisible state when finished. This workaround is cumbersome and prone to user error.
In this post, we’ll tackle the challenge of designing content that reacts to changes at runtime, the problem with the traditional workflow, and a better way to visualize content throughout its modalities.
Challenges with working with dynamic content at design time
Traditionally, this has been the workflow:
- Toggle the visibility of the layer (and all those that are obscuring it)
- Work with the content on the layer to make desired changes
- Restore the visibility of all the changed layers
This workaround is error-prone because all it takes is forgetting to restore the visibility of a single element to leave things in a bad state. Also, it's tedious and time-consuming because these additional steps aren't providing any additional feedback to the developer when they restore the layers.