Here in Orange County, CA, Ruby Users' Group, we're in the process of selecting a "group project".
A Suggested Project
Here's an idea. Implement a simple graphical tool for Ryan Singer's recent posting on a shorthand notation for UI flow. Forrest and I both like it. If you haven't already, read Ryan's post. Here's an example from his article:
In the following discussion, I'll refer to Ryan's subject matter as "UI shorthand".
Now, it is to be admitted that Ryan himself protests building a tool for UI shorthand, but Forrest suggests that perhaps Ryan's shorthand could be another Cucumber script. Just because a Cucumber script doesn't attempt to "document everything" doesn't mean that the metaphor isn't a valuable vehicle for test-driven-development. We suggest that UI shorthand could be an additional valuable input for TDD.
Implementation Alternatives
So, presuming for sake of discussion that this is a project worth pursuing, what do we have w/ UI shorthand? Its artifacts are hand-drawn diagrams. Hmm, don't want to parse those.
If we want to capture the information in the hand-drawn diagrams in a parsible way, I can see two strategies:
- Create a DSL (Domain Specific Language) that will generate the diagrams.
- Build a WYSIWYG tool to interactively draw the diagrams.
Alternative 1 - Create a DSL and generate the diagrams
This can be implemented either on the server or the client. Since graphics are involved, if this is done on the client, then the user will need to download the rendering engine we select. If this is on the server, then the server can generate the graphic in a form that the user's browser will already know how to download and display.
This would be an opportunity to get involved with a graphics tool like SVN.
An example of a site doing something equivalent can be found here. http://yuml.me/
Here is an example of their generated output:
A second step would be to implement a filter that would convert the DSL to Cucumber or RSpec syntax.
Alternative 2 - Build a WYSIWYG tool to interactively draw the diagrams.
Ruby has all the libraries needed to implement a full WSYIWYG on the client. In this case, perhaps the tool would also generate the DSL so that it, in turn, could be converted to Cucumber or RSpec as described in alternative 1 above.
Doing a WYSIWYG is much harder on the server. About all I can think of is having the server rapidly generate a mouse-drag in Ajax while updating a image of the drag. At best, this is likely to be sluggish.
Or we could do it in a proprietary browser "desktop" like Microsoft's Silverlight or Flash.
Summary and Call to Action
Anyways, that's the extent that I've thought about it. This sound interesting? OCRubyists, please weigh in w/ comments here.
Thanks for your participation.