WordPress: a scalable solution for a magazine publishing business

2,341 views

Published on

My presentation for WordCamp Melbourne, 2011.

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,341
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • WordPress: a scalable solution for a magazine publishing business

    1. 1. WordPress: a scalable solution for a magazinepublishing businessDiscussed by Kate KendallFebruary 2011#wcmelb
    2. 2. @KateKendall // @thefetchkendall.kate@gmail.comkatekendall.com // fetch.org
    3. 3. Where it began...• Worked as a fresh-faced journalist for Marketing magazine (non-technical background)• Spent hours editing with a glitchy CMS• Moved on to digital director role looking after a portfolio over 10 content sites• Left in 2010
    4. 4. The landscape
    5. 5. Niche Media• A small (~55 employees) independent magazine publishing business in Melbourne• Mixture of niche, business-to-business mastheads plus a consumer- focused coupon arm• Titles such as Australian Macworld, Marketing, Desktop, Architecture Review Australia, (Inside) magazine, etc.• Entrepreneurial employee-driven culture (not resistant to change)
    6. 6. The problem
    7. 7. The problem• Each site was taking over six months to a year to build• Each site had a custom poorly-resourced CMS• Editors had to lodge job bags for the simplest of tasks• There was a backlog of work and the developers were stressed• By the time a site was built – a few months later it was already outdated in comparison to the market• Highly competitive industry – being first means something
    8. 8. The problem• The development project management system wasn’t streamlined• There was no action plan – builds often got pushed out by months• The technical and business goals had shifted further and further apart – both sides were constantly frustrated at each other• Editors had to enter contributor’s articles manually as the CMS was too complex or broken• Less focus on the creative and design due to development pressures• The sites were down many times a month
    9. 9. And basically – everything was costing a lot
    10. 10. The big picture• In a sensationalised statement in mid-2009, I posed: “We need to stop building and start publishing. We need content to publish and to get content, we need editors. We need flexibility, we need support. We need to be tenacious and dynamic. We are currently trapped inside a structure that is not suiting our needs. We need a template, so we can start replicating and stop spending money building. The average user of our sites doesn’t care about what is behind it. The average user cares about the content. If we don’t have a site, we don’t have content. If we don’t have the structure, we can’t have content.”
    11. 11. The big picture “Advertisers are attracted by an audience. Audience doesn’t need to be about the numbers, but it’s about the audience. To increase the audience, we need to increase publishing, and increase traffic. We aren’t concentrating on publishing, we are concentrating on building. We’re in a trap, we’ve been building for two years. This time is too long and the longer we spend on building the less time we spend on publishing and building audience. There is never a finite end to any project. If we focus on building, we’ll be building forever. After five unique site builders, we still don’t have one template.”
    12. 12. The big picture “We need a template, so we can start replicating and stop spending money building. The average user cares about the content. If we don’t have a site, we don’t have content. If we don’t have the structure, we can’t have content. We need to start now or we’ll lose.”
    13. 13. The answer?
    14. 14. Awesome tip jar!
    15. 15. Well, rather... “I deal with the obvious. I present, reiterate and glorify the obvious -- because the obvious is what people need to be told.” ~ Dale Carnegie #awesomesource
    16. 16. Media companies using WP• http://wordpress.org/showcase/tag/news/ & http://vip.wordpress.com/ clients/
    17. 17. The dev team• One Ruby on Rails developer• One sysadmin/PHP developer• One front-end developer/designer
    18. 18. The new dev team• One sysadmin/PHP developer• Two front-end designers
    19. 19. Moving to agile• Tried Basecamp, Daylite (CRM), Yammer, email and Wufoo to manage our communication and project management needs – as well as considering/ trialling many other systems• Developers were focused on their version control // code editors and didn’t naturally take to giving attention to the other programs• Many benefits of agile – the increased interaction and physical face time meant for greater problem solving, team engagement and focus• It also meant the wider company could visually see what the dev team was working on and not bombard them with requests
    20. 20. Moving to agile flickr // fright42
    21. 21. Hiring and empowering editors• Print editors were stretched and used to edit both a monthly print magazine as well as posting the odd update for online• Bringing on passionate online editors meant the sites could be given the care and attention needed to build their communities• Having an open source CMS meant less training for current editors working across titles, for new hires and contributors (the universal CMS?)• Editors had more control – everything (including static pages) could be changed by them with no waiting time or cost
    22. 22. Considerations• We had pages and pages of content to transfer over to the new sites and some fields didn’t match (e.g. associated images) – therefore one of the guys wrote a script so the editors didn’t have to manually do it• URL structure changed and was hard to replicate between the old and new sites – concerns about link rot and loss of search rankings• One modified template was used as the base and functionality/plugins added from there• We could build two sites at once
    23. 23. Some work in action – Desktop and Macworld
    24. 24. Smaller sites – Idea Awards and Helinews
    25. 25. Great work by the current team there
    26. 26. And ka-pow! The result
    27. 27. The result• Site traffic increased• Sites looked and functioned better than ever• We could tailor and create custom areas easily – for special editors, partners and advertisers• Developer and business relations improved• Costs were down• And we published more :)
    28. 28. Where might it not work?• Special or complex processes or applications• High traffic sites (although we’ll hear how it can work today)• In organisations bound by relationships and affiliations (proprietary CMSs)
    29. 29. Giving back? Businesses and opensource
    30. 30. Cheers!Now for questions (or the awkward pause time...)
    31. 31. Enjoy your time in Instragram-licious Melbourne!

    ×