VID3 is a very different beast from the good/bad old VID that we know and love/hate from REBOL/View 1.3 (hereafter named R2). The design of VID3 has been the subject of rather intense debate among R3 developers and this blog post is an attempt at avoiding such a debate again, because VID3 ain't your daddy's old VID! There are a number of reasons why VID3 isn't just a "completed VID", but changes its philosophy quite a bit.

What's good and bad about R2 VID

It's a layout engine that is optimized for placing graphics on screen in a way that you don't normally do, when creating a typical computer application: You can put elements anywhere and directly style them on the spot inside the layout dialect. This is great for custom kiosk graphics, media center graphics and some impressive looking technical drawings and also very importantly, it's quick to make a user interface in a few minutes, as long as you stay within its capability limits.
By this level of customization per face inside the layout dialect, you can create all sorts of colorful and exciting user interfaces that look impressive and rich with many fonts and all sorts of button shapes.

VID as it appears in REBOL/View 1.2 (image grabbed from rebol.com)

It is, however, no good for advanced and complex computer applications. Such flexibility places a large responsibility into the hands of the application developer: How should a single face appear? Do I want this button to be green, yellow or just the default color? The edge size? Font shadow? 24 or 30 pixel tall button? Etc. There is a big amount of design decisions happening here.
This gives an illusion of control, of power to change the appearance of any part of your application, but in reality you lose a lot of control over uniformity and styling, if your application contains many windows or if you're building many applications. Uniformity becomes a laborious task that should not be placed in the hands of the application developer. The STYLIZE function is VID's only weapon to promote uniformity, but the design of VID works essentially against that, because a style is so easy to override.

I like to compare VID with MS Word in this respect:

There are probably millions of MS Word documents out there that are created incorrectly, because the user has not used the style system in MS Word to modify the appearance of the document. The user has instead used the font panel, colors and adjustment directly on the selected section they want to change.

From a user's point of view it's simple and easy to do this to make the document look "nice" (which means green Comic Sans and Word Art, sigh...). From the system's point of view, you are polluting the document with crap and preventing the Table of Contents system and element browser from functioning correctly. MS Word can't tell that a sentence with 24pt bold tags wrapped around it, is in fact a headline that should be used in the table of contents.

MS Word causes it's own problems by allowing the user to change the style of a piece of text on the spot.

This is very analogous to the problems that VID has. You can talk about VID's freedom in two ways: Either it's a blessing for the UI experimenter and hacker who wants to see interesting, colorful and unique results or it's a big responsibility hog for the person who just wants to create an application that behaves in a standardized way in a short amount of time.

VID3 is inspired by these responsibility principles and it will cater to application writers who want as little UI responsibility as possible. This also maximizes control for standardization for the style designers. It will at the same time solve shortcomings and unfinished features in the original VID, such as easy resizing and a event handling system that scales much better.

Displays

Another huge reason is that more different display systems will be available to REBOL3 than there ever was for REBOL2. Both in the extreme high resolution variant and low color, low resolution PDA displays. You may even not have a graphical display!

How is the application designer going to adapt to each display type easily? It's better to let VID3 handle that for you and it's the job of the style designer to allow a certain display type to be supported.

Dialect

What should be possible to do in the VID3 dialect? What shouldn't be possible? Well, the goal is to split the application development and style design into two separated tasks. Custom styling inside the dialect is therefore largely removed. That includes face sizes. If you want a custom face in your layout, you have to create new styles. Oh, man!

This cleans up the dialect: You have less face definition code inside the dialect block and it becomes smaller and clearer.

No more face hacking:

view layout [

  button "Test" with [ ...lots of face hacking code...]

  button "Quit" with [... more face hacking code...]

] 

But now:

view [

  button "Test"

  quit-button

] 

What you lose in immediate on-the-spot redesign flexibility, you gain in integrity, readability and consistency. That tends to be able to scale up and gives you much greater comfort in creating programs that have a lot of windows and interfaces.

But faces are not Lego Duplo blocks. You can still, as a style designer, give a face a ton of options, as many as you like, even appearance settings, if you want to allow that.

Face Options

The new OPTIONS system replaces WITH in the original VID, but it does not allow full access to the face. For example:

view [button "Hello" options [rounding: 10]]

If the style supports it, the appearance will change so the corner radius will be 10 pixels. Otherwise the option is just ignored. The rounding feature for the button is still in flux, and it may be removed.

So why this limitation on what you can access in a face? First of all, plain encapsulation. As a style designer, you may wish to limit the options you want the user to be able to change in the layout. Therefore the OPTIONS code provides an encapsulated approach to accessing extra features in the face, rather than like in the original VID, where extra options are slapped on top of a face.
If you have 20 options, it's hard to see in VID what's new and what's part of the original face if you probe the content of the face. In VID3, you simply have an OPTIONS block and use that.
Second, controlling the options makes it easier to document the specific options for a face. A face gets a simple and ordered API, rather than being just an object to poke at, hack and throw stuff at.
Third: Security. It helps to control the input from VID3 better.

SET-FACE and GET-FACE

More is done to make up for that face hacking is no longer possible: SET-FACE and GET-FACE will now function properly on all faces thanks to a much cleaner way of handling these function in style code. You should only use SET-FACE and GET-FACE to change and get data from faces and groups of faces in your user interface. No more FACE/TEXT: "Hello", etc.

ARGH! Too Little Flexibility!

Still it appears too simple only have styles to choose between. It will be, if we only provide 7 styles: Button, Toggle, Label, List, Field, Popup and Group and stop there. Most potential new REBOLers would walk away, if we did that!
VID3 needs many styles; Refine the button to ok-button, cancel-button, yes-button, no-button, quit-button, close-button, creating a range of buttons that exists in a common pattern, each with their own little useful variation. The same for field: Generic field, number-field, search-field, password-field and so on.
The style designer can provide the appearance of the ok-button and that style alone will have to be used by the application developer. This means that the user always knows what an OK button looks like, which provides UI consistency. But so does the system! And this is what lifts us beyond R2 VID, because the aforementioned pattern recognition in the user interface becomes possible.

An early face alignment test in VID3.

Hypothesizing on VID3's Future

OK, I'm gonna go Fleecy Moss now, so you are warned:

If VID3 is done this way, you can provide programmability on the patterns of a user interface in this (still hypothetical) scenario: Where's the OK button in a window? With a completely standardized style system, REBOL can tell that and use it as the default highlight, when you press Enter to close the dialog. As an application developer, you don't need to provide the code for an OK button, but simply use an OK-Button style. REBOL will recognize it.
Even more complex: "Where's the user input part of this window?", or perhaps "What does this window do?"
This lets your system read dialog boxes and UI elements as syntax patterns, for example for use in a disability system that reads out important parts of dialog box content for blind people. This gives meaning to the content in a window or dialog.

While this hasn't been completely decided, VID3 is headed in this direction. If we dare to move further, UI creation can be truly simplified and let you create user interfaces based on concepts and not concrete element placement. It would be made into concepts like form windows, preferences windows, help windows, search windows, or complex interface elements, like a label/field set, or a searchable table of data. You don't need to design these things yourself. They are designed beforehand by style designers and can be attached or adapted to your task. They are off-the-shelf components.

More to Come

I hope this helps a bit in understanding what VID3 will be. I hope also to return in a future blog post to talk about more features of VID3 when more of VID3 has been completed and show more concrete code examples.