Well, the last post may have been opaque - and was in some sense vacuously true.
What Obsidian is, and what I think the GUI should evolve to be, is…a meta GUI.
Meta-GUI: Where the user sits down and can choose some data and choose operations to perform on that data, AND choose how they want to see and work with the set of available data and see and work with that particular data of interest and see and work with the set of operations and see and work with the operation itself in action and see and work with the results.
All this so easy that a CEO can do it. Actually, Obsidian is more targeted towards ordinary people - but deep down, way deep, CEOs - who typically are targetted because of their software-purchasing budget powers - are ordinary people too [OK, sorry for the post market bubble bursting CEO humor].
Anyway, as you can see, this meta GUI is a very general flexible description of how humans interact with computers. It is just that, currently, most of these things in most applications are FROZEN by the programmer - so that the user has NO flexibility - they are in a multi-dimensional straight-jacket (and don’t talk to me about ’skins’ - The ability to change the application’s colors…? whoo hoo!]
This degree of flexibility takes the GUI beyond the physical metaphors we have been tied to since Xerox PARC - or rather builds upon them to make the user some kind of super-being in the virtual reality of the computer.
The challenges the Obsidian Framework has are - well there is really only one:
How to make using the GUI with so much flexibility as easy to use as, say, using a TV? or driving a car?
Well, there I go asking a question and answering it in the same sentence… :-)
The solution Obsidan itself takes, and it is the easy-way-out so to speak, but if you think about it there is no other answer for a generic framework supporting this kind of GUI, is
To make the Meta-GUI itself a plug in.
The key here is to realize that the Meta-GUI is somewhat recursive. No, that’s not right. It is like those Russian dolls where inside one doll is another, and inside that is another, etc. Except that any of the dolls can contain any of the other dolls - and/or itself. [and, unfortunatately, this is not the typical ‘container isa part’ relationship, though visually that is often what it looks like].
I.E. a Meta GUI defines interactions between other plug-in GUIs, that may and often do define iteractions with (for example a list, or a search field) other GUIs and on and on. And of course there is a GUI to displays the choices of possibleMeta GUIs, and a GUI to choose the GUI that lists Meta GUIs. All plugins of course.
It is the flexibility of this ‘Universe of Choices’, where the atoms are more or less well-defined but what you can build with them is not - and how do you ‘boot’ such a universe? - that makes writing Obsidian somewhat of a challange.
Oh, yeah, and there is how to make all these plugins - functional plugins, GUI plugins, and data source plugins, plugin-customizer plugins, plugin-network-builder plugins all work together.
The last post talked about how it is these types of frameworks, no matter how crippled thye have been in the past - that have spawned large numbers of very specialized, one-of-a-kind ’software screw’ factories’ (ex: Photoshop). The point being that the specification of how to make a plug-in just has to be understandable and to actually work - it does not have to be created by some consortium populated by big companies with their fiduciary desire and need to over complexify everything.
So that is one key to how Obsidian is being designed… Keep it small, simple and stupid. Otherwise my poor brain is just too lazy these days to Grok it. There is enough inherent challenges for the brain with respect to Meta GUIs - no reason to add more.
But sometimes small, simple and stupid creates its own complexitites - especially with regards to debugging.
For example, there is only one kind of Data in the whole framework - in order that every plugin, and every type of plugin, knows what to expect - and it can be interesting to debug a piece of data as it winds itself through the system.
[Which creates a need for a god-like set of choosable nested GUIs that looks at the Meta GUI from the programmers perspective…]
Next… more on the architectural choices taken to make this all work and make it implementable in finite time… oh, and maintainable by someone with not a lot of free time.