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.
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.
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.
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.
5 comments
[ 3.3 ms ] story [ 18.2 ms ] threadAlso, 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.
You should re-read the article, unless you're simply asserting that is the One True Way of doing it.
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.
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.
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.