Ruby on Rails as rapid prototyping tool
Ruby on Rails might be the perfect match as a prototyping tool. It delivers consistent productivity gains compared to any other prototyping tool. Very few lines of code makes it easy to change. Here is why we use it at work as our preferred prototyping tool.
First time I heard about Ruby on Rails was when David Heinemeier Hansson, Jason Fried and Ryan Singer presented the “Building of Basecamp” workshop in Denmark June 2005. Basecamp was the project that sparked the development of the Ruby on Rails framework.
I recognize the reaction that Deane of gadgetopia describes:
So what was the biggest shock of the Basecamp seminar? Finding out that it was written in Ruby. Yeah, that’s right — that Japanese language that you thought no one was using. They’ve apparently put together a Web development framework for it which they’re releasing to open-source.
(from www.gadgetopia.com June 25, 2004)
I was immediately interested in the possibility of using Rails as a productivity tool, where in some cases a Rails application can be developed up to ten times faster than a similar Java or .Net application. Very promising.
Prototyping satisfaction survey
I’ve tried a lot of different prototyping tools: Paper, Photoshop, Powerpoint, Dreamweaver, HTML. Until Rails I was perfectly happy with HTML prototypes: I consider them easy to maintain, fast to produce, possible to search and replace during development.
My experience goes pretty well with the 2002 GUUUI survey where 52 people replied on their preferred prototyping tool and their satisfaction with it (people preferring HTML were the most happy with their tool).
| “I’m perfectly happy with the prototyping tool I’m using” | |||||
| Strongly disagree | Mildly disagree | Neither agree nor disagree | Mildly agree | Strongly agree | |
| All replies (52 replies) | 7.5% | 37.7% | 15.1% | 32.1% | 7.5% |
| Using a visual or text based HTML tool (15 replies) | 6.7% | 20.0% | 6.7% | 60.0% | 6.7% |
| Using a diagramming tool (13 replies) | 7.7% | 76.9% | 7.7% | 0.0% | 7.7% |
| Using a graphic design tool (10 replies) | 10.0% | 20.0% | 20.0% | 50.0% | 0.0% |
Source 2002 GUUUI survey on prototyping tools.
Enter ruby on Rails
One thing I miss in HTML prototyping is the lack of real data. For instance, a user enters a date on one page. On the next page, the date is hardcoded. Chances are that users at a user test enter values that are different from what I hardcoded on the screen. Here Rails is perfect. In stead of building screens, we build the application front-end.
At my work in Capgemini Denmark, we have used Rails for some months at work projects and it has proven to deliver:
- Very high fidelity prototypes that can use real data. The high fidelity give much better findings in usability testing.
- Consistent productivity gains compared to any other prototyping tool.
- Very few lines of code makes it easy to change prototype.
- Doesn’t have to be thrown away after building prototype.
Consider the fact that Rails can actually live on in the application development. I believe that Rails is a perfect match for making rapid prototype development. Also this approach is what Garret Dimon invented “just build it“, and it fits like a glove with the agile approach of the guys at 37signals.
Whats your thoughts on this? What tools would you use for prototyping?
- Digital Web Magazine: Just Build It: HTML Prototyping and Agile Development
- Garrett Dimon: AJAX & DOM Scripting: Just Build It
- 37signals: Getting Real, Step 1: No Functional Spec
- Particletree: A Designer’s Guide to Prototyping Ajax
- GUUI: 2002 survey on prototyping tools
Technorati Tags: prototyping, html, ruby on rails, business case, capgemini, productivity
April 12th, 2006 at 08:09 (GMT-1)
I work at Capgemini too, and use RoR for the same purpose.
It tooks me 3 to 4 days to implement all the functionalities + some css.
The production application – rewritten in java – is often a replicate of the prototype.
Actually, I’m pretty sure that no one can make a difference between the prototype and the final product.
Now I just hope that one day I will ship my RoR app as a final product.
ps: are there any psychological side-effects in using both RoR and Java/.Net in parallel? Do you have to keep RoR out of the reach of the developers to keep them motivated in working with other frameworks?
April 12th, 2006 at 09:00 (GMT-1)
Just curious, why do you rewrite it in Java? Is it just some kind of company policy or inertia perhaps?
April 12th, 2006 at 10:05 (GMT-1)
Very interesting post; nice to see large consulting companies embrace RoR, even if “only” for prototyping.
I think it will still be a while until enterprises dare to use RoR as a production platform, which also somehow answers Xavier’s question: The customers have invested large amounts of money in J2EE or .Net, so for obvious reasons they’re not likely suddenly to switch to a platform, they probably haven’t even heard of.
As of the psychological side-effects in using both RoR and Java/.Net in parallel , my guess is that developers will get smarter using RoR and try to adopt some of the agility principles of RoR on a more general basis, f.ex. write or implement meta-programming tools, think about “convention over configuration” when writing their own micro-framework apps and so on. Sticking rigidly to the conform rules of (most) Java frameworks or .Net technologies will become a pain faster than one can spell ActiveRecord, that’s true, but these rules come with the frameworks and since neither J2EE nor .Net is likely to go away for a long time, it’ll be a matter of bending them.
Nice thing is to see larger RoR adoption in my home country, Denmark. Do you know of any RoR knowledge groups in DK, and if so, could you post it here? I’d be very interested.
April 12th, 2006 at 10:35 (GMT-1)
This question came from the Rails mailing list.
Two of the projects, were big offers in the public sector where we used Rails to define the user interface. In these cases, the clients had already chosen technology and platform. So Rails was only used for prototyping during the process where we wrote our offer.
One of these, which we won, we decided to modify the Rails prototype so that it will reflect all requirements for the user interface. The rationale behind this: It’s faster to modify this in Rails and then port to the platform that the client required. Furthermore, we want to make sure that we share the understanding of the system with the client. This is where a prototype is way better than a written document.
In this way, we use Rails to gain equal expectations of the system’s capabilities. (Oh by the way, the contract obliges us still to document our work in word documents but I guess it’s the way the enterprise world still works).
The third project has just passed a milestone where the client wanted us to give an estimate on how it could fit into their existing environment (Microsoft technology). The client would choose between two options: 1. Rails solution running on IIS and with MSSQL server. 2. A port of the prototype to .NET (which is estimated to cost approximately 3 times as much). I have no more details to share right now, but I’ll definately post more (on justaddwater.dk ) when I can share more details on this project.
I hope this responds to your questions.
April 12th, 2006 at 21:11 (GMT-1)
These are great tidings. As a matter of fact, during the process of persuading my own boss(es) to let us adopt Rails I was asked if any of the big consulting firms were using it. Since I knew of none, my boss got a worried look on his face. Very good news this.
April 12th, 2006 at 23:24 (GMT-1)
> Xavier Noria Says:
>Just curious, why do you rewrite it in Java? Is it just some kind of company policy or inertia perhaps?
Only Java (TM) EJB (TM) are allowed.
RoR was my own initiative, my other alternative was to write a Word document.
April 17th, 2006 at 10:09 (GMT-1)
Hi Jesper! Interesting article… I agree with you. But if we want to make grow RoR as a platform there are some questions (I think that is better be an devil’s advocate :-)):
1. In my experience, one of the problems I can find with this approach is the “What’s left? Can we make it run NOW?” effect. I mean, . Sometimes, they take the high fidelity for the final product. If you show your client an almost ended product, he can put pressure on the development phase. The advantage of the RoR approach is that you almost don’t have functional specs… so… all the product design and development team has the same perspective about functions, look and feel of the final product… Just build it.
2. The HCI and Interface team need to be remodeled: I mean, you can’t only sketch the UI. You need more technical profiles. So maybe, from a pure UI Team perspective you are lacking “agility”, because you raise the client’s expectations: he expects to hace a very high fidelity pre-definition of the final product.
3. Last. Are we degrading Rails to just a “nice prototyping platform” with this approach?
April 22nd, 2006 at 01:37 (GMT-1)
[…] justaddwater.dk Instant Usability & Web Standards “I would love to change the world, but they won’t give me the source code.” « Ruby on Rails as rapid prototyping tool […]
May 2nd, 2006 at 00:27 (GMT-1)
Not sure RoR makes sense for non-programmers, but I can see it working for those willing to learn.
We’ve started using a new prototyping tool (www.easyprototype.com) that can take scanned paper sketches and link them into interactive HTML without us having to code (it’s not our strong suit). It works pretty well, and the prototypes could never be confused with the real thing :-)
May 11th, 2006 at 13:10 (GMT-1)
[…] My talk is based on some of the ideas I posted about in the article Ruby on Rails as rapid prototyping tool. In case you missed it, yesterday I announced that I’ll also be speaking on usability and rapid prototyping May 19. […]
May 16th, 2006 at 00:11 (GMT-1)
[…] Justaddwater.dk Ruby on Rails as rapid prototyping tool by me: At my work in Capgemini Denmark, we have used Rails for some months at work projects and it has proven to deliver: […]
May 22nd, 2006 at 09:18 (GMT-1)
[…] We’re looking forward to this conference. As frequent readers here may know, we’re using Ruby on Rails in Capgemini for things like rapid prototyping of web applications. Also I’m particularly interested in the business value of using it. […]
June 26th, 2006 at 23:00 (GMT-1)
[…] Danish translation: Volunteers for paticipation in translating all error messages, active record messages, scaffolding, etc to Danish. That would be extremely valuable for working with close relation do Danish customers or public authorities that need their websites in Danish anyway. I no repetition, and a translation plugin (or more likely GLoc/Globalize) to be used especially when working professionally with rapid prototyping. […]
August 3rd, 2006 at 15:42 (GMT-1)
Hello,
Very nice post!
Thanks!
August 14th, 2006 at 23:10 (GMT-1)
[…] Ruby on Rails as rapid prototyping tool […]
September 12th, 2006 at 13:39 (GMT-1)
[…] The point David touches here is whether you could consider an “Immature” technology in the enterprise. Joel and David seem to disagree on this point. And Joel seems to disagree with himself. For the case of Ruby on Rails considered immature for the enterprise, i strongly disagree. As I wrote previously, Ruby on Rails has proven to deliver: […]
October 9th, 2006 at 23:12 (GMT-1)
[…] [Jesper’s note: Nobody mentions using Ruby on Rails as Prototyping tool.] […]
November 16th, 2006 at 11:48 (GMT-1)
[…] The best part of it — my personal opinion — is probably the early bird free web design fridge magnets. They will fit perfectly in the way we do rapid prototyping with Ruby on Rails at work. […]
November 23rd, 2006 at 20:08 (GMT-1)
[…] Ruby on Rails as rapid prototyping tool (tags: rails ia @lesen) […]
December 26th, 2006 at 22:17 (GMT-1)
[…] Earlier I wrote how we use Ruby on Rails as rapid prototyping tool at work. Hobo is a promising plugin for Ruby on Rails to speed up development even more. At work, we’ve been looking into rapid prototyping of web applications for quite some time. Hobo might even help us to speed up development even more. […]
February 13th, 2007 at 09:54 (GMT-1)
[…] Justaddwater.dk: Ruby on Rails as rapid prototyping tool […]
February 28th, 2007 at 21:23 (GMT-1)
[…] Ruby on Rails as rapid prototyping tool (Apr […]
July 9th, 2007 at 14:07 (GMT-1)
SAP Design Guild has an outdated paper on prototyping that focused on paper prototyping: http://www.sapdesignguild.org/resources/archive/prototypes-old.asp
November 18th, 2007 at 17:32 (GMT-1)
[…] Ruby on Rails as rapid prototyping tool (Apr […]
December 1st, 2007 at 16:15 (GMT-1)
[…] happy. When faced with a Rubygmatic programmer, words like “productivity” and “rapid development” will be […]
January 2nd, 2008 at 21:55 (GMT-1)
[…] Ruby on Rails as rapid prototyping tool […]