2020 Site Redesign
Writing a brief
Been a little longer than I said it would hasn't it?! Never mind...
I always start a new project by roughing out a brief of some kind. It's never too long and detailed as I like to be able to take advantage of the serendipitous discoveries I make along the way, but there needs to be some approximate objectives. I find that stating the requirements, examining the shareholders of the project and perhaps identifying some constraints or possible issues early are all that's needed. Once I get started I tend to use Basecamp's Shape Up process to build each feature or requirement. This provides enough information that I can get started quickly without wasting time on plans that never get referred to again.
- Post articles I'd obviously like to be able to write. This will be longform writing as well as shorter thoughts. No "hot takes" though; I promise!
- Post 'photosets' I don't use Instagram anymore so I'd like a place to share my photography. I'm a big proponent of using photography to tell stories (as opposed to single "bangers" that look great on the 'gram but are otherwise meaningless) so I'll be looking to post groups of photos with some supporting copy and metadata to provide more context to the images.
- Going with the grain of the web This will mean using proper, semantic HTML markup with all the attributes required to be a11y and SEO friendly. Using HTML for markup, CSS for styling and JS only where necessary. A bonus of this approach is that it should be fast and work well for years without suffering web-rot.
- Static pages For the defacto "about" and "work" pages.
- Lists I'd like to experiment with public watching/reading/listening lists. Something that also occured to me was consolidating the hundreds of browser bookmarks that I don't really look at (even though I saved these pages for a reason, so should!) into a public reference on different topics.
- HTML caching Static sites are great...until they aren't. I can get pretty far with my likely web stack of choice (more on that later) but adding full HTML caching will take a lot of load off the application if I ever get a spike in traffic.
- RSS & JSON feeds I'm ashamed to say that my site has never had either. Something I'd like to rectify
- Private posts Again to navigate around my avoidance of social media, perhaps some posts of family adventures and the like which only select people can view. Will require a lot of work relative to the results so may ultimately end up on the never-ending back burner.
- Email digests I don't use much social media, so I'd like people to be able to sign up for email digests at regular intervals (for example once per week, once per month or as new posts are made) without using a newsletter provider like Mailchimp. By building it myself I can keep user's email addresses out of a third party's hands and automate the content of each email.
Objectives & Constraints
I initially thought it might be a good idea to explore "precompilation" as the driving concept of the software design: Optimising the deliverables as much as possible ahead of any requests. However, static sites are pretty much end game in this regard and I've been down that road and found that going 100% static actually creates as many problems as it solves. I think there's real value to having a running application behind a site, even if it *could* get overwhelmed in a traffic spike.
I'm also a bit fed up of all my CSS and JS needing a compilation step. Instead I'd like to concentrate on writing and delivering human-readable code without a compilation step where possible. This improves the value of the code as a learning resource both for me and any one that chooses to take a look at the source code.
I've lately become a big fan of StimulusJS and TailwindCSS, but to get the best out of them you really need to be using Webpack. This isn't the end of the world. At this point I've already sunk the time into understanding it, but I always feel uncomfortable adding it to a project - it just feels fragile and brittle.
Of course I have to weigh this approach against the ultimate performance of the site. Ditching Webpack isn't a valid excuse to suddenly be serving huge assets. This will likely require that I take an extremely conservative view on using libraries and frameworks. Not a bad idea, but it will come with a productivity penalty. As this is a personal project and one where a primary objective is exploring the web as it should be, it's a trade off I'm happy to make.
Representing content as data inside a database allows for templates to generate the precise HTML required, whilst also keeping design and content as distinct entities. (*cough* looking at you Wordpress! *cough*)
Changes to one shouldn't (always) require changes to the other. This seems to be exactly what I want, except that you largely lose the ability to author content without an interface specifically designed for the structure of that content and how fine-grained that data is can be a balancing act. Whilst a nice feature, an online editing interface is a huge undertaking, and I would like be able to at least view my content in any text editor, ideally write it there too.
Using a database for content has always felt wrong to me. It creates more problems than it solves. Content is best represented as markup which is why we use things like HTML and Markdown, the latter becoming the default for most static site generators. Using git to version control your content is a compelling enough reason to store content as markup, rather than data.
The problem is that HTML is cumbersome to type and Markdown loses a lot of it's appeal when you're adding lots of attributes to it - you end up writing HTML anyway.
As mentioned in my first post, I've always marvelled at Paul Stamatious's site and particularly his photosets. The layout and design is incredibly varied and nuanced with lots of small edge cases that make it look just right. I've always wondered how complex his templates must be to allow for all those variations. Turns out he actually authors his site in HTML rather than Markdown so that he has the control over the layout that he needs.
This leaves me in a quandry. I don't particularly want to be writing HTML whenever I write a post, but it does genuinely seem to be the best approach all round. This is something I'll explore in my next post when I start planning out the application
The application will of course require the storage of other data, but I'll hold off on using a database until it's utility can justify the additional dependency. There lots of other ways of persisting data!
The Open Rebuild Begins
It seems that 2020 is the year of the open site rebuild. So far I've watched as Jonnie, Frank and now Nathan put their thought & work process out there for the world to see.
My site isn't more than a collection of a few blog posts these days, but I've had big plans for it since about 2018, at least according to my journals. I've wanted to post more of my photography, share smaller thoughts more often but also have a place for deep dives and series. Inspiration unashamedly taken from Paul's site.
These plans scared me. They are big and imposing, and I struggle to
find make time to even update my Twitter bio. An open, incremental rebuild seemed the perfect solution.
However, whilst I cut my teeth on design, I'm primarily a developer these days, so my public rebuild is going to be a bit different. I'll cover the (minimal) design decisions that I make, but this is going to be about the code that runs the site.
This site has been built 100 different ways at this point - all of them complete overkill considering it's needs. My personal site has always been a place for to experiment with new ideas and test new technologies. Given all this, you're probably anticipating that I start talking about the hot JS framework du-jour, but instead I'll stop you there.
Rapidly moving from designer to developer, I missed a lot on the way, most of which could be considered fundamentals. I spent a whole week with only the most basic of CSS selectors before jumping into SASS frameworks (it wasn't Bootstap...what was the other big one?). I learnt JS whilst building a marketplace with MeteorJS & React (that was a wild ride). Using Meteor meant using Mongo, so I was very late to the SQL party!
I'll be doing my best to follow Jeremy's Resilient Web Design principles, using the native tools of the web to their fullest before cracking open anything more complex. I'll be server-side rendering everything, and I might even stick to using flat files. In short, I'll be coding like it's 1995!
This seems like an odd thing to do right? Well, as I said, I missed a lot of the fundamentals along the way. I learnt pretty much everything I know about development from reading blogs online, and the problem is that most blogs - particularly today - only talk about building with the hottest of hot tech. Those fundamentals just aren't sexy enough to get much screen time, but they are kinda... y'know... fundamental.
That's why I want to build this site in the open, always taking the simplest, most resilient and durable path I can; documenting it all the way with articles, guides and source code. I'll examine my options and explain my decisions as I go. I learnt so much from the open web: it's time I gave something back.
I'm going to be doing this around regular work and looking after an 18 month-old that's just starting to learn his own mind (no easy feat itself) so I can't say how long this will take, or when the next post will go up. I'll try to find a rhythm and make regular updates, but bear with me whilst I find my feet again. It's been a while since shipping anything!
You'll find the git repo with all the source below, along with a link to my (now) old site. In time I'll move the old content over too.
That's all for now!