Comments on: 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

Comments:

-pekr- 24-May-2008 16:40:39	Didn't we already set on 'options word usage? There was even some blog article about "larger options" concept in R3. When I first looked into VID3,I really missed the ability to go "underneath" e.g to set 'font-color. But Gabriele is right - if we want to allow advanced things as auto resizing, etc., we must probably prevent users from some actions. I can agree to make VID3 more both users and programmers understandable, but I would like to know - what do we loos from so far proposed system flexibility and cool features? What will we left out, if we take RISC aproach? As for me, I can't accept any VID2 like limitations anymore, even if VID3 would be used by millions. Because - what we also want is VID3 to be used for more than few occassional dialog boxes - we want it to support PITL, right? Well, but you know me, I always worry about how things will turn out in the end. So, keeping fingers, holding my breath!
Paul LYS 24-May-2008 17:09:21	I am french people so I apologize for my english. I think it is importante to keep rebol expressive and natural. but what's natural for me, it's not necesserally natural for you. So to be natural and expressive for different people rebol has to be "style of programmation tolerant". I mean if two different syntaxes don't compromise the coherence of rebol, why don't keep these two syntaxes? Rebol would be more understanding. More precisely: why don't use the expression with [    ] in "user-name: field "default name" with [ area-color: black text-color: white ]" to define a new style in the style sheet? In that case the interpreter would add automatically the defined field as a new style in the style sheet.And the programmer could disabled it if he don't wont a new style. And as I say before this mecanism and syntax can coexist with the vid R2.
Chris 24-May-2008 17:13:07	I like this, though I think presentation can be completely devolved from the face object: face: make face [ style: make style [ color: black font: make font [color: white] effect: [rotate 90] draw: [pen blue box 10x10 20x20] image: load %tree.jpg ] ] You can otherwise keep the face object compact, and still have wide scope to make small or wholesale changes intuitively; build on shared visual descriptions. Higher level language such as VID can be used to manage the way an object changes based on state, class or name property -- whatever. Or utilise a visual grammar -- Rebolized CSS? I can see the drawbacks though -- occasionally styles depend on differences in visual components, such as thumbnails or icons, where reuse perhaps becomes a liability.
pekr- 25-May-2008 4:33:37	If we are talking about aletrnative word to 'with (as we really need some word, because block datatype is usefull other way, not to override/set some options), the candidates could be: - 'with (we are used to it from R2) - 'options (R3 was supposed to have "larger options" concept, and we have already thing as 'mold/options) - 'using (as we have 'use in REBOL) - 'having (borrowed from SQL)
Karol 26-May-2008 3:14:53	I just want to ask if graphical editor for VID is also planned? Are there any guidelines for creating graphical editor for VID? I mean is VID designed with keeping this in mind?
Paul LYS 26-May-2008 8:54:54	Exactly Chris the presentation can be fully defined in the graphic objects and even more you can provide a stage of the interpretation of the layout that index objects declared in the style sheet. The trigger would be 'with. With can also initialize the object graph. To generalize I think rebol must move RAD. Functions a group around the idea "codeconscious" ;) has a famous reboleur because its essential function, other than those of normal RAD, would be a summary dashboard data created and manipulated by the program. It would among other contain styles reported. layout [ user-name: field "default name" with [ area-color: black text-color: white ]] will do: username: make face [ style: make style [ color: black font: make font [color: white] effect: [rotate 90] draw: [pen blue box 10x10 20x20] image: load %tree.jpg ] ] and "codeconscious" would show : username is graphic object username-style is style from username
DideC 26-May-2008 9:13:56	Carl, I like your approch. My main reason is that VID2 was powerfull but in the end difficult to read : you wonder all the time if a word refer to an option of the style, a block of values in the apps, an alternate name for a color or a size, and so on... In fact any word can be anything in that neverending list. If VID3 allow a better separation between the layout specification (what it contains, and how it's placed), the style specification (how it looks like) and the data/apps interraction (how it react to a user/data input/change) then it will be more readable for all of us. As a note, having a well define (and even better : not too common) word to put before the block that contain the changes of the style would allow a simple code colorisation to make it easy to read. 'with can be it as, AFAIK it is not used anywhere else in the Rebol dialects. I dream of an editor that display VID code in different colors regarding the content of a block (style, code, layout...)
Karim 27-May-2008 5:13:49	Carl,I like this approach too. But I want to emphasis on the simplicity of extension of the VID widgets (or faces, or gadgets). Creating a GUI is not just adding widgets and changing style but manage the interaction between widgets, user and datas. Many complex widgets can be seen as a group of simpler widgets interacting with each others. Example : A drop down list can be the association of a text field (read-only), a button (with a triangle) and a list which is displayed when the button is clicked and until an element is selected. mySelector: dropdown with [ data: [1 "Hello" 2 "Hola" 3 "Bonjour" 4 "Dag"] textcolor: blue ] I can imagine that widget is provided by standard VID3, as a tree widget. OK, Now I want to create a new widget from these ones. I need a "drop down tree" and I need to define a new component, inherited from the standard drop down but where I change the child widget "list" by a "tree". I want to say to Rebol, use this widget for rendering instead of this one. My questions are "What is the most appropriate syntax to do that ?" "What write in VID3 dialect ?" "What write in rebol code ?" If I want to reuse or distribute this new widget, I want that another developer can use a very simple syntax, as other standard widgets : myTreeSelector: dropdowntree with [ data: [1 "USA" [2 "California" [3 "San Francisco" 4 "Los Angeles" ] 5 "Nevada"] 4 "Belgium" [ 6 "Vlanderen" 7 "Wallonie" 8 "Bruxelles"] ] textcolor: blue ] "What syntax to define that ?" I think the real challenge is there. Finding a syntax simple enough but still powerful to extends the VID3. Then the Rebol3 Dev Dream Team can focus mainly on some standard widget and some complex but useful widgets (a tree). Other developers can the create tons of cool widgets ;-) PS: And yes, this is really a dream team !
Robert 27-May-2008 8:42:07	Why not get some ideas from RebGUI and put them into VID3 as well? IMO RebGUI is very simple to understand, gives you 90% out-of-the-box and lets you write apps fast. Mixing this with the new options R3 gives us and we have a powerful GUI lib.
RobertS 27-May-2008 9:52:55	Carl's proposal has worked well in the language in which I am currently most active on a large industrial scale as the lead: Curl ( our project has much code, many GUI's ) ( we use explicit macros where Rebol has 'dialects' )
Karim 27-May-2008 9:58:42	I agree with Robert. For easy migration to Rebol3, why not take good ideas from others. RebGUI is a good inspiration source. As Carl wrote, CSS syntax is well known by developers. There are also many good ideas in Adobe Flex (Namespaces in MXML). That's also why I like to keep the 'with keyword, because all rebol programmers already know the meaning in this context.
pekr- 27-May-2008 15:56:16	Karim, Robert - because our target is not boring business apps, but kind of Flash/Flex, Silverlight - simply put - whatever kind of UI apps. New VID has to be more flexible. Ashley could as well port RebGUI to View directly, but he choosed to wait to not kill VID effort, but maybe I just remember it incorrectly ....
Karim 28-May-2008 7:35:14	Pekr, I understand. I was just talking about syntax and dialect keywords not about functionalities. I simply propose to always choose the most common words/syntax already use inside Rebol universe but also outside. 'field or 'textinput or 'textfield ? 'btn or 'button ? 'combobox or 'dropdownlist or 'select ? It is easier for a programmer to migration to Rebol language if keywords and syntax are meaningful to him. But Rebol programmers don't want to learn a completely different VID dialect. We have to choose the right way between these two.
Brian Hawley 28-May-2008 15:16:26	I would prefer clarity - we can use tricks to change the clear specs into the fast runtime data structures. I need clarity when making my boring business apps.
Norm 28-May-2008 21:15:57	The risk approach of Carl is fitting nicely with Karim suggestion to enable to backtrack the problem by specifying the most common usage, which is quite answered by RebGui (apart from editor area). Comes to mind to define the interface to simple common cases, and provide an interface to describe a corresponding underneath framework. At least this will drastically reduce the size of the aimed object tree. And those wanting to explore other ways will simply have to adhere to the parcimonious top interface of most common cases and still be able to do more. Under the hood, those wanting difference or to devise other paradigms may go their ways to draw Widgets, and more. RT is simply narrowing down to keep it simple. There is a niche for the myriads of ad hoc tasks; the huge framework is already an encumbered market.
RobertS 31-May-2008 17:27:31	Could we list a few VID alternatives which are not widely known and in a small grid check-off strengths and weaknesses? I would propose Tk, Unicon, Curl (the latter 2 being expression-based)
Shadwolf 18-Jun-2008 23:34:49	Let me think a bit .... To resume in one hand we have rebol VID2 wich all widgets where based on the same multi purpose drawable on screen item we call that a face. the side effect of this is many unwanted fields for the objet face in the new end hand widget a button for example... Wich leads to don't really know on a line wich parameter match with wich field.. On the other hand we have all the others wigets librabry wich are heavy structured. button1 = new *Button; Create_new_Button( button1); Set_Button_Text( button1, "The text"); set_Button_Size(50,20); set_Button_position(100,100); set_Button_Callback( button1, button1_callback); That's long that's borring to write but that's clear to read, but compared with the VID2 way to do that's so archaic. I simply like the fact to be able to define a widget and it's parameters most of the times in one line. But i understand too some times its hard to find out who is what ... That don't mean in my opinion the finality is wrong maybe this issue can be solved with some tricks like: 1)better shaped widget a widget should contain only the needed fileds for it use (that's mainly what rebGUI did in fact) 2) dedicated data styles for example: button t1"text1" t2"alt-text" sz50x30 pos100x100 act[ click_function ] that will be easier to understand than button "text" "another text" 50x20 100x100 [click_function] and less borring to write than the "I fill all objet fields method" like that: button with [ text: "text" alt-text: "Another text" font: [ ] postion: 50x20 offset: 100x100 action: [clic_function] ] Vid2 already offers this way to design interface but franckly why i have to write 10 lines when 1 line allows me to do the same. and in my opinion having a short GUI code allows programmers to focus on the main problem what does this GUI allows the user to do or to see. the other thing to notice with VID2 is the ability to predefine some recurent parameters to a preset style to save code. maybe and that will be my last though on the topic. In GTK or QT widget you can organize your positionning of widgets using a positionning virtual grid.... this concept allow the programmer to don't care at all the sizing and postion with precise values. you do a layout in it you call for grid_layout 5 5 wich means 5 row and 5 columns you want a button OK on the lower right part of the layout you write button "OK" 5 5 the 5 5 there means you put the button on the 5th row 5th column. So the bottom irght lower part of the window. And on fully resizing window that can have a big interrest. But the problem of that system is that is you start with a small sized window and resize it wide all your widgets in it will grow GIANT on the same way. so mayby a rafinement would be to fixe to some widget the impossibility to get it's géometry change... In some way that's what VID2 can do too with "below" and "at" and "accros" abstract the programers from borring parameters writting and In my opinion that's the way VID have to go. Ther easier the wiget implementation is the easier it will be to write a rebol GUI designer tool in rebol. But we have been able to do projects like rebGUI because we had accès to the VID object face wich was the base object wich all the other widgets inherited ... So this point is a crucial point.
shadwolf 18-Jun-2008 23:57:55	But I like VID that's such a smalltalk way to think the relation betwin widgets. One big object able of anything transmiting its super powers to any of his child object. Any widgets is able to do anything you can draw on top of them put an image and draw on top of that to animation draw loops on any widgets set text etc... what you can do to one widget. That's freedom and that's normal.... REBOLution leads people to freedom... the first 100 years that's scary but after you are used to it ^__^
Bertrand 5-Jul-2008 4:54:20	I agree with Paul LYS (24-May-2008 17:09:21): "I mean if two different syntaxes don't compromise the coherence of rebol, why don't keep these two syntaxes? Rebol would be more understanding." This sample would be as a shortcut (for developing, for interactive mode, for beginners, etc.) : view layout [ text "TEST" black 20x70 ] and this one, clearer, would be for (larger) scripts : view layout [ text with [ text: "TEST" color: black size: 20x70 ] ] Sorry, for my english ... :-)

Post a Comment:

You can post a comment here. Keep it on-topic.