Introducing: "Scenes" or "Snapshots" to resolve screen duplicates

I don’t know if this idea has already been expressed here. At first glance, I could not find anything about it.

You advertise that you no longer have “artboard chaos” with Antetype. That is possible and correct. However, different artboards (here: screens) have their reasons to exist, in order to have different screen states directly accessible and if necessary to export them in projects as an image.

My wish would be to have as few screens as possible, simply to reduce redundancies and thus possible sources of error and inconsistencies, BUT still have the possibility to quickly access screen states, e.g. dialog XY open, tab 2 displayed, etc…

In my imagination you could introduce so called “Scenes” or “Snapshots”. I.e. that I have the current state in the prototype “stored” in it. This way you don’t create redundancies/copies of screens, but states are simply saved and made quickly accessible like favorites. I could quickly show these in customer presentations without going through click paths or I could export them as PNG. The number of keyscreens thus remains the same, which serves the clarity.

What do you think about this?

2 Likes

Agreed 100%. Screen states were actually one of my earliest requests on Antetype 1.0. I was just about to re-ask but you beat me to it! As a workaround, I have long used my own screen state module like so: Antetype Cloud

2 Likes

Cool! At least it takes away the redundancies regarding screens. If Antetype itself would now take away the work of wiring manually, that would be a great added value.

Interesting idea and yes, I remember the “Screen States” @bendansby mentioned.

Do you have an idea how to define a “Scene/Snapshot/Screen State”? In Edit Mode, where I can imagine storing the active states (and maybe visibility :thinking: ) or more enter “In Place-Preview”, play around and hit “make snapshot”. I am asking because storing states/visibility sounds more or less straightforward, but the second option sound complicated since we can basically change everything in presentation mode. Maybe we could record the actions the user made to get to the state.

What happens if you later change the prototype and the “Snapshot” can’t be restored?

Yeah, I think widget state and visibility would be a good place to start. In terms of a state breaking, I would probably handle it the same way you handle broken interactions, which is to say there’s room for improvement :laughing:

For me personally, the biggest advantage of a built in system versus my own is if it were possible to easily export all screen states as though they were screens. Exporting images for comment is a big part of my workflow.

1 Like

@fizfaz The most intuitive way for me personally would be to go into “In Place-Preview”, play around and hit “snapshot”. This is true for me as I’m into wiring things up and bringing things to life. But of course there might be people who don’t wire up things. In these cases your first approach would be a way to do it. I think both ways are somehow important as they fit different user strategies.

Regarding your questions “what happens if you later change the prototype”… then of course the snapshot would be “broken”. A little hint would be good for awareness, but it shouldn’t be an error or something. Personally, I would then recreate the snapshot. This seams for me logical as it means also that I changed significant parts of the screen anyway that broke the snapshot.

1 Like

Thinking on this, I realized a more robust version of states that lets you modify any property could be a solution to a flaw in Antetype’s piggybacking on widget states to add media queries. Because only widgets can have breakpoint states, you end up turning lots of things into widgets that are not widgets (that is, reusable atomic components) in order to change layout of containers for mobile, for example. If any given cell’s property could be modified for a given screen state or “super-state”, that would reduce the “misuse” of widgets.