How do you develop starting from design

[dnagir]

Hi,

I am just wondering how you guys deal with working from having UI
design to the actual Rails implementation?
(e.g.: 37signals - Interface First)

Sometimes we get the design of a web site from a "professional
designer" which (in 99.999%) of cases looks very nice and usable.
(And way better that I could possibly come up with).

Unfortunately such designs often do not follow a lot of Rails
conventions (REST is ignored, Flash messages are not used, Validation
errors presented in an absolutely different way etc).

This is often a barrier to using some Rails goodness (for example,
form builders - formtastic, simple_form).

So I, as a developer, either have to change the design bits to fit
into the Rails conventions or try to live with the design as-is.

Unfortunately I am pretty bad at UI design and prefer to trust the
designer.

What are your opinions on that?


Thanks,
Dima.

[Michael Gall]

I think the only way to manage it is be involved throughout the design
process. I make sure they realise that there are certain UI elements
that are important and they should be sure to include them in their
mockups. I've found that most designers just brush over error messages
and notification panes (read: flash) yet they are some of those little
polishes that turn a nice looking app into something that feels right.

Cheers,

Michael

> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-...@googlegroups.com.
> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
>
>

--
Checkout my new website: http://myachinghead.net
http://wakeless.net

[Jason Crane]

I've never had a problem with designers glossing over features, or polish items because the designers have worked from an interaction specification detail level set of wireframes.

That being said, all I'm doing is pushing the problem described further down the chain to the interaction designers - however, boxes and arrows are much more easily approachable to discuss by coders who think they can't design (yes, you can).

So I'd suggest getting involved when the site is wireframed, and as Michael suggested get involved during design.

J

[Myles Eftos]

If I'm working on a brochureware site, or a really small app, I send the app back with notes on what needs to be polished, then either get the designer to implement the changes in CSS or send me back a PSD. The trick is to make it clear to the designer ahead of time that you'll do this, so they know to leave some time for this step.

For large apps, it's all about iterations.

----------------------------------------------
Myles Eftos
Mobile: +61-409-293-183

MadPilot Productions - Created to be Different
URL: http://www.madpilot.com.au
Phone: +618-6424-8234
Fax: +618-9467-6289

Try our time tracking system: 88 Miles!
http://www.88miles.net

[Tim Lucas]

Rather than you needing to get involved during design I'd flip it and say get the designer involved during build stage, actually working on
front-end code too. Pretty soon they'll be doing Rails-friendly design work, and they can see the holes in the design and plug them or modify the design as necessary. The longer you work with them in this way the better you'll get at collaborating and the easier things will be to integrate.

That's how I like to work with dev teams anyway, not just throwing designs over the fence.

– tim

[Nicholas Faiz]

Using mockup tools like Balsamiq help a great deal, especially if your
customer is happy to use it to help visualize the application you're
building. The designer can also work from that too, but the customer
understands that the rougher looking app is modelled off a prototype.
It can increase confidence while waiting for the final design to be
implemented.

There isn't a lot of work when refactoring a HTML design into Rails
helpers, etc.. I just make sure I *don't* use HAML for such projects
(I generally don't use HAML anyway), because it's foolish to rewrite
all of your HTML files into another format.

Cheers,
Nicholas

[Tim Lucas]

On 24/11/2010, at 12:13 PM, Nicholas Faiz wrote:

> Using mockup tools like Balsamiq help a great deal, especially if your
> customer is happy to use it to help visualize the application you're
> building. The designer can also work from that too, but the customer
> understands that the rougher looking app is modelled off a prototype.
> It can increase confidence while waiting for the final design to be
> implemented.
>
> There isn't a lot of work when refactoring a HTML design into Rails
> helpers, etc.. I just make sure I *don't* use HAML for such projects
> (I generally don't use HAML anyway), because it's foolish to rewrite
> all of your HTML files into another format.

Great design is a process that goes all the way from idea to execution and back again, whether it's code or UI. Having HTML thrown over the fence isn't a process I'd recommend for Rails dev, I've been on a project or two like that and the end result was always terrible.

To the original question…

On 24/11/2010, at 11:07 AM, dnagir wrote:

> I am just wondering how you guys deal with working from having UI
> design to the actual Rails implementation?
> (e.g.: 37signals - Interface First)

37signals have a designer working and collaborating on each team during build, not just at the start handing over photoshops or HTML.

Don't think interface *first* development, think interface *driven* development.

– tim

[Julio Cesar Ody]

> Unfortunately such designs often do not follow a lot of Rails
> conventions (REST is ignored, Flash messages are not used, Validation
> errors presented in an absolutely different way etc).

No, what they're ignoring is the fact that one screen has many states.
E.g.: when showing notices and when not, when a user is logged in and
when not, etc, etc.

You either have one mockup per screen state (not hard to do), or you
have one PSD /AI file (if you or your designer uses Adobe tools, but
could as well be Pixelmator) and layers that you can trigger their
visibility to show/hide different states.

So sure, if you can, get them to understand Rails or what have you.
But the problem can also be solved by you telling the designers all
the possible states of a screen.

--
http://awesomebydesign.com

[Daryl Manning]

I have to agree with Tim. Every project I've had go off the Rails where design is an issue is because of the lack of inclusion of design at a stage where it can inform functionality and design. Good design, like good dev, is worth its weight in gold and the earlier the better.

Daryl.

[Nicholas Faiz]

I think you may have made an assumption here. How does involving a
mockup tool mean that the process "from idea to execution", that you
mention, isn't followed, and how does it mean that design is thrown
over the fence?

I definitely agree that involving design at an early stage is the way
to go. In my current project we have an early design for some things,
and are using Balsamiq in others, and it forms a good loop between the
design company, the customer, and dev..

[dnagir]

Thanks to all who replied. Appreciate it.

Assuming the designer is available most of the time, then it seems all
agree here that:

1. Continuous communication between dev<-->business<-->designer is the
key.
2. Making it right is an iterative approach.
3. Dev and Designer should speak the same "language" and understand
each other's tools.
4. It is a team effort and cannot (should not) be done by exchanging
screens via emails or so.

(this just sounds as a normal Agile-ish style... why wouldn't it...)

From this perspective, if the designer is not a part of a team; but
rather doing "once-off", "pay and go" stuff, the failure of UX seems
to be imminent.

In this situation options are:
1. Get a good designer on-board (might not be an available solution
ATM).
2. Keep as close as possible to the original design while continuously
updating the application.

The option #2 can probably work only so much.

> > rails-oceani...@googlegroups.com<rails-oceania%2Bunsubscribe@goog legroups.com>
> > .

[Tim Lucas]

On 24/11/2010, at 1:10 PM, Nicholas Faiz wrote:

> I think you may have made an assumption here. How does involving a
> mockup tool mean that the process "from idea to execution", that you

> mention, isn't followed and how does it mean that design is thrown
> over the fence?

Don't get me wrong, I'm a fan of Balsamiq, OmniGraffle and a chalkboard, and using them doesn't mean throwing anything over the fence!

I was trying to point out that a mockup tool doesn't do the "and back again" part, it's mainly only useful at the start, and what you need more than anything is a designer that you can collaborate with as it gets built, not one that finds out and plans for every corner case ahead of time.

– tim

[Tim Lucas]

On 24/11/2010, at 1:26 PM, dnagir wrote:

> Thanks to all who replied. Appreciate it.
>
> Assuming the designer is available most of the time, then it seems all
> agree here that:
>
> 1. Continuous communication between dev<-->business<-->designer is the
> key.
> 2. Making it right is an iterative approach.
> 3. Dev and Designer should speak the same "language" and understand
> each other's tools.
> 4. It is a team effort and cannot (should not) be done by exchanging
> screens via emails or so.
>
> (this just sounds as a normal Agile-ish style... why wouldn't it...)
>
> From this perspective, if the designer is not a part of a team; but
> rather doing "once-off", "pay and go" stuff, the failure of UX seems
> to be imminent.
>
> In this situation options are:
> 1. Get a good designer on-board (might not be an available solution
> ATM).
> 2. Keep as close as possible to the original design while continuously
> updating the application.
>
> The option #2 can probably work only so much.

An Option #3 would be to make sure whomever you work with is available to be around during integration and future iterations, basically try to collaborate with them a little more (that is, if they're open to it).

– tim

[Nicholas Faiz]

Thanks for clarifying. Agreed.

Cheers!
Nicholas

[jamesl]

>>So I, as a developer, either have to change the design bits to fit
>>into the Rails conventions or try to live with the design as-is.

Others have replied about the importance of being involved in the
"process" and I totally agree with them.

HOWEVER, one thing I feel strongly about is the suggestion "change the

design bits to fit into the Rails conventions"

I see my job as helping the Customer deliver, not changing the
Customers expectations to fit what I or some framework
can or can't do. Communicating with the rest of the team on the "cost"
of taking one approach verses another is also
my job but in the end it is the Customers choice not mine on which
approach is taken and how the design is or isn't.

When Steve Jobs says I think tablet computers are the way to go, how
do you think he would react when the engineers
say "but Mr Jobs, desktops are all we can build?"

See the Design as a challenge and learn new ways of delivering it or
get a framework/language that does, but don't
try to change them. Suggest the pro's and con's of each approach and
let the Customer decide.

Rgs, James.