April 17th, 2021
Three years ago, I published a post that explained my approach to building this website. It has been a static guide for the most part as the tools and resources that I use have remained about the same with only minor changes added in 2019. I have since modified my workflow and I felt that it was time to revisit and update that guide in its entirety. The old guide will no longer appear on this site and this guide will take its place moving forward. I should note that this is not meant to be a step-by-step guide on how to build your own personal website and portfolio. My approach is to merely provide a high-level overview of what I thought to be important considerations when building your own website based on the perspective I had after building mine.
Choosing the right hosting platform is an important first step. While googling "best website hosting 2021" is not a bad place to start, I found Stack Exchange and web developer sub-reddits on Reddit to be useful. Simply take a hosting platform that you have found and read what Stack Exchange or Reddit has to say about them. If this is your first time building your own website the amount of information can be overwhelming, but I believe that you can limit your choices significantly by looking at two key factors: network uptime and customer service. Network uptime is your website availability. Some hosting platforms will offer a 99.9% network uptime over the course of a year with reasonable exceptions made for scheduled server and resource maintenance. Also, there is customer service. You will, at some point, be contacting customer service with questions and you will appreciate having a hosting platform that values its customers.
I haven't yet mentioned cost and while cost certainly should be a consideration, it shouldn't be your primary consideration. Good, dependable hosting is going to cost you money. Pennies-on-the-dollar hosting is tempting (I've been there myself) but do yourself a favor and look at what the company is really offering you. There should be no ambiguity about their capacity to offer you dependable service. Also, introductory offers are exactly that: introductory. It is important to find out what your renewal expectations will be. If you're not comfortable with the monthly fee after your introductory year of special pricing expires, then all of your initial effort will be a waste of time.
This site has been hosted by Siteground since 2018 and I have been happy with the service so far. There have been no unplanned disruptions to my service and their customer service has been responsive when I've needed them. At $24.99 per month, it's a little expensive for shared hosting, but I feel it's a fair price for what the hosting plan offers and the reliability. Siteground is by no means the only option, so carefully consider your options. You will thank yourself later.
Content management systems (CMS) like WordPress or Squarespace are popular for a reason: they offer an easy way to create a website and manage content. Websites can be built quickly with standard practices so that your website is easily viewable across all devices and platforms. A secondary approach is creating a static HTML website. In other words, the website itself is an inventory of HTML pages with CSS files that help stylize the content. Those files are delivered to your hosting platform via FTP or direct upload via the hosting platform's file manager. I choose to build this website using static HTML, for several reasons.
First, while static HTML is not as convenient as a CMS, its structure is simpler. There are no databases or additional server-side applications to distribute your webpages. Everything has a dedicated page that can be easily identifiable and modified. Second, I liked the hands-on approach that static HTML offers. I am not a web developer but the design language that I had in mind for this website was easier to achieve using static HTML rather than a CMS. If you decide to use static HTML, I highly recommend using an HTML boilerplate to help you get started.
Boilerplates are extremely useful as they provide the basic foundation for developing and designing a website. Similar to a CMS that provides website templates, boilerplates include standardized HTML and CSS files that ensure a website is easily viewable on all devices and browsers. They take away a lot of the guesswork, especially if you're unfamiliar with HTML and CSS coding. For this website I wanted a boilerplate that kept functionality simple. I chose Skeleton. Skeleton is an extremely small boilerplate that offers a nice baseline of functionality. As far as I can tell, Skeleton isn't routinely updated but I don't know that it needs to be. It offers everything you would need to get started and functionality can be easily added after the fact.
Once you have the framework of your website built, you can then work on the details. I started with choosing a layout. There are no right or wrong answers. The layout that you see here is a function of the default layout provided by Skeleton. It is a simple layout with the main content centered on the page with a maximum width of 960 pixels. There is some logic behind that number that you can read about here, but I find it's a width that continues to work nicely on desktop computers and mobile devices.
Fonts have a way of transforming the design of a website and I spent far too much time trying to find the right fonts to pair with body and title text. Font repositories like Google Fonts or Adobe are useful tools as they offer a database of fonts to review and an option for embedding fonts in your website. As useful as these tools are, however, I favor web safe fonts. Web safe fonts are fonts that are standard to nearly all browsers and operating systems. The advantage is that you don't need to consider how your website will display for the end-user. All content that you see here is using Arial and it is an easy font to read on the desktop or on mobile devices.
Functionality that is not provided with the Skeleton boilerplate is a photo gallery. I went through several iterations of a photo gallery by using a 3 x 3 grid-based system on my Portfolio page and then a slideshow with interactive thumbnails. In the end I choose to keep things simple and use thumbnail previews that were the same width as the container of my website. The container is 960 pixels wide which is a manageable size for an image preview. The lightbox functionality of the image when clicked is being served by Fresco. This is an open source JavaScript package that runs locally on my hosting server and it is easy to implement and configure.
Regardless of how many pages your website will be, there will be common elements that exist on all pages. For this site, that includes my name, the navigation bar, and the footer, which includes the copyright information and year. Relying on HTML to serve these elements required me to update every page with that information. It did not take long to realize how inconvenient that task would be. This is where PHP is extremely useful, and the solution PHP offers is fairly approachable for those with no PHP knowledge.
To get started, all web pages have to be converted from .html to .php. So, for example, a home page will typically be named 'index.html'. To convert to PHP, you replace the '.html' file extension with '.php', so you would then have 'index.php' instead of 'index.html'. From an end-user perspective, nothing changes. There are no visual differences in how the page renders once the file extension becomes '.php'. This update is required so that you can a) use PHP code on your page and b) have your hosting server render that code. PHP will typically be included as preinstalled functionality on your hosting server, but it doesn't hurt to check if it's active or whether you need to enable PHP first.
The feature of PHP that you will be using is a statement called includes. This statement will take HTML elements that exist in a file and add them to pages you target. W3schools has a useful guide on how to use includes. Implementing this feature is well worth your time and will pay dividends in time saved in the short-term, not to mention long-term.
An advantage of a CMS is being able to easily add features that would otherwise be complicated to develop. A good example is a contact form. Using static HTML contact form options tend to be more complicated. The easiest approach is using a third-party service that lets you configure a contact form and embed that form in your website. Often these third-party services will offer limited free plans and paid tiers that offer additional functionality and an increase in submission quotas. For the first two years, I used Zapier. While I did not have issues with Zapier, I did not like having my contact form handled by a third party. This was largely due to my own personal feelings about having as much control over my content as possible. A contact form, or some other function that allows someone to contact you, I feel is an important feature and relying on a third-party service to host that feature carries some level of risk: namely that the service could one day no longer exist. In short, a self-hosted option is preferrable.
After considering my options, I choose an entirely different route: an email address. I like to keep things simple where I can, and it is hard to get much simpler than an email address. Rather than provide my email address in plain text somewhere on the website, I opted to use the feature Mailgo. It's an elegant solution for providing access to an email address in a user-friendly interface that integrates nicely into a website. Spam has not been an issue and, best of all, it's a feature that is self-hosted and low maintenance.
So far, I've covered the highlights of the web front-end, but I wanted to briefly cover some of the items I use to take care of the back end. For the minimal coding that I do to update this website, I use Visual Code Studio. It was only recently that I started to use Visual Code Studio. For the first two years I used Brackets but development support for Brackets had sunset with a recommendation of using Visual Code Studio instead. So far, it’s been great. As an IDE, it's not wildly different than Brackets and, I feel, more stable.
To transfer files, I use Transmit. It's FTP software for Mac only but, if you are a Mac user, I recommend it. While there are many free options (Filezilla, for example) the price for Transmit is worth it just because it works reliably and quickly. It's been my go-to for the last two years and I don't see that changing any time soon.
I don't have a consistent approach for word processing. Blog posts are generally written in either a blank page in Visual Code Studio or the Notes app on MacOS. When I need to convert what I've written to HTML, I'll convert the document manually by adding the required HTML tags myself. It's not a particularly efficient process but it doesn't need to be. I'm an easily distracted writer, so writing in plain text and converting to HTML later has worked just fine.
It's only been within the last year where I feel like I've settled into the workflow I've built for myself. What I have provided in the list above is largely a reflection of that. If something does change, I'll make inline updates to this guide as needed. In the meantime, if you have any questions, please feel free to get in touch.