Here’s a video of my talk on Weaving Design and Development at WindyCityRails. The motivating question is: What happens when designers have an idea to change a feature that is already built? The first half of the talk walks through an example of designing on an existing app, and the second half looks at the process between design and development that is necessary to implement changes in the design. There are 15 minutes of good questions at the end as well.
Simon B.
on 21 Sep 10It’s the half-life guy!? (sorry, couldn’t resist)
Zachary
on 21 Sep 10Ryan,
Great talk – one thing you said that made me curious was “helpers shouldn’t generate HTML, except maybe one tag if you have to.” I’m relatively new to Rails, but it seems as though the loudest voice in online communities right now says that this is the only thing that helpers should do.
What niche would you say helpers fill exactly? Should they essentially only be used to format strings (like currency, time, etc)?
RS
on 21 Sep 10Helpers are mainly for two things: (1) Moving view logic out of the template when it would be too verbose or distracting, and (2) Extracting view logic that you use over and over into methods to reduce duplication and simplify maintenance.
An example of (1) is a complicated condition. Suppose you want to render a different form tag depending on whether it is necessary to accept a credit card on the form. A helper like this does the job well: Example 1. Writing that in the view would be distracting and unnecessary because the difference in the form tag is immaterial to the display of the form.
An example of (2) is when you want to render an avatar over and over in your app, and every time you wrap the avatar in a link, apply the same classes and call the same method on an object to get the avatar url. Instead of doing…
...every time you render an avatar, you could write a helper that lets you do this:
That helper would make the view cleaner when it includes a lot of avatars, and it would simplify maintenance if you choose to render avatars differently in the future.
I hope these examples give you an idea.
Eric Hayes
on 21 Sep 10“HAML … I don’t know who that’s for but it’s not for designers who make applications” —Yes! Thank you for saying that.
I know HAML is all the rage, but even if it can do all the Ruby stuff ERB can, it’s still another language that has to be learned, and translated by a designer. Significant white space?? Really?
Give me good clean HTML any day. ERB doesn’t get in the way like counting spaces with HAML does. With HTML+ERB, If I’m using an editor that doesn’t have the right tab-space configuration I don’t get an exception because one character is off.
Learn Textmate shortcuts or use something like Zen coding if writing HTML is too slow for you.
Having said that, I think Ryan’s real beef is with Liquid templating; that’s a sandbox.
Neil Heinrich
on 21 Sep 10I work primarily as a front-end engineer in Rails. For me the differences between HAML and ERB is that HAML forces you to offload markup into helpers more often. From what I can tell that’s the point, clean views/templates. Personally, I don’t think HAML is much more difficult to understand vs. HTML/ERB.
My preference tends towards ERB as sometimes my Ruby skill gets in the way of my ability to abstract something out properly..
That said, SASS is a complete necessity.
Parker Selbert
on 21 Sep 10I was at WindyCityRails and enjoyed Ryan’s presentation, but as an avid HAML/SASS user I was distracted by his comments on it.
During questions Yehuda Katz pointed out that Ryan’s generalization that there was no logic in the template was entirely incorrect, which was a relief. I’d hate to have the couple hundred people there who respect what Ryan has to say but don’t know anything about the templating language take his shallow understanding of a technology as fact.
The only argument I hear against HAML is that it requires users to learn a new language, or it prevents other designers / developers from being able to collaborate on templates. Anybody versed in HTML and especially with the use of ERB could pick up HAML in less than an hour. Honestly, take 10 minutes to translate a template you have and you’ll see it is easier to read, shorter, and far more ruby-like. I can see where some non-developers may not appreciate a templating language being more ruby-like, but then what are they doing writing inside <% ... %> tokens anyhow?
One last thing about spacing: There are other languages that require spacing for indentation, Python is a notable one. Any fastidious designer is already doing this in their markup anyhow. In fact, and sorry but I wasn’t able to find a link for this, Matz is on record stating that he wished he would have used an indentation based syntax for clarity.
Zachary
on 21 Sep 10Thanks for the advice, I’m relieved to see that’s essentially how I’ve been using them, for the most part.
I’m a huge fan of SASS (would not want to go back to writing regular CSS), but I tried HAML for about half an hour before deciding it was definitely not for me.
I didn’t really find it easier to read than regular HTML, and I dislike anything that takes indention and spacing seriously. (Python, HAML, makefiles, etc)
RS
on 21 Sep 10Proponents of HAML say that HTML is dirty and HAML is clean. Many designers like myself don’t share this sensibility. We actually like HTML and enjoy a feeling of more flexibility in ERB. You don’t have to agree.
Berserk
on 21 Sep 10As a non-Ruby person I just spent a few minutes looking at HAML, and I will never use that (or anything similar to that) unless I have to.
Sass on the other hand I would use in a heartbeat if I found a good Sass 3 parser for Perl.
One obscures things I want complete control over, the other simplifies things without taking anything away.
Parker Selbert
on 21 Sep 10So long as people are given an accurate portrayal of a technology I welcome any dissenting opinion. Of course nobody has to agree!
My real issue, which I may have lost sight of in my post, is that I hate to see somebody as experienced as Ryan and representing somewhere as reputable as 37S slighting a tech that it is clear they haven’t used and didn’t really read about.
That said I’m also sorry for getting onto this topic again. I thought it was a great presentation (The live drawing style was unique), and a lot of the discussion was hijacked by this minor tangent.
Thanks for sharing your experience.
Robert
on 22 Sep 10Great talk. Thanks.
Eric Hayes
on 22 Sep 10SASS is something I’d like to try, but I haven’t seen any real-time tools for it. I use CSSEdit to see my CSS changes in as I make them, which makes designing in the browser a great experience —no recompiling or refreshing.
Perhaps I just haven’t come across such a tool, anyone seen one?
Kevin Bombino
on 22 Sep 10Here’s a Haml success-story from the battlefield:
We just completed a massive visual redesign of one of our apps (50+ controllers worth of views). While we made the changes mostly in CSS, there were a number of changes we had to make to the markup to accommodate the new design.
Because all our views are written in Haml, we were easily able to do a lot of Regex-based find-and-replaces in our code to implement the markup changes. It was easy because the markup was remarkably consistent across files.
Had we been using HTML/ERB, automating this would have been much more difficult due to the greater variety that would have likely existed in the code. There’s no doubt in my mind that the process would have taken dozens more hours.
Al
on 22 Sep 10Can we get bigger image you show around 30:00? That’s really something I should print it big…
Pete
on 22 Sep 10Ryan,
This talk was really excellent. I have two unrelated comments:
1. A process that combines design and development, and where as few abstractions as possible are used, is truly an effective and enjoyable way to develop software. We try to do this, and it is extremely satisfying to see your feature working by the end of the day, instead of just drawn or, worse, written up in a PRD (product requirements document for 37’s benefit). The technology choices that were the focus of the Q&A are completely irrelevant. You can use any stack, as long as designers have the ability to modify logic, which is Ryan’s point.
2. I think everyone involved will be surprised when I draw a parallel to some developments in the Microsoft world.
There has been a real renewal in design at MSFT, as evidenced by their “Expression” tools which offer analagous tools to the Adobe line of Photoshop, Flash, Dreamweaver, etc.
Most importantly, however, I’ve noticed in a lot of their talks they stress that designers and developers work from the same set of files, from the same version control system. In particular, the Visual Studio and Expression productes, for developers and designers, respectively, use the same projects and files precisely to make this possible. They evangelize iterative design. They even hired the famous designer Bill Buxton to evangelize all of this. (http://www.billbuxton.com/)
Interesting, and most likely to be met with ridicule by the Rails crowd, but it’s worth pointing out the parallel lines of thinking between (parts of) Microsoft and 37Signals.
Thanks for sharing this talk online for free. It’s very helpful to get an inside look at how you guys create your excellent products, and to really hear in depth about the process. The quick hit attitude pieces are nice and motivational, but this is educational.
Nate Klaiber
on 23 Sep 10RE: Parker
You said:
My question is: why? What benefit does HAML have to the everyday designer? I was at Windy City Rails, too, and was applauding Ryan’s stance. Of course it wasn’t well accepted, because it was a room full of Ruby programmers, many of which don’t enjoy dealing with HTML.
For designers, HTML is their natural language. Why would they want to abstract it? It’s like telling a Ruby programmer that they have to write their Ruby in .NET or Cold Fusion, that then gets translated to Ruby. Of course you would think that’s stupid, because you love Ruby and you enjoy writing it.
Many designers feel the same way about HTML. Why add another barrier or unnecessary layer?
Parker Selbert
on 23 Sep 10RE: Nate
Actually I think it fits well with the message that Ryan was giving: developers and designers should work together, on the same files (front-end at least) and using the same version control system. A productive and well meshed designer is already writing some ruby and javascript, or is versed enough to understand it.
I think this analogy that HAML is another language is flawed. It is more akin to what Markdown or Textile does for HTML as well—you still have to understand HTML, it just makes it clearer to read, edit, and concentrate on the content. Surely designers care as much as developers about clarity and simplicity behind the scenes in the source they are responsible for.
Admittedly my position may be skewed as I do both design and development.
Nate Klaiber
on 23 Sep 10RE: Parker I don’t see HAML as another language, but it is abstracted from what most designers are used to: HTML. While I do both design/development, I prefer to collaborate with someone who solely does design – as it helps the pace of a project. They are all well versed with HTML/CSS – and have been for years. They don’t write their markup in Markdown or Textile – they write it in HTML.
For me, the core is that HTML is not that hard. You have a small subset of tags/attributes, and even a smaller subset of those that you use on a daily basis. What benefit does HAML provide for that? Even as a developer – I despise HAML. I like writing HTML/CSS. I have done that for years.
I see HTML clearer as HTML, not as HAML. I am curious, what about HTML is not clear, or hard to read? What isn’t simple about it that it requires another parser to sit on top and translate it to … HTML?
Kieran
on 24 Sep 10Hi, Just a quick (potentially naive) comment/question on HAML and SASS, from the perspective of someone who has never come across them before.
How is SASS different to LESS?
HAML looks light it might be an absolute nightmare to maintain if used in a team. How can whitespace be relied upon to provide such a crucial part of the structure of the code?
Kieran
Parker Selbert
on 24 Sep 10Re: Kieran
It isn’t at all strange to keep consistent indentation in code. I rarely see OSS without consistent space based indentation. If it was so difficult to coordinate we wouldn’t have any Python code created by a team.
In practice I find it easier to change a single tag than finding an open and close tag to replace.
Honestly, I’m really not a HAML envangelist, just interested in keeping things grounded in fact. Use what you will!
Alex
on 25 Sep 10What application are you using to do that drawing? It looks awesome.
Alex
on 25 Sep 10That was stupid of me, obviously it’s Photoshop.
Kieran
on 25 Sep 10@kieran
<a href=”http://lesscss.org/ ”>LESS is CSS+helper functions (prefer it myself, because it doesn’t need conversion of CSS)
SASS is a different, more HAML like way, of building CSS.
but looking at the SASS site right now, they seem to have introduced SCSS which doesn’t seem to be much different from LESS
This discussion is closed.