Answers.Body: <p>We used to do what you are doing, for a good many years - it was especially helpful when we didn't know what CMS we were going to use yet, or when we had a front end specialist (hello) who would send the files off to the back end specialist for implementation.</p>
  
  <p>However, with Craft, we've found that the front-end people can use it well enough to not need a 'back end specialist', so we find ourselves no longer doing site builds as front-end assets first. It's just faster and easier to build the HTML/CSS/JS from inside the Craft templates.</p>
  
  <p>We also used to (and still do for larger projects) build a completely non-styled "blueprint" of the website. The objective was to ensure that the site structure was correct - here's an example: <a href="http://example.bp.myvcsite.com/" rel="nofollow noreferrer">http://example.bp.myvcsite.com/</a></p>
  
  <p>That was/is part of our whole approach where we split things into blueprint; visuals; static build; CMS integration: <a href="http://example.myvcsite.com/" rel="nofollow noreferrer">http://example.myvcsite.com/</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-01T15:11:46.100Z
Answers.LastActivityDate: 2016-12-01T15:11:46.100Z
Answers.UserDisplayName: Matt Wilcox
Answers.Body: <p>Tobias: I don't think there's a "right" answer for everyone.</p>
  
  <p>What I do find is that Craft "gets out the way" a lot more. Craft's file structure and Twig templates aren't that far away from just static HTML. </p>
  
  <p>You can actually throw an <code>index.html</code> file inside Craft's <code>templates</code> folder and Craft will serve it just fine. All the stuff you need to grab from the database just won't pull in. Then when you're ready to break out the <code>header</code> and <code>footer</code> into the <code>_layout</code> template and hit the CMS, it's ready for you.</p>
  
  <p>Unlike other CMS, for example WordPress, where it expects a theme to work in a certain way and live in a certain folder structure, Craft is a bit more flexible in this respect.  (In WP land can change these defaults of course and use something like Timber but that's getting off track.)</p>
  
  <p>We try to get a lot of the content roughed in as early as possible because it can dictate design decisions. A lot of designers work backwards and make content fit the layout. I find Craft fits our "content first" methodology a bit better.</p>
  
  <p>We still produce static comps, get design approval and then build from those but a lot of people design in the browser because they find it faster and can show off a responsive design better. I'd argue Craft is no better or worse in this respect. I tend to switch from "design mode" to "programming" mode; when a design I created is set, then I figure out how to make it work, oftentimes incorporating the content we setup with the client at the same time. In this way, we are able to show the client a more "complete" website. At that point, we're just tweaking image and copy.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-02T23:01:01.287Z
Answers.LastActivityDate: 2016-12-02T23:01:01.287Z
Answers.UserDisplayName: RitterKnight
Answers.Body: <p>Interesting question. I think one answer depends on the speed of fidelity, ie that point at which you need to show something to a client AND how much fidelity they need ( ie in terms of completed visual design). I'm still finding the sweet spot and doing it both ways depending upon project time and budget.</p>
  
  <p>I do think there is a lot of merit for building it in html/css within craft as it enables resources like js and sass, images etc to be more ready to go.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-06T00:36:25.993Z
Answers.LastActivityDate: 2016-12-06T00:36:25.993Z
Answers.UserDisplayName: joomkit
Body: <p>I hope this question does not sound to banal:
  I am currently switching to Craft CMS and I am used to build my HTML/CSS/JS templates as static pages with dummy content. </p>
  
  <p>This (seemingly?) has 3 advantages for me:</p>
  
  <ol>
  <li>I have an early, clickable prototype, presentable to the client
  before I have to touch any CMS</li>
  <li>I am not forced to insert real content via the CMS yet </li>
  <li>It gives me a very clean Git Repository for the frontend without any
  CMS dependencies yet</li>
  </ol>
  
  <p>The disadvantage is of course that I have to manually split my static pages up later to work with Craft CMS (or any other CMS) templating logic.</p>
  
  <p>Thus I was wondering how you approach templating, especially with Craft: Whether you start directly building your frontend from scratch in Craft’s Templates folder or if you start independently, and do the splitting of files every time as a necessary step …</p>
  
  <p>Any suggestions?</p>
  
Tags: <templating><workflow>
Title: Best Practice for Templating-Workflow, coming from static HTML
ThreadText: # Best Practice for Templating-Workflow, coming from static HTML
  
  (Asked by: username_0 on 2016-12-01)
  
  I hope this question does not sound to banal:
  I am currently switching to Craft CMS and I am used to build my HTML/CSS/JS templates as static pages with dummy content.
  
  This (seemingly?) has 3 advantages for me:
  
  1. I have an early, clickable prototype, presentable to the client
     before I have to touch any CMS
  2. I am not forced to insert real content via the CMS yet
  3. It gives me a very clean Git Repository for the frontend without any
     CMS dependencies yet
  
  The disadvantage is of course that I have to manually split my static pages up later to work with Craft CMS (or any other CMS) templating logic.
  
  Thus I was wondering how you approach templating, especially with Craft: Whether you start directly building your frontend from scratch in Craft’s Templates folder or if you start independently, and do the splitting of files every time as a necessary step …
  
  Any suggestions?
  
  **Tags:** templating, workflow
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2016-12-01. Score: 4 | Accepted answer
  
  We used to do what you are doing, for a good many years - it was especially helpful when we didn't know what CMS we were going to use yet, or when we had a front end specialist (hello) who would send the files off to the back end specialist for implementation.
  
  However, with Craft, we've found that the front-end people can use it well enough to not need a 'back end specialist', so we find ourselves no longer doing site builds as front-end assets first. It's just faster and easier to build the HTML/CSS/JS from inside the Craft templates.
  
  We also used to (and still do for larger projects) build a completely non-styled "blueprint" of the website. The objective was to ensure that the site structure was correct - here's an example: <http://example.bp.myvcsite.com/>
  
  That was/is part of our whole approach where we split things into blueprint; visuals; static build; CMS integration: <http://example.myvcsite.com/>
  
  
  ---
  
  ### Answer by username_2 on 2016-12-02. Score: 3
  
  username_0: I don't think there's a "right" answer for everyone.
  
  What I do find is that Craft "gets out the way" a lot more. Craft's file structure and Twig templates aren't that far away from just static HTML.
  
  You can actually throw an `index.html` file inside Craft's `templates` folder and Craft will serve it just fine. All the stuff you need to grab from the database just won't pull in. Then when you're ready to break out the `header` and `footer` into the `_layout` template and hit the CMS, it's ready for you.
  
  Unlike other CMS, for example WordPress, where it expects a theme to work in a certain way and live in a certain folder structure, Craft is a bit more flexible in this respect. (In WP land can change these defaults of course and use something like Timber but that's getting off track.)
  
  We try to get a lot of the content roughed in as early as possible because it can dictate design decisions. A lot of designers work backwards and make content fit the layout. I find Craft fits our "content first" methodology a bit better.
  
  We still produce static comps, get design approval and then build from those but a lot of people design in the browser because they find it faster and can show off a responsive design better. I'd argue Craft is no better or worse in this respect. I tend to switch from "design mode" to "programming" mode; when a design I created is set, then I figure out how to make it work, oftentimes incorporating the content we setup with the client at the same time. In this way, we are able to show the client a more "complete" website. At that point, we're just tweaking image and copy.
  
  
  ---
  
  ### Answer by username_3 on 2016-12-06. Score: 2
  
  Interesting question. I think one answer depends on the speed of fidelity, ie that point at which you need to show something to a client AND how much fidelity they need ( ie in terms of completed visual design). I'm still finding the sweet spot and doing it both ways depending upon project time and budget.
  
  I do think there is a lot of merit for building it in html/css within craft as it enables resources like js and sass, images etc to be more ready to go.
  
  
  ---
  
  