Why your project needs up to date HTML slices

Ok, here’s the situation: you’ve started your project, currently your team has frontend developers and backend developers. Everyone is happy and doing their parts.

As frontend developer I can tell you that the fastest way to slice or prototype pages is working with plain HTML files. It allows you to work with your (S)CSS and JavaScript files without any issues of caching, server-side compiling, etc. It just works.

What happens when the pages are ready for implementation?

You guessed it, it goes to the hands of the backend developers who will do their magic: create the components for choose your favourite CMS here.
At this point we’re still happy, everything is working just fine and the project will be delivered on time.

First iteration

A couple of days have passed and some JIRA tickets have been raised: we need to fix something in the frontend.

No problem, the frontend developer will open up the HTML files and do the proper edits.

Iteration two hundred seventy six

At some point between revision 1 and revision 276 someone updated the backend CMS component and not the HTML static file. Probably the change was simple enough, there was no need to involve any frontend dev.
That is actually fine! It’s way cheaper, project-wise, and faster to develop.

Now, be careful, that decision might cause a lot of trouble in the future, when new major features will need to be added. An out of date slices will force us to download source files from production. We all know those files can be messy, with random ID’s everywhere, extra empty divs, inline styles, uncommented code…

So, what’ the proper way of applying frontend changes?

frontend-workflow-v2

 

I would add that in case of a JavaScript change, even if we’re using Grunt or similar you might be able to do the change yourself. The issue might be that not everybody has it installed locally. Although I would certainly recommend it 😉

Also, if the project has enough budget to have a frontend developer on board, the above workflow is useless. Just send everything to the frontend dev.

Conclusion

Try finding balance!

This best practices should not be a burden, if you get used to it I think you’ll get real benefits. If someone is capable of changing a component’s markup, is also capable of editing plain HTML files.

You should always keep your static HTML files up to date. Not with content changes but markup. I’m not saying it’s easy or cheap but it’s the right way to iterate. Not all projects will have the budget or client will to maintain this code standards. We, as professional, need to advice and convince our clients this is mandatory. In the end, it will probably save them money.

I hope now you have better insight of how you can be more productive and have a better future-proof code in your projects.

Have something to add? Leave a comment down below.

Share

Published by

Ricard Torres

Ricard is a Senior UI/UX Developer @ TBSCG. Based in Barcelona he also plays guitar, takes photographs and teaches Haidong Gumdo.

2 thoughts on “Why your project needs up to date HTML slices”

  1. Great article Ricard !

    I have a question, in the flow above it seems the back-end developer knows if a css pre-processor or a Java-script task runner are in use. Is this really the case?

    • If so, why do you think this would be ignored?
    • If no, how to make sure they know?

    Many thanks!

    Yolanda

    1. Good questions Yolanda. If the developer was involved from the beginning they will know.

      It might be the case a new developer steps in for a task. In that case, I think it’s easy for them to see by:

      • Taking a look at the code repository and finding “.scss” files instead of “.css” files in the source folder. A folder called SASS or SCSS should contain them.
      • If the JavaScript or CSS files on production are minified and/or concatenated. Although it can be done server side as well, at TBSCG we usually take the approach of compiling, minifying and concatenating locally before uploading. This will give them a hint, the production files will be unreadable.
      • A Gruntfile.js should be found in the root source folder in the code repository.

      Thank you!

Comments are closed.