This interesting article that Sam Habiel e-mailed me last weekend touches on several of the things that once upon a time made VISTA not only great but spectacular:
a) that users could easily learn to do their own programming (e.g., in creating Fileman templates, which were easy to wrap into options for production use);
b) that their programming language was easy to extend in task-specific directions (using Fileman's Function file); and especially
c) that there were clear visual metaphors for the data (esp. via Fileman's modular UI, which was once the basis for all VISTA applications' UIs).
The shift to GUIs and now web have confused things for VISTA, particularly in that we have rushed to create single-purpose applications like the CPRS Chart client, effectively creating one-off UI designs instead of a universal visual vocabulary, stranding our universal visual metaphors in the terminal-based world. What should Fileman data look like on the web, and how should all VISTA applications be built out of those metaphors, whatever they should be? This author is right that putting user-driven programming - the point of allowing and encouraging task-oriented programming by users - at the center of how we design our visual metaphors is essential to getting that design right.
Some of the great leaps forward for VISTA over the decades have been the result of putting our focus back into these cross-hairs, where we focus on exposing the data in clear, intuitive ways so that end users (or at least super-users) can develop their own software to some extent. The original Timson-Munnecke design of Fileman; Greg Shorr's work on Q-Man; Dave Bolduc's work on VPE; the Salt Lake City ISC team's amazing CPRS server-side architecture; Tom Munnecke's work at SAIC on integrating Excel, Word, and other office automation into the realm of data that MUMPS/VISTA can access, manipulate, and generate; Dr. Doug Martin's modular, extensible, and user-configurable plug-in architecture for Viewcentric; Conor Dowling's recent work on exposing Fileman data in a web-browsable form; and so on, have each been so revolutionary in part because they aim at that sweet spot described in this article.
When we let ourselves drift too far into the abstractions of a purely textual, linguistic, mathematical conception of our data, we lose our way, in part because our users cannot follow us there, but also because even we are not as proficient in that mode of thinking as we may like to believe. The extra processing boost - the free lunch - of the human brain is our visual cortex. Anything that we can express visually is something we can think about as though we were twice as smart as we are. Capturing the right visual metaphors - as Steve Jobs knew - is central to good design, even when we're designing supposedly "back end" things like databases. Part of what this author is reminding us is that there should be no "back end" in the absolute sense in which we use the phrase, that any division of the computing world into things that are never seen (and therefore need no visual metaphor) and things that are may do more harm than good.
In the modern world, this is a kind of heresy. We're supposed to treat "legacy" systems as silent partners in a layered system. As everywhere in life, our biggest troubles in life come from the unexamined assumptions we make on the way to the things we are examining - in this case, the assumption that we can just decide to make the heart of the system an invisible back end, the assumption that nothing bad could possibly come from this. Implicit in this article is the disproof of that assumption, because keeping a strong and consistent visual metaphor for the data (which is the "back end") is a prerequisite both for having a common look and feel throughout the whole system and also for making it possible for users to do simple, task-oriented programming wherever in the system they may find themselves.
So today VISTA is great but not visually spectacular. We can change that, if we understand our core goals clearly enough. For all the invisible architectural changes we want to make in the years ahead - and I agree with Tom that there are plenty of them - the priority for this renaissance (other than training up the new generation of experts) must lie in putting users back in the driver's seat, by giving them something they can visually understand well enough to drive in the pursuit of the practical tasks that make up their work. In the process, we can create a new generation of consistent and intuitive visual metaphors and building blocks, from which all iEHR applications would ideally be built.