

Mockup-Driven Development - judofyr
http://timeless.judofyr.net/mockup-driven-development

======
audionerd
I like the term "Mockup-Driven Development". This is a problem I've been
thinking about for quite some time, and I think the author describes it well.
There's clearly room for progress in the integration between client-side
HTML/CSS designers and server-side programmers.

I've found two things help integration greatly: "Super Templates" and "Logic-
less Templates".

 _Super Templates: e.g.: building a single page template for the entire site_

This a technique I learned from Nicole Sullivan's "Object-Oriented CSS"
<https://github.com/stubbornella/oocss/wiki/FAQ> (see the section: "Why have a
single template?"). A colleague of mine has nicknamed them "super templates".

Building everything in a single template provides essentially an "integration
test" for your HTML components. CSS conflicts are made visually obvious.

Most likely, you would build each HTML component in isolation, and stitch them
together into such a "super template" via {{< include}} or similar. To avoid
CPU overload, you toggle on/off HTML/CSS as needed for a given test.

 _Logic-less Templates: e.g.: {{mustache}}_

<http://mustache.github.com/>

Mustache templates are language-agnostic. You only have to build them once,
and you can use them everywhere.

Mustache views provides a Mustache template with content. So within one app
you might use the same Mustache template server-side (with a Ruby view), and
client-side (with a JavaScript view).

Because of this flexibility, the Programmer and Web Designer can use _the same
mustache templates_ , using a view appropriate view for their needs (either
the real view or a "stub").

The Web Designer would use a "stub" view. It has fake data structures, dummy
lorem ipsum. Just enough to build a template.

The methods of this "stub" define an interface which can later be implemented
in the real view, at the Programmer's convenience.

This results in the same "Mockup-Driven Workflow" the author describes, with
no additional libraries required. The Web Designer works (in the browser) on
the templates, using JavaScript view stubs. The Programmer uses the _SAME_
templates, coupled with his server-side views, in the actual application.

------
wccrawford
Actually, your designer shouldn't be continuing to work on your mockups in the
first place. After the mockup is complete, it gets turned into a template and
then everyone works on that. The mockup was just a proof of concept to the
customer. It wasn't meant to keep being used.

Also, be careful with your mockups. If you're demoing functionality, you don't
want the looks of the site to be pretty, and if you're demoing the visual
appearance, you don't want the site to work at all. If you mix the 2, the
customer will get it in their head that most of the work is already done, when
it's not even close.

~~~
audionerd
I agree with your arguments when the purpose of a mockup (Photoshop or
otherwise) is for visual concept / art direction / client presentation.

But when you move past that stage, and begin to integrate HTML/CSS with server
code, things get messy real quick, and that's the problem I think this article
is proposing to solve.

I think the terminology may be confusing. For example, in the vernacular I'm
familiar with, "mockups" are in Photoshop, "templates" are static HTML, and
"views" run on the server. And even so, I find these terms are often used
interchangeably.

------
jamesbritt
Reminds me quite a bit of MasterView (<http://masterview.org/>).

There are static HTML pages that can be used to walk a client through an
app,but they are also used to generate the actual Rails templates.

