Some notes on mockup engines
Magnus Holm
think this is the workflow most teams use today:
1. Designer cooks up static HTML template.
2. Programmer sprinkle it with rhtml tags to make the dynamic elements dynamic.
3. Designer and programmer can both revisit the template to make changes.
There is one little detail about the third point: It requires that the
application is running. For a programmer, this doesn't matter so much,
but for a designer it can be quite a hassle — or, most of the time
it's going to be hassle for the programmer who has to set up an
environment for the designer (and keep it up to date).
Also, after the app has changed a bit, the original mockups (from step
1) are no longer equal to the templates, and if you want to experient
more with HTML mockups, you'll have to view the source and port them
over.
Mockup Template Engines attempts to solve these problems, and I think
it's a pretty awesome idea, but there's still not an engine which has
implemented it fully.
== Current engines
Lilu - http://github.com/yrashk/lilu - is the first I've heard of. You
keep your templates as pure HTML files and write rules:
if @users and !@users.empty?
populate('#found_user').for(:each,@users) do |user|
mapping 'h1' => user.name
end
remove('#no_matching_users')
else
remove('#found_users')
end
However, it's quite old (2006-ish) and no longer maintained. The
latest must be Effigy: http://github.com/jferris/effigy. It looks very
similar to Lilu.
Performance-wise, Effigy does exactly as Lilu: Parse, find the nodes
and replace the content at *runtime*. The only improvement (as far as
I can see), is that it's using Nokogirl, but that's it.
== What's missing?
I don't think neither Effify nor Lilu is really usable for big
applications at the moment. So what's missing?
1. Speed. While the performance of template only takes up a fraction
of the request, parsing/finding/replacing HTML at every request is
costly, and it would be terrible if you reach a point where you're
forced to switch to ERB because of performance issues. And I believe
it would be possible to get these up to ERB-like performance with some
tweaks.
2. Easier for the designer. If we're going to merge step 1 and 2
above, we'll have to make it easier to create and update mockups. One
example: In Lilu you could have a template like:
<ul id="found_users">
<li id="found_user">
<h1>John Doe</h1>
</li>
</ul>
<h4 id="no_matching_users">No matching users found</h4>
But under no circumstance #no_matching_users is going to be displayed
under #found_users. If you want to use it as a real mockup (get a
feeling of how it would look, maybe share with clients etc), you
somehow have to hide one of them. I also believe partials/layouts
would be really nice to have (that is, explicitly in the template,
without any need of Ruby-code).
3. Tools. The features (partials/layouts for instance) I describe here
requires tools in order to end up at .html, therefore it's very
important to have a wide range of tools so it's usable by everyone.
== Thoughts?
How are your workflows when it comes to templates? Do you have the
same problems as I described above? More? Fewer?
And of course: What do you think of this idea? Could it work? Would it
really solve the problems?
Any other features needed?
// Magnus Holm
Chris Wanstrath
> == Thoughts?
>
> How are your workflows when it comes to templates? Do you have the
> same problems as I described above? More? Fewer?
>
> And of course: What do you think of this idea? Could it work? Would it
> really solve the problems?
I use mustache + kicker to accomplish something similar:
http://ozmm.org/posts/static_sites_with_mustache.html
--
Chris Wanstrath
http://github.com/defunkt
Magnus Holm
posts.html" and it would look good, while with Mustache it would have
{{ name }} all around. However, I just realized that when you
introduce partials/layouts it wouldn't be that easy... Hm...
First of all I think not having a depenency on your app is the most
important advantage, even though you still need a preprocessor. And
with some JavaScript + XHR it would probably be possible to make "open
index.html?posts" work too... Maybe...
//Magnus Holm
Danny Tatom
Danny Tatom
http://dannytatom.me
Magnus Holm
lot easier. In this case the mockups are going to live forever (and
not thrown away after converted to ERB) and without layouts/partials
doing something as simple as changing the header can be a tiresome
operation.
//Magnus Holm
runeb
convention over configuration to the designers and have them organize
their mockups in an app/view action == action.html structure? Or
should template lookup also be expressed in the Ruby code you'll have
to write? If we're trying to keep the designers happy by letting them
do what they've always done, should we be telling them what their
files need to be named, and in what folders they have to live?
And maybe we should get some non-coder designer/html people to chime
in here about how they work and how they want to work.
I know some designers have a low tolerance for command-line tools for
instance...and maybe they are already using tools to edit multiple
html-files at once?
//Rune Botten
On Jan 8, 3:16 pm, Magnus Holm <judo...@gmail.com> wrote:
> You don't *need* it, but I suspect it would make the designer's job a
> lot easier. In this case the mockups are going to live forever (and
> not thrown away after converted to ERB) and without layouts/partials
> doing something as simple as changing the header can be a tiresome
> operation.
>
> //Magnus Holm
>
>
>
> On Fri, Jan 8, 2010 at 01:08, Danny Tatom <dannyta...@gmail.com> wrote:
> > I could be wrong, but I don't think you need layouts with something like
> > effigy or lilu. All the designers I know mock/code up each individual page
> > anyway (about, blog index, blog post, etc) to show the client. So, if this
> > is the case, each page is the layout, you're just rendering text/whatever to
> > it.
>
> > On Tue, Jan 5, 2010 at 2:04 AM, Magnus Holm <judo...@gmail.com> wrote:
>
> >> One of the advantages of mockup engines is that you can just "open
> >> posts.html" and it would look good, while with Mustache it would have
> >> {{ name }} all around. However, I just realized that when you
> >> introduce partials/layouts it wouldn't be that easy... Hm...
>
> >> First of all I think not having a depenency on your app is the most
> >> important advantage, even though you still need a preprocessor. And
> >> with some JavaScript + XHR it would probably be possible to make "open
> >> index.html?posts" work too... Maybe...
>
> >> //Magnus Holm
>
> >> On Tue, Jan 5, 2010 at 09:09, Chris Wanstrath <ch...@ozmm.org> wrote:
Magnus Holm
designers' work. There will always be some work with integrating the
mockups, and I think either the implementor should write explicit
template lookup code or reorgnanize the files himself. The former
gives more freedom, while the latter forces a sensible structure. We
should allow both (aka. not force a structure, but give a sensible
default).
I think the point is that the filename really doesn't matter that
much: it can easily be changed later. Some applications might require
different structures and we should be as flexible as possible. It's
more important to make it easier for designers to just create a
template and hook it into the current layouts/partials/etc and play
around.
And we should definitely get some non-coder designer/html people to
chime in. Designer-focus is more important than performance is more
important than programmer-focus (since it will anyway be less for us
to do).
// Magnus Holm