This is the difference between a good photograph and a great photograph.

A great photo elicits, rather than describes, an emotion. I get it.

>So... how do we achieve that in an interface...
>
I think we first have to figure out what the real rules are.
Lets coll them "conventions' rather than rules - I hate rules:)

I gave one, "the Icon has to communicate something." That actually can be extended to most of the elements of the interface.
I second!

The green screens with the dropping characters in the Matrix look cool, but I don't think could use that interface
I was not referring to the "Matrix" splash screens. I was looking more to the "dock management" interfaces in "Matrix Reloaded" (graphics showed acceleration curves and ships moving to the dock area (black wire frames on white) and data was being listed.

The "Final Fantasy" also had some great ideas. In both productions the display (and controls) were holographic projections. But that is not what caught my eye as much as the repeating of the "list" presentation theme that "Star Trek" TNG offered as early as 1987.

Since my projects are usually "just" data, I thought the "list" services looked interesting.

I wish we had transparent background on "selected" textbox objects!

I'm begging to feel a bit like I'm lecturing here, as I said earlier... I'm just thinking out loud. Hopefully someone out there is finding this prattle useful :)

I am!

And it has - I am fooling with a "home made" replacement for the OCX toolbars. At least I can use a "transparent" container - the packaged ones are cool but dated.

I also downloaded a "foxpro" (not OCX) treeview that one of our UT folks posted a link too. I am going to check that out.

Oh and I'm still trying to wrap my head around a '"stateless" data GUI paradigm'
In the old days, some projects would present a blank form with an empty field for a "key" entry, like an account id or something. There would be a search window (or page) button or form too.

These projects would also have a "New" button (for adding a record). An a edit button, for changes to an existing record.

To approach state-less-ness, remove the "New" (or "Add") button as well as the "Edit" button.

It works like this - should the user enter an account id that is not on file,then the "state-less" approach would assume it was a "New" or "Add" record request. No need to click a "New" button (unless to clear form). Should the account id exist, the stateless approach would retrieve it for edit. Should an item be selected from a search list, a stateless approach might simpley populate the form with fields from that record and the user could just select the fields and edit.

"Writes" or "Saves" can be handled several ways. They could be subject to a user preference service. Some projects update the corresponding fields with text values immediately upon lost focus. Some wait until the user exits the las field or press the "Save" button. The automated write at the field level could cause problems should the user learn they are editing the wrong data and cannot undo. Also - if the data changes are meany, the one to one write would force the "server" to do more work than necessary, in these case, a stateless approach (at "last" field exit)would save (implicitly) - [or] message to offer to save. Requiring a "Save" (as well as "Add" or "Edit") button be pressed is a "wait state" - the system is waiting for the user to "authorize" before committing to an action - where as a "stateless" solution commits to an action without the users "autorization".