> This sounds really interesting.  What is your primary goal in creating  
> Maui?

The primary goal is to minimize the effort required to have an interface to a
model of domain instances.  Also, I want user-interface development to be as
"lazy" (i.e., late) and incremental as possible, rather than having to spend
chunks of time developing the UI up front (as well as with each change).  So,
as a domain evolves, I don't close existing UI's on the screen that are
currently representing "live" domain instances.  Instead, I just reconfigure
any particular domain instance the way I want, then right-click and save that
configuration, and all objects using that named configuration automatically
change, in-place, to match the new shape of the particular one I changed.

> How do you envision using it?

I am discovering that building usable UI's where you only can have one object
per "screen" is proving to be a challenge.. or, at least, requiring different
thinking than windowy interfaces I'm used to using.  Sometimes I find myself
tweaking my domain to be more suitable for the UI; something that consternates
me, at least in principle.

I'm actually still not sure I'm not gonna run into some sort of major usability
barrier at some point, I'm still exploring.

The good part is, UI's built in it can "integrate" with each other as their
underlying domains allow, without having to write a line of UI code.  For
example, it would be extremely easy to associate a heterogeneous bunch of
objects related to a topic; anEmailThread, aWebPageLink; aPdfArticle, and a
Smalltalk Class into a single OrderedCollection via drag-and-drop.

 - Chris