A Redesigned Artsnova Website Part 1

GTmetrix website performance report snapshot
GTmetrix website performance report snapshot. Green is good.

It is now 2024 and my deployment of a newly designed Artsnova website is finally a reality. I'm embarrassed to say that this has been a couple years in the making and is long overdue. I'm also embarrassed to say that during this period I have added very little new content to the website and wrote no blog posts. I'd like to share with you some of my thinking with respect to this website redesign.

Website Redesign Objectives

When I made my decision to redesign this website, I had four top priorities:

  1. Unify the main static HTML website with my blog which was using the Wordpress CMS.
  2. Redesign the UI (user interface) and come up with a new graphic design for the website.
  3. Simplify website management.
  4. Minimize website demand on server resources.

Another objective was to move to a new hosting company. I had been happy as a customer of Lunarpages and never had any issues: web hosting worked well and customer support got the job done. But then Hostpapa bought Lunarpages and service went downhill in terms of both hosting and customer support. My hosting plan renewal date then became my redesign deadline - that date being January 25, 2024.

For background, the Artsnova website began life as a static HTML website. A couple years later I decided to add a Wordpress blog to the site. To expedite the blog's rollout I decided to not incorporate the existing website into Wordpress. Instead I developed a custom Wordpress theme so that my Wordpress blog looked very much like the static HTML website.

Operationally this meant that while the Artsnova website appeared to be a single website on the front end, on the back end it was actually two separate websites. Of course this meant that every time I made a site-wide change to either the static site or the Wordpress blog, I had to recreate the effects of that change on the other site in order to maintain a consistent UI/UX (User Interface / User Experience) experience for visitors to the website. This certainly complicated my life hence a redesign that integrated the two sites on the backend was a top priority.

To achieve this boiled down to asking the question of what tool(s) would I use to build and maintain a new, fully-unified website? In addressing this question, I identified my core objectives as being

  1. improving website performance with respect to page load speed
  2. minimize website demand on server resources
  3. creating the most portable website possible
  4. minimizing security risks and attack vectors on the website
  5. having a high ratio of content to code

My investigation led me to quickly rule out using Wordpress as my CMS (Content Management System). While the development of CDNs (Content Delivery Networks) has greatly improved the user experience with respect to page load speed, the other Wordpress challenges are still present. On the positive side, discarding Wordpress meant that I no longer had to worry about:

  • Regularly updating themes and plugins
  • addressing issues that arise when a Wordpress update and/or a theme update and/or plugin update breaks some aspect of website presentation or functionality
  • addressing brute force attacks on login scripts and other security issues
  • regularly backing up the Wordpress system (database and associated files)

Clearly Wordpress does offer a lot of functionality for anyone (individual or business) who wants to build and maintain a website - which is why it is the dominant choice of web developers today. In fact I still have Wordpress powered websites, the main one being chicagospace.org. On the con side, in abandoning Wordpress I am giving up access to the added functionality that plugins offer - although most of the plugins are there to address Wordpress shortcomings.

One alternative I seriously investigated and tested out was that of static site generators and the Jamstack (Javascript,API,Markup Stack) which is a low overhead alternative to the traditional LAMP (Linux, Apache, MySQL, PHP/Perl/Python) stack. The static site generators I most seriously investigated were Jekyll, Hugo, and Gatsby - which I installed on my Linux machine. In consideration of my own unique requirements, in the end I decided to go with my own custom-built offline static site generator CMS that makes use of a combination of skeleton files, LibreOffice Calc spreadsheets (more flexible than a database system), and a bunch of Python programs - to which I am still adding functionality.

Complexity Versus Simplicity in Web Design

What does complexity mean with respect to web design? For me, I classify the issue of complexity vs simplicity into three categories. The first and perhaps most discussed category is that of visual complexity. Examples of visual complexity are too many fonts, too many colors, and too many design elements - all of which make it challenging for a visitor to easily read a web page and quickly find what they are looking for. The second category would be that of interaction complexity. Give me clear, simple, concise, accurate navigation system and I'll be happy. Recall the classic line taken from the web design book of the same name: Don't Make Me Think.

My final category of complexity vs simplicity addresses the amount of code a webpage requires in order to deliver content to the user. What I seek is a high ratio of content to code as opposed to a high ratio of code to content. For me, a high ratio of code to content means more moving parts, more dependencies, a more fragile website (as opposed to a resilient website), more difficulty troubleshooting/debugging, and a greater likelihood of something breaking when one or more components in the chain are updated. Recall how I previously said that I had installed Gatsby on my Linux computer. It worked for all of two weeks and then stopped working because I had installed a Gatsby update which was not compatible with components of the other software packages that I was required to install in order to get Gatsby to work.

As an example of a high ratio of code to content, there is a Wordpress powered website I am familiar with. Looking at that home page, the loaded page that the visitor sees as loaded has 395 words on it requiring less than 3K of character data. As to the webpage itself, the actual page size is approximately 425K. That 425K page size is due to all the HTML, CSS and JS-related code and data that gets loaded in order to display the page and have the visitor able to interact with it. Note that I am excluding the size of images here as that is not relevant to this discussion. So the ratio of code to content data is approximately 142:1 or 142 characters of code for every 1 character of user readable content. For my own home page, there are 2.3K characters of content which translate into 362 words which the visitor sees and reads. Behind this content, the actual page size (HTML+CSS+JS) is 154K resulting in a code to content ratio of 67:1 or 67 characters of code for every 1 character of user readable content.

For me, code simplicity means a faster website, an easier to maintain website, a less likely to break website, and an easier to upgrade/modify website.

You may be asking yourself the question Is there an ideal code to content ratio?. The answer is no. In fact, depending on the functionality a web page needs, a high code to content ratio may be absolutely critical. Personally, as a software engineer, one question I've always asked myself in the course of developing a new program or system of program is whether or not I can achieve the same degree of functionality while using less code. This is particularly important when undertaking creative coding projects where CPU and memory use can be critical factors in the success of a project that requires real-time interactivity.

In the next installment of this series, I'll address the design solution I choose and the process of implementing that solution.

| Return to the Blog Index | This article was published 2024-01-25 and is filed under Computing and Web Design.