Museums Wellington

Museums Wellington - homepage

Website: museumswellington.org.nz (site has since been redesigned) - view screenshots

Size: 22 templates, 50 pages

Government status: funded by Wellington City Council

My professional status: independent web designer/developer

Website client: Museums Wellington

Dates: July - December 2010, with ongoing support after delivery

Categories: Scoping/pitching/quoting, Client liaison, Project manager, IA & UX, Website designer, Front-end developer, Govt web standards tester, Writing for the web, CSS-based layout, jQuery/JavaScript, e-govt/WCAG compliance, HTML email, SilverStripe, Government websites, Small sites

Brief: Museums Wellington are responsible for three Wellington museums - the Museum of Wellington City & Sea, the Cable Car Museum and the Colonial Cottage Museum. Each museum had its own website, none of which matched each other or the new Museums Wellington branding.

Their aim was to bring all three museums plus Plimmers Ark under the same umbrella website, and to use their new branding as the basis for the overall site design.

Shelley Masters had already done the rebranding for print and signage for all three musuems, and he was asked by Museums Wellington to design the new website. He invited the WebWeaver team to do the information architecture, the front-end development and the CMS integration for the new site, as well as e-govt compliance, QA and CMS training.

Hi Ali, Tom and Shelley! Rave reviews about the website – including “best museum site in NZ". We think it is fabulous.

Kim Young, Marketing Manager, Museums Wellington

Achievements:

  • Made a potentially very complex set of templates easy for the web editors to use by pre-programming as much as possible so that the correct template was automatically used by the CMS, depending on where the page was located in the site tree
  • Had the self-confidence to throw out my CSS half-way through and start again  in order to simplify the build for both Tom to integrate and the web editors to use (and still came in on-time and on-budget)
  • Pushed to build a very accessible website, tested against the WCAG criteria, even though strictly speaking, the site didn't have to be - because I believe all websites should be accessible to everyone.

My responsibilities included:

  • Writing and negotiating the proposal for the website fixed-price contract
  • Creation and refinement of the information architecture and site schematics, including template wireframes and sitemap
  • Project management including the development of design/development timelines within a programme of work and ensuring that the WebWeaver team achieved all our project milestones in a timely fashion
  • Ongoing liaison with the Museums Wellington team in order to achieve all their aims for the site, and to work through a range of technical and implementation issues with them
  • Extending Shelley's website design - including improving the colour contrast for accessibility, streamlining the number of different templates that would be required, and simplifying the layout grid to improve consistency sitewide
  • Development of a set of 22 templates in CSS and XHTML 1.0 Transitional, hand-coding to a very high level of accessibility and e-government compliance
  • Initial testing of the site for e-govt compliance using Firebug, the Firefox Web Developer toolbar, Wave, Ask Cynthia and the Juicy Studio Luminosity Colour Contrast Ratio Analyser, and with reference to the new NZ e-govt guidelines and WCAG online documentation.
  • Testing all the templates against the 62-point WCAG 2.0 checklist to ensure that the website was fully e-government compliant, and providing test documentation to this effect
  • Incorporating dynamic graphical effects using jQuery including accordions, Shadowboxes and table striping
  • Ensuring that the jQuery provided progressive enhancement while still allowing complete accessibility for those users with JavaScript disabled
  • Extensive testing of the site at all stages of the development process, ensuring complete consistency across the following browsers and platforms (Yahoo! Graded Browser Support list for Q1 2010):
    • PC Windows7: IE8; Firefox 3.6
    • PC WindowsXP: Internet Explorer IE6, IE7, IE8; Firefox 3.0, 3.6, Chrome 4
    • Mac OSX 10.6: Firefox 3.6, Safari 4
  • Ensuring that every template and page had been validated using the W3C Markup Validation Service and that it conformed to XHTML 1.0 Transitional requirements
  • The development of a sitewide CSS print stylesheet - tested in IE6, IE7, IE8, Firefox and Safari
  • Building the skeleton site in SilverStripe so that all the pages would be ready for the Museums web team to input content quickly and efficiently
  • Writing a CMS training manual for the team, that described the CMS setup for their website and detailed how to use the CMS to maintain the website
  • Training the team to use the CMS, together with ongoing support as they developed their SilverStripe skills
  • Selecting and resizing a selection of photographic images on the site, from the museums' extensive image library, and providing the web team with a Photoshop template that they could use to make their own images once the site had gone live
  • Ongoing liaison with the Museums web team, to ensure that the new templates and backend functionality were working as expected, and to provide additional HTML, CSS and content graphics as required
  • Carrying out a full content QA of the site once the team had completed the content-loading, to ensure that all content was properly formatted and that the site was looking its best before go-live.

Shelley's design was fairly complex, in that he wanted quite a wide variety of layouts for different pages within different sections of the site. I ended up building 22 templates to show Tom (some of which were variations on the same template but in different areas of the site), so that he could follow the logic and integrate the site more efficiently.

As we really didn't want the client to have to choose one of 22 different page types within the CMS each time they wanted to build a new page, my templates had to be similar enough in structure so that Tom could program a number of these to self-select under the same page name, depending on where they were in the site tree.

I decided to build almost all of the templates with the maximum 5-column layout so that the structure of the HTML was consistent throughout the site (which would help Tom with the integration), and then depending on the design/layout of that particular template, to hide various columns and double the width of others so that the visual display matched the designs. At about the mid-point in my template build I threw away virtually all my content CSS styles and started again so that I could simplify the build and the CSS and so that there would be no unexpected gotchas for either Tom during integration - or for the web editors who had to live with the CMS.

We ended up with a very usable site within the CMS, where the web editors had a certain amount of freedom in the templates they chose to use, while at the same time ensuring that these templates displayed the content the way Shelley originally envisaged in his designs.

This was quite a challenging site design to build, with a wide variety of templates required for different parts of the site, and many combinations of five possible columns in the content area to build and style. I think all websites should be as accessible as possible to everyone, which is why I pushed to get as close to achieving full accessibility as I could, even though we didn't have to (the site is City Council-funded rather than being a government-run site and therefore doesn't have to be e-govt compliant).

I was pleased with the result, and I was also pleased that we were able to make the CMS as accessible as possible (in terms of user experience) for the web editors at the Museum. They took to it like ducks to water, even though it was a fairly complex structure.

A few months after launch, the Museums Wellington team decided they wanted to be able to send out HTML emails to their members and supporters, so Shelley designed one under my technical guidance (because HTML emails are so specific in what they can and can't display). I built it using Campaign Monitor, which is my go-to application for HTML emails.