1

I have a designer who has great knowledge of HTML, CSS and JavaScript (Not jQuery or AJAX though).

He gives me his designs in those files and I have to incorporate it into my apps.

The site is not static so I have trouble incorporating it.

When the site was static I used to save the HTMLs in my app/views directory and the other CSS, JS, fonts in the public/... dir. The files are directly linked from the HTML is read just fine.

But now, I have to replace HTML tags with .erb ones <% --rails-- %> when some dynamic action needs to be performed. Even this seems harder than it sounds

Anyone developer experienced with this? How did you solve your problem?

OR should I ditch this designer and get a designer who has good knowledge of rails?

2

I have worked with many designers, some who can work within Rails apps and others who can't. I highly recommend that you only hire designers who are capable enough to integrate directly into the project itself. You will be surprised how valuable a good designer can be once they can integrate their work with the team.

Integration will require a little teaching and continual guidance before you will see results. For a short term project I don't think it's worth it -- in those cases hire a different designer. But for a longer term project its worth the time investment if you're working with a designer already skilled in HTML/CSS/Javascript.

Integrating a Web Designer into a Rails Project:

1. Set up the Designer's IDE

Non-programmers are easily overwhelmed by compatibility issues, so it's best to make sure their dev environment is aligned properly from the get go with tools they need to use to develop for Rails. A very good way to onboard a designer quickly for a Rails project is to install this installation script by Thoughtbot. This will install nearly every dependency they will need to work on most Rails apps in local development.

An alternative approach is to use contained IDE for development to keep everybody synced, using tools such as Nitrous.io

Next, make sure they are hooked up to all of the relevant config settings needed to boot the app, such as having a working database.yml

2. Teach them basic Git

Manually implementing mockups from a designer is a gigantic waste of time. If you want them to be able to use Rails, then is imperative they can also integrate that work easily with yours by using a version control system. This is essential for seemlessly integrating their changes with the project, sparing you time, and enabling faster change/deployments.

Your designer should set out on learning how to become comfortable using basic git commands such as understanding branches, how to push, pull and commit. If merge conflicts happen you might be better off handling them yourself (these should not occur to much for the designer if most of their work is separate from your changes).

There are great GUI tools such as SourceTree that make learning and using Git much easier if you don't want to learn how to use git from the command line.

3. Explain the Rails file/folder system where relevant

In a Rails app, your designer does not need to know too much about a Rails filesystem to get working. They just need to know what part of the file system to focus on:

  • app/views: Where HTML files are stored. Here some concepts they need to know to get working is:

    • Data portions of the html can be spotted because they use ERB tags: <% --rails-- %>. Tell them this is usually the part they should avoid changing when manipulating the HTML. (In your views it may help to use comments to explain to your designer where important data fields are showing up so they can design HTML/CSS targeting them properly)

    • Partials are snippets of HTML that can be detected because they have an underscore in their name. E.g. _edit.html.erb is a partial. index.html.erb is not.

    • The main app layout is found within app/views/layout. Explain the <%= yield %> ERB tag is what loads the other parts of the app's views for each page.

For front-end javascript/stylesheets/images:

  • app/assets or app/public:

    • Inside asset pages (e.g. home.css.scss) correspond to the name of every view folder's title.

From here, you can even go farther by helping them gain a little knowledge about how stylesheet precedence is handled by the asset pipeline in Rails (and compiles into a single application.css files). If they have knowledge of sass or less, it may also be useful to explain how these files compile down to css e.g. home.css.scss -> home.css

4. Teach them How to Start a Rails Server

To work within Rails a designer needs to learn basic command line actions to at least enough proficiency to be able to boot Rails once the app is set up.

This means a designer will need to learn how to navigate the command line filesystem using cd and cd .., including how to get to the Rails projects root from their Path.

Inside a basic rails app project path, they just need to follow this workflow to get started:

  1. git pull in latest changes from the rails app root directory.
  2. bundle install
  3. bundle exec rake db:migrate [you may need to tell them to e.g. bundle exec rake db:drop db:create db:migrate db:seed to fix database issues occasionally]
  4. rails s to start the server.
  5. And then to visit http://localhost:3000 to load the app's webpage.

Now they're done! Also remind them to use ctrl + c in the command line to stop the server if they are pulling in new changes.


By this point, your designer should have enough knowledge now to make html/css changes directly inside your Rails app comfortably within your existing project.

It's likely you will need to still help them out when complications arise (such as their database getting out of sync, or needing special account powers to work in a restricted part of your site), but the time savings you will gain will still make pursuing integration worth it.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.