May 23rd, 2018
Here's the too-long-didn't-read version. A number of decision had to be made to fit within my framework of lightweight and fast, clean and neat. These are the resources and tools that I used to make that happen.
This is an extension of my previous post where I wrote about my decision to move away from Squarespace in favor of self-publishing through a hosting platform. I wanted to put together a narrative about the decisions I made in building and designing this website and that it might be a helpful resource for others looking to do something similar. I tried to approach building this site as logically as I could, so each 'Part' is, more or less, in order of consideration. As such, I will begin by discussing my first decision in choosing a hosting platform.
Choosing a hostling platform was a bit of struggle. With numerous options available you think it would it would be anything but, however, quantity does not always equal quality. Simply googling "best website hosting 2018" is not a bad place to start to get a handle on the current environment of website hosting. You can then use that information to further filter your choices. Another option, and the one I eventually chose, was to search Stack Exchange and web developer sub-reddits on Reddit. Both have a massive user base and what better way to find this kind of information than from the people who are likely to have experience using hosting services? There was plenty of good advice to be had, but many stressed the importance of quality customer service over technical differences. Speaking of technical differences, one technical decision you will likely have to make is choosing between shared hosting or dedicated hosting. With shared hosting, as the name implies, you are sharing server resources along with other websites. Dedicated hosting, on the other hand, provides dedicated resources for a single website. Both have their benefits. Shared hosting is significantly cheaper, while dedicated hosting favors stability. I would venture to say that for the vast majority of people, shared hosting is more than enough.
After comparing most of the major players in web hosting, I eventually chose a shared hosting plane from Siteground. They received great feedback from users (especially customer service), had reasonable yearly rates for shared hosting, and a solid introductory feature set for users just starting out with their own self-managed website.
When you sign up for a Squarespace account, you will also likely register for your own domain (website) name. It is actually a nice feature that Squarespace offers in that, as a service, everything is self-contained. You can have your domain name and website up and going in the 10 minutes that it takes to create an account; no need to buy a domain from another provider. This was the route I took when I used Squarespace and registered my name as the domain name. Squarespace, fortunately, makes this a relatively painless experience by offering the tools needed to prepare your domain to be transferred to another provider. I followed the exact steps found here and encountered no issues. The transfer from Squarespace to Siteground took all of 10 minutes (although they do estimate that it can sometimes takes as long as 48 hours). With the domain transfer complete, it was time to begin putting the pieces together for this site.
The next decision was to decide whether I should use Wordpress or static HTML/CSS. Saying that Wordpress is the most used CMS in the world is no exaggeration. According to Wordpress, 30% of websites are built using Wordpress, which include a number of big names such as The New York Time, Forbes, BBC America, TechCrunch. If Wordpress is good enough to manage these websites, it is good enough to manage your own personal website. The ubiquity of Wordpress also means that hosting services generally offer easy Wordpress installations. So, if you are coming from Squarespace and still like the idea of a CMS, Wordpress (or one of the many variants) is a good way to go. But, there is another consideration and that is a static HTML website. Static meaning no CMS or dynamically rendered web pages, say, via PHP. There are advantages to static HTML websites. First is simplicity. You have an HTML file for every page and a series of CSS files that style them. Once finished, you upload to your preferred hosting service and you are good to go. Also, static HTML websites tend to have faster load times. Another advantage is that static HTML pages can offer more SEO (search engine optimization) flexibility.
There is a significant downside, however and that is, interestingly enough, content management. A CMS, like Wordpress, is built to do just that, manage content. You can write and upload to a page through an easy to use text editor as well as upload photos using any number of photo gallery plugins available. Static HTML requires you to directly edit the HTML of the page and then upload that page via FTP to replace the old with the new. It is pretty archaic when compared to Wordpress or other CMS'. If you’re constantly adding new content, this is not exactly ideal.
Weighing the advantages and disadvantages of both Wordpress and static HTML, I went with static HTML. In an environment where modern websites have a tendency to be feature heavy, I was looking for speed and simplicity. Static HTML/CSS offers both.
January 2019 Update: Since starting this website roughly 9 months ago it was hard to anticipate how the website would evolve and the approach needed to make those updates. For the most part things have stayed pretty consistent save for two things; updating the navigation bar and changing the copyright date. It became clear that it wasn't ideal nor reasonable to make manual updates to every page in the event that I added a new section or change the footer to reflect new copyright information. To remedy this, I've added some PHP so that, instead of updating each and every page, I can update just two documents that will reflect those changes across the entire site. It's an enormous timesaver.
I don't have much experience with web development. I have managed websites using a CMS, but not coding a website from scratch. My familiarity with HTML/CSS is basic; enough to know some of the terminology and not a whole lot else. The one piece of information that I was aware of are HTML/CSS boilerplates. Boilerplates, or skeletons as they are sometimes called, provide the basic foundation for developing and designing a website. Since all HTML pages have a required page structure, boilerplates include this structure as well as other common features that help speed along the website development process. These boilerplates usually include a css file (cascading style sheet) that normalizes your webpage to help keep it consistent between web browsers (typically called normalize.css). Each web browser has the potential to style webpages differently. Including a normalized css file will help keep your website looking the same across all browsers. Speaking of web browsers, boilerplates will also include functionality that will make your website mobile-ready. The key is to be able to have your webpage viewed easily across any device; whether it is a cell phone, tablet, or full desktop computer.
Like everything up to this point, choosing a boilerplate required some decisions. For myself, there were two important factors. First, the boilerplate could not be large in size. Boilerplates have a tendency to be quite large depending on the features that are packaged in them. Secondly, the boilerplate had to be user friendly. At the end of the day all I needed was the bare minimum. Enter Skeleton. Skeleton is billed as 'a dead simple, responsive boilerplate', which is no joke. The entire download is no more than 26KB. Skeleton also includes some nice, simple stylized features like buttons and forms if you choose to use them. A criticism that I have seen online is that it is not as consistently updated as other boilerplates and not as feature rich, but neither of that mattered for me. As my website is largely driven by photos and text, there isn't much need for any additional overhead by way of user-experience functionality. Simple is all I needed and Skeleton more than fits that bill. Highly recommended.
I knew that putting together a photo gallery wouldn't be as straightforward if I had opted to use a CMS like Wordpress. Since this website is more hands-on, I knew that a photo gallery would require a little more work. I wanted to minimize not only the amount of potential work/coding, but also keep with my theme of simple and lightweight. It took a solid evening but I came across the photo gallery utility called Fresco. It is fast, easy to implement, and provides plenty of customizability to suite most photo gallery needs.
Although design should probably be the first thing that you consider and sketch out rather than the last, it is Part 3 in this series for reason. From using Squarespace for a number of years, I kept mental notes about things that I wish I could have changed but could not because of the limitations of the templates. The Squarespace templates are nicely designed that generally follow many of today's most popular web design trends: screen spanning images, large, blocky text and fading transitions between elements. While pleasing, they were personally irritating. I had a long standing mental vision of how I would arrange my own website, so I did not have to spend much time sketching out the details. My ultimate design philosophy for this website was pretty simple; lightweight and fast, clean and neat.
I chose to go with a pretty standard layout. The container (the part of the website that you are reading now) is 960 pixels wide, and centered. Using Skeleton as my boilerplate made this simple as this is the default layout. This 960 pixel working space can be further divided into columns to help support arranging elements on the page. For example, my Home, Blog, and About pages use 100% width of the container (all 960 pixels), or one column.
My photo galleries, on the other hand, are split into thirds so that I can have my photos arranged in a three-column grid. A single page can have columns of various widths to help accommodate multiple layouts depending on content. Best of all everything is kept responsive so content will scale proportionally.
January 2019 Update: I've greatly simplified my Portfolio page to take advantage of the entire width of the container rather than rely on a grid with thumbnails like before. The images end up being more accessible on both desktop and mobile platforms as well provide higher quality previews. I have also reduced the number of photos and created separate pages per group for a cleaner presentation.
Choosing the right font is a big deal. I would say it is up there as one of the most important decisions you will have to make design wise. It does not help that there are thousands of fonts available. A few key considerations will help considerably narrow the field of choices. Regardless of whether a font will be used for a heading or body text, you want a font that will be easily readable and stay consistent between browsers. Thankfully repositories like Google Fonts offer dynamically hosted fonts that will display regardless of platform and browser. Another plus one for Google Fonts is that they are free. Not all fonts are free and often require a license to be purchased. As convenient as Google Fonts is, my thoughts are is that you are better off choosing a web safe font. A web safe font will typically display regardless of what browser you are using. I wanted to use a san-serif font and Arial is a web-safe font available for display on all browsers. Since Arial is considered a system font I did not have to rely on Google Fonts to serve the styling. Arial is used for both the body text and the headings of this website. While Arial may not have a lot of design wow-factor, it is one of those fonts that goes with almost anything; kind of like the neutral color equivalent of fonts.
I realize that high resolution, screen filling photos are hugely popular on websites, but this can also equal slower rendering and possibly expensive downloads. Google has several excellent resources that covers image optimization which are well worth the read. They can be found here and here. The images on this website average a size of 200KB, which strikes a nice balance between size, quality, and speed.
There are a number of programs that can help compress JPEGS without sacrificing too much in terms of quality. Some of them include online utilities such as TinyJPG and Compressor as well as desktop programs such as imageOptim (Mac only. I'm not too familiar with what options are available for Window users). While I have used these, Adobe Photoshop covers all of my image compression needs. If you already have a Creative Cloud account then there is little need to add anything else to your workflow. If not, the utilities mentioned above will work well.
I will use this last part to cover the workflow and applications that I use to maintain and update this website. There are numerous alternatives to what I will cover below but, for now, this is my current setup (may change depending on circumstances. If so, updates will be posted here).
There are numerous HTML/CSS editors available and I don't really have any specific advice to give for one over another. Unless you are a hard core developer with very specific needs, there is little reason to purchase HTML/CSS editing software. The only advice I do have is to find one that has robust HTML/CSS autocomplete and Live Preview. Autocomplete HTML/CSS is extremely useful and helps take the guesswork out of coding while Live Preview lets you view your webpage as if it were live and up on the web. This is useful when reviewing the content of a page before you upload it to your website. I chose to go with Brackets. Mostly because of its simplicity and uncomplicated feature set, as well as the inclusion of autocomplete HTML/CSS and Live Preview. It also allows for extensions of which there are many. I use Beautify which helps organize the HTML/CSS code in a more readable manner.
Since this is a static website, that means that I replace the old HTML files with the new HTML files along with uploading other website content. While hosting services offer online portals to access your FTP site, the easiest route is via a FTP client. FTP clients allow you to store your log-in credentials for later use so once logged in, you can simply reconnect. Like HTML/CSS editors there are many FTP clients to choose from, but I use Filezilla, which is available for both Mac and Windows. It is free and gets the job done.
January 2019 Update: I have replaced FileZilla with Transmit (Mac OSX only). With regular use I have found that FileZilla frequently has issues opening directories once connected, or dropping an FTP connection all together. If you use an FTP client infrequently FileZilla would suffice. Otherwise you would be better served by using Transmit. If you're not willing to pay for an FTP client consider Cyberduck.
For word processing I will use both TextEdit and Brackets. TextEdit (the Windows equivalent of Notepad) is mainly to write the rough draft. Once I have the rough draft complete, I will copy that into Brackets to arrange into sections on the HTML page and then complete the final review. Live Preview is especially useful here as I'm able to get a better sense of the page layout before that page is made live.
In light of the many options available to individuals who want to create and maintain a website, this whole effort seems a little archaic. I am not leveraging any of the automated features of a more robust framework through a CMS or any server side distribution of pages. On the other hand though, I have found that I highly enjoy this hands-on management of my content. It is certainly not for everyone, but I would not rule all of this out completely.
As my workflow improves, this will be updated to reflect any changes that I make to any of the resources listed above. If you have any questions, please feel free to email me, firstname.lastname@example.org