Gents, We''re hard at work on a new Rails app. We''re a small group of developers...not a web designer in the bunch. We know CSS enough to be dangerous, but we shy away from the "softer" skills (all the while envious of those with that capability). We intend to grow our application in terms of functionality, but I need to make sure we keep an eye towards "prettying it up" down the line. At some point, we''ll hire a real live designer to improve the look and feel. With this in mind, what should a Rails programmer do to make sure that his application lends itself to the work of a talented designer downstream? Is it enough to assign and id and class to every html entity, or are there other things one should keep in mind? The programming gods will reward you for any information you provide, and I will be eternally grateful. B.A. -- Posted with http://DevLists.com. Sign up and save your mailbox.
Aaaah! You absolutely should *not* add a class and id to *every* element. Knowing where to place id and class is a skill that you develop over time. You don''t need as many of them as you think. On good read on the subject is Joshuink''s tutorail "Avoiding Classitis": /http://joshuaink.com/blog/330/avoiding-classitis / CJ On 30 Apr 2006 19:32:49 -0000, BA Baracus <devlists-rubyonrails@devlists.com> wrote:> Gents, > > We''re hard at work on a new Rails app. We''re a small group of > developers...not a web designer in the bunch. We know CSS enough to be > dangerous, but we shy away from the "softer" skills (all the while > envious of those with that capability). > > We intend to grow our application in terms of functionality, but I need > to make sure we keep an eye towards "prettying it up" down the line. At > some point, we''ll hire a real live designer to improve the look and feel. > > With this in mind, what should a Rails programmer do to make sure that > his application lends itself to the work of a talented designer > downstream? Is it enough to assign and id and class to every html > entity, or are there other things one should keep in mind? > > The programming gods will reward you for any information you provide, > and I will be eternally grateful. > > B.A. > -- > Posted with http://DevLists.com. Sign up and save your mailbox. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
BA, As a developer I understand the temptation to grow the app in functionality and then adding a designer later to pretty it up, but after seeing that developers tend to build the worst user interfaces, that lead to failed projects because the people who use those interfaces get confused by developer logic, I finally came to the conclusion that not having a designer from the get go is a big mistake. I''ve found that I develop much better applications that people actually want to use if I concentrate on the UI first and the functionality second. I know this sounds counter-intuitive to a developer and it took me a long time to accept it, but simple, sexy, usable UI''s contribute to selling software more than large feature sets do. I understand if you can''t find a designer (a good one is hard to come by), we still have times where I''m ahead of the designer and start building things out according to an idea in my head, and then the designer alters afterwards. Sometimes this works, sometimes it doesn''t, the ideal is to have the design in mind before you start coding. If you want to build a rails app with a designer to add later (and understand that this is less than ideal), first try to think from the UI and work your way in, second make liberal use of partials and layouts so that your UI layer is somewhat modular and can be rearranged more flexibly, and as Carl-Johan alluded to above don''t worry about classes and ID''s, designers have their own ideas about how they like to arrange things, it tends to be a personal aesthetic of the designer and can''t be predicted. 2c, Tim Case tim@karmacrash.com On 4/30/06, Carl-Johan Kihlbom <kihlbom@gmail.com> wrote:> Aaaah! You absolutely should *not* add a class and id to *every* > element. Knowing where to place id and class is a skill that you > develop over time. You don''t need as many of them as you think. > > On good read on the subject is Joshuink''s tutorail "Avoiding > Classitis": /http://joshuaink.com/blog/330/avoiding-classitis > > / CJ > > On 30 Apr 2006 19:32:49 -0000, BA Baracus > <devlists-rubyonrails@devlists.com> wrote: > > Gents, > > > > We''re hard at work on a new Rails app. We''re a small group of > > developers...not a web designer in the bunch. We know CSS enough to be > > dangerous, but we shy away from the "softer" skills (all the while > > envious of those with that capability). > > > > We intend to grow our application in terms of functionality, but I need > > to make sure we keep an eye towards "prettying it up" down the line. At > > some point, we''ll hire a real live designer to improve the look and feel. > > > > With this in mind, what should a Rails programmer do to make sure that > > his application lends itself to the work of a talented designer > > downstream? Is it enough to assign and id and class to every html > > entity, or are there other things one should keep in mind? > > > > The programming gods will reward you for any information you provide, > > and I will be eternally grateful. > > > > B.A. > > -- > > Posted with http://DevLists.com. Sign up and save your mailbox. > > _______________________________________________ > > 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 >
On Apr 30, 2006, at 12:32 PM, BA Baracus wrote:> Gents, > > We''re hard at work on a new Rails app. We''re a small group of > developers...not a web designer in the bunch. We know CSS enough to be > dangerous, but we shy away from the "softer" skills (all the while > envious of those with that capability). > > We intend to grow our application in terms of functionality, but I > need > to make sure we keep an eye towards "prettying it up" down the > line. At > some point, we''ll hire a real live designer to improve the look and > feel. > > With this in mind, what should a Rails programmer do to make sure that > his application lends itself to the work of a talented designer > downstream? Is it enough to assign and id and class to every html > entity, or are there other things one should keep in mind? > > The programming gods will reward you for any information you provide, > and I will be eternally grateful. > > B.A.This is a common mindset of web developers. "Let''s build the application and make it look prettier later." If I can offer any advice, think of it the other way around. Get the *talented designer* involved as soon as possible. Let the design help guide your project down the right path, rather than be an after thought. Thinking about it and addressing that it is a need in your project is a step in the right direction, but it''s been my experience that the sooner you get the design, wireframes, html prototypes put in place, the quicker the rest of the application will manifest during development. Otherwise, you''re almost guaranteed to have a stage where you''re rushing the design and the new design requires some slight functionality change. If design and development are to share responsibility in the success of the project, they should also have the same opportunities to influence it. My two cents... Robby Robby Russell Founder & Executive Director PLANET ARGON, LLC Ruby on Rails Development, Consulting & Hosting www.planetargon.com www.robbyonrails.com +1 503 445 2457 +1 877 55 ARGON [toll free] +1 815 642 4968 [fax]
Hi, it''s clear to me that you should be able to do the following as a programmer to hand-off to your designer: o Mock-Up of what happens on a single screen as well as the transitions between screens on an event o Next, I agree with most of Tim''s comments of having a designer early on. However, I don''t think that designer or programmer should impact the productivity of the other. Rails uses the MVC of creating applications. Thus, it would be the designer role to design these views and layouts for the appliction. Next, the programmer would responsible for generating models and the controllers. Also, they would be responsible for providing the logic within the views. Lastly, the designer and programmer can work together refine the UIs. -Conrad On 4/30/06, Tim Case <tcrails1@gmail.com> wrote:> BA, > > As a developer I understand the temptation to grow the app in > functionality and then adding a designer later to pretty it up, but > after seeing that developers tend to build the worst user interfaces, > that lead to failed projects because the people who use those > interfaces get confused by developer logic, I finally came to the > conclusion that not having a designer from the get go is a big > mistake. > > I''ve found that I develop much better applications that people > actually want to use if I concentrate on the UI first and the > functionality second. I know this sounds counter-intuitive to a > developer and it took me a long time to accept it, but simple, sexy, > usable UI''s contribute to selling software more than large feature > sets do. > > I understand if you can''t find a designer (a good one is hard to come > by), we still have times where I''m ahead of the designer and start > building things out according to an idea in my head, and then the > designer alters afterwards. Sometimes this works, sometimes it > doesn''t, the ideal is to have the design in mind before you start > coding. If you want to build a rails app with a designer to add later > (and understand that this is less than ideal), first try to think from > the UI and work your way in, second make liberal use of partials and > layouts so that your UI layer is somewhat modular and can be > rearranged more flexibly, and as Carl-Johan alluded to above don''t > worry about classes and ID''s, designers have their own ideas about how > they like to arrange things, it tends to be a personal aesthetic of > the designer and can''t be predicted. > > 2c, > > Tim Case > tim@karmacrash.com > > > > On 4/30/06, Carl-Johan Kihlbom <kihlbom@gmail.com> wrote: > > Aaaah! You absolutely should *not* add a class and id to *every* > > element. Knowing where to place id and class is a skill that you > > develop over time. You don''t need as many of them as you think. > > > > On good read on the subject is Joshuink''s tutorail "Avoiding > > Classitis": /http://joshuaink.com/blog/330/avoiding-classitis > > > > / CJ > > > > On 30 Apr 2006 19:32:49 -0000, BA Baracus > > <devlists-rubyonrails@devlists.com> wrote: > > > Gents, > > > > > > We''re hard at work on a new Rails app. We''re a small group of > > > developers...not a web designer in the bunch. We know CSS enough to be > > > dangerous, but we shy away from the "softer" skills (all the while > > > envious of those with that capability). > > > > > > We intend to grow our application in terms of functionality, but I need > > > to make sure we keep an eye towards "prettying it up" down the line. At > > > some point, we''ll hire a real live designer to improve the look and feel. > > > > > > With this in mind, what should a Rails programmer do to make sure that > > > his application lends itself to the work of a talented designer > > > downstream? Is it enough to assign and id and class to every html > > > entity, or are there other things one should keep in mind? > > > > > > The programming gods will reward you for any information you provide, > > > and I will be eternally grateful. > > > > > > B.A. > > > -- > > > Posted with http://DevLists.com. Sign up and save your mailbox. > > > _______________________________________________ > > > 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 > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Carl-Johan Kihlbom wrote:> Aaaah! You absolutely should *not* add a class and id to *every* > element. Knowing where to place id and class is a skill that you > develop over time. You don''t need as many of them as you think.Why not? What''s the danger of a few extra classes? Will the code be harder to maintain? Will the page rendering be slower? I know that avoiding extra classes and ids is conventional wisdom with every CSS purist out there but to me the arguments seem to have more to do with aesthetics than with pragmatism. alex
On 5/2/06, Polite <m4@polite.se> wrote:> Carl-Johan Kihlbom wrote: > > Aaaah! You absolutely should *not* add a class and id to *every* > > element. Knowing where to place id and class is a skill that you > > develop over time. You don''t need as many of them as you think. > Why not? What''s the danger of a few extra classes? Will the code be > harder to maintain?Yes. When you''re assigning classes and ids to every element, chances are you''re not using inheritance like you should be -- if you need that level of specificity on all of your elements, then something is either wrong with your markup structure or you have redundancy in your CSS. Now, obviously there are some exceptions -- I think it''s better to *strive* for less classes and ids than to make this a rigid rule -- nothing is black and white.>From experience, when I see markup with lots of unnecessary classes,usually it''s because the class names describe the class values (i.e. <div class="red">) and not the document structure (<div class="alert">) so when .red { color: red; } is ported to some locality where red is not the dominant "warning" color, and it becomes .red {color: green;} you now have a misleading representation of the style. On a few pages? not a big deal; embedded in a huge content repository? different story.> I know that avoiding extra classes and ids is conventional wisdom with every CSS > purist out there but to me the arguments seem to have more to do with > aesthetics than with pragmatism.Aesthetics, in as far as readability is concerned, is very important in my opinion -- you wouldn''t name your variables in an inconsistent and obtuse way, would you?> alex > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
My advice would be to get Jeffrey Zeldman''s book "Designing with Web Standards." Do everything in a highly structured way and then just attach the CSS to it later. The more you conform to outline-based HTML, rather than appearance-based HTML, the better off you''ll be when time comes to add design. Using a pure outline structure makes it pretty easy to adapt the CSS to anything you want. Check out csszengarden.com, it rocks. -- Giles Bowkett http://www.gilesgoatboy.org On 5/2/06, GravyFace <gravyface@gmail.com> wrote:> On 5/2/06, Polite <m4@polite.se> wrote: > > Carl-Johan Kihlbom wrote: > > > Aaaah! You absolutely should *not* add a class and id to *every* > > > element. Knowing where to place id and class is a skill that you > > > develop over time. You don''t need as many of them as you think. > > Why not? What''s the danger of a few extra classes? Will the code be > > harder to maintain? > > Yes. > > When you''re assigning classes and ids to every element, chances are > you''re not using inheritance like you should be -- if you need that > level of specificity on all of your elements, then something is either > wrong with your markup structure or you have redundancy in your CSS. > Now, obviously there are some exceptions -- I think it''s better to > *strive* for less classes and ids than to make this a rigid rule -- > nothing is black and white. > > >From experience, when I see markup with lots of unnecessary classes, > usually it''s because the class names describe the class values (i.e. > <div class="red">) and not the document structure (<div > class="alert">) so when .red { color: red; } is ported to some > locality where red is not the dominant "warning" color, and it becomes > .red {color: green;} you now have a misleading representation of the > style. > On a few pages? not a big deal; embedded in a huge content repository? > different story. > > > I know that avoiding extra classes and ids is conventional wisdom with every CSS > > purist out there but to me the arguments seem to have more to do with > > aesthetics than with pragmatism. > > Aesthetics, in as far as readability is concerned, is very important > in my opinion -- you wouldn''t name your variables in an inconsistent > and obtuse way, would you? > > > alex > > _______________________________________________ > > 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 >
On Sunday, April 30, 2006, at 1:30 PM, Robby Russell wrote:>If I can offer any advice, think of it the other way around. Get the >*talented designer* involved as soon as possible.Thanks Robby. The problem is, where does one go to find said designer? I have programming contacts out the proverbial wazoo...but I don''t run with the designer crowd. I''d be happy to bring one on, but where can one find quality designers willing to work on promises and possibilities? B.A. -- Posted with http://DevLists.com. Sign up and save your mailbox.
Hey BA, the best way to locate designers is via their work (i.e. websites). This is exactly what I did on a current project because I simply liked this designers work. BTW, this person was from csszengarden.com. Also, you can simply type in the following or combination into google.com: website designer Good luck, -Conrad On 2 May 2006 23:19:55 -0000, BA Baracus <devlists-rubyonrails@devlists.com> wrote:> > > On Sunday, April 30, 2006, at 1:30 PM, Robby Russell wrote: > >If I can offer any advice, think of it the other way around. Get the > >*talented designer* involved as soon as possible. > > Thanks Robby. The problem is, where does one go to find said designer? I > have programming contacts out the proverbial wazoo...but I don''t run > with the designer crowd. I''d be happy to bring one on, but where can one > find quality designers willing to work on promises and possibilities? > > B.A. > -- > Posted with http://DevLists.com. Sign up and save your mailbox. > _______________________________________________ > 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/20060502/b963388e/attachment.html
On 5/2/06, Giles Bowkett <gilesb@gmail.com> wrote:> My advice would be to get Jeffrey Zeldman''s book "Designing with Web > Standards." Do everything in a highly structured way and then just > attach the CSS to it later. The more you conform to outline-based > HTML, rather than appearance-based HTML, the better off you''ll be when > time comes to add design. Using a pure outline structure makes it > pretty easy to adapt the CSS to anything you want. Check out > csszengarden.com, it rocks.:: blink :: Wow, this does rock. The flexibility and power would easily allow any designer worth his salt a chance to mark that sucker up with a stylesheet. You could even do the "one stylesheet to rule each season" stuff that you occasionally get from clients. Brilliant. This could even flow over a bit into the "how to replace components" issue that I''ve been struggling with lately. A good way to utilize patials to create "sidebars" or "dashboards" or such... Let it generate the sucker with a partial and if it''s not suppose to be displayed, cancel the display with CSS. It''s maybe not a perfect solution, but is still probably faster overall that trying components.
http://wiki.rubyonrails.org/rails/pages/AvailableForHire On May 2, 2006, at 19:19, BA Baracus wrote:> > On Sunday, April 30, 2006, at 1:30 PM, Robby Russell wrote: >> If I can offer any advice, think of it the other way around. Get the >> *talented designer* involved as soon as possible. > > Thanks Robby. The problem is, where does one go to find said > designer? I > have programming contacts out the proverbial wazoo...but I don''t run > with the designer crowd. I''d be happy to bring one on, but where > can one > find quality designers willing to work on promises and possibilities? > > B.A.
On 5/2/06, Curtis <cuspendlove@gmail.com> wrote:> On 5/2/06, Giles Bowkett <gilesb@gmail.com> wrote: > > My advice would be to get Jeffrey Zeldman''s book "Designing with Web > > Standards." Do everything in a highly structured way and then just > > attach the CSS to it later. The more you conform to outline-based > > HTML, rather than appearance-based HTML, the better off you''ll be when > > time comes to add design. Using a pure outline structure makes it > > pretty easy to adapt the CSS to anything you want. Check out > > csszengarden.com, it rocks. > > :: blink :: Wow, this does rock. The flexibility and power would > easily allow any designer worth his salt a chance to mark that sucker > up with a stylesheet. You could even do the "one stylesheet to rule > each season" stuff that you occasionally get from clients. Brilliant. > > This could even flow over a bit into the "how to replace components" > issue that I''ve been struggling with lately. A good way to utilize > patials to create "sidebars" or "dashboards" or such... Let it > generate the sucker with a partial and if it''s not suppose to be > displayed, cancel the display with CSS. It''s maybe not a perfect > solution, but is still probably faster overall that trying components.Bit of a threadjack but yeah it does rock. Have a look at the code, it''s pathetically simple really. Or read Zeldman''s book, it''s brilliant. All you do is make a clean, logical separation between the structure of your content and the way it looks. One stylesheet per season, that''s slacker mode. ;-) In the Praggies'' book "Rails Recipes" there''s a thing about how you can set it up for one stylesheet per user, but realistically, you could easily have one stylesheet per session. With the exception of the graphics, everything else in a stylesheet could be auto-generated. It wouldn''t actually be **that** hard to write something which could divvy the page up into little boxes and choose color schemes automatically. Of course it would be almost completely pointless, too, but who needs a reason?. -- Giles Bowkett http://www.gilesgoatboy.org
I highly suggest finding talented designers through AIGA - it''s a professional association for designers - http://www.aiga.org/ The website has a lot of resources for people trying to find a designer - you can view their resumes and portfolios through the site. On May 2, 2006, at 6:37 PM, Jim Gay wrote:> http://wiki.rubyonrails.org/rails/pages/AvailableForHire > > On May 2, 2006, at 19:19, BA Baracus wrote: > >> >> On Sunday, April 30, 2006, at 1:30 PM, Robby Russell wrote: >>> If I can offer any advice, think of it the other way around. Get the >>> *talented designer* involved as soon as possible. >> >> Thanks Robby. The problem is, where does one go to find said >> designer? I >> have programming contacts out the proverbial wazoo...but I don''t run >> with the designer crowd. I''d be happy to bring one on, but where >> can one >> find quality designers willing to work on promises and possibilities? >> >> B.A. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/railsJana Ballard Software Developer 206.268.5435 -+-+-+-+-+-+-+-+-+-+-+ Greater Good Network One Union Square 600 University Street Suite 1000 Seattle, WA 98101