Forum: Ruby on Rails Programming with designers in mind

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
BA Baracus (Guest)
on 2006-05-03 18:56
(Received via mailing list)
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.
Carl-Johan Kihlbom (Guest)
on 2006-05-03 18:56
(Received via mailing list)
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
Tim Case (Guest)
on 2006-05-03 18:56
(Received via mailing list)
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
Robby Russell (Guest)
on 2006-05-03 18:56
(Received via mailing list)
On Apr 30, 2006, at 12:32 PM, BA Baracus wrote:

> line. At
>
> 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]
Conrad Taylor (Guest)
on 2006-05-03 18:56
(Received via mailing list)
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
A23b9d78d4d80732b9dc94c5bbedbf76?d=identicon&s=25 Alex P. (alex789)
on 2006-05-03 18:59
(Received via mailing list)
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
Fcf4895707e11fdfc91a71b87bd6e33e?d=identicon&s=25 Gravy F. (gravyface)
on 2006-05-03 18:59
(Received via mailing list)
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?
Giles Bowkett (Guest)
on 2006-05-03 19:00
(Received via mailing list)
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
BA Baracus (Guest)
on 2006-05-03 19:05
(Received via mailing list)
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.
Conrad Taylor (Guest)
on 2006-05-03 19:05
(Received via mailing list)
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>
91577d00348e23566f04e26438ace241?d=identicon&s=25 Curtis S. (cuspendlove)
on 2006-05-03 19:05
(Received via mailing list)
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.
Jim Gay (Guest)
on 2006-05-03 19:06
(Received via mailing list)
Giles Bowkett (Guest)
on 2006-05-03 19:06
(Received via mailing list)
On 5/2/06, Curtis <cuspendlove@gmail.com> wrote:
> 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
Jana Ballard (Guest)
on 2006-05-03 20:00
(Received via mailing list)
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:

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

Jana Ballard
Software Developer
206.268.5435
-+-+-+-+-+-+-+-+-+-+-+
Greater Good Network
One Union Square
600 University Street
Suite 1000
Seattle, WA 98101
This topic is locked and can not be replied to.