With my website design ready to go and everything in place, I needed to start making some important decisions about my website and get to work coding my new January Creative LLC website.
The goal of this article isn't to get extremely technical and in-depth with the coding of the website (if you want to know the techy details, you can always reach out to me and I'm happy to chat about it). So I'm not going to bore you with the line-by-line coding details in this article.
I mainly want to focus on a few decisions that I made when developing the website and the big picture items when it came to the coding of the website and to give a glimpse into why I did certain things a certain way. Below, I talk about my content management system of choice, how the site was coded, a few other decisions I made, and why I ended up recoding a big bulk of the site over again (what?).
Deciding on a content management system
Version one of January Creative LLC's website initially was developed on the WordPress platform. At the time, I was just learning the platform and what better way to learn than to develop your own site with it.
When I developed version two of January Creative LLC's website, I moved away from WordPress to a content management system called Statamic, a flat-file, no database content management system (CMS). There were multiple reasons for this, but the main reasons were to learn a new CMS, to get away from a database dependent site (where my content wasn't stored in a hard-to-get-out-of database), and to make developing the site much easier and sustainable in the long run.
Those reasons are still the same reasons I chose Statamic again for my CMS of choice for January Creative LLC.
Version two of my site used Statamic V1, which was great but had a few issues to it because it was new. It even became where recently I couldn't update parts of my site anymore because of some bugs and broken bits with the software (which is why my portfolio never had new pieces added to it). That was a risk I took with choosing a brand new CMS to work with while it was still in it its first version.
Statamic has grown up substantially since I started using it in 2015 and my new website is powered by Statamic V2.
It is leaps and bounds better than V1 was, and developing with it was so much better than I remembered it being in 2015. I even tweeted about how easy it was a few times. I really put this software through the test developing with it, and it worked near-flawlessly the entire time (and the bugs I did encounter were corrected within a couple of weeks in an update).
In theory, Statamic is set up in a way where you don't have to start 100% fresh when you want to launch a new redesign of your site. However, I opted to start from scratch and not carry anything over from my V2 website to my new V3 website. There were several reasons for this, but the biggest was due to wanting to review every single piece of content that comes to the site.
I wanted the site to be the best it could be. Part of my plans with this entire rebrand was to critically analyze every single part of my business, even down to every word and picture on my website.
I opted to manually import all of my content while proofreading, editing, and updating the content as I went along and replacing/resizing pictures as needed. Thus, my decision to do this had nothing to do with any shortcomings with Statamic and everything to do with how picky I am when it came to this new site and how I wanted it to be moving forward.
Coding the site from scratch
One very big point I want to focus on in this behind-the-scenes look is the fact that I did not code my website with any prebuilt frameworks or templates. I started 100% from scratch with nothing but a couple of dozen lines of CSS code I use in all of my projects (a basic CSS reset and my development grid, but even that grid was customized for this site).
I fully believe in the importance of keeping it simple when it comes to your site.
Using frameworks like Bootstrap, or templates, or any other "helpers" tend to add unnecessary bloat to your site that just isn't needed. Taking something built by someone else for different purposes then trying to bend it to make it work to your site means you're going to inevitably have parts of the framework go unused, all while your browser is still pulling that code and rendering it (slowing down your site in the process).
There are developers who feel strongly about using CSS frameworks (i.e. Bootstrap or the like), CSS processors or using things such as Genesis for WordPress, and if that works for them, then great. I'm not here to bring down developers who use frameworks or pre-built templates, as I know these tools have a place in the web development world.
I just like to have only the code on my site absolutely necessary for how it looks and functions, and nothing else.
This is how I approach my client websites as well. I like my sites to be lean, easy to load, easy to maintain and update by literally everyone who knows HTML and CSS (and in this case Statamic too) and doesn't require having to keep it updated or worry about things breaking because the framework changed.
Thus, my website is coded completely from scratch with no frameworks or prebuilt templates.
Every single line of code was written with respect and consideration to how it is used on my site. It is coded in straight HTML and CSS (no fancy things to figure out) and has as little jQuery/JavaScript as I could possibly get away with.
Did this add time to my development? Likely. Did it cause issues along the way? Also likely (read below). However, I feel really good about the codebase that my site is running from today, how clean everything is, and how literally anyone with HTML and CSS skills can edit the site without having to learn a framework or processor or anything else first.
A few other considerations for developing the site
With every web development project I work on, there's a handful of considerations and decisions that need to be made. I discussed a few of those above (CMS, using frameworks, etc.). However, there were a few for my site I wanted to discuss in detail here.
The first consideration was the approach to how the site would be developed responsively. There was no question I wanted the site to work on all devices, but just how would I start this process was the question. So, I turned to my analytics for guidance and answers.
Roughly 75% of the traffic to my site view my site on their desktop computer, not their mobile phones or tablets.
Looking at my analytics, it was clear that roughly 3 out of every 4 visitors coming to my site were doing so from their desktop computer. This is a statistic that is a bit out of line with the norm for most websites (the norm is roughly about half of visitors come from desktop while the other half come from tablets and mobile devices). Mine overwhelmingly leaned desktop, so the site was designed and coded based on the desktop-first (instead of mobile-first) approach.
Secondly, I wanted to focus even more on my search engine optimization (SEO) of the site. Having a site that relies on search engine traffic for the most part, I didn't want to hurt my current SEO while also improving what I already had. I did some research to start and ended up making sure the coding of my site matched the current best practices for what I wanted to achieve so it set my site up for the best possible success at SEO.
Finally, I wanted the website to use as little jQuery and Javascript as absolutely possible. Some visitors tend to block rendering of these two items on sites due to fear of malicious code, hacking or other reasons. I wanted to make sure my site used as very little of it as possible for these cases.
Recoding major parts of the site
After I had the bulk of the site coded and ready to go, I was doing some responsive design work so that the site worked well on tablets and mobile devices, and started to run into some issues.
Because I coded the site in a desktop-first approach (because my analytics shows that over 75% of my traffic comes from desktop devices), that presented a few issues when I started making it work for smaller devices. Not only that, the design also needed to be tweaked in order to make it work as well responsively.
So, after the site was initially coded, I ended up dismantling pretty much the entire website and piecing it back together to fix site-wide responsive issues.
This took about five days to complete because I reused large chunks of code. The site is actually better now than it was previously because of hindsight and knowing what I actually needed, plus it works so much better on mobile and tablet than the path I was headed down before.
Not everyone has the ability to code their site, then completely recode it before launching, and honestly, I was not thrilled on the idea because it pushed back my launch by nearly two weeks. However, I knew that if I had not done it now, I would be doing it very soon anyway.
The recoding of the site is not included in the time-lapse video below because most of the coding I initially did is still there, just reorganized a bit. I could have easily left out this part of the process, but because I like transparency, I wanted to include it to show that things aren't always smooth sailing, and that things happen where you have to take a few steps back to fix things before moving on.
Time-lapse video of the web development process
Similar to my previous articles, I screen recorded every step in the website coding process and combined it all together in this time-lapse video.
I'm taking you behind the scenes to show you the time-lapsed version of the website coding and content management system development process that it took to rebrand my design firm January Creative LLC. The video below has an introduction followed by the time-lapse. Feel free to speed it up or slow it down using the function in the bottom right-hand corner to make the time-lapse faster or slower depending on what you want to see.
The website coding and development process took roughly 52 hours (before recoding it). Some of this is learning Statamic and making adjustments with the new CMS. The recoding of the website (not seen in the time-lapse above) took roughly 21.5 hours, while I've spent about 5 hours since the recoding (as of writing this article) on additional coding for small changes (like the testimonial slider on the home page).
Also, none of the time above includes the time it took to add all the content, write new content, proofread content, and make new pictures for most of the content (which, as of this writing has been roughly 43 hours and counting).
Some parts of the site likely look different now than they do in the video above, due to making some changes so that the site worked better responsively.
This is the last article in the behind the scenes series! I really enjoyed taking you all behind the scenes in every step of the major parts of this rebrand and hope you enjoyed this peek behind the curtain to see how it actually all came together!
