What extensions can people think of? What is #8, #9 on this progression?
A different angle would be to introduce server-single-client interop to each application (starting with counter). Then multiplayer.
Another one is to show how easy it is to take one instance and add another on the screen. Any singletons preventing this? How easy it is to then connect the two instances / drive them from another source of data.
#8 Error handling: on an exception, does the whole app crash? What parts of it become unusable? What are the reset paths?
#9 Data consistency indicators: how functional is the UI when in a fallible state like server updates? (In multiplayer games this would be stuff like client side prediction and reconciliation) What is the recovery path so that data isn't lost across many users? CRDTs and their competitors solve it for document editing but what about general purpose GUIs?
#10 User driven layout: Plugins, configurable UI elements, and a panel manager like you'd find in most IDEs.
#11 Automation/accessibility: mapping UI actions to command line calls or a scriptable layer (former for technical fields like EDA packages, latter for more GUI centric stuff like line of business app). Automation and accessibility are two distinct factors but the implementation details align almost perfectly.
Bonus #12: Remote execution for secure GUIs and ultra high processing power collaboration - think stuff like graphical CAD/FEA simulator with an entire bridge assembly. This is usually only possible with X or if you stream something like display lists/GL calls from a browser engine on the server to a client renderer.
I've seen #8-10 absolutely tear through every UI architecture I've ever seen and #11 is important because it's a nonstarter (or should be) for any serious application that goes out to the public, especially as the ADA's reach expands. The latter requires deep integration with any platform it's on so sadly would eliminate all but the big well funded GUI packages.
#12 has broad implications on how humans interface with computers but I've never seen it implemented at the GUI framework level - think WASM style bytecode for streaming UI state updates (I think ember.js's renderer works this way?).
I don't quite get #8. An exception should be handled where we expect it, depending on a reason for the exception. If something totally unexpected happened, it's better to let the whole app crash than to let it continue running in a corrupted state (unless it's a software for nuclear plants), isn't it?
> If something totally unexpected happened, it's better to let the whole app crash than to let it continue running in a corrupted state (unless it's a software for nuclear plants), isn't it?
That depends entirely on the use case. I certainly don't want my MCAD/ECAD software crashing because someone introduced a rare bug in the CSV parser that trips over some unrelated library files - I'm perfectly capable of learning how to get it to a safe state for a restart without losing any data. Anyone who uses massive software package like that for their livelihood learns to work around bugs that cause inconsistent state.
#8 is important because there needs to be a generic way to pass errors up through component hierarchies that may not look like the call stack. In many architectures, for example, the exception in an event handler has to get handled at the root of the event loop, not the parent component. That exception handler has to be smart enough to bubble that exception up through parent components.
So the actual challenge should be a bit better specced. The flight booking example, but some configurations are invalid and the validation can only be calculated after the form is submitted. How should the error be handled?
A different angle would be to introduce server-single-client interop to each application (starting with counter). Then multiplayer.
Another one is to show how easy it is to take one instance and add another on the screen. Any singletons preventing this? How easy it is to then connect the two instances / drive them from another source of data.