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
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