Especially, don't do this for interactions that aren't core to your business. Under the real world constraints where I work, this kind of design thinking causes non-core features to explode in complexity, cost, etc.
replySpend your complexity where it has an impact!
If you have control of your data model, design its structure and endpoints around user goals. Then expose that layer as directly as possible in the UI.
replyThat's probably a half-decent summary of domain-driven design.
Not necessarily. You design your data model to prioritize (1) correctness and (2) performance. It doesn't have to resemble the UI at all, as long as the UI can fit on top of it with some abstractions.
replySome examples that come to mind: - video games with their entity-component systems; - high-performance text editors like VS Code. [1]
[1] https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
I wasn't advocating a single-layer data model or speaking against common data structures, just saying the structure of the data should follow directly from user goals.
replyCorrectness and performance are normally the top user goals.
hard agree. the issue here is that it tries to implement user goals but based on something other than asking the user and then respecting their choice. that becomes guessing at the user's goal, never confirming, and then acting on that goal anyway. the end result is that i as the user am presented with options and there's no map between what option i pick and what the behavior of the app actually is.
reply