The British Academy, a secondary level educational institution, located right here in Trinidad and Tobago, came to Abovegroup Ogilvy around August 2010 for a complete re-branding of their identity. A little more than a year later, the entire project is finally coming to a close. Despite the long tiring hours, the mental taxation, and the countless finger cramps from typing infinite lines of code, I have to say that I feel an incredible sense of pride to have been a part of it all.
I should make it clear at this point that I’m a web developer here at Abovegroup Ogilvy and I was tasked with building their re-designed website. My part to play was small in the grand scheme of things but vital nevertheless. After all, what’s a new image without a matching website in this day and age?
It goes without saying that the experience I’ve gained as an ExpressionEngine user, as well as an XHTML/CSS coder from this project has been invaluable. However, in order to truly illustrate the sense of accomplishment and the range of growth I’ve achieved from seeing this project through, allow me to take you on a sentimental retrospective of the arduous journey it took to get here.
I started at Abovegroup Ogilvy in February 2011 as a web developer extraordinaire. Okay, so maybe not extraordinaire but after a few introductory jobs to get me used to ExpressionEngine, I was given the responsibility of developing British Academy’s monster of a website.
Starting the project was easy enough – a few semantic HTML5 elements here, a couple of CSS3 classes there and hey presto! Now, keeping in mind that this is not necessarily a web development blog, I’ll do my best to keep the technical terminology to a minimum. Honestly, this post is meant to share an experience of personal growth and regardless of the medium, I’m pretty sure this is something to which most people can relate.
Planning for web development takes a lot more than most people realize. As I’ve come to learn from this project, a website is akin to a building, it has pages as floors, links as doors, sub-pages as rooms and, most importantly, code as its foundation. You could surely make this analogy with any other abstract, given enough thought, but nothing truly represents the detail with which you need to plan a website as an architect plans a building. I naively thought coding each page as a separate entity was a suitable approach but now I understand, just as an architect understands each floor as part of a collective, similarly a web developer must understand that each page should always be treated as part of a greater whole.
Architects have it easy though (hopefully there aren’t any easily offended architects reading this); after people start using their buildings it’s unlikely that they’ll want to make structural changes to the rooms and floors. Chances are that even if they want to, they can’t, at least not without the assistance of the architect. Web developers, on the other hand, don’t have it that easy. Clients can be fickle creatures; their minds change often and at times, drastically. This is an appropriate point as any to deviate from my architecture analogy. Websites are meant to be a digital extension of a business. As such, they should be flexible enough (an unintentional pun for the web developers reading this) to grow with the business, a fact that I didn’t pay enough attention to when starting the British Academy website. I believe now, that this oversight gave me the biggest problem during development. To put it into words, as succinctly as possible: How much of a website do we leave open to editing by a client?
The content of a website is arguably too dynamic to confine to one set of pages set forth by the almighty developer. As I mentioned, a website should be free to grow and evolve with the business it represents. Obviously, we can’t allow clients to change the fundamental design of the website they’ve willingly paid professional designers to create. Though, as time goes by, they may find themselves needing one or two new pages, they may need to change an image or two, or perhaps, even reduce the number of current pages. For British Academy in particular, the issue was with the photography. The images used to build the website were taken from the photo-shoot we were hired to conduct. It became clear as development progressed that sooner or later the photography would need to be updated. What then? Do they hire us for photography and website adjustments each time in order to keep the clean aesthetic our designers worked so hard to create? Or do we build the website with enough foresight to allow for these changes to be made by the client themselves?
ExpressionEngine is a wonderful content management system. The flexibility it provides is potentially limitless. Thankfully, with enough research, and a bit of a kludge, I was able to manipulate it to fulfill the needs of expansion the website would face. This isn’t a method I’d be willing to repeat and probably never will again. It would be nice to imagine that the future of websites allows for clients to adjust much more than just content. With this being tantamount to your average homeowner creating new extensions, or remodeling his house by himself, it seems unlikely.
With regards to ExpressionEngine, it really is a remarkable piece of software. The online support alone saved me from development purgatory on so many occasions. Its extensible nature also allowed for so many features to be incorporated easily into the British Academy website. The events calendar, for example, was built using an amalgamation of a JQuery plugin called FullCalendar by Adam Shaw and a module called Calendar, developed specifically for ExpressionEngine by Solspace.
So many professionals use ExpressionEngine that massive libraries of add-ons have been developed that allow for a host of additional features. The automatic resizing and caching of images (Image Sizer by David Rencher) and the ability to create complex image galleries (Channel Images by DevDemon) both proved to be particularly useful.
Although it would be easy for me to blather on about the barrage of issues I faced while building British Academy’s website, I think I’ve shared the most important lesson that I’ve taken from it all - the mark of truly great work is the time and care involved in its planning. This is something that can be taken for granted so easily when building a website. It’s easy to let knowledge of code and technical ability over-shadow the simple ability to step back and appreciate the magnitude of a project from start to finish. For those not actively involved in the development process, it’s easy to assume that making the magic happen, happens by, well, magic.
My confidence as a developer has grown since this project landed on my desktop. My technical ability has also prospered, but it all pales in comparison to the maturity I’ve developed when approaching new projects. Hopefully, I’ve succeeded in shedding a bit of light into the thought process behind building a website. If nothing else, I’ve brought some more awareness to the depth of thought involved. It’s been an invaluable experience. I’ve taken all that I can from it and look forward to the next project that demands I adapt my methodology to see it through.
Posted in ProgrammingWeb Design on 20th Sep 2011