Sessions at RubyConf India 2010 about SlideShare

Unscheduled

• Mortal Kombat: Developer vs. Designer

  by Kapil Mohan and Arun Jay

  Web front-end engineering has become way more complex than one imagined. There is HTML markup, content, CSS and Javascript intertwined to produce amazing web experiences we see all over the web. And this results in a problem which everyone must have faced - the developer/designer overlap.

  Here's an example of a typical development workflow: designers do wireframes, mockups, page layout, visual design, typography, CSS and markup. And hand it over to developers to wire it up with ruby code. It is quite unrealistic to assume that view layer will have zero ruby code (you will, at least, need print statements!). Now, once the markup is wired up with ruby code, maintenance becomes a problem for designers. A designer cannot go back and change the markup without a developer. Also, to multiply the problem, there are partials. So, designer can never look at the markup as ONE single HTML page and make design improvements. And if you'd look closely, the 'hand over markup' part suggests that this entire workflow is NOT agile!

  The underlying problem with this workflow is that the code and markup are not 'completely' separate. In an ideal situation, code, markup (page structure), CSS (visual design/style), javascript (behavior), media (flash, images, etc) should all be separate. Separation helps developers and designers focus on what they do best. The designer can focus completely on getting the final page exactly the way they designed it. This includes page structure, semantics, standards, accessibility, and optimization. This lets the developer focus on writing great code and solving their problems. Yes, we are talking about zero ruby code in the view layer.

  Enter hquery: Invented by (Chew) Choon Keat from Singapore (github.com/choonkeat), hquery is an unobtrusive server script implementation for Ruby on Rails - github.com/choonkeat/hquery. It is a rails plugin which lets you manipulate HTML markup using selectors etc, almost like jquery, except that it is on server. It was Choon Keat himself who introduced and demonstrated this powerful plugin to us while he was working with us at SlideShare. Since then, we've adopted this markup/code separation technique for all important pages at SlideShare. And it makes our developers and designers much happier. We find them playing Mortal Kombat on PS3 more than in their real lives now.

  The idea is that you have 2 files - .hquery and .hquery.html for every webpage you need. .hquery.html is ONE file with entire HTML markup needed to render the page. And, .hquery has code which uses hquery plugin to replace markup in the .hquery.html file with ruby code and turn it into a .erb file. .hquery file is used to compile .hquery.html into .erb files. Obviously, replacing markup with ruby code and then rendering it on the fly will get expensive soon. So, this transformation of plain HTML files to .erb files can happen once during the application deploy step.

  The end products (.hquery file and .hquery.html) are more maintainable, especially as logic piles on. There is a clear separation of the designed web page and it's structure (.hquery.html) and the server data that's weaved in (.hquery). The connecting factor is CSS class names that act as hooks to connect the two separate layers.

  During the talk, we'd like to show demos of how we use hquery and talk about pros/cons and more advanced stuff like code reuse etc.

  • Ruby on Rails
  • SlideShare
  Coverage slide deck