From TIME magazine comes insight into what Ruby on Rails does:
To help build Basecamp, Campfire and the company's other core applications, [David] Hansson developed Ruby on Rails. It gives 37signals' software a consistent look: sleek, friendly and without the extraneous bells and whistles that plague much of the bloated software sold by larger companies.
True, I'm not a programmer but lets makes this clear, Ruby on Rails has absolutely nothing—zero, zip, zilch—to do with the look of applications and websites. Sorry TIME, you still need to hire designers to do that kind of work.
Join the fray by reading through and commenting at the end.
Talk about ignorance. That's just unbelievable!
This type of misinformation always bugs me. There's a lot of things Rails does; but it doesn't design for you.
On the bright side, I hear Ruby on Rails increases your profit by 27% in the first quarter of production alone. It's also been known to cure various diseases when the time is right.
D'oh
Ruby on Rails helped me with my tennis elbow.
Unfortunately, I think it also caused some ear wax buildup.
Ah wuz on crack, but Ruby on Rails set me straight. Now ah sell magazeen subscriptchuns at the Ah-95 auf-raimp.
Wow. Pretty pathetic reporting, there. I can appericiate the attempt to "put it in layman's terms," but damn -- not. even. close.
I guess this is what people are talking about when they say they are frustrated with clients not understanding what they are talking about. Thanks TIME for another proverbial nail in the coffin.
I was swamped in dept and I couldn't afford to make the monthly repayments; then Ruby on Rails consolidated all my accounts into one easy monthly repayment!!! Now I've got the financial security AND my hair is shiny and soft!!!!11ones
you still need to hire designers to do that kind of work....
Not to mention the need of a reporter with some level of technical knowledge.
> Not to mention the need of a reporter with some level of technical knowledge.
Oh, I thought Microsoft Word provided a consistent level of reporting.
Speaking as a programmer, Rails DOES help you achieve a higher level of consistency WITH your design. It has a kick ass templating system which makes it very simple to break down the visual elements into reusable pieces. As an example, all the freeware previews at the Iconfactory are done with one template.
The integration of AJAX into the framework also helps generate a consistent feel for an application.
Of course, all of this is for naught if there isn't a coherent visual design in the first place. But saying that Rails "gives software a consistent look" is a valid statement.
-ch
Ruby on Rails once successfully thwarted a Chuck Norris roundhouse.
Seriously though, Craig, RoR might affect the ease of implementation of your design, but if you're relying or even leaning on your programming language/style for a consistent look throughout your application, you're in serious trouble.
I read this article last night and said the same thing to my girlfriend. "Ruby on Rails = clean design? Somebody missed the boat".
Didn't 37 Signals get to see the article before it went to press? I would think they'd want to prevent that kind of crappy reporting about what they do.
> It has a kick ass templating system which makes it very simple to break down the visual elements into reusable pieces.
That's not exclusive to Rails. We've had that ever since includes became available through CGI in, what, 1995?
> Ruby on Rails once successfully thwarted a Chuck Norris roundhouse.
Yes but I heard that a year later Chuck Norris defeated Rails after he realized how to Get Real.
> Didn't 37 Signals get to see the article before it went to press? I would think they'd want to prevent that kind of crappy reporting about what they do.
Not very likely. After you're interviewed you don't hear from the publication until after it's gone to print.
Yes that scaffold.css is lovely!
Greg, that comment about CGI includes indicates that you don't really understand how important the Rails templating system is. It allows your code to FOLLOW a design rather than dictate it.
It's like saying that grid based designs aren't really new or important -- designers have been lining things up for years, right?
-ch
Yeah I'm not following here. I've never let code decitate anything I've designed. And, no, grid based design isn't new it's been around for quite some time.
Of course, all of this is for naught if there isn't a coherent visual design in the first place. But saying that Rails "gives software a consistent look" is a valid statement.
Yes, taken out of context of the article it is a valid statement. But to state it as the feature of Rails is certainly invalid. Additionally, templating isn't new. Breaking up code into reusable parts isn't new. Frameworks have been doing that for a long time.
Rails' design does encourage the DRY method of programming, but that's a technique, not a feature of Rails. You can write and use crappy code and templates in Rails if you want. It doesn't force you to do anything.
I'd have to agree, the programming has little or nothing to do with the design. On projects that need 'back end stuff' (whether that's CMS, shopping, or some other web app) I'm partnered with a company that is chock full of comp sci grads, serious gearheads with Masters degrees and such. They've had their own code libraries for web apps for a decade or more, so we can put stuff together like LEGO, but it's also very custom.
Anyway, I plan and design everything, right down to the back end admin side before we do any programming. The programming has zero impact on design. We design everything first, then the programming makes it happen. I've never had any experience other than programming following design. Isn't that just common sense? Kind of the same way a web design is finished in Photoshop before any coding begins (oops, that's Adobe Photoshop Imaging Software, I think).
I'm not a programmer, BTW, so I've probably used some terminology wrong, but my point is, I don't consider the programming much when designing. I'll check in with my programming guys to ask if some feature is possible, and it usually is, but that's about it.
I guess the answer is just that some tools make good work easier than others. A good designer can create great websites with Notepad on Windows, but how much more pleasant is it to use, for instance, Textmate on the Mac? Rails's template language, and its enforced separation of views into easily reusable components, is like a dream compared to clunky, messy crap like Smarty or, god forbid, PHP itself.
All this time I was led to believe talent played a role in designing a site - now I find out one has to learn RoR.
there's another problem with the statement that rails was developed to create basecamp, etc.
if i'm not mistaken, the framework was extracted from basecamp after the first iteration was finished.
-----
A good designer can create great websites with Notepad on Windows, but how much more pleasant is it to use, for instance, Textmate on the Mac
-----
A website is *designed* with a pencil and a piece of paper, and then the design is finished with a tool such as Photoshop. That's design. The above snippet is talking about coding. You don't design a website using Notepad or Textmate. You 'bring your design to life' with Notepad or Textmate, but those aren't design tools.
Am I wrong? Am I drinking too much in the afternoons?
Greg Paulhus,
This conversation is interesting, because I didn't realise I had a firm opinion on the matter until I read your response! I find that a design often iterates back and forth between Photoshop and the text editor -- being forced to confront real markup often exposes weaknesses in the original comp or opens up previously unconsidered opportunities. For the latest design I'm working on, I had a clear idea in my head of the layout, which I then wireframed in XHTML and basic CSS. I then took a screenshot to work over in Photoshop.
> A website is *designed* with a pencil and a piece of paper, and then the design is finished with a tool such as Photoshop. That's design.
Precisely.
@Nick
My opinion is that you start a design concept with pencil sketches, then move into Photoshop to completely finish all design elements. I might move into Photoshop pretty quickly, but it seems to me that an iterative process that moves too quickly into actual coding is a dangerous route that could waste a lot of production time.
I could also be too 'old school', having been working as a designer for close to 20 years now.
This discussion reminds me of a great Ray Bradury quote:
-----
"Put me in a room with a pad and a pencil and set me up against a hundred people with a hundred computers -- Ill out create every goddamn sonofabitch in the room."
- Ray Bradbury
-----
Please excuse the language. But it's a good point. I haven't found a tool yet that beats pencil and paper.
Yeah, but the pencil thing is a bit of a strawman. I guess I'm just more amazed that people think the design process STOPS with Photoshop. Of course it generally STARTS with pencil and paper. Visual design is only a small part of a web designer's job.
You can not limit yourself with code when designing a website (or any web application for that matter). Actually, design and UI should always be your main focus. Coding might bring some limitations, but if your developers are anything like the people I work with, they should enjoy the challenge.
Nick, I think we're just not using the word 'design' in the same way. What you're calling design is actually development. I mean, you could argue that *all work* is design, but when designers say 'design' they mean the visual look and feel, the UI, the aesthetic. Design does stop with Photoshop. Then the process of development or production begins. Are there 'design' decisions in the process of development? Sure. But that's not what we're talking about.
For me it's two phases: design and production (I'm not a developer: I don't program, currently). I design the user experience, which includes visual design, communication design, and interaction design, and then I put the design into production by converting from HTML to template code or cranking out the pages.
I have to admit - and this is just a personal reaction - that the rhetorical construct of "you call it x, but it is ACTUALLY y" is a faintly patronising one. I'm sure it wasn't intended. In this context, it's clear that 'design' is a word with complex and shifting connotations and neither of us should to assert that any particular meaning is denotative.
"should to assert?" Me fail English? That's unpossible! Sigh.
I'm only butting in because this is the second time I've heard the pencil-and-paper mantra put forward in the last hour, and it's kind of surprising to me. With CSS Zen Garden and others advancing markup as a design tool, and not just code, and considering the nature of the medium, it seems hard to maintain that design can be defined as a conceptual sketch, even if that sketch is very detailed and helpful.
If design stops at Photoshop, how is it, exclusively, web design? It may be indispensable to the process, but the attempt at precision is questionable. Does a clothing designer stop being a designer and start being a manufacturer when he stitches his creations together? Or is that also a part of the design process?
I'm only butting in because this is the second time I've heard the pencil-and-paper mantra put forward in the last hour, and it's kind of surprising to me. With CSS Zen Garden and others advancing markup as a design tool, and not just code, and considering the nature of the medium, it seems hard to maintain that design can be defined as a conceptual sketch, even if that sketch is very detailed and helpful.
If design stops at Photoshop, how is it, exclusively, web design? It may be indispensable to the process, but the attempt at precision is questionable. Does a clothing designer stop being a designer and start being a manufacturer when he stitches his creations together? Or is that also a part of the design process?
@Dan,
As I said previously, you could indeed consider all work to be design. And you're correct, there are many design decisions in the production stage. You could certainly say that it's design.
But I'm talking about visual design. And I'll still say that it's bassackwards to start designing a website with markup.
I get your point though. You could do only rough sketches and move into markup from there. Still, that leaves you open to an iterative nightmare because you haven't made all the design decisions before starting production. Perhaps that doesn't matter much, with markup as fast as it is these days, you'll waste some time, but maybe not enough to worry about.
Although, at what point do you get sign off from the client on the visual concept? What do you use to get that sign off if you've only got rough sketches and the client can come back at you once you're in production and say 'That's not what I thought it was going to look like, we need to change it', because the client only saw a conceptual sketch that was three-quarters finished. What then?
That's quite funny.
That's an excellent point, Greg. Hadn't given that enough weight.
Familiarity with CSS, though, and even experimental engagement with it, might lead to different design choices at the conceptual stage. And I think that's the point: not just that you can use markup to get your visual image on the page, but that markup can be a tool for designing the page to begin with. Not just technically, but creatively. Pencils think in lines, code thinks in layers, so to speak. (Not to say one precludes the other, just what it tends to.)
> Although, at what point do you get sign off from the client on the visual concept? What do you use to get that sign off if you've only got rough sketches and the client can come back at you once you're in production and say 'That's not what I thought it was going to look like, we need to change it', because the client only saw a conceptual sketch that was three-quarters finished. What then?
Careful, I've had clients try to come back on me after presenting them full-on, in depth comps. We're thinking of adding a puppet show to the design phase so as to act out what happens to clients if they don't pay attention to the design approval process.
> I've had clients try to come back on me after presenting them full-on, in depth comps.
I know, it's a problem for sure. I've had this happen (only a couple times), and without the finished comp and the client's signature on the design approval, I doubt I would have been able to charge extra for the new design work.
I'll have to think about adding a puppet show to my own process, or maybe a PowerPoint presentation with Muppets. 'Kermit says you have to pay extra if you change your mind after the design has been approved. Fozzie Bear agrees, it's only fair after all.'
HTML makes pretty colors.
@Greg Paulhus:
Currently attempting a transition from coder to designer, I often wondered why all the designers I worked with use Photoshop as their design tool of choice. Coming from a code background, I thought "wouldn't it be easier to use the building blocks (css+html) to start with?" But the more I transition, the more I see the pure designer's point of view. Whilst css+html is incredibly flexible, and a good css ninja can whip up incredible designs, Photoshop still wins with speed, power, and choice.
So I find myself gravitating to a pencil->Photoshop->css workflow. Unfortunately, I think too many designers stop at the Photoshop step, and fail to appreciate the limitations of web tech. "What, you mean I can't have my baby font in that color?"
I'm a bricks and mortar architect. and this discussion is a familiar one. Someone injected the term "visual designer" into the conversation. That is a term we have found useful in describing one who approaches design primarily from the visual side. I like CuRoi's comments about using all tools while designing. Remember that in my world, we stop at some point and give it to others who build our model, in real space and time. At that point, there are still design decisions that have to be made and remade, but the focus is on producing rather than designing. In the web, you are designing and then producing, but the character of the thing is similar all the way through.