VID: Expression Optimization vs Clarity

Here is a design principle I use often: RISC.

RISC stands for reduced instruction set computing. It was a revolution in CPU theory back in the 1980's. In a nutshell, it means to optimize for the most common cases.

Many years ago, when I designed my house, I used RISC concepts. For example, the kitchen is optimized to work best for the most common case: cooking meals on a daily basis. For large family gatherings, it does not work as well. But, such events are rare, so it does not matter much.

In the design of VID, we must do the same. It should be optimized for the common cases.

When VID was created for R2, it was a revolutionary new approach to GUI construction, and we did not yet know what was common and what was not. Now, for R3, I think we know more, and we should use that knowledge.

In R2, VID faces were described mainly with a style name, followed by a sequence of datatypes. For example, you could write:

button "Here" "There" red green 100x32 [browse home]

So, we placed a high value on expressing modifications in a minimal way. This made VID powerful for expression a great number of variations of styles easily, but we should ask, is that the most common usage?

Well, it's great for demos, but beyond that, most applications do not use that many variations of style, and when they do, they normally define them in a style-sheet for easier management, not within the description of a panel.

This is the CSS concept, where variations are provided via property names. I like this approach because it makes the GUI more readable to those who are not experts. You can see more than the value, you get to know what the value relates to.

For example it is clear to write variations of properties in this way:

width: 20%
area-color: blue
text-color: white
edge-color: silver

So, indeed, that looks a lot like CSS (or should I say that CSS looks a lot like REBOL, interestingly enough), although not totally identical, it is close enough that HTML-aware users will not fear it.

In other words, we do not need to allow ten or more variations of face (style) properties via direct, unnamed datatypes. Instead, let's allow just a few of the main ones, and put the test into a property sheet format with named fields.

I mention this because as we move to the finalization of VID for the standard built-in GUI method, we want to evaluate the usage patterns and apply RISC concepts to make them optimal for users.

We can now re-examine and optimize the top level grammar of VID. I think we can say that, in order of importance, we have:

1. style (the name, e.g. BUTTON, PANEL)
2. contents (e.g. button text, panel block)
3. name (the set-word label for it)
4. action (what to do on events)
5. variations (of the style)

Let's take an example:

user-name: field "default name"

Now, if for some reason you need that field to look different, such as use white text on black box area, you would first want to ask yourself if that should be defined as a new style in the style sheet. But, if not, you could write:

user-name: field "default name" with [
    area-color: black
    text-color: white
]

This specification is simple and clear. Yes, it is a bit more wordy than VID in R2, but I think it is a better approach.

Some of you may be asking, is the word WITH really necessary? To that I would reply in RISCish way: "what is more common?" Is style variation the most common... probably not.

Something like this is will be much more common:

panel [
    button "Yes"
    button "No"
]

It's quite common, so it seems to me it makes a better choice for the use of a block.

Finally, I want to mention that this subject can go on and on, and everyone will have their opinions. But, let's set opinions aside, because we must think in terms of usage, not in terms of REBOL dialecting capability, which we know is quite unbounded.

19 Comments