Designer rates - weigh in?

[scottmotte]

Anyone willing to weigh in on their current rates? I think it could be
helpful in matching up designers and coders.

For me:

I'm a slashie (programmer/designer) at $60/hr. http://spitfiresky.com/portfolio.html

My ruby skills are growing but I'm certainly not top tier. I haven't
contributed to any open source projects.

My design skills are ok. I prefer 960.gs and I use sites like
cssremix.com for inspiration to piece together my own designs.

I am increasingly more of a programmer. I prefer it that way. My
programming skills are increasingly growing at a faster rate when
compared to my design skills. Just recently I worked with a designer
jointly - rwldesign.com.

[jeromegn]

I feel like I'm still building a reputation, so I'm offering my
services for a somewhat low price.

I charge $40/hour freelancing as a "user experience designer".

I'm in a similar situation as yours. Currently developing some Ruby on
Rails thingies, I know how it all works (apart from the testing part,
which I know is essential, working on that!) and I've already pushed
an app to production just for fun... so if I was to develop some Rails
backend, I'd charge lower than my UX fee since I'm not all that great
yet with it. Also looking forward participating in an open source
project.

The grid system is essential ;) I'm not sure if you were talking about
the CSS they provide or just the concept and the PSD templates... I'm
not too sure about the CSS, I sort of like throwing my own.

Jerome.

On 12 fév, 02:47, scottmotte <sc...@scottmotte.com> wrote:
> Anyone willing to weigh in on their current rates? I think it could be
> helpful in matching up designers and coders.
>
> For me:
>

> I'm a slashie (programmer/designer) at $60/hr.http://spitfiresky.com/portfolio.html

[khiltd]

On Feb 11, 11:47 pm, scottmotte <sc...@scottmotte.com> wrote:
> rwldesign.com.

How many browsers have you looked at this in?

[scottmotte]

@jerome - I was talking about the css they provide. I've really
enjoyed their grid system.

@khiltd - just firefox and safari on mac. why is it bad? he's recently
adopted 960.gs though. he worked with me on my spitfiresky.com
branding and site.

[Kennon Ballou]

I had never heard of 960.gs before, but how is this any better than just
using tables for layout? Looking at the example html for 960.gs, it
seems like you have layout-specific information in every single div.

Now I know that it might not be 100% necessary to have "complete"
semantic separation (at some point for some designs it's just not
possible), but this seems to be a major step backwards, since there ARE
a whole lot of advantages in keeping the content as separate as possible
from the layout/design. CSS might be more flexible at times than tables,
but using this approach would seem to have one of the same major
drawbacks as tables.

Am I missing something here or do I not understand 960.gs properly?

| Kennon Ballou
| Angry Turnip, Inc.

[scottmotte]

I'd encourage you to try it out. It really cut down my time to put
together a layout. But to each his own.

Tables are ugly and messy to manage. And if you work with another
developer it's almost impossible to find out what he was trying to do
with the layout. I hated navigating through and maintaining tables. It
was a nightmare. This is nothing like that. Navigating the markup and
maintaining it is easier than anything I've found because it's
essentially a css framework of convention over configuration (similar
to rails).

"ARE a whole lot of advantages in keeping the content as separate as
possible from the layout/design."

- What are they?
- I have not found this true in the real world. Every time I've had to
do a redesign it's involved changing more than just the css.
- The only time I really see it useful is when you have a service
(shopify comes to mind) allowing your users to quickly change themes.
And in that case, I would not recommend using 960.gs
- wait, there's a 2nd time too. web based iphone apps that use a style
sheet change based on the viewport meta tag.

I am not a top notch css guy though. I got tired of struggling/
tinkering with layouts in different browsers, etc. This makes creation
of a layout so enjoyable/productive for me and allows me to just 'get
things done'.


And in real world experience I have not found actually found

[Fisher]

I think the grid systems are interesting.

Have yet to use them, but I found this the other day, incorporates some of the advantages of a few major grid systems all in one.

http://bluetrip.org/

-F

[Kyle Neath]

Personally I love the 960.gs photoshop templates — I've been using
them quite extnsively for a while.

As for the CSS, I just don't see the point. It takes me about a minute
to create a column base and another maybe 15 seconds or so to create
new variations. I'd rather have semantic names for my elements and
not inherit cruft from libraries.

- Kyle

[Chris Eppstein]

Regarding the use of semantic markup and avoiding presentational class
names:

If you're building a small site with just a few pages or a site that's
not going to require daily maintenance and/or team collaboration, then
adhering to semantic markup is just a way to geek out and show that
you can adhere to best practices to prove you can do it when it
matters.

But speaking from experience, using a grid framework like blueprint,
960, bluetrip, etc really falls apart when you get into any product of
sufficient complexity. Here's some of the problems I encountered
working on version 1.0 of caring.com which was built on blueprint:
Using grids within partials makes them less reusable
Using grids within your templates limits your layout choices to only
those layouts designed to work with specific grid widths.
Blueprint specific: Gets into my div.last class which I like to use
for non-grid uses.
Requires the use of extra markup because the grids only apply to div
elements or because you've built a flexible partial and need to
constrain it to a grid.
Alternate stylesheets and theming are constrained to just changing
colors, fonts, etc. They can't really get into the layout of the page.
My solution to this was different from most. Instead of stopping to
use these frameworks, I ported them to Sass and implemented all of
their classes as Sass mixins. This evolved into the compass framework:
http://compass-style.org/ With it, you can quickly apply grid styles
to your semantic markup.

To the point that grids aren't that complicated and you can reproduce
it:

Sure, you might have grids memorized and can write the CSS by heart. I
don't know that most can, but it's not really that complicated once
you know the strategy. In just a few minutes, you can probably
reproduce it from first principles and get it working in your primary
browser. But here's the thing: browsers are evolving and the grid
frameworks should be in charge of working out the browser support
issues. When IE9 is released maybe it will break things, upgrading
your grid framework instead of running around finding all of the
broken css, is going to be a time saver.

Programmers have realized for a long time that creating abstractions
and building on those abstractions is a huge time saver for both the
initial implementation as well as the long term maintenance. Grid
frameworks give you abstractions that more closely match how you are
thinking. Also they make some choices for you and liberate you from
having to decide on the nitty gritty details -- if you've bought into
rails, then you've bought into the philosophy whether you know it or
not.

Also it's easier to understand original intent when you use
abstractions. I would argue that (I'm going to slip into some sass
here so I don't have to mix html and css):

#sidebar
+column(5)
+append(1)

is easier to understand and maintain than:

#sidebar
float: left
width: 190px
margin-right: 10px
padding-right: 40px

Though I wouldn't argue that it's easier to debug. But again, that
shouldn't be your job -- that's the job of the framework maintainer.
It's your job to report bugs :-)

-Chris

[Kyle Neath]

Honestly, I've got to disagree with your bottom half 100% here.

If I want to put some content in a sidebar, does it make more sense to
put it in "append(1)" or in "#sidebar"?

Semantic markup isn't about geeking out, it's about writing code that
means something. Think of OO programing. Do we call our objects
ObjectWithFiveProperties and subclass that from
ObjectWithFivePropertiesBase just so we don't have to write out 5
properties to an object named Person? We use semantic naming so that
we code in human speak, not in robot speak.

With regards to grid browser compatibility... honestly, it's 11 lines
of CSS and you have columns that work flawlessly in IE6-8, Firefox,
Safari, Opera, everything. (http://warpspire.com/tipsresources/web-production/css-column-tricks/
). These frameworks only serve to add code you didn't write and don't
understand (and inherit bugs from).

This may sound condescending, but ever since we stopped supporting
IE5.5 when our box models coalesced and you're struggling with
columns, you're just doing it wrong. CSS columns are dead easy now.

- Kyle

[khiltd]

On Feb 13, 12:26 am, scottmotte <sc...@scottmotte.com> wrote:
> @khiltd - just firefox and safari on mac. why is it bad? he's recently
> adopted 960.gs though. he worked with me on my spitfiresky.com
> branding and site.

If that was intentional then I'd tend to say your pricing is rather
aggressive. Must be a small town.

[Chris Eppstein]

Hi Kyle,

I think somehow I didn't communicate my intention well because I think
we mostly agree with each other. Perhaps you're not familiar with sass
syntax?

I think of OO programming all the time, I'm our site architect ;-) But
sometimes, I just write a script to get a job done today and then I
discard it -- I didn't need OOP, just some looping and iterating.
Those who know me, know I'm a huge proponent of semantic markup and my
compass framework is built to enable it. But I don't take the stance
that semantic markup should be used in all cases, because sometimes
you just need to throw something together (think prototyping, or a
quick client site on the cheap).

To your point that grid/browser compatibility is pretty stable, I
agree 100%. I think we've got the box model figured out now. But that
doesn't mean there are other aspects of web browsers that aren't
changing. Frameworks often do a whole lot more than set up a grid,
they reset your styles, setup your typography, and my framework allows
you to go even further. These are things that can break over time and
by using a framework, you reap the benefits of a community of users
sharing a common code-base and working through the issues together.

If you're inheriting bugs from a particular framework, either it's not
well maintained, you're not staying up to date with their releases. As
with any build vs. buy decision, you should take this into account.
Another thing to be aware of is that some frameworks don't lend
themselves well to being easily updated (e.g. frameworks that generate
a bunch of css for you based on some input gathered via a form). I
wouldn't recommend those as anything more than a way of getting
started quickly.

Chris

> >http://compass-style.org/With it, you can quickly apply grid styles

[Matt Williams]

On Fri, 2009-02-13 at 10:35 -0800, Chris Eppstein wrote:
> Regarding the use of semantic markup and avoiding presentational class
> names:
>
> If you're building a small site with just a few pages or a site that's
> not going to require daily maintenance and/or team collaboration, then
> adhering to semantic markup is just a way to geek out and show that
> you can adhere to best practices to prove you can do it when it
> matters.
>
> But speaking from experience, using a grid framework like blueprint,
> 960, bluetrip, etc really falls apart when you get into any product of
> sufficient complexity.

Actually, as I understand it, blueprint was based on a system developed
for/by a newspaper which made numerous updates daily.

I'd argue that such a site has a level of complexity. Yes, the pages
tend to be laid out similarly -- at least section by section, however,
the systems were developed to allow for rapid posts/changes to the
layout of the site (like Extra-Extra-Read all about it items).

I'm not sure I agree with your feeling that it is not able to handle
complex products.

Perhaps, like any tool, if you're trying to use it for something it was
not designed to do -- the "If all you have is a hammer...."...

Matt

[Chris Eppstein]

I think I was pretty specific in the ways that using presentational
class names that come with most grid frameworks can come back to bite
you. Frequency of updates was not one of them. I defined complexity in
this case as having large numbers of partials, templates, and layouts
and wanting to mix and match them. A newspaper is churning content
over at a very rapid pace and the a lot of the html that they write is
pretty short-lived -- so long term maintainability costs are not as
much of a consideration.

If you're putting non-semantic class names in your html that you're
trying to reuse, especially class names that are targeting layout like
blueprint and 960.gs, you're in for some problems. There are best
practices that can be followed to avoid them, but they're not as easy
as just writing good, unobtrusive stylesheets to begin with.

I'm not arguing against using frameworks, I'm just trying to help
folks understand the trade-offs that exist if they do. My opinion is
that the frameworks that we have today are pretty darn useful if
you're willing to make some long term maintainability tradeoffs. If
you're using Sass, most of these can be worked around, but I'm sure
you'll hear folks tell you that you're just trading those problems for
others. For what its worth, CSS3 is shaping up to have many of the
features Sass has right now for the low, low cost of a compilation
step.

Chris

[Justin French]

There's plenty of grey areas here, but I think the fact remains that
if you use tables as a purely visual layout tool, you're using
elements that are intended to represent tabular data, rather than
elements that are intended to represent non-semantic divisions of the
content.

Better? Worse? That's a conversation that never really ends well :).
It's really up to the owners if the site/document, but I know what my
preferences are.

Justin French

On 13/02/2009, at 10:38 PM, Kennon Ballou <ken...@angryturnip.com>
wrote:

[NoveltyVotary]

Sorry, what was the topic of this post anyways? I've forgotten.

I'm charging $35/h for rails/graphic stuff. I don't have too much of a
portfolio as of yet as I've only been doing it casually for the
past... 7 years.