Redesign
02 April 2017It was long overdue, but a while back I finally decided to do a major rework of my website. Below are some notes on this redesign, and the motivation of behind various technical decisions.
Section changes
In the past I've always aimed to have 5-6 separate sections, and the result was that some of them ended up being place-holders for material that never got written. This time round I decided I will simply cut out all the dead pages, and defer the decision with what to replace them with until I actually had material to publish.- Landing page
- If this site does go towards being entirely article-driven I would put a latest-X-articles list here, but until then it will remain the cheesy 1990's banner advert (sans link) and some intro text that is not really up to date.
- Sites section
- I concluded that this “micro-site” section that listed three other websites that I basically don't maintain was not very useful, and I didn't want to keep it as a place-holder either. Since the articles of real interest are the how-to guides within the technical section, I had thought about having a jump-table of such guides instead, but in the end felt that it did not add any real value.
- Tech & Misc sections
- I kept these sections as-is, because they are what this website is really centred around, and changes to how they operated I decided to keep out-of-scope. Longer-term I want to change how articles are identified, and perhaps index them differently, but that is future work.
- Picture gallery
- I've always been in two minds about the picture gallery. A lot of it was student days material that I no longer consider appropriate and hence have since culled, and for various reasons I never got around to creating galleries since leaving the UK. If it wasn't for a bunch of pictures I took and sorted of various places in China last year, I probably would have considered doing away with the gallery completely. For now it (once again) survives..
- Links section
- The links section is now gone. I never really maintained it, these days people resort to Google rather than looking at lists of website links, and it was starting to attract requests for addition from people I assume where after SEO. Link pages is really one of those things that was in fashion back in the 1990s and early-mid 2000s before everyone started having their own domains.
Website appearance
From quite a bit of digging the current appearance dates back to July 2009, which was roughly when I bought in the articles system, but how the site evolved before then is now guesswork. I think this 2009 rebuild is a graphically-enhanced version of a design I think dates back to Q3 2003, which in turn shows design traits of a website I built in 1998. I have found HTML files I wrote dating back to April 1996, but that depth of history is beyond the scope of this write-up. All I will say is that back in the 1990s things were a lot more experimental.Prior to the current update the website had three views that were semi-independent, which in part was down to hysterical reasons related to bad standards compliant and expedient use of website program code. However they have all been cleared out in favour of two views that only differ in CSS, as I felt it was time for a clean break with the past, and having to take account of three separate website views was one of the two major sources of inertia. It was time for a clean(ish) slate.
The php-index
I think the “PHP Index” dates back to 2006, and it was originally introduced as an alternative to the main frames-based view. Ten years ago CSS was still pretty much a joke for anyone who cared about cross-browser compatibility, and even back in 2010 when I finally stopped using frames in favour of CSS-based layouts MSIE6 was still officially supported so the PHP Index was maintained as an alternative Javascript and tables-based view for broken browsers. These days even Microsoft considers MSIE dead, and even with the supposedly all-new “standards based” Edge browser, Microsoft's browser popularity has continued its long-term decline, and some surveys put it at below 5%. Good riddance as far as I am concerned, but since search engines preferred the PHP Index I kept it during the last refurbishment. It was nevertheless a headache to maintain, as it required URIs in common HTML snippets to take account of the rather different locations they may be included from. It was in part propagated because the navigation layout and underlying PHP code used for the mobile view had quite a lot of commonality with the PHP Index. It was finally the time to sweep this all away and let a bunch of PHP-based redirects force search engines to update their indices.Mobile view
The mobile view is the most recent view to be introduced, and it came about because the side menu was somewhat inappropriate for a portrait-orientated mobile screen. It was modelled after the PHP Index in terms of navigation and implementation, since at the time it was the path of least resistence. Since the PHP Index was getting the chop I did not want to maintain multiple parallel navigation structures, and since menu items were no longer images the bandwidth requirements of the remaining views was basically going to be the same. As a result I wanted the only difference between the main site view and the mobile view is to be the CSS. The redirects for the PHP Index as it happened would be identical for the Mobile index, but by that point things were already decided.Although there are several way for a site to automagically give either a desktop or mobile view based on what browser is being used to view it, this was on the whole a seemingly non-trivial task. In partiuclar i wanted it to be easy for a desktop browswer to opt for the mobile view and vice-versa. In order to avoid headaches with relative URLs (i.e. http://www.remy.org.uk/mobile/ was out) and to take account of the above concerns, I decided to adopt the convention of putting the mobile site under a seperate virtual host, in this case m.remy.org.uk.
Construction decisions
In doing this rebuild, there are several ideas that drove choice I made this time round. Some things I decided to change, whereas other things I decided to keep the same. The main thought are discussed below.The menu
One long-standing source of inertia for the website as a whole was the use of graphics for the menu, as it resulted in any change in section headings being a major undertaking. Even though I still had the GIMP project file and ImageMagick image slicing scripts, this time round I decided I was going to do away with menu graphics. My original expectation was to have a completely new look using a font that was freely available for non-Windows systems, but almost by accident I found out that CSS3 was able to do a shadow/highlight effect that closely resembled the effect I used previously, so I ended up reimplementing the same look in CSS. With menu items no longer represented using images the loading footprint of the site, in both terms of bytes to download and the number of resource requests, was about halved. It was also apparent that it would be possible for the main and mobile sites to only differ in CSS, which was a major objective from the start. It was only at the last moment I then decided that the fall-back Google Font I had selected would in fact be the primary typeface, as my thinking was tending towards wanting a fresher look.Search-engine-friendly URLs
I made a move towards having technology-neutral “friendly URLs”, because in the longer-term that is the direction I want to take the whole site. I have wanted to change the system used for article access for some time, and in the process change how article IDs are encoded, but backlinks sorta derailed that plan in the past. Article IDs are currently a Unix timestamp which is a source of headaches, especially when I was in New Zealand as the original code did not properly take account of time-zone differences. For now I decided to keep article links out of scope. I moved the picture gallery over to friendly URLs as it is a section I'm not really fond of people linking to and I am unsure whether I want to keep it at all. I am a big believer in persistent URLs, and for now I think it enough to let the changes resulting from the mobile and PHP-Index view changes settle down.Switch to HTML5 & CSS clean-up
I am not sure how old the oldest HTML on the site was, but there was a definite accumulation of artefacts particularly in the older technical articles, mainly as a result in changes to how styling was done. The most obvious examples being the various different ways source & script code listings were handled, and a lot of embedded CSS to remove unwanted padding. This time round I decided that I was going to switch to HTML5 and enforce a single set of styles throughout the entire site. At some point in the past I considered a switch to XHTML, but at the time it felt overly restrictive and had little gain to show for all the effort. This time round HTML5 seemed the way to go as it had dispensed with a lot of historical baggage such as the verbose DOCTYPE tags and using meta tags for language.
In the process what surprised me is how much broken HTML came out of the woodwork. In some older articles quote marks and currency symbols were not-too-surprising errors, but the number of issues with the syntax of links was surprising. Not dead links but links missing the http:// prefix and in some cases the links being empty. 11 years of HTML is going to have a few skeletons, but some of these were in relatively recent articles. Suppose it happens..
Choice of web-server software
Historically I've used Apache because all the lightweight alternatives I tried over the years always missed one or two features I required at the time. At one point I had an interest in Cherokee, which I suspect was circa 2007 based on excerpts from some FreeBSD 6.2 notes, but it lacked SSI support which at the time was an important requirement of mine. I did at one point write my own SSI implementation, but have no idea whether I ever deployed it to a public server. Think in the end concerns over whether Cherokee was being maintained made me give up on it. Later on I had an interest in Lighttpd and in this case I know I used it on public-facing servers, but I eventually became disillusioned with the attitude of its developers. To me it looked like a one-hit-wonder aimed at being the front-end of single-domain sites, and in the end I ditched it because I got fed up of its half-hearted attitude to deployments that stray from this narrow path.I summary I ended up using Apache for longer than I really ought to have, basically because all the alternatives were deficient in one way or another, and it was something of a headche to build & configure. Eventually I dropped it in favour of Nginx back in 2013, and I think now Nginx is the only web-server software I use. Nginx has its own quirks, but in the time since it has done everything I wanted out of it.
Choice of technology
For all its faults PHP is still by far the best fit for my requirements, mainly because it is the only FastCGI-capable technology I am aware of where the script files are kept alongside the static content. The site layout and much of the content is static with article content being in flat files rather than a database so using the filesystem for structure works out well, and PHP is the only major technology I'm aware of in the Unix world that is code-within-HTML. In the past I have shifted website logic off-line, and if it was not for article lookups using URL parameters (i.e.tech.php?tech=xxx) the whole site could be implemented statically using Server Side Includes (aka SSI). The main issue is that it might need a bit too much trickery in terms of symlinks & internal URL rewrites. This would be a bit of a turnaround, as in the current rebuild the few remaining bits of SSI were actually removed.
Language-wise I would prefer Python, since PHP is a language I am now quite rusty at, but all the Python-based offerings I have come across would require putting website business-logic into an application server. I am less adverse to this than I was in the past, but from some basic prototyping using flup I suspect it uses significantly more memory than PHP. In the grand scale of things the difference probably does not matter and I might not actually be making a fair comparison, but I would still have to run the PHP daemon because of other websites on the same server. A switch from PHP to Python in itself would be a major changeover. For now it is a kick into the long grass.