Monday, September 28, 2009

UI Flow Shorthand Application - A Proposal

The OCRuby Users' Group Needs a Group Project

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:
  1. Create a DSL (Domain Specific Language) that will generate the diagrams.
  2. Build a WYSIWYG tool to interactively draw the diagrams.
Either of these alternatives could be implemented within a web application or as a Ruby-based client application; although some solutions would be more difficult and/or less-satisfying to the user than others.

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.

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.


  1. Scott posted for Juha as he had connection problems:


    I did not have the needed IDs to comment your blog so I decided to send you my comments via email.

    For me the suggested project topic makes sense. I have seen the same idea applied in many places where interaction design is a key way to find requirements, allow users to participate and improve the usability.

    I would like to raise the bar a bit since we can use DSLs to do a better job than just showing the diagrams. That is: you draw the diagrams with the DSL and then generate the code for it: less errors, more fun!

    The type of generated code depends on your needs, but consider for example the case at: SImiarly to Ryan’s idea the nodes typically shows what the user sees and the arcs what to do next. From this domain-specific model you can generate fully running application. This particular DSL is focused on symbian phones but other domains and platforms need a different DSL (and code generators). Some such cases are shown at:



  2. Sorry about the permissions problem, Juha; I've loosened them up.

    I like your idea of "raising the bar", but I admit that my thinking was that Cucumber and/or RSpec _test_ code is generated, not the final _functional_ code. My test-driven orientation makes it hard for me to wrap my head around the notion that DSL generates functional code as well as diagrams. Also history hasn't been kind to efforts such as those to convert between UML and code and vice-versa.

    So this implies that I was casting this project as a more "light-weight" effort than I think you are considering. That being said, I'm open to what the group wants to do.

    Let the negotiations begin! Anyone else want to weigh in?


  3. Hey Scott,

    I think this is a pretty good idea. I would love to practice rails on an actual project. I cant seem to focus on projects I set for myself...go figure. Also I haven't seen any activity on in the OC Ruby Users group, are they still active?

  4. Hi Nirmit,

    Scott Hobson has recently stepped down from running OCRuby; a group of enthusiasts (including me) is intent upon re-energizing the OC Ruby community. So hang in there and keep track of the OCRuby web site and Yahoo group.

    In terms of being motivated for self-created projects, that is a challenge for many of us. The reason, I believe, is that many of us developers have done enough development "on our own" and find it much more rewarding to work with other developers. I know that's true for me. So, providing project teams that have an opportunity to work together is an important goal for the OC Ruby Users Group. Let me know if this is something you want to participate in.

  5. YES!!! Need to do something to keep my mind active...feel the repetition of everyday life draining my youth.