3 ms·

I've talked about "template animation" (or "mockup-driven development" as I've called it) before, but focused mostly on how to achieve static files that can eas

by judofyr 15y ago

I've talked about "template animation" (or "mockup-driven development" as I've called it) before, but focused mostly on how to achieve static files that can easily be opened in the browser (without any server components) and still be modular (layouts/partials): http://timelessrepo.com/mockup-driven-development http://timelessrepo.com/mockup-driven-development This article seems to solve modularity by splitting it out into different files. On the same page you can have dozens of modules that can have several different states;how are you supposed to combine them all? How do you say "this page contains a sidebar, a blog post, comment section" and that there should be a "new comment"-form if the user is logged in and "delete"-links if the user is a moderator? In the example in the article, it seems that would be solved by having blog_post.html, blog_post_logged_in.html and blog_post_moderator.html, where 90% of the content in the files are duplicated. Beside, in the example templates you can't actually open the templates in a browser (because it only contains the content, not the stylesheets, script-tags etc. that you need). So if the designer wants to see how it actually looks, he still needs a server that can wrap the layout around it. Okay, but maybe you don't need the "view this template without running the server"-requirement. I'd still argue that dools' current approach is brittle. The reason is that he's now tying together two layers (the template layer and the animation layer) and there's no easy way to see what the animation layer will actually do. This means that small changes in the template might invalidate the animation. You really don't want to re-write the animation just because the designer switched from <h3> to <h2>. This problem is easily solvable though: Use custom attributes which doesn't conflict with HTML/CSS: <form> <dl class="error" id="whatevsError" animate="error"> <dt>You have to do something about this</dt> <dd>The reason we ask you do do this is so that we can laugh all the way to the bank</dd> </dl> <dl> <dt><label for="whatevs">Whatevs:</label></dt> <dd><input type="text" name="whatevs" id="whatevs" /></dd> </dl> </form> However, as you're adding more features to these attributes, you'll actually end up with another template language; it just happens to be encoded in HTML/XML. From here on we might wondering, why should we "hide" the logic inside attributes (where it can be easy to miss) when we can use a more distinctive and effective syntax? To summarize: - If you want to separate the template and the animation (so that you can easily change the template without updating the animation) you need to stay away from HTML/CSS-semantics and use custom attributes/tags that you know won't conflict. - If you use custom attributes/tags you've essentially created another language which deals with the logic for you. - If you don't care about the "view the templates without running a server", you might as well use a completely different syntax (which probably is going to be easier to understand than the "hide everything in the DOM"-approach).

dools 15y ago
These are great points, and I certainly agree that some convention is required in template development to ensure "less brittleness". I think it's simple enough to do this with ids and classes, though, and even when it does break, the time it takes to fix it is going to have a pretty trivial impact on your overall project because the problem is solvable, quite simply and without much hunting around, by one person without the need to communicate with anyone else on the team. Regarding the logic issue, I don't think you'd realistically end up with an intractable number of logic variations. If you have extra links that are there when the moderator is logged in, they should be there in any template with that structural element in it and then removed if the person logged in isn't a moderator. Granted, though, I have to put my money where my mouth is and port one of my existing applications over to using this methodology (which is, in fact, what I plan to do so the proof the pudding will be in the eating). Regarding the issue of "viewing the template without a server" - in the case of Fragmentify, all the frontend dev needs is the standard apache/php that ships with OSX. This is considerably less complex than having an entire framework/application environment installed and kept current. That being said, however, the way in which templates arrive at the "animator" is not the animator's problem. Dreamweaver lets you edit common assets and then exports head-to-foot complete HTML files in a ZIP, so just use that. So long as the "animotor" has complete HTML files to work with, that's all that matters.
- judofyr 15y ago
  > I think it's simple enough to do this with ids and classes, though, and even when it does break, the time it takes to fix it is going to have a pretty trivial impact on your overall project because the problem is solvable. The real issue is that now the designer needs to mentally figure out "is this a safe refactoring" for every change. Because he doesn't have the real application running there, he can't verify if it works or not. I fear that this might lead to "leave the markup alone; change CSS only"-mentality from the designers because they don't want to introduce the animators for a simple design change. (You might say that changing only the CSS was the "right" solution anyway, but sometimes things becomes more much simpler when you can e.g. just wrap something in a div). > If you have extra links that are there when the moderator is logged in, they should be there in any template with that structural element in it and then removed if the person logged in isn't a moderator. Aha, but how can the designer see how it looks like for regular users? He probably wants to make sure that it looks good without the link too (maybe it's more like a button which floats). It seems like a sub-optimal workflow to manually remove the link (or display:none it) every time he works on the regular user page. (He must also remember to put it back in.) > This is considerably less complex than having an entire framework/application environment installed and kept current. Fair enough. > … Dreamweaver … If an editor can make it easier to work with the templates, that's good. Just don't make it impossible to work with the files unless you use some proprietary editor…

by judofyr 15y ago

dools 15y ago

These are great points, and I certainly agree that some convention is required in template development to ensure "less brittleness". I think it's simple enough to do this with ids and classes, though, and even when it does break, the time it takes to fix it is going to have a pretty trivial impact on your overall project because the problem is solvable, quite simply and without much hunting around, by one person without the need to communicate with anyone else on the team. Regarding the logic issue, I don't think you'd realistically end up with an intractable number of logic variations. If you have extra links that are there when the moderator is logged in, they should be there in any template with that structural element in it and then removed if the person logged in isn't a moderator. Granted, though, I have to put my money where my mouth is and port one of my existing applications over to using this methodology (which is, in fact, what I plan to do so the proof the pudding will be in the eating). Regarding the issue of "viewing the template without a server" - in the case of Fragmentify, all the frontend dev needs is the standard apache/php that ships with OSX. This is considerably less complex than having an entire framework/application environment installed and kept current. That being said, however, the way in which templates arrive at the "animator" is not the animator's problem. Dreamweaver lets you edit common assets and then exports head-to-foot complete HTML files in a ZIP, so just use that. So long as the "animotor" has complete HTML files to work with, that's all that matters.

judofyr 15y ago
> I think it's simple enough to do this with ids and classes, though, and even when it does break, the time it takes to fix it is going to have a pretty trivial impact on your overall project because the problem is solvable. The real issue is that now the designer needs to mentally figure out "is this a safe refactoring" for every change. Because he doesn't have the real application running there, he can't verify if it works or not. I fear that this might lead to "leave the markup alone; change CSS only"-mentality from the designers because they don't want to introduce the animators for a simple design change. (You might say that changing only the CSS was the "right" solution anyway, but sometimes things becomes more much simpler when you can e.g. just wrap something in a div). > If you have extra links that are there when the moderator is logged in, they should be there in any template with that structural element in it and then removed if the person logged in isn't a moderator. Aha, but how can the designer see how it looks like for regular users? He probably wants to make sure that it looks good without the link too (maybe it's more like a button which floats). It seems like a sub-optimal workflow to manually remove the link (or display:none it) every time he works on the regular user page. (He must also remember to put it back in.) > This is considerably less complex than having an entire framework/application environment installed and kept current. Fair enough. > … Dreamweaver … If an editor can make it easier to work with the templates, that's good. Just don't make it impossible to work with the files unless you use some proprietary editor…