+972 52-548-6969
Help: Can you think about a UI representation?
time to read 1 min | 93 words
I am currently writing the chapter about creating professional DSL. One of the subjects that I am dealing with is creating graphical representations of a textual DSL.
Here is the DSL script in question:
specification @vacations: requires @scheduling_work requires @external_connections specification @salary: users_per_machine 150 specification @taxes: users_per_machine 50 specification @pension: same_machine_as @health_insurance
I am not sure what kind of UI representation this should have.
For that matter, let us take the example that I commonly use, of a rule engine for an ordering system:
when order.total > 1000 and order.payment_method = 'CreditCard': apply_discout_of 5.precent
How would you visualize that?
Comments
The point of a DSL like this is to make it as English-like (non-techie readable) as possible, right? So the correct visualization, IMHO, would be to make it fully English.
When the Order Total is greater than $1,000 and the Order Payment Method is 'Credit Card', apply a discount of Five Percent (5%).
As to your first DSL (the specification), I'm not sure. Maybe you could show boxes and lines with tool-tips when they hover the mouse?
Try to make it work when you have 5 operation and a complex condition.
The text is very expressive already, turning that into English means that you have to read it, instead of tokenize it.
I am looking for graphical approach
Take a look at these.
http://www.ilog.com/image.cfm?name=3_0_RSO_DOC_2.jpg
http://www.ilog.com/image.cfm?name=3_0_RSO_XLS_2.jpg
http://www.ilog.com/image.cfm?name=3_0_RS1.jpg
It is still textual but it might turn some light.
The first example (specification) is not clear just by looking at it, and so could use some form of graphic visualization (boxes and lines).
The last one doesn't require anything else, like you said, it's already self explanatory. I've seen many a business rules engine with a custom expression syntax much like that and some had visualizers, but everyone (even the business folks) always switched to the expression view and looked directly at the syntax (like what you've got above).
Another option might be to do something like what the Scratch UI does (http://scratch.wik.is/Support) and have a drag-and-drop syntax where the different language elements are slotted so that they only fit with appropriate pre- and post- elements.
Oren,
For discount example, pictures will express it better.
Show money & have a ballon indicating more than 1000 bucks
Show Credit card symbol
and Show 5% off symbol
e.g. 1001 + Credit Card = 5% off
Pictures can say a lot here.
For the first example, the specification looks like a bucket for other rules. Each rule type can be a different shape with text that describes it briefly. If the second part of the "requires" statements are well-known, then you can create a separate icon for each and put them in the bucket for the specifications that use them.
For your second example, I'm thinking of a directed graph where the combination of conditions lead to an action (or set of actions). The conditions are connected to each other and to the action eventually by lines. Lines that share a vertex are considered "AND" operations, multiple lines leading to an action or other condition are considered an "OR" operation (with an optional indicator for "NOT" at the connection. This way, the user can trace the lines of logic to get to a particular action and all the separate lines leading to the action are the possible logical combinations for that action to take place. In a more interactive UI, the user would be able to isolate actions or trace conditions easily.
Seem's you can use two approaches - one is algorythmic, and another is functional. First appoach intended to be concentrated on small atomic steps you need to take to have result. And you have deal with single OR and ANDs and XORs, that are combined by graph net from begin to end. If you use Simulink from Matlab (R) you can consider what I mean. Suddenly, it becomes too complex very fast.
The functional approach typically has only 2 clouds symbols - start and finish. A lot of arrowed lines links that clouds and contains conditions (or references to conditions that represented somewhere else to save space) that allows each exact actions to execute if true.
And there is the the hybrid one - workflow representation. You have start cloud, finish cloud and intermediate "cloudies" with functional-style transitions/conditional gates beetween them. And another thing you need - is a expression constructor, allowing to bind workflow transitions/gates with conditions.
Something like that ;)
Visualizing the textual DSL isn't the right approach: you'll end up with visual blocks which represent textual keywords and if something is useless, it's that. It's useless, because it's so incredibly verbose and still reads exactly the same as the textual one (so it doesn't have any expressional power nor gives it extra insights in what's going on).
What you should look into is visualizing the MEANING of what's written in the textual DSL. If that's not really possible without falling into the trap of visualizing text keywords with blocks, visualizing the DSL isn't really a good idea.
If the statements written in the textual DSL get really complicated after a couple of keywords, the DSL is perhaps not properly designed.
It might sound silly, but if the user who needs to read them is comfortable with Excel, you might want to look into looking into a representation of the statements in excel-like spreadsheet logic with cells and workbooks.
I say use a grid with two column with one use for comment that can be hidden as needed
So whenever I look at the rule I'll understand exactly what it does. Of course syntax highlighting would help.
I don't know about graphic representation. It's actually would be nice but it took way too much effort to get it to behave correctly and I don't think it's that necessary. As long as one month or a year after I wrote a set of rules I can come back and understand what it does then it meet the requirement for me.
First ones as RDF graph maybe. Last one is hard to visualise but hey, you can use AST :)
Just to throw something in the mix (not saying it's good or bad), see this image...
http://www.tobinharris.com/AyendeRules.png
Slightly OT and IMHO
A visual DSL that reflects against code such as the class designer is a good thing. When the DSL is XML and generates code this is a BAD thing.
Class Designer is a GOOD DSL.
Tobin,
That is PRETTY!
How did you do that? Is there a component for this?
@Ayende,
Thanks!
It's created with a mind-mapping tool MindNode (http://www.mindnode.com). It will run in OSX on your MBP. No API as far as I know :(
I raved about it on my blog a few weeks ago - PRETTY was the exact word I used too :)
http://www.tobinharris.com/2008/8/9/pretty-simple-software
How about something similar to the Outlook Rules Wizard.
I had a requirement where I work to throw a DSL over a wall (I know, I know - not my decision, and I fight as hard as I can against it). To make that happen I had to have something dirt-simple that the users could understand. They already understand how to make Outlook rules, so I went with that format.
I spiked a graphical representation of our basic rules by mimicking the Outlook Rules Wizard (our rules are written in C#; nothing as fancy as Boo). The hyperlinks become the configurable variables (1000, Credit Card, 5%) and I used attributes and a bit of reflection to tie those properties to a dialog of a particular type. So when the user creates a new "Apply Discount" rule and clicks the hyperlink for the "Discount", an attribute links that to the Discount dialog which pops and allows the user to enter a decimal value.
There wasn't a lot of code to this sort of system, but it does make us hard-code rule "types" (which has as much to do with our rules being written in C# as anything, I imagine). So the flexibility of creating a whole new rule type isn't there, like it would be with a true DSL in a language like Boo (so the "Apply Discount" rule is pretty rigid, as you can imagine).
But in my opinion, once you start talking about a graphical DSL you've crossed the Rubicon anyway. Your trying to represent the DSL for an audience that is not a developer. At that point, the elegance and simplicity of the DSL is going to be lost.
To my way of thinking, the whole point of a DSL in a language like Boo is so that developers like us can write (and TEST) rules in a way that is convenient and simple for "us".
I'm using codepress in a web application to highlight a custom language.
You can define customization through js files. It's pretty simple
Comment preview