Sorted

Sorted - homepage

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

Size: 30+ new page templates, 16 popup modal screens and page structure/header/nav tabs for 10 calculator pages

Government status: Government-funded (independent) organisation

My professional status: contractor at Chrometoaster

Website client: Commission for Financial Literacy and Retirement Income (formerly the Retirement Commission)

Dates: August 2011 - January 2012

Categories: Front-end developer, Govt web standards tester, CSS-based layout, CSS3, jQuery/JavaScript, e-govt/WCAG compliance, Drupal, Government websites, Large sites

Brief: the Sorted website, with its iconic mouse branding, provides money planning and savings information for Kiwis, with advice and help in managing money, getting out of debt and planning for retirement, and includes a range of interactive calculators as well as written content.

The Commission has an ongoing relationship with Chrometoaster, who designed and developed the original Sorted website. I was invited to join the Chrometoaster team to help them with a complete re-design and rebuild of the site.

This was a complex project, with a large number of templates having been designed, and a team of three front-end developers (me plus Dan and Bas from Chrometoaster) all working together on the new site. Dan and Bas concentrated on the calculators, and all the other pages were my responsibility. The page templates were integrated into Drupal 7 by a team of developers at HeadFirst.

Ali - the client loves their site, and they are running TVCs as of Sunday night, so it's all go. Anyway, a big thank you to you for all your effort on the build - I know it wasn't easy at times. Thank you also very much for doing all those print stylesheets for us – it is _very_ much appreciated. It was great working with you, as always, and we’ll see you again soon. I hope we can work together again sometime.

Nina Spence, Senior Project Manager, Chrometoaster

Achievements:

  • Worked very effectively as part of the Chrometoaster dev team, one of three front-end developers on this project, and managed to avoid overwriting anyone else's code by the sensible use of subversioning software
  • Took complete responsibility for the front-end dev of all the content page types on the site (30+ templates in total), leaving my colleagues free to focus on the calculators
  • Successfully built and fully tested the full set of templates at the same time as they were being integrated into Drupal by the dev team - which, as anyone who has done it can tell you, is no mean feat.

My responsibilities included:

  • Building 30+ different page templates in pure CSS and XHTML 1.0 Transitional, including sample content and unique layouts for each template - as well as the chrome, background layers, header, footers and navigation elements for the entire website
  • Building 16 popup modal screens in pure CSS and XHTML 1.0 Transitional
  • Building tabbed navigation elements for 10 of the calculator pages in pure CSS and XHTML 1.0 Transitional
  • Hand-coding to a high level of accessibility, and following NZ e-government Guidelines (WCAG 2.0) as far as possible (some aspects of the website, including calculators and My Sorted bookmarking require JavaScript to be enabled)
  • Ensuring that each of my CSS styles were written in a consistent and logical order, as follows:
    1. positioning styling
    2. dimension styling
    3. color styling
    4. font styling
    5. box model styling (inside to outside)
    ...and compiling an order list of all possible style attributes, which I used consistently and shared with Dan and Bas
  • Re-using and refining form field and button styles that Dan and Bas had developed for the calculator pages, creating my own variations where necessary
  • Incorporating a range of CSS3 effects within my stylesheets including linear-gradient, border-radius, box-shadow, and transform:rotate - all of which had to work in (almost) all the browsers on our test list
  • Using CSS3 PIE plus various filters (including AlphaImageLoader and Matrix) to get IE7-9 to display CSS3 styles (and IE6 to display PNG images) properly
  • Initially we also used PIE to target IE6 but eventually decided not to include it because it slowed down page loading too much; so I also ensured that IE6 styling/display was as close to the original design as possible without the CSS3 enhancements, in the same way as I created fall-back CSS styling for IE7-9 for situations when JavaScript was disabled by the user
  • Styling both the custom typefaces used on the site (embedded using Fontdeck) as well as the fallback web-safe alternatives
  • Writing a small amount of jQuery myself, requesting other jQuery elements from Chrometoaster's programmer and incorporating various jQuery effects into my code - and liaising closely with Chrometoaster's jQuery guru who programmed these complex elements, to ensure that my code would work for him
  • Creating styles that would allow the jQuery to provide progressive enhancement while still allowing complete accessibility for those users with JavaScript disabled
  • Restyling the jQuery UI tabs that were used for the tabbed sub-navigation on various pages and calculator screens - and ensuring that the JavaScript-disabled fallback styles were fully accessible and aesthetically pleasing
  • Extensive testing of the site at all stages of the development process, and ensuring consistency across the following browsers and platforms; using VirtualBox to host the range of test PC operating systems and browsers required:
    • PC (Windows7): Internet Explorer IE9
    • PC (Vista): Internet Explorer IE9, IE8
    • PC (WindowsXP): Internet Explorer IE8, IE7, IE6; Google Chrome (latest), Firefox 3.6, Firefox 4.0, Firefox 7.0
    • Mac (OS X 10.6): Firefox 3.6, Safari (latest)
    • Mobile - iOS (iPad, iPhone)
  • Ensuring that all my templates and modal screens were validated using the W3C Markup Validation Service and that they conformed to XHTML 1.0 Transitional requirements
  • Setting up a local version of the site templates on my Mac using MAMP and Versions (a Subversion client) so that I could view the pages properly using my Mac as a server, and integrate my work seamlessly into the much larger Chrometoaster version
  • The creation of a CSS print stylesheet tested across the full range of browsers and operating systems - making the majority of the print stylesheet design decisions myself, based on an initial basic set of styles for the general content page template from Chrometoaster's designers
  • Taking part in progress meetings with the Chrometoaster and HeadFirst teams, as well as in-house progress meetings with Chrometoaster designers, front-end developers, project manager and programmer
  • Liaising closely with Dan at Chrometoaster who was organising our massive task list, to ensure that I completed all my tasks, that our techniques retained a good level of consistency across the site, and that the three of us minimised the possibility of overwriting each other's code or creating time-consuming conflicts in Versions
  • Updating Redmine (our bug-tracking software) on a regular basis, both to provide a record of my progress on the tasks assigned to me, and also to ask and answer questions and request actions, fixes and changes from the Chrometoaster and HeadFirst teams
  • Liaising with various HeadFirst programmers and support staff in order to ensure that they didn't break my code during integration and that any fixes I needed them to do were actioned as quickly as possible.

Dan broke the job down into a range of tasks for each template, and these were delivered to HeadFirst on an ongoing basis so that they could be integrated at the same time as we were working on the front-end dev. Feedback from HeadFirst in terms of any tweaking that needed to be done was also carried out at the same time.

In the early stages I was able to build my page templates as static, stand-alone pages - within the dev environment but not yet integrated into Drupal 7. About a month after I started, HeadFirst had built enough of the backend for us to be able to test my templates within the CMS, and from that point on I worked on a combination of statics, semi-integrated and fully-integrated pages and broken-up page elements.

When the project began, Drupal 7 was very new (and quite different from previous versions) so it was a steep learning curve for all of us, both at Chrometoaster and HeadFirst. Initially it had been suggested that the front-end dev team should work pretty much exclusively from within Drupal (as opposed to building templates in the dev environment using Dreamweaver) - creating the Drupal modules, regions and whatnot as required, but it soon became apparent that this wasn't going to be a practical or efficient way of working, as front-end developers and programmers have quite different skill-sets and areas of expertise.

One of the trickier aspects of working on projects of this type is that the front-end dev and the CMS integration take place concurrently due to tight timelines. This means that templates within the CMS which worked fine yesterday sometimes don't work today because the programmers are tweaking stuff - but they'll probably work again tomorrow once the programmers have completed that bit of work.

My solution is to set up an online testing record sheet, and to test all my pages regularly, watching out for iterative backend changes that affect the front-end display. I track these on the record sheet on an ongoing basis and provide bug-tracking and fixing feedback to the dev team as required (constant communication is vital). This is important, as you're never quite able to completely tick something off as "finished" until the project is close to completion. It does increase testing time, but it's really the only way to keep your sanity and ensure that everything keeps on working as it should.

Drupal 7 integration also produces an enormous amount of bloated HTML code due to Drupal's contextual editing facility, and this, combined with Drupal's technique of breaking every page into many smaller elements, modules and regions, means that post-integration tweaking of front-end code can be somewhat challenging and time-consuming. But then I always love a challenge.

The best way to handle this, in my experience, is to create templates using very consistent, very straightforward and logical HTML and CSS coding - and to make sure that the class names I use are both descriptive and unique to my CSS - so that I don't go picking up any Drupal classes or styles by mistake. As this is my normal way of working, it's not really a problem, but I do feel a wee bit sad when I look at the completed HTML code and see all the extra Drupal divs and multiple classes everywhere. Drupal's not my favourite CMS - but it isn't the worst I've worked on (that honour goes to Plone!).

I learned a whole heap of new stuff during this project - using CSS3 for various elements was something I'd only dabbled with once before - on the Batucada website - and Dan was a great help in getting the three of us on the same page in terms of CSS3 techniques and tricks.

I had a great time working on the Sorted project, despite an occasional frustration with the CMS. The Chrometoaster team are lovely people to work with and I really appreciate their very high levels of perfectionism and attention to detail. Contracting for them always brings out the best in me, and I look forward to working with them again in the future. The design of the new Sorted website is gorgeous - Dave, Aaron and Ben at Chrometoaster always do such beautiful designs - I just love the new Sorted "world" and the new mice are fab!

Awards

Bronze medal, 2012 Best Awards

The Sorted website was a finalist in the 2012 Best Awards, in the Interactive - Large Scale Websites category. The Best Design Awards is an initiative of The Designers Institute of New Zealand, and is the annual showcase of excellence in graphic, spatial, product and interactive design. The winners were announced on Friday 5 October 2012, and the Sorted website was awarded a Bronze medal. Well done guys!