Wagtail people: Tim Heap
In the first of an ongoing feature where we will be interviewing some of the core contributors to Wagtail from the community, we talk first to Tim Heap, of Takeflight in Hobart, Tasmania.
Q) Who are you and what do you do?
I'm Tim Heap. I'm from Hobart, the (tiny) capital of Tasmania, Australia. I've been a web developer for over 7 years. I recently started working for Takeflight, a new, small web agency based out of Hobart.
Q) What other CMSes have you used?
I've used a few! At my first job, working at Ionata Digital, I was tasked with creating an in house CMS for our clients: Pandani. I made Pandani in CakePHP, and it ran the majority of the sites for our 50+ clients, including many government deparments and large businesses. As the business expanded and got more clients, we outgrew Pandani and its limited extensibility, and we moved to Wordpress. Because of the simplicity and large range of plugins, I was no longer involved in the development of sites requiring a CMS, and concentrated on developing custom web applications for clients.
At that time, we started building larger applications in Python and Django, preferring the nicer language and features available compared to the PHP projects around. We sampled a few Python and Django CMS projects, but never found any that suited our needs: simple to use, for both clients and developers; plays nice when combined with other functionality; easy to add and develop plugins; and friendly and active developers. Eventually, we settled on developing two project for each client project that needed it: A Wordpress frontend for the CMS, and a Django backend for the application. A fairly ugly compromise!
Q) How did you first hear about Wagtail?
When I started working at Takeflight, we decided as a company to avoid Wordpress work where possible. Looking around for a replacement CMS, my boss found Wagtail, which had just had its 0.2 or 0.3 release. We decided to investigate, and have not looked back.
Q) What made you want to try Wagtail?
That it is a Django based CMS was the initial draw. It wasn't Wordpress or PHP! Looking further in to it, Wagtail successfully avoided many of the flaws of other CMS projects: It didnt rely on the Django admin, providing its own attractive and customisable administration; it played nicely with other Django applications, meaning everything could live in the one project; and the developers were active and involved in the growing community.
“With the recent addition of StreamField, the client can even create very rich and complicated content... Rich text editors just can not compete.”
Q) What projects have you completed recently using Wagtail?
The team here at Takeflight have finished some great projects recently:
- University of Tasmania 125 Years timeline, for the celebration of the 125 anniversary of UTAS
- Digital Ready for Business, a government program to help local businesses participate in the digital world
- The Australian Clearinghouse for Youth Studies
- The Typewriter Factory (coming soon!)
We also had a student from Year 9 come in for work experience, and taught him some programming and web development by helping him convert some of our old sites built in other systems to Wagtail. He then went on to create Wagtail sites with our help for his parents business, including making a plugin to help with invoicing and customer management!
Q) What makes Wagtail a good CMS for you?
For starters, it is built with our preferred technology: Python and Django. Not only that, but it is built using good Django conventions, which means it lives very happily along side other Django applications in the one project. Because of this, we can develop applications that integrate both a nice CMS, and bespoke functionality, side by side. Having all the important configuration kept in code makes Wagtail very friendly: no more defining page types in your database through a GUI. This means it plays nice with all our other tools, such as version control, virtual environments, and virtual machines. It is easy to run up a new instance quickly, as all the critical information and configuration is right there in the code.
“Having all the important configuration kept in code makes Wagtail very friendly”
From a client's perspective, the administration interface is attractive and friendly. The interface exposes only those things that a client should be able to edit, so we don't have to tell them "Never change these settings, or your site breaks!" We can configure the administration interface to present a nice editing experience for the client. With the recent addition of StreamField, the client can even create very rich and complicated content, right from the interface, which the front end developers can then format and print out in any number of previously impossible ways. Rich text editors just can not compete.
Q) You’re very involved in the Wagtail community, through answering questions on the Google group to contributing code directly via GitHub. What advice would you give to someone looking to contribute to the project?
Just jump in! There is lots of ways a new developer can help. Depending on your level of technical ability, you can help by editing documentation, answering questions through Google Groups, participate in Github issues, write plugins for Wagtail, or hack on the Wagtail source itself. The Wagtail and Wagtail Developers mailing lists are good places to start. You can see common issues new users have in the mailing list, as well as participate in discussions about the future direction of Wagtail.
Q) What other open source projects do you contribute to?
Wagtail is the open source project I contribute most to. I contribute to Django core occasionally, mostly when I have found a bug. If I'm using one of the many excellent Python or Django libraries on PyPI, and I find a bug or a missing feature, I often send a pull request. Mostly though, I make small reusable components as part of developing at work, and publish those for others to use. These can be found all over the place, but mostly on my Bitbucket and Github pages