Artists & Craftsmen of Pittwater website
ACOP has been a fascinating website to do because for the first time, I had an existing website done by someone else, and my task was to update its design and content.
Now, I really don't want to criticise the previous person. When he wrote it in HTML4.01 around 2011 or 2012, he had almost no funding to work on it (and I'm not paid at all), and he was getting no co-operation from the organisation's members to provide any new content. So what he'd achieved in the circumstances was pretty good.
When I set out to do the site re-vamp in 2014, web designers had just changed to going for a "responsive" site (one that rearranges itself to work on any size phone, tablet, laptop or desktop screen), using CSS3 to embellish the visuals (because older web browsers will automatically ignore anything that they don't understand, thus just leaving out the fancy stuff), and using web fonts to improve the default Arial and Times New Roman typography (because the Google fonts are free, and because even very old web browsers support web fonts). So that's what I did.
The site's layout (menu header, slim footer, wide main content column and member menu in the narrow right column) was working well, so I kept it. You can see the old site here in the Wayback Machine. Drupal already provided a responsive layout for the old site, with the right-hand menu column moving to the bottom of the page on phones, so I set up the same behaviour by using Ryan Brill's Liquid Layout CSS. This is common practice, and Google has a name for it, they call it a Mostly Fluid responsive web design pattern. Doing this makes web pages particularly long on phones, so that scrolling back up to the top of the page to get to the menu is a real pain, so I added a Scroll To Top button as contributed by Robert.
Getting a usable menu on the scarce screen area of phones really needs the menu to display only when asked for, which makes it still a pain. This used to be done in JavaScript or jQuery, but by 2014 there were now well established HTML/CSS-only solutions using the checkbox hack out there, and I adopted the one by Michael Billard. By now, people are so used to the three horizontal bars icon that most know it means to click here for the menu, but back in 2014, I played it safe and used text, because for an art/craft website, I hardly expected early adopters to be the main audience.
What I felt did need an update was the colour scheme, which to me, had a grey feel to it. So I decided to base a colour scheme on the colours of Pittwater. I adopted a CSS3 gradient for the menu background, using the local ocean colours of blue and green, with a fall-back to blue for older browsers. A pale sky blue worked well as content background, and I used a deep blue (the colour of Pittwater itself) for the borders and also for the footer. The obvious other local colour to use for the site background was beach sand, but I found that a plain colour didn't work well, so I searched DeviantArt and found a great collection of wallpaper textures by Giles Hodgers- and paid him the whole six dollars or so that he asks for commercial use of his entire collection.
As for the web fonts, I rather liked Chewy (which was already used on the old site for the page titles), so I kept it, but in a darker shade of blue (to improve the contrast). For the other fonts, I didn't do anything original, I followed the guidelines by Jeremiah Shoaf, who says that using Roboto for the menu and Open Sans for the content is now pretty much standard practice.
Working out how to display the galleries of members' work was a problem. There were so many good gallery plug-ins out there (virtually all written in jQuery) that there's no point in trying to write your own. I eventually decided that Fotorama by Artem Polikarpov was the best for the purpose, because I wanted a manual slideshow with thumbnails (like the old site). The only penalty was that Fotorama doesn't support IE6, but even Microsoft now run their own Counting down the end of Internet Explorer 6 website, which says that IE6 usage here in Australia is down to just 0.3%. So I wrote a Fotorama plug-in for CMS Made Simple's Gallery module, and one of these days, I'll get around to sharing it.
The old site had recently been updated with contact details for members, with a few email addresses exposed to the web. So I needed a contact form to replace that. There is a contact form template in CMS Made Simple, but it only allows one email address, and the documented solution was quite complex (hence risky that it might not survive the next CMS software upgrade). So I searched for other people's solutions, and found Joe Pettersen's Contact Form and modified it extensively, by using PHP instead of jQuery to do the input checking, and adding select case statements to contain the name and email address data. The result is a bit clumsy (in the sense that it mixes software and data) but works fine, and is easy to maintain because it is a single PHP code module.
The person who had recently taken over the content on the old site had already updated much of the content, but we both felt that it needed more content to tie it to the local area, so I wrote an About Pittwater page, and realised I could point out that Pittwater has Australia's third largest scheduled ferry network (after Sydney Harbour and Brisbane River). I don't think that's generally known, and it was a nice tie-in with one of my other sites. The problem on this page was getting a good picture to use, and I found a great air photo on Wikipedia, which fortunately has a licence that allows re-use if credit is given.
To test how the website worked, I used Google's PageSpeed, which taught me a lot about how to optimise the page HTML and CSS. I think the site is now just about as fast as it can be, within the limitations imposed by using Google fonts and Fotorama, and by not having different sizes of images for different devices (because it would then be harder to maintain the site). For further advice, I used GTmetrix which gave me an A-grade on both PageSpeed and YSlow desktop speed tests - that's nice to have, although it did not rate as well on phones.
Photo editing for the web can be a minefield, so we don't get the members to do it themselves. We use freeware XnView (on Windows) for all photo editing. It's good enough, because it can do cropping, resizing. metadata removal (and if necessary, manual adjustment of brightness, contrast and colour balance), and it aggressively compresses the output jpeg images. The results are better, and the files smaller, than allowing CMS Made Simple to do resizing itself.
The original site had tried and failed to interest members in setting up and maintaining their own pages, so I decided that the CMS Made Simple limitation of not being able to assign separate edit permission for each gallery page is unlikely to ever be a problem. If it turns out that there are people who want to keep the text on their own pages updated, then this will be achievable, by assigning them ownership of their page, and the page template that I've written will prevent them accidentally messing up the galleries.
I wrote the 2014 update in XHTML, which had seemed to be the future of websites at the time. Since then, I have updated the website to HTML5. Both PageSpeed and GTmetrix keep changing their assessments as the web changes, so I need to keep making improvements, although what appears on the screen may not change.
Although jQuery was once regarded as the answer for creating plug-ins such as Fotorama, W3C and others now recommend writing your own vanilla Javascript, which results in smaller code. It seems the author of Fotorama died in 2023, and it is no longer maintained. For the time being, I'm using the much, much smaller vanilla JS solution posted by The Art of Web a few years ago. I do lose the navigation buttons, but it is so small that both the CSS and the JS can be embedded in the HTML, so that's many less files to wait for - two navigation buttons, the CSS file, the JS file, and the jQuery runtime. Both PageSpeed and GTmetrix really like having 5 fewer files, and the size reduction is impressive - Fotorama was 65kB, and jQuery is 86kB, but this solution is less than 1kB for both the CSS and the JS.
For HTML5, I no longer use web fonts as much as I did in 2014. It has been suggested that perhaps it is safer to let phones use their default fonts, because the phone designer has optimised what looks best on their screen. With this in mind, I dropped the use of both Roboto and Open Sans for HTML5. Visually, there is no difference worth bothering about, and of course the change is liked by both PageSpeed and Gtmetrix.