On May 22, 2014, at 10:00 AM, Jordan C. wrote:
(who would then go on to implement back-end)?
This can work, although it’s not optimal. It’s going to put more burden
on Sam to figure out how to pull things apart and put them in the
appropriate partials and templates. It’s also going to assume that Matt
knows all the levels of CRUD and that he needs to provide interfaces for
every possible state that the application might find itself in.
A better way to try this is to let Sam scaffold the whole thing (I mean
that metaphorically, not literally) and show a working prototype to
Matt, who can then decorate that working prototype. If Sam is even
remotely skilled, he will be adding classnames and IDs to things that
need them as he works, and the resulting HTML will be easily decorated
(because there are enough handles to grab on to with CSS).
There may need to be a little back-and-forth after the initial
decoration, say if Matt wants a block to move above another, or to have
an additional level of nesting for some nefarious purpose or another.
But I would imagine that this would be the fastest way to get this done,
rather than trying to cram a designer’s well-intended opinion of how the
application should work into the opinionated structure of a Rails
Of course, if Matt has built or worked on a few Rails projects already,
then this advice may not be appropriate. But given a designer who knows
how things ought to look, and a developer who knows how they have to
work, I think it’s going to be fastest to start with the developer’s
constraints rather than the designer’s wishes.
I say all this as a designer/developer “unicorn”, so I’m not preferring
one over the other arbitrarily.