Designing HTML views is an iterative, interactive process by nature. And anything that slows down the iterations, slows down development.
I was working on a form recently where the steps to show it went something like this:
- Go to the home page
- Log in
- Click “New Thingit” (domain terms have been changed to protect the innocent)
- Click “Edit” on the Thingit
- Click “Settings”
- Click “Enable Facebook integration”
- Click “Save”
- Click “New Wodget”
- Fill in the “New Wodget” form
- Click “Save”
- Click “Edit” on the saved wodget
All this just to get to the “Edit” view of a Wodget. Once you got this far the iterations were a little tighter, but because the forms were presented via AJAX, you couldn’t just hit F5 to refresh the form after making a view change. You still had to take a few steps:
- Click “Cancel”
- Click “Edit”
All this rigmarole got in the way of quickly seeing the results of view tweaks.
The way I finally decided to address the issue was to create a “view sandbox” inside the app where I could easily fiddle with arbitrary views.
I created a routing section for the sandbox which would only be enabled in the “development” environment:
if Rails.env.development? match 'sandbox/:action' => 'sandbox' end
Then I created a very basic SandboxController, with an action dedicated to the view I wanted to play with:
class SandboxController < ApplicationController helper 'thingit' helper 'wodget' layout 'application' def edit_wodget @thingit = Thingit.find_or_create_by_name("SANDBOX_THINGIT") do |thingit| thingit.wodgets.create(...) end @wodget = @thingit.wodgets.first end end
The controller action created just enough example model data to keep the view happy.
Finally, I created a
views/sandbox/edit_wodget.html.haml view corresponding to the action, which simply included the Wodget form partial.
With this in place, I was able to simply navigate to http://localhost:3000/sandbox/edit_wodget to experiment with changes to the view, hitting reload when I wanted to see the effect.
Maybe there’s a better way to do this, and if there is I hope you’ll clue me in. I present this in case anyone else has run into a situation where the change->preview->change roundtrip is just too darn slow.
Wow, awesome technique. Thanks for sharing it.
What you did illustrates the difference between the “slow easy” way and the “fast hard” way. It took some thinking to set up the sandbox, and it would have been easier just to train your fingers to go through all the steps. Instead, you thought more deeply about the problem and saved all kinds of time and effort.
I was trying to explain to a friend the other day that for me “flow” (deep, productive concentration) more often than not looks from the outside like a man leaning back in his chair staring into space. I find the shortest path from point A to point B often involves thinking a lot and typing very little.
And that’s one of the main problems I (personally) have with pair programming.
A fair point. I’ve often found it necessary to say “I need to take a walk now” to my pair, because I have some deep thinking to do.
Great tip, Avdi. We have something just like this where I work. We actually use it to enable another workflow as well:
That makes a lot of sense. It almost seems like it would be a necessity in any project where developers and designers are working in parallel.
Bryan I want to be a UX guy where you work…
I tried to explain the HTML+CSS development process to our .NET guys on a project where I was the UX guy. The site was liquid layout, client themeable, and supported both browser native font-sizing as well as buttons on the site for users to set font-size. Our client base is 40% IE6, the rest IE7-9 and FF. I prototyped the front-end w/ Ramaze+HAML+SASS, and needed 2-4 second cycle times to be efficient since each component and page needed to be checked on 5 browsers * 3 font-sizes * window width from 800-1280px.
@amsheriff: To quote Martin Fowler, if you can’t change your company, change your company.
Agreed! Now I’m inspired, no matter which way I interpret that quote.
One thing I love to do is use Selenium IDE as a macro recorder. When, for some reason, I cannot (or don’t want to) test-drive it, I speed the manual loop by just recording something, tweaking the selectors and then running it instead of doing it. Speeds up the preview->change->preview dramatically.
This probably applies to a different set of problems, but I though I should share it anyway.
That’s a great idea!
I really like your approach, thanks for sharing.
This aspect of development doesn’t get the attention it deserves, and I think there’s a real problem here that needs to be solved. In my opinion, the problem is that the presentation code (HTML) and logic is in one place: the view. If those two things were separated, this would be a trivial problem to solve; just turn off the view logic and the only thing left is the static presentation code.
You might be interested in checking out Pakyow (pakyow.com), which attempts to solve this problem by separating view logic from the view. I’d certainly be interested in hearing more of your thoughts on this topic.
Thanks for the links to those resources!