|
Google Maps is one such example. Every time you click on something, change the zoom, toggle the layers, etc., it gets saved to state (and persisted to the URL). That way you can use your browser back/forward buttons to switch between different places or views of places, and also share that with your friends. Miro (the collaborative whiteboard)/Figjam is another... the boards can grow pretty big in x-y space, and losing your place in space is very easy to do, especially if you ctrl-z a few times and forget what you were even working on. Just knowing that "somewhere on this board, something changed" isn't helpful if you can't see what it was. Analytics is another such use case, for when you're composing queries or search filters, date ranges, etc. Google Analytics does something similar by giving each set of criteria its own unique URL, so that you can use the back/forward in your browser to go between states. Not exactly the same as an undo/redo button, but pretty much the same idea. Another example: I work for a solar company, and we're building a web app that equipment installers can use to monitor the performance of rooftop solar arrays they've installed. It tracks, for example, each solar module's power production on a heatmap, arranged in the same layout as on the actual roof. There's a lot of interaction that can happen... selecting a particular unit, choosing a particular timeframe, deciding which metric you want to look at, search terms, table filters, sort order, etc. None of that needs to be written to our database as actual changes to the layout and device pairings. But it would still be handy handy for users to be able to undo/redo, bookmark, permalink, etc. I think of it this way: A set of UI states like that, taken as a whole, is in and of itself a form of "data"... it is a human user's carefully framed view of some point in time, and some selection of data, that they have deemed important. Being able to save and retrieve that state in case they make a mistake (cat jumped on the mouse) or want to share it with others ("hey, check out what's happening to this module on X date at 4pm") is helpful, even if it doesn't ever need to be written to the server (since it can be stored as local state and/or URL strings). |