A Redesigned Artsnova Website Part 2
In A Redesigned Artsnova Website Part 1, I provided general background on my website redesign objectives. The website redesign priorities that I identified were:
- To unify the main static HTML website with the blog which was using the Wordpress CMS (Content Management System).
- To redesign the UI (User Interface) and come up with a new graphic design for the website.
- To simplify website management.
- To minimize website demand on server resources in order to minimize hosting costs.
In deciding on the more technical objectives for the redesign, my emphasis was on a solution that:
- Improved website performance for the user in terms of page loading speed.
- Minimized website demand on server resources to maximize the amount of traffic my web hosting account could support.
- Created the most portable website possible, making it as easy as possible to migrate between different web hosting platforms.
- Minimized the website's security risks and attack vectors by eliminating online database and site management scripts.
- Had a high ratio of content to code, thus simplifying management, development, and code support activities.
If you think about it, the objectives listed above all boil down to three priorities:
- Improving the user experience.
- Maximizing the amount of traffic the web hosting account can support.
- Minimizing the amount of time required to develop and maintain the website.
At the conclusion of A Redesigned Artsnova Website Part 1, I told readers that I would address the design solution I chose and the process I used to implement that solution in Part 2 of the series. So here we are.
The Selected Web Design Solution
The website design solution that best met the criteria I had established with respect to design, deployment, and maintenance was that of a static HTML website using a single light-weight CSS framework with no other dependencies. Limiting library dependency to a single lightweight CSS framework file provides the following advantages:
- it minimizes the number of CSS files that must be loaded for the design to work
- it eliminates the need to download Javascript files for the design to work
- it simplifies the coding environment
- it minimizes total web page sizes in kilobytes
- it eliminates compatibility and upgrade issues
- it makes it easier to migrate to an alternate solution if necessary
Deploying the design as a static HTML website as opposed to a dynamic site actively managed by a CMS provides the following set of benefits:
- it minimizes the total work load on the server
- it minimizes the number of failure points in the page construction process
- it eliminates software-related upgrade risks
- it minimizes security risks
- it minimizes server software stack (aka LAMP, MEAN) dependencies and issues
- it maximizes site portability
- it simplifies troubleshooting
- it eliminates the worry about database corruption on the server
- it eliminates the need for creating backups from the server
- it minimizes the amount of time required for the web server to deliver web pages to the user
By it maximizes site portability, I mean that with a static HTML site, I can migrate the site from one hosting company to another with a simple copy operation.
And there is no need for creating backups from the server because the master copy of the entire website exists on my computer which is itself backed up.
Selecting A Light Weight CSS Framework
Rather than coding up my own CSS framework, as I had done in the past for several websites, I decided to make use of a production CSS framework. This approach offered many benefits. In terms of time, this approach minimized the amount of time I spent on development, coding, and debugging. It also provided access to a wealth of examples that other web designers had come up with, as well as discussion of the issues they had encountered.
Some examples of CSS frameworks are Tailwind CSS, Foundation (originally ZURB Foundation but migrated to being an open-source project several years ago), Bootstrap, UIkit, and Bulma. I did have experience using the Bootstrap framework, having used it to build an earlier version of the Chicago Society for Space Studies website but opted not to use it. The downside of Bootstrap was its size - which can also be considered as being a proxy for complexity.
For my website redesign, I decided that limiting my search to lightweight CSS frameworks would be the best approach. The challenge was to strike a balance between a framework that was lightweight and a framework that had a sufficiently rich feature set. I also wanted a framework that had a well established community of users. Examples of lightweight CSS frameworks I considered are Pure CSS, Foundation, and UIkit. With a lightweight CSS framework as a top criteria, the following table lists several frameworks along with their associated file size.
| CSS Framework | CSS File Size - KiloBytes |
|---|---|
| Tailwind CSS | 2092 kB |
| Bulma | 207 kB |
| UIkit | 256 kB |
| Bootstrap | 164 kB |
| Foundation | 134 kB |
| Pure CSS | 17 kB |
Table 1. CSS Frameworks compared based on File Size
For the record, I conducted this evaluation in late 2021. If I undertook a CSS framework evaluation today, I might come to a different conclusion. My investigations led me to choose the Foundation framework. Having settled on Foundation, I then spent some time learning the framework and experimenting with its CSS classes. Once I was comfortable with my knowledge of the code, I then undertook the task of developing and testing different designs. It wasn't until the fall of 2023 that I began serious work on finalizing the website's design.
Perhaps surprisingly, choosing a CSS framework was far easier than choosing a website generation method.
My Original Website Generation Method
In Part 1 of this article I wrote that the Artsnova website was a combination of two site generation methods. The first and original website was a hand-coded, static HTML site with absolutely no production automation. Everything was done by hand (hand-crafted as Starbucks might say). At the time I did consider WYSIWYG (What You See Is What You Get) site editor options but I did not at all like the HTML code they produced nor the constrained workflow. I did experiment with using Adobe Dreamweaver as a website creation tool but was dissatisfied with the experience. Prior to establishing the Artsnova website, I had been using NetObjects Fusion professionally to create websites on the corporate Intranet. I also recall that at one time I had been asked to evaluate Microsoft FrontPage as an alternative for producing websites. I think the grade I assigned to Frontpage was 'F' given the combination of its feature set, the GUI, the production workflow, and the abysmal code it created. While Netobjects Fusion was a dream site creation tool compared to Microsoft Frontpage, I still personally preferred the flexibility and optimized code I was able to create using a hand-coded approach.
The second production method I used was Wordpress. After the Artsnova website had been live for a few years, I decided to add a blog and chose Wordpress as my CMS (Content Management System) of choice. At the time I felt that migrating the hundreds of static HTML web pages that already existed into Wordpress was more work than it was worth and that it would be easier to just create a Wordpress theme that mimicked my existing static website design. The obvious downside of this solution was that anytime I changed the design of the static HTML website, I had to reproduce those changes within the Wordpress theme, more than doubling the amount of work I had to do.
Selecting a New Site Generation Method
A central objective of this redesign was to fully unify the two parts of my website: the static HTML pages and the dynamically generated Wordpress blog. From a top level perspective, this resulted in my having a fundamental choice to make.
Option 1: Go with a dynamically generated website, ie picking an online content management system like Wordpress.
Option 2: Go with a fully static HTML website online and use some offline site creation method.
Selecting option 1 and a dynamically generated website would mean choosing a server-based software package to manage the site. My background with Wordpress effectively made this the default choice. Given the priorities I identified earlier, this was not an option I wanted to consider.
Going with a fully static HTML website (Option 2) was the clear winner but one that resulted in a further down-select process. How would I generate the static HTML website? As I saw it I had three options:
- Manually hand-code the entire website
- Use a static HTML website generator software application
- Use a WYSIWYG website editor application
It was at this point that I began to evaluate various static website generators. For a better understanding of what a static website generator is, I recommend the Cloudflare article What is a static site generator? Whatever software application I chose would have to be one that was available on both Windows and Linux OS platforms as I have a foot in each OS camp. (Note: the time is overdue for me to get a new desktop. My current desktop is running Windows but given how badly Microsoft has done with Windows 10 and Windows 11, I will most likely abandon the MS Windows platform. As to my laptop, my current laptop is running Linux, as was my previous laptop. And note that Linux is not without its own set of problems.)
What made the selection of a static website generation application challenging is the surprisingly large number of options that are available. For example, there are 460 generator options identified on the web page A Definitive List of Static Site Generators - and while this list says that it is 'definitive', it is not comprehensive.
Keeping an open mind, I did initially investigate the more standard WYSIWYG site builder options. As I mentioned, in a different age I had used NetObjects Fusion software to build websites offline. In searching for a modern day alternative, I most seriously considered Publii - a static site CMS that runs on both Windows and Linux. After investigating I decided not to pursue the Publii option but that is only because of my unique set of circumstances. Someone else could easily come to the opposite conclusion.
Another newish option that I had no experience with was that of the Jamstack system. My experience had always been with the LAMP stack. LAMP is an acronym for Linux-Apache-MySQL-PHP. This is the software stack that is used to run web servers and is the most popular web server software stack. I was intrigued by the Jamstack option and seriously investigated it.
The 'Jam' in Jamstack stands for Javascript, API, Markup and represents a new approach to web development. Even though I had decided that I did not want the actual website to be dependent on Javascript programming and libraries, I was willing to investigate the use of Javascript as the foundation for an offline content management system. A wonderful resource for starting an investigation is the Jamstack list of site generators. At the time I did my initial investigation, their rank order list (note that the list now uses Github stars) of the top website generators was:
| Site Generator | Popularity |
|---|---|
| Next.js | 60.5 |
| Hugo | 49.6 |
| Gatsby | 48.7 |
| Jekyll | 42.0 |
| Nuxt | 33.2 |
| Hexo | 32.0 |
| Slate | 31.9 |
| Gitbook | 23.3 |
| Docusaurus | 21.2 |
| Vuepress | 18.2 |
Table 2. Jamstack Site Generators Ranked By Popularity (old data)
Of the site generators listed above, the one I settled on was Gatsby. I downloaded it, installed the software tool chain needed to get it running on my Linux laptop, and did some experimenting. As luck would have it, an online Gatsby conference was scheduled just several few weeks out so I signed up to attend. It was time well spent but one thing that perturbed me was that in the weeks that had passed a new version of Gatsby had been released but it was not compatible with the tool chain that the prior version of Gatsby used so I had to reinstall everything. For me, a chain of software dependencies represented a red flag and with that I abandoned my pursuit of Gatsby.
The Site Generation Method Decision
To summarize my website design decision, I was going to go with a static HTML website that had a single, static CSS dependency - that being a single Foundation CSS file - specifically Foundation version 6.6.3. I understood that by kicking Wordpress out, I would be sacrificing some functionality, but for my website I did not see those Wordpress functions as being important. I do want to emphasize that the plan of action I have chosen for the Artsnova website is unique to my situation. I also have websites that are running Wordpress because I view that as the best option for those situations.
In Part 3 of this article, I will detail the offline static HTML website generation method I decided to implement. But so as not to keep you wondering, I will say that the website generation method I decided on was to create my own offline content management system that combined the use of flat files, spreadsheets, template files, and Python programs to create a flexible website management system that separates content from design and provides significant elements of automation - though not nearly as much as Wordpress.
If you have questions about this article or would like to provide feedback, please do so by using my contact form.
| Return to the Blog Index | This article was published 2024-06-zz and is filed under Computing and Web Design.