In my prior article, I wrote about the general, high level requirements of the R3 GUI. And, over the last few weeks, I have spent a great deal of time reviewing the current R3 VID design and evaluating how it meets those requirements. (And reading all of your comments as well.)
In general, I have concluded that there is more work to do.
Because the GUI is critically important to R3, I will be talking a lot more about it in the weeks ahead, but before I go into great detail, I want to point out an essential design rule. This rule applies to design in general, not just software. It is:
Some of you may think that VID is designed for guru programmers or advanced application builders. But, that is not its purpose. After all, we know that expert programmers will always be able to make things work, regardless of the system. Look at JavaScript for example, or even VID in R2. Applications have been built with those, and they work quite well... even if it took special effort to do so.
In addition, experts always have precise demands that are difficult to satisfy for general cases. If necessary, they can always construct their own GUI system from the lower level graphics libraries.
But what about other users, ones who are not so expert? This is the group I am interested in, and I would include myself in this group as well!
Most of the time, I do not want to struggle with the GUI. Instead, I want to focus my energy into the application code itself and spend only minimal time on code related the the GUI. In fact, the perfect situation is where the GUI portion of the app is totally descriptive, and I don't even need to write a line of code for it.
If you think more about the concept of REBOL dialects, you will recognize my point goes to a deeper level. A dialect is a shortcut for expressing a concept. You can always code something without a dialect and most other programming languages are proof of that.
However, when you have a dialect, you have a special tool for getting work done faster, and for making the end result easier to build, maintain, and improve.
So, the fact that we call our GUI the Visual Interface Dialect, VID, is a hint that we really want more than just gurus to use it.
This knowledge helps us to precisely tune our design requirements.
Now, I know what some of you are thinking... you want a powerful GUI system, not just one that works for beginners or even non-programmers. But, I should point out, you actually have that right now! There's nothing to stop you, the expert programmer, from doing whatever type of graphics and GUI you need. You are free to make it as interwoven, complex, and complicated as you desire.
But, VID is for the rest of us, and VID is for me too. On this, I will not compromise. It is our primary objective. Our target user is defined.
I found REBOL originally after reading your article about putting the "personal" back in personal computing. I am one of "the rest of us."
Brian Tiffin 24-May-2008 0:56:50
Agree; to a pooff point. I don't normally relish GUI building, being a CLI user at heart, but I'd really like VID3 to be modern. That means a simple dialect word like TREE would have to do a lot of magic. Sadly all our mileages vary so a nice TREE to me may look like tangled bushes to many others. It would be quite handy to pass a nested block to something like TREE and have it do all the normal grunt work that such high level graphical elements usually entail (intelligent expand and collapse with reasonable iconics for the + and -, and now that Unicode is in place, + and - may not even be the iconics to use etc). I for one have faith that what does emerge will be REBOL cool (and TREE was just an on the cuff example, don't necessarily mean VID3 needs a TREE).
Next would be persistence. One of the great pains of GUI development (not VID in particular, most that I've encountered) is attaching screen elements to disk store. It always seems like such a manual chore and completely breaks the Don't Repeat Yourself paradigm. If VID3 alleviates that time and code line consuming layer, mmmm goodness.
Cheers
Henrik 24-May-2008 2:44:14
After coding GUIs for a few years now, I can only say that I really miss high level standardized constructs, like entire preferences windows or complex setups where you should only fill in a few bits of information to make it work. I seem to be making the same code all the time for certain interface arrangements.
I'm not talking about finished dialogs like file requesters, but complicated, common parts of a UI that you have to spend even just 5-10 lines of VID code to write. Some common parts require hundreds of lines of code in VID. Compress it to 2-3 words and we can make it work.
I think VID3 should provide not only an easy to use dialect, but also such standardized constructs. Some may see it as inflexible and they will have to build their own, if the construct doesn't fit them. Others (me) will see it as the standardization that we need in order to build good UIs very quickly.
Brian Tiffin 24-May-2008 14:01:35
One more point. For REBOL 2 GUI apps, I usually use RebGUI. Simple, clean and professional looking. Ashley did an amazing job of harnessing the power of View for end-users and getting to the "business" of application development.
Cheers
-pekr- 24-May-2008 16:23:46
My opinion is, that we actually have two target groups here - end users, and programmers.
As for end users, they will get what they want either way - VID being complicated underneath or not - the use upper layer dialect. If the styleset is complete, they have no need to extend it, they are just using it.
But - then we have programmers here, who might want to modify/extend styles, adding new, non tradition ones, etc. Current VID3 proto 3 is not all that trivial to understand. And here I am not with author, that I should never care about internals. It is kind of psychological thing. Back at Amiga days, I liked AMOS basic. I used it, because I liked to use it! It just felt right! This is imo why languages like php or javascript got popular - ppl liked to use it. So - even for programmers, system has to be understandable easily, in order to be customised and extended ....
