(disclaimer, I have read papers and slide decks, but not the book)
The way I would think about the “Refresh” concept:
There is some kind of persona, like “Viewer” or “Receiver”; I wouldn’t call it “User”, since I associate users with login, and that seems unnecessary for refresh to make sense.
There is some some remote state and a cached local copy
The OP states that when the remote state changes, refresh changes the local copy
A related concept might be “Sync”, where the local version needs to send changes to the remote version
I would say that it’s a good idea to pretend that the system is perfectly reliable when describing the concept, since failure isn’t relevant to the core of the UX around refresh (though it may be for sync).
This also makes me wonder about the relationship between concepts and “user stories”. My intuition about user stories is that there are actually two stories around refresh: one where I want to update my local copy with newer content, and one where I want to recover from a failed state in which my local copy is empty (e.g. website failed to load due to spotty internet). My sense is that there are not two distinct concepts, but I don’t have a good sense as to why not.
Not clear to me that we even need a Viewer: if the principal that executes the action isn’t identified as as an argument of the action, that principal is probably not relevant (and could be swapped out at any point by another one, eg).
One difference between a concept OP and a user story is that the OP encourages us to think about a full history and not just a transient interaction. Here that raises the question: how did the remote data get there in the first place, and is its updating related in any way to the refreshing? Presumably there’s an update action and a refresh action?
Is it relevant that the remote data is often a (mutable) collection of (immutable) items? Or is the concept rich enough with just a single data item?
Not sure what you mean by assuming perfect reliability—that after an update, a refresh always gets the value it put? But maybe it’s the essence of Refresh that you just get a recent value (and that if you refresh again, you never get an older one)?
Is the local copy being empty a failed state? Maybe that’s a common starting state when the data isn’t there yet?
Re user stories vs. OPs, in general a concept can have multiple OPs. I’ve written a draft post about this. Comments welcome!
Makes sense. My main point was that “User” should be avoided
This doesn’t match my experience with user stories; after all, a feature is rarely specified by a single user story, so there would usually also be a story involving setting the remote state (though there probably wouldn’t be an explicit story for their composition, whereas I’d imagine a concept would include something explicit).
I think it depends on what the elaboration brings you. I think the single datum version is rich enough for any application in which the remote state is an incidental detail, but if it needs to actually deal with the distributed nature in common cases, more nuance may be necessary. And of course you can instantiate the concept multiple times or have arbitrarily complex state in one instantiation.
I’m just imagining that for certain applications, the right description ignores the distributed nature of the system; for others, the right description is the one you just gave, which guarantees monotonicity; for yet others, perhaps there’s also some guarantee against staleness. Perhaps the maximally general concept is what would be included in a catalog, and the practitioner would decide on the level of detail to include in the design?
Sort of. I’m imagining something like a 503 error, where the remote state can’t be read; in principle (and perhaps it would be better UX) you could just get a cached version of the web page from your browser.