Visual Ruby and Rails - Our Philosophy
Recently I’ve been writing a good deal about the nitty-gritty details of the Visual Rails Workbench. I have been so involved in this project for such a long time that I guess I may be guilty of taking it for granted that people will understand what we are doing and why we are doing it. That’s probably an unreasonable assumption. So, for once, I’d like to step back from the details of the Workbench, and explain in more general terms the philosophy behind it - in other words: what does it do and why did we decide to do it that way...?
What, No Templates?
Currently most solutions to the page design problem in Rails take the form of some kind of ‘templating’ system. Templates come in many forms - they generally involve a blend of HTML/XML and Ruby code or other formatting instructions and have to be pre-processed in order to generate the HTML of the page that eventually appears the browser.
Templating systems are fine and dandy but they do not provide you with ‘What You See Is What You Get’. They are code-centric which may make them more appealing to a programmer than to a visual design specialist. By contrast, the Visual Rails Workbench makes the page layout which you see at runtime (in the browser) available at design time - or at any rate, as much as is possible without actually running Rails. So you can make adjustments to the size, position, styles and images on a page using keyboard and mouse - and see those changes instantly!
Instead of writing commands in code to specify that a button should go at point X and a text DateTime Selector should go at Y, the Visual Rails Workbench lets you drop those components onto a page, resize them and set properties to change their text or colour. This lets you make pixel-perfect changes quite literally in seconds.
Professional web page design specialists are quite likely to have a background in art rather than programming and they may prefer applications such as Dreamweaver rather than Visual Studio. That’s no problem. Once the programmers have created a basic layout (likely to be fairly blank pages containing the required the data-bound components), the Visual Rails Workbench can export the generated HTML. This can then be edited in some other web design application such as Dreamweaver. Here the layout can be fine-tuned, styles can be added, seamless images and backgrounds can be inserted and positioned using CSS or table layouts.
Finally the whole lot can be saved to disk (still in the form of ordinary HTML) and imported back into the Visual Rails Workbench to be translated back into embedded Ruby (ERb/RHTML) format and broken apart into the various files required by the standard Rails templating system.
Don’t Lock Me In!
When we first started planning the Visual Rails Workbench, we had long discussions about whether or not we should do ‘our own thing’. In other words, should we create special widgets that only Ruby In Steel could understand and use? Some PHP tools take this approach. They define their own class libraries which give them some useful capabilities at the expense of locking the end user into a specific set of tools and technologies.
We made the decision to keep the Visual Rails Workbench tool-and-technology-neutral. In other words, it does not ‘lock you into’ Ruby In Steel and it does not impose any additional deployment requirements on your applications. No matter how much drag and drop designing or importing and exporting you do along the way, what you end up with is a standard Rails 1 or 2 application with standard Ruby files and ERb templates. When you put the site online nobody would even be able tell that you’d used the Visual Rails Workbench - well, apart from the fact that the page design will probably look a great deal slicker than if you hadn’t. :-)
We are well aware of the fact that many Ruby programmers do not use visual design tools and do not like visual design tools. That’s fine. The Visual Rails Workbench is not obligatory. If you don’t want to use its page designer you certainly don’t have to. Indeed, if you really don’t like its environment (the Workbench hosts various editing and navigation tools inside an integrated workspace) then you can turn it off completely and use the same code-centric Rails editor provided in version 1.1 of Ruby In Steel.
Truly ‘Visual’ Ruby
Personally, I must admit, however, that I am very much prejudiced in favour of visual design tools. When I first began programming, in the early ‘80s, such things didn’t exist (well, unless you count Smalltalk which I only discovered later). With the advent of Windows, a variety of visual development tools began to appear. Over the years I’ve used a good many of them - both programming languages and IDEs such VB, Delphi, Visual Cafe and C#, and web designers such as Dreamweaver and Expression Web. When I began programming Ruby, the lack of visual tools was one of the things that struck me most.
The Visual Rails Workbench is just one of the technologies which we are developing in order to provide users with the sort of visual tools they take for granted in other languages. Last year we released a free component, The Ruby Connector, which lets you link .NET programs with the standard Ruby interpreter and create visual front ends to your Ruby programs using C# or VB.
What I would really like, though, is a version of Ruby that provides true visual drag-and-drop event-driven development in 100% Ruby. At the present moment that isn’t available. But it will be soon. Microsoft’s IronRuby language for .NET will finally make it possible for us to create a programming environment that allows users to design and write visual Ruby applications in just the same way that they have hitherto designed and written VB, C# and Delphi applications. We already have an IronRuby IDE in alpha (this will be released to our customers shortly) and we will release the finished IronRuby IDE shortly after IronRuby itself ships.
And after that...?
Yes, we certainly do have some projects scheduled for a later date. If you hunt around the blog assiduously you’ll find that we have already dropped a few hints about future projects. I don’t want to go into precise details at this early stage. Suffice to say that we are not now, nor will we ever be, content with what we’ve done so far. In fact, it’s that sense of discontent that motivates everything we do.
Later in the year I’ll explain our longer term plans here on the blog (taking us into 2009). For 2008, however, the Visual Rails Workbench and the IronRuby IDE are our two major developments.