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. He had almost no funding to work on it (and I'm not being paid at all for this one), 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.
For any site re-vamp today, web designers generally go for a "responsive" site (one that rearranges itself to work on any size phone, tablet, laptop or desktop screen), use 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 use 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.
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 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 are 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 is 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've recently used GTmetrix which gives me an A-grade on both PageSpeed and YSlow desktop speed tests - that's nice to have, although it does 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.