A UI can be represented as a set of concurrent/asynchronous prompts. UI takes the model and possible next actions, presents this to the user, gets a response, and returns this as an action which is then applied to update the model.
Alerts and login forms are clearly prompts. But so is an complex editor: it constantly prompts the user for the next action, e.g. enter text or change existing text’s formatting. Or a social-media site: possible actions are “login”, “view post”, “create post”, and so on.
Even an FPS can be warped into a prompt-based UI, where the model is the game state (or what the player sees of it), and the prompts are “move, turn, shoot”. But you probably shouldn’t do that. Asp bad examples: a weather or stock viewer where your options are null, and the model is the weather or stock which you can’t change.
Nonetheless prompt-based UI is really useful for many otherwise-ordinary cases. It lets you write a UI like a CLI and automate your UI very easily; it tells you which state is truly part of the “model” and which is just part of the UI; it’s composable spatially (more elements) and temporarily (series of steps). I don’t know if it’s been explored much.
In prompt-based UI, the UI is sort of a pure function of the model. It’s an asynchronous function which takes the model and returns a stream or future of the next action(s).
You’re describing how statecharts model things. I’ve used them to describe and implement user interfaces for at least 15 years. Works great, easy, very few bugs.
Alerts and login forms are clearly prompts. But so is an complex editor: it constantly prompts the user for the next action, e.g. enter text or change existing text’s formatting. Or a social-media site: possible actions are “login”, “view post”, “create post”, and so on.
Even an FPS can be warped into a prompt-based UI, where the model is the game state (or what the player sees of it), and the prompts are “move, turn, shoot”. But you probably shouldn’t do that. Asp bad examples: a weather or stock viewer where your options are null, and the model is the weather or stock which you can’t change.
Nonetheless prompt-based UI is really useful for many otherwise-ordinary cases. It lets you write a UI like a CLI and automate your UI very easily; it tells you which state is truly part of the “model” and which is just part of the UI; it’s composable spatially (more elements) and temporarily (series of steps). I don’t know if it’s been explored much.
In prompt-based UI, the UI is sort of a pure function of the model. It’s an asynchronous function which takes the model and returns a stream or future of the next action(s).