I am considering trying Rails out on a small web project where I will be working with a designer. What is the typical workflow and relationship for this: 1 have the designer learn rhtml or 2 have the programmer take html mock ups and turn them into rhtml In the past I have used Django (also very nice), which has a fairly accessible (ala php) templating language. Thanks, David S. -- Posted via http://www.ruby-forum.com/.
On 3/14/06, David S. <davidschein@alumni.tufts.edu> wrote:> I am considering trying Rails out on a small web project where I will be > working with a designer. What is the typical workflow and relationship > for this: > 1 have the designer learn rhtml > or > 2 have the programmer take html mock ups and turn them into rhtmlMy preference has always been to have the designer produce very clean, static, HTML. Then I''ll break that up into the various pieces that I need. I guess it depends on how technical the designer is. -- James
David S. wrote:> 1 have the designer learn rhtml > or > 2 have the programmer take html mock ups and turn them into rhtmlHere''s my preference -- start with a graphic designer who understands the mechanics of HTML page layout, and have them produce flat comps (ie, PSD files). Then the developer can take those and implement them as HTML/working pages. I think this approach allows the designer to focus on design, rather than worrying about technical details in the HTML -- presumably that''s not their core competency anyway. It also saves the developer from having to rewrite poor HTML. The prerequisite is making sure the designer and developer have a good, close working relationship; breakdowns in the process usually come from poor communication over design goals and technical limitations. -- Posted via http://www.ruby-forum.com/.
David S. <davidschein@...> writes:> > I am considering trying Rails out on a small web project where I will be > working with a designer. What is the typical workflow and relationship > for this: > 1 have the designer learn rhtml > or > 2 have the programmer take html mock ups and turn them into rhtml > > In the past I have used Django (also very nice), which has a fairly > accessible (ala php) templating language. > > Thanks, > David S. >My recommendation would be to create temporary object per page that includes all fields needed for that page, this object is then passed to the view. Then the designer can simply place <%= pageObject.field1 %> ....<%= pageObject.field2 %> etc in the middle of the HTML, rather than having to do any logic in view or reference multiple objects. These fields should contain all calculated values etc. Ville
You might want to consider hiring a designer that is a css expert. With CSS, you can build highly designed sites and it can be designed after the structure is already formed. The developer would just have to output well structured html. You might want to look at: http://www.amazon.com/gp/product/1590593812/102-7785155-3448109 Ville Maanpaa wrote:> David S. <davidschein@...> writes: > >> >> Thanks, >> David S. >> > > > My recommendation would be to create temporary object per page that > includes all > fields needed for that page, this object is then passed to the view. > Then the > designer can simply place > <%= pageObject.field1 %> ....<%= pageObject.field2 %> etc in the middle > of the > HTML, rather than having to do any logic in view or reference multiple > objects. > These fields should contain all calculated values etc. > Ville-- Posted via http://www.ruby-forum.com/.
On Mar 14, 2006, at 10:39 AM, Chris Bruce wrote:> You might want to consider hiring a designer that is a css expert. > With > CSS, you can build highly designed sites and it can be designed after > the structure is already formed. > > The developer would just have to output well structured html. > > You might want to look at: > > http://www.amazon.com/gp/product/1590593812/102-7785155-3448109+1 The markup should be strictly independent of the design! All the designer should need to do to the .rhtml files would be to tweak class attributes and other minor changes for the purposes of identifying particular divs and spans. -- -- Tom Mornini
On 3/14/06, James Ludlow <jamesludlow@gmail.com> wrote:> My preference has always been to have the designer produce very clean, > static, HTML. Then I''ll break that up into the various pieces that I > need. > > I guess it depends on how technical the designer is.This is what I like to do. There''s no real need to have designers work directly in the app, if you''re just hiring them to design a couple pages. Also, if they work on a running app then you''ll need to help them get Rails up and running on their machine, maybe teach them to use SVN, etc. Much easier to say, "Hey I need X pages" and let them go. On 3/14/06, shinji kuwayama <shinji@kuwayama.com> wrote:> Here''s my preference -- start with a graphic designer who understands > the mechanics of HTML page layout, and have them produce flat comps (ie, > PSD files). Then the developer can take those and implement them as > HTML/working pages. > > I think this approach allows the designer to focus on design, rather > than worrying about technical details in the HTML -- presumably that''s > not their core competency anyway. It also saves the developer from > having to rewrite poor HTML. > > The prerequisite is making sure the designer and developer have a good, > close working relationship; breakdowns in the process usually come from > poor communication over design goals and technical limitations.This is the approach that I''ll be taking next time. The last project I worked on, I asked the designer up front if he could build the pages using CSS layouts, no tables. He said that wouldn''t be a problem. When he finished the design though, it had tables nested seven or eight layers deep! I would have been really pissed, but I loved the design, so I decided to just recode it myself. I don''t know HTML/CSS at all, so it took me about 8 hours to figure out how to do the layouts with CSS. I wasn''t pleased that I spent that time coding HTML, but I did learn a bit more about how to approach a project (either just get mockups as Shinji suggested, or make sure that the designer can actually write really clean HTML), and also have confidence that I can convert a design into clean HTML/CSS if necessary. Pat
> The markup should be strictly independent of the design! > > All the designer should need to do to the .rhtml files would > be to tweak class attributes and other minor changes for the > purposes of identifying particular divs and spans.As a designer, I whole-heartedly agree that all presentation should be in the CSS file(s). However, access to and the ability to *structure* the templates is just as important, in my opinion. For one thing, the more "advanced" table-less layouts -- rounded corners, for example -- require some <div>-juggling or <div>-itis, depending on your point-of-view, so having the ability to set-up the page structure like this is very helpful.
+1 on comments by Chris and Dean. CSS should be used *heavily* for the layout of the site... and yes, it get''s a wee bit tricky when you need to introduce rounded corners and other fancy workings. It''s funny that I just read this thread... because our designer finally sent me the HTML to integrate with, and it''s a bunch of static pages generated by ImageReady. Literally everything is an image, and hundreds of spacers are used everywhere. Help me... please... help me :) On 3/14/06, Dean Matsueda <dmatsueda@bsr.org> wrote:> > > The markup should be strictly independent of the design! > > > > All the designer should need to do to the .rhtml files would > > be to tweak class attributes and other minor changes for the > > purposes of identifying particular divs and spans. > > As a designer, I whole-heartedly agree that all presentation should be > in the CSS file(s). However, access to and the ability to *structure* > the templates is just as important, in my opinion. For one thing, the > more "advanced" table-less layouts -- rounded corners, for example -- > require some <div>-juggling or <div>-itis, depending on your > point-of-view, so having the ability to set-up the page structure like > this is very helpful. > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060314/f442c814/attachment-0001.html
My advice is to start from scratch with rails tags. Otherwise you will go insane. I had the exact same situation. You go mental on the div naming id''s alone. I started from scratch with my own CSS and div naming scheme. A lot of work but otherwise it will be a maintenance nightmare You will need a desiner that is prepared to code the rails way. And if he does he will find out for himself that its cool to do it like that. Good luck -- Posted via http://www.ruby-forum.com/.
I''m the developer in a two man dev team of which it''s me (experience rails programmer) and one other person (experience designer but still new to rails). We started with him creating mockups and then I went in and wired it up as an rhtml template for use in the application. As time has gone on, he''s seen what I''ve done and made changes to the view code himself based on what''s already there. It works great. He''s learning rhtml as he need to get things done. The rhtml templates are intuitive enough that most any designer can pick it up with a little time. On 3/14/06, Dylan Stamat <dylans@gmail.com> wrote:> > +1 on comments by Chris and Dean. > > CSS should be used *heavily* for the layout of the site... and yes, it > get''s a wee bit tricky when you need to introduce rounded corners and other > fancy workings. > > It''s funny that I just read this thread... because our designer finally > sent me the HTML to integrate with, and it''s a bunch of static pages > generated by ImageReady. Literally everything is an image, and hundreds of > spacers are used everywhere. > > Help me... please... help me :) > > > > > > On 3/14/06, Dean Matsueda <dmatsueda@bsr.org> wrote: > > > > > The markup should be strictly independent of the design! > > > > > > All the designer should need to do to the .rhtml files would > > > be to tweak class attributes and other minor changes for the > > > purposes of identifying particular divs and spans. > > > > As a designer, I whole-heartedly agree that all presentation should be > > in the CSS file(s). However, access to and the ability to *structure* > > the templates is just as important, in my opinion. For one thing, the > > more "advanced" table-less layouts -- rounded corners, for example -- > > require some <div>-juggling or <div>-itis, depending on your > > point-of-view, so having the ability to set-up the page structure like > > this is very helpful. > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060314/c5ed6110/attachment.html