how to convert erb files to html for use by designers?

Hi,

I've written all my view templates in erb, but now I need to convert
them to straight html so that designers can work with them. How do I
do this?

In this connection, any comments on best practices for working on RoR
apps with designers would be appreciated.

thanks,

Lille

Hi,

I’ve written all my view templates in erb, but now I need to convert

them to straight html so that designers can work with them. How do I

do this?

Not possible - your designers have to know to work around the erb portions, however all the erb should be framed within html so they should be able to work with the views as is. This is the case with every framework I know - php, .net, rails, etc, that there will always be to a degree some artifacts in the html/view file.

In this connection, any comments on best practices for working on RoR

apps with designers would be appreciated.

As far as work flow, depends on what you use for source control and whether they have a source control account or whether you will just manually manage the commits. Bottom line is that you should have tests for your app, and commit regularly, including changes from designers to assure that nothing has broken. Some others may have more extensive experience and advice on this.

Thanks for the clarification of the erb matter. (I guess the basic
requirement of these scripts is the employment of a vernacular that
any designer can work with.)

OK, so get a GitHub account and RSpec the views, e.g., to ensure that
any html elements involved in client-side functionality remain intact.

Comments on good 'marketplaces' for RoR-savvy designers invited...

Lille

You do not have to use github, though that is a perfectly viable
route. You can also just run git locally.

Colin

Thanks for the clarification of the erb matter. (I guess the basic

requirement of these scripts is the employment of a vernacular that

any designer can work with.)

OK, so get a GitHub account and RSpec the views, e.g., to ensure that

any html elements involved in client-side functionality remain intact.

For views, even better try cucumber. I adopted it a couple months ago and find that it makes writing tests simpler (using Engligh rather than so much code), helps focus the tests through the user experience, and has faculties to use selenium or similar to test javascript/ajax, which is something that you might want to make sure has not broken with collaborating.

Comments on good ‘marketplaces’ for RoR-savvy designers invited…

Cant help much here but I would think if you find someone who has worked with php, working with Rails Erb should be an easy switch. But also depends on the complexity of your designs and how much interaction there is between design and code.

I have had problems in the past getting some designers to use vcs. Another option is to let them FTP files somewhere and write a directory watcher to automate the commits.

Best Wishes,
Peter

Right.

Further clarification sought: the designer needs to run Rails while
they design. This is what had me assuming I could translate erb into
pure html; I would think it ideal if designers didn't need to use any
framework to do their work, which, after all, only involves the .html
files.

Lille

Right.

Further clarification sought: the designer needs to run Rails while

they design. This is what had me assuming I could translate erb into

pure html; I would think it ideal if designers didn’t need to use any

framework to do their work, which, after all, only involves the .html

files.

Yeah, actually that is a good point and argument for having someone who does know Rails. There are easy to install environments - like Instant Rails on windows and I know there are some others for Linux… Virtual Rails I think. So you could go this route and educate them enough to run the app and load pages.

OK, a final question. If I go out into the freelance marketplace, how
do I protect my proprietary models? With a preloaded set of html
templates, I get around this problem, bc I don't need to provide
anything else, but if the designer needs to run Rails, then they get
everything. What are my options, mocking everything?

Lille

Lille wrote in post #959146:

OK, a final question. If I go out into the freelance marketplace, how
do I protect my proprietary models? With a preloaded set of html
templates, I get around this problem, bc I don't need to provide
anything else, but if the designer needs to run Rails, then they get
everything. What are my options, mocking everything?

Good NDAs.

Or just get raw HTML -- or even images -- from your designer and make it
into ERb (or better yet, Haml) yourself. That's usually a better bet
anyway; very few designers know how to produce decent HTML. If yours
does, you've found a real treasure! (I work with one of these
treasures. She also knows how to use Subversion and Git.)

Lille

Best,

OK, a final question. If I go out into the freelance marketplace, how

do I protect my proprietary models? With a preloaded set of html

templates, I get around this problem, bc I don’t need to provide

anything else, but if the designer needs to run Rails, then they get

everything. What are my options, mocking everything?

Thats an interesting question - I have not dealt with this but is a real problem. Maybe give ftp rights just to the views folder on your staging environment, let them upload changes and then they can see them in contxt of the app. Of course that kind of bypasses source control which you would have to work out. Curious what others would suggest.

Marnen Laibow-Koser wrote in post #959151:

Or just get raw HTML -- or even images -- from your designer and make it
into ERb (or better yet, Haml) yourself. That's usually a better bet
anyway; very few designers know how to produce decent HTML. If yours
does, you've found a real treasure! (I work with one of these
treasures. She also knows how to use Subversion and Git.)

I very much agree with this point. I think it would be very rare to find
talented designers that are both capable and willing to deal with markup
issues.

In my view there are really three roles, (1) programmer, (2) web
developer, and (3) designer. If we're talking about the latter, then
that person is mostly likely interesting only in drawing pretty
pictures. I don't mean to downplay that role at all. It's a talent I
wish I had, but simply don't. It is often unreasonable to expect the
best artists to have to deal with HTML at all.

All of this, however, depends on the needs of the application. If design
and artistry is highly valuable to the success of the project then don't
hinder their process with roadblocks they don't have the skills to
manage.

Bottom line is, work with them, not against them. Make sure your
application design avoids anything but trivial logic inside view
templates. It's reasonable to ask a web developer/designer to avoid a
few embedded custom tags, but if that gets too complex you're likely
going to frustrate them. You probably won't get their best effort.

Think about the development roles like we think about MVC. Programmer is
to the Model as Designer is to the View, and Web Developer is like the
Controller "glueing" it all together. Of course in many cases the
Programmer role and the Web Developer role is the same person, but if
you think about the roles separately it might help in planning the
translation of the art into the code.

If you want to give your designer a bit of freadom without them needing to know erb/ruby use liquid

http://www.liquidmarkup.org/

check what it is in this screencast

http://railscasts.com/episodes/118-liquid

basically is

“Ruby library for rendering safe templates which cannot affect the security of the server they are rendered on.”

and looks like this

<ul id="products">      `

`      {% for product in products %}`
`        <li>`
`          <h2>{{product.title}}</h2>`

`          Only {{product.price | format_as_money }}`
`      `
`          <p>{{product.description | prettyprint | truncate: 200 }}</p>`

`                    `
`        </li>      `
`      {% endfor %} `

`    </ul>`

`

With this you can define a small set of variables or methods that they can access and so you can give them a small “dictionary” telling them for example that inthe product page they can use a variable called product that has x attributes.

Hey guys,

I work with freelance designers all the time. Here's my standard
workflow.

1) Send them wireframes of the pages
2) They send back mockups in image
3) I/Client approve
4) They send me html pages (Stop here if you don't need them to
maintain the html, else proceed to step 5)
5) I convert html to erb
6) Create new branch call 'design'
7) Let them push/pull only on design branch, I'll keep the branch up
to date (merge/rebase/force etc)

This way they only have to remember limited set of git commands, and
they can't screw up the repo.
Most designers will immediately understand the pattern/logic.
When new pages needed, I just add route/controller and blank view.
They'll treat it like static HTML, then I fill in the logic again.

I don't worry so much about giving them access to the source. But when
I must, here's what I've done.

1-5) as above (all new pages will repeat these steps)
6) Give the URL to staging
7) Get then to do live edit (firebug, even better if CSSedit)
8) Send back new stylesheet (with any image changes)

A bit more hassle really. But it worked for me in few occasions.

Cheers!
Arzumy

Thanks for all this feedback, everyone.

I'm intrigued by Liquid and by Arzumy's detailed work flow.

As it happens, the project I wish to have re-designed contains
extensive JQuery in a three column layout. So, I would look to adapt
Arzumy's workflow as follows:

1) Send them html and accompanying stylesheets of only those pages
with novel div container structure
2) They send back images of their modifications to those
3) I/Client approve
4) They send me html pages and stylesheets
5) I convert html to erb
6) Create new branch call 'design'
7) Let them push/pull only on design branch, I'll keep the branch up
to date (merge/rebase/force etc)

WRT Robert's valid observation, the design function, whether performed
by a person or group, is faithful to the MVC outline if it includes
i) .css styling and ii) enforcement of cross-browser standards. Who
else should police the view if not the designers? This is why a
complete designer -- again consistent with the MVC formulation --
really should be expected to know i) and ii) -- those are view
responsibilities. This is precisely where I'm at: I can do everything
else, but striking into the appearance and my ii), above, would be new
undertakings necessary for the view alone.

Lille