Gabriel Koen from PMC (Variety.com, Deadline Hollywood) presented “Launches: Lessons Learned” at the recent Big Media & Enterprise Meetup in San Francisco, California, now available with full transcript. 

View the presentation slides below:

I come here from Penske Media I’m going to be talking essentially about our product launches and what’s gone wrong and how we’ve used that to essentially adapt what we do and how we do it.

For those of you who haven’t heard of Penske Media, you might have heard of some of our brands. This includes TV|Line, Deadline, Variety, BGR, entv, Hollywood Life. We run about 30 events, including some that are on, I don’t even remember what, CW I think, and a couple of others.

To give you an idea of what our launch schedules tend to look like over the last few months, everything from new major sections on our sites to actual site redesigns and brand new sites themselves.

We launched mundial section for Variety Latino, a Contenders Awards aggregation section for Variety. Back in May we did a full on site redesign launch for TVLine events, like our power of women event, International Editions on Variety, a new section for our events. And generally, every month we do at least six or so brand new products or sections for our sites. Anything from just a new page, to a new major feature, to brand new site.

So basically getting on to what we’ve done, these are in no particular order. So one of the things that’s the most common that we’ve run into in the past especially is you know, we go through all this trouble launching a new feature, a new section on the site and 3 months down the road we realize hey we’re not getting any mobile traffic to this section.

So obviously, we forget to add a link to it, to our mobile themes header or side bar or you know even forget a mobile optimized version of it.

Sometimes the solution is changing the way that you develop or think about your products in general.

It’s odd but it happens and then essentially we’ve targeted that by we’re making a push to do a responsive theme for all of our sites at this point and I think the number one driving reason for that, aside from higher mobile engagement as the years go on is just that, you have to account for different devices and different sizes when you’re dealing with responsive. You know, it gets bakes into your QA processes and your thought patterns.

So the key take away from that is just not every problem that you encounter has a solution like “oh yeah I need to remember that”, sometimes the solution is changing the way that you develop or think about your products in general. More so than “ oh, I have to remember to do this on launch day”.

Another big one, especially a big problem for sites like ours that are ad-driven for our revenue, we forget to loop in different team members or different people within the organization and then we find out they were completely unaware of the launch and you know, we didn’t think that they needed to know.

So you know something happens like ads don’t even show up on your new section, or the wrong ads show up in the wrong places on your shiny new website design. So in order to combat that we started doing cheat sheets where prior to each launch, we just put together a simple one-sheeter that explains okay, here’s all the key dates, people involved and milestones that are going to get us from the concept to actual page on site.

So the overall take away there is just every team involved knows who else is involved and what other teams are there someone in there is bound to know “hey so and so from the editorial team or from our vince coverage team is gonna need to be involved in this and it just helps circulate the communication there.

We just put together a simple one-sheeter that explains here’s all the key dates, people involved and milestones that are going to get us from the concept to actual page on site.

We have had launches where we forgot to actually turn it on whether it’s actually activating the theme or enabling a core feature for the theme or dragging the widget to the sidebar.

And the problem there is there wasn’t one person who was owning that launch or that feature, that particular thing. So from then on, we just have to make sure that every thing that’s on our checklist, everything that’s happening, has one person that owns it, since we found that everyone on the team may know what’s going on but they may think that someone else is actually going to do it.

And sort of adjunct to that is you know, it’s useful, we’ve found that, you need to have someone who’s, with a small team especially, you tend to get focused on all the little pieces needed to pull the whole thing together, but the way things like this get missed is you tend to not have somebody just keeping the eye on the overall thing or project or launch and just making sure all the piece fit together.

And we’ve had launches where the key stakeholders never actually saw the feature we were building before we built it and pushed it out. So obviously hilarity ensued once actually saw that we launched a major section of the site that they were responsible for or feature that they had to suddenly start populating content for etcetera.

So essentially to combat that, we realized in addition to just making sure that we flip the switch and loop in ad ops teams and editorial teams and what not, we need to make sure that communication was actually part of our list. You know, so at a certain point, it’s like one of the steps is make sure that you know who to communicate this to make sure that you actually get them to review it at certain points.

 From then on, we just have to make sure that every thing that’s on our checklist, everything that’s happening, has one person that owns it

So you know, treating your milestones and key communication points as actually just something else you do just like QAing the feature, just like building it, just you know, every other piece of it.

And one of the last two are kind of some of the more embarrassing ones at least from my point of view. So the times when we broke something and just kind of hoped that nobody would notice while we were scrambling to fix it.

And of course, meanwhile, the actual stakeholder sees it and you know, starts being very vocal about seeing it, which very quickly escalates the situation. So it’s kind of obvious in hindsight, but you just have to you know, own up to what you’re doing. Whether it’s good or bad, when things are going wrong, when things are running late, you just have to make sure that you’re, you know, keeping constant communication going with your key stakeholders for a project.

Key stakeholders, just a sidebar for a second, could be anyone from if you’re launching a new section, well it’s going to the the editor or writer of that section it could be the general manager of the site. Just whoever it is that is most invested in the success of that project or product.

Whether it’s good or bad, when things are going wrong, when things are running late, you just have to make sure that you’re, you know, keeping constant communication going with your key stakeholders for a project

And then I think the key thing that we also learned from it is overall, those, it stings a lot less whenever you go to someone and say “hey we just noticed we did this or something happened, we’re actively working on it and we wanted to let you know and keep you in the loop” than them suddenly looking at their site and seeing a mess, you know.

Other ones are right after our launches. Having the general manager of the site say, “hey I noticed I’m getting fewer page views can you look into it?”

What’s going on? Well many things. We found a couple times where we’ve accidentally blocked search engines from indexing things we had meta tags or robot […] files from our dev sites that made it into production and we just never looked because who would do that?

Other times, we left analytics off of pages, especially when doing ajax operations and you know, things that aren’t a strict load where you still want to track page views or other engagement based off of that.

So essentially what we’ve found there is kind of a two-fold answer because there’s multiple problems there. First, it is not making assumptions. Maybe you looked at something or scanned it at one point and said “oh yeah, that looks good” and you move on.

Or maybe you’re just like, “yeah of course we’re tracking page views on this why wouldn’t we do that?” And the kind of take away that we really got driven home in those scenarios is, product launches do extend past the launch date.

Not only from just keeping an eye on things and just making sure things are working, but just from this point of view of from if you’re a product person, measuring the success of the product or project that you’ve just pushed out.

Is it working? Are people actually using it? And being able to respond to those things that you see, whether it’s in analytics or whatever so, that’s pretty much it.

Just to quickly go over how we at PMC have overall handled dealing with these things we’ve sort of, we start with the idea of let’s just do something and let’s just do it as a small team and see what works and what doesn’t work.

As we make mistakes, we introduce process to combat those mistakes that happen frequently and we constantly strive to reevaluate whether what we’re actually doing is working or not.

So we know that as we grow in size and as our sites grow in complexity, there’s just more process that you have to do to be able to handle these various scenarios. But we also know that process can kind of get in the way and the more process you have, the less likely you are to actually follow those processes, so it’s really finding a very happy balance between the two so that you’re actually being effective with the things that you’re trying to do.

So I’ll just kind of go over these quickly you know, it starts with project planning we typically work backwards and forwards from our launch date to make sure that our timelines meet somewhere in the middle, to make sure that we’re identifying all the people who are involved in the project and getting them looped into the timeline discussions.

We put together our little one-sheeter cheat-sheet with stakeholders, dates, URLs for being able to test things and check things dates, when they can go in and look at it, that type of thing.

We have one checklist for what we need to do before we launch, things like who we need to coordinate with to get on the actual launch time, it’s usually the WordPress.com VIP folks and then we need kind of configurations that we have to deal with.

We have our timeline for launch day, it’s literally a minute by minute calendar with who’s responsible for something and what the status of it is. We use Google Docs for all of this because our company is on Google Apps for business, but previously we used things like Trello and whatever works.

The key to all of this is to make it easy for people to access. Since we’re on Google Apps and using Google spreadsheets, we don’t have to do anything special for someone to log in and see a sheet or someone to edit it or for someone to have access to it.

Then we have our actual launch checklist, just a general overview of what needs to be done and who owns that piece of testing or review and we go through that once right before we launch and once right after we launch.

One of the newer things that we’ve introduced that’s been really successful is our support structure. Essentially we’ve started creating a chatroom, sometimes it’s a Google hangout sometimes it’s a Skype chatroom, it depends on who the stakeholders are and what they use every day.

On launch day, we everybody gets into the chat room, and that way whenever somebody comes across a problem or something, they just type it in or say what they’re seeing and you have that instant one-on-one communication.

We also try and identify one or two key people on the team, like if you’re doing a site launch, it might be the general manager of the site and the lead editor.

They’re the conduit between the writers and the other staff on the site and us so it lessens the noise that goes on on those launch days and our ability to find out what is actually a problem.

So that is basically it. Any questions?

Q: One thing on the VIP team that we’re really bad at right now is celebrating our launches internally So when we put in weeks or even months working towards a launch, we’re not very good at patting on the back and saying nice job, good effort, all that stuff.

Do you guys do anything like that to celebrate the launch or sort of like, boost internal moral?

A: That’s actually a very good point, that should actually be part of this because it’s certainly something that all of us on the team have strived to make part of our launch process. You know, we’ll send out an email and we’ll include the CEO and other people on it just saying “hey, this went live”, if there were people who were really, you know, worked 24/7 to get it out, we’ll make sure they’re acknowledged in that.

Our CEO is actually really great about it as well, he’ll respond and say fantastic job, especially, Amit Sannad or whoever else on the dev team that has been working weeks and weeks to get the thing out.

You know, we’ll usually, it’s tough because we have a distributed team as well, so those of us, like most of the product team is based out of Los Angeles, so we’ll get together and go out and have drinks or something like that.

We just try and, we’re still working on figuring out how to better include the people who are located outside of our office area. So far, we’ve just been making up with small gifts and tokens of appreciation thanks and emails and pats on the back and so forth, but we ‘re trying to find ways to do better on that.

Q: Do you use automated testing at all to help eliminate some of those issues?

A: We don’t. Sorry, he was asking if we use any sort of automation or automated testing to help with these things, and you know the short of it is we don’t. There’s a lot of reasons why we don’t and none of them are really that good.

Most of them boil down to like we haven’t found out how to automatically test for some things. We have introduced some types of automated tests like we have pingdom alerts that look for the ad strings on our various pages so we know if ads aren’t rendering and things like that.

But we’re still not at the point where we’re using any kind of unit testing. We’re not using any kind of selenium or UI testing. It would definitely help quite a bit with some of these things.

Any other questions?

Awesome, thank you.

See the presentations from previous Big Media & Enterprise WordPress Meetups. For Big Media & Enterprise WordPress Meetup groups in other cities, see the full list on VIP Events and join your local group. 

Want more information about WordPress services for media or enterprise sites? Get in touch.

Mo Jangda from Automattic gave a presentation and lead a discussion on Code Review at a recent WordPress Big Media Meetup in New York City now with full transcript. 

So to get a sense of what the room looks like, how many people here are developers? So the majority of people, probably 70-80 per cent. How many people are editorial? A few people, that’s good. How many people are management? You guys in the suits.

If you’re a developer, how many people have a code review process built into their teams right now? Not everyone, which is disappointing. So that’s what I’m here to talk about.

The goal should be to have at least one other person than the person who wrote the code look it over and to review it for things like quality standards, security concerns and performance and so on, things like that.

You can’t code review if you’re doing it live. So, ultimately the goal with code review is basically to improve the quality of your code.

So if you’re editorial, right, the idea is that you’re not going to push something out any sort of published articles without going through the copy editing phase, unless you care about money, in which case you don’t care.

You want to make sure the stuff you’re putting out is good quality, and that’s where code review is – that’s why it’s sort of nice to do.

The goal should be to have at least one other person than the person who wrote the code look it over and to review it for things like quality standards, security concerns and performance and so on, things like that.

So it doesn’t necessarily have to be a junior to senior. It’s a learning opportunity for both, different skill sets as well.

And the secondary goal is you sort of becomes that you’re learning from each other as developers. It doesn’t necessarily have to be a junior developer passing off their work to a senior developer and them telling them basically everything they did wrong.

It can actually go the other way where a senior developer passes off their work to a junior developer and says here’s the code I’ve written,can you look it over and see what I’m doing?

It gives the junior developer an opportunity to look at how the code is being written by the senior developer and learn from them, right?

So it doesn’t necessarily have to be a junior to senior. It’s a learning opportunity for both, different skill sets as well.

The other thing to sort of keep in mind is that code reviews shouldn’t be something else that you tack on. It’s part of the development process, right?

So it’s not something that you should consider a tedious thing that should be going on, it’s something that you should have built into your processes as part of your deployment, as part of your coding, so something you do on a regular basis.

There’s different ways you can do code review obviously. You can have a gatekeeper-type approach. Where you have one person who’s sort of like master of the code review, so every bit of code that gets written goes through that person.

So that person can be a senior person, can be a rotator role so all code goes to that person, they review it, send feedback and iterate on the code that way.

One flow, or one specific approach to code review is not going to work for everyone. So you’ve got to find something that works for you.

You can do some things like peer review, where you have teams of developers put together, so one person is buddied up with another so any time a person needs feedback, anytime a person is finished working on a patch or working on a new feature they can pass it off to their fellow developer and say, hey can you give me feedback.

You can have a committee-based approach, where you have multiple people giving feedback on patches. If you’re using something like Git or GitHub you can use pull requests. GitHub makes it really easy to comment on code, and pull requests and commenting and so on.

You can also do pair programming, which I personally dislike, but it works for a lot of people if you’re into extreme programming or agile processes and stuff like that. You can have people working on code at the same time and the cool feature of that is that you’re essentially doing code review live because you’re questioning each other as you’re writing code.

One person types up something, the other person sort of questions: Okay, why did you write that?

There’s different points in time where you can actually use code review so you can actually start doing code review before writing a single piece of code and you’re essentially talking out the concepts with each other.

You know, we planned out the specs and functionality, we’ve thought about what my classes are going to look like, what my functions are going to look like.

So it’s a good opportunity to actually talk with you, what approach you’re taking to code review, to talk with the person with whom you’re doing the code review to see you know, does this make sense?

Obviously you do things like pre-commit reviews, look at patches, so before you even commit the code send the patch over, send over and review it that way.

It’s a great way for your team to actually write better code and build a more cohesive unit.

We also do post-commits, so once the changes are done, committed, you can review the pull request or the actual committed code.

You can also do post-deploy, so if you don’t actually have time, to do a full code review before pushing it out, you can still go back and do code review on stuff that’s pushed live and make changes over time.

The most important thing obviously is you got to find a flow that sort of works for your team.

So one flow, or one specific approach to code review is not going to work for everyone. So you’ve got to find something that works for you.

Doesn’t necessarily have to be anything very specific. It can be sort of totally casual, like a conversation between two developers.

So it’s pretty important to find something that works for you. You also don’t need fancy tools, you don’t necessarily need to go out and get your own license of Phabricator, which is a code review tool that Facebook has built up.

To be honest, it can just be as simple as two developers passing around a patch to each other. Looking it over.

So it doesn’t have to be complex, but if you want it to be complex, you can.

But you can keep it simple, find something that works for you and so on. When it actually comes to doing the code review, there’s a few things to keep in mind.

Throw your ego out the door.

The most important thing, and this goes for both the person reviewing the code and the person receiving feedback is throw your ego out the door.

There’s no such thing as ego and emotion during code review. That’s the most important thing to keep in mind.

The reviewer is not smarter or dumber than the person whose code they’re reviewing. In the same sense, the person whose code is being reviewed they’re at the same level. So ego is not involved, it’s not supposed to be personal. It’s supposed to basically be about questioning the code, right?

Not questioning the person. So one thing that I usually try to keep in mind while I’m personally reviewing code is that I usually recommend to people is that when you’re phrasing your feedback never include the word “you” .

So it’s not YOUR code, it’s THE code. Right? So that takes away the personal aspect of it and it makes the reviewer feel less attacked.

Because getting your code reviewed can be a very scary thing, but it shouldn’t be.

You should get to a point, where you should actually be proud to have your code reviewed and proud of the code you’re presenting to your teammate, senior developer or boss and so on.

To show that this is the amazing thing that I’ve done, and you know what, I expect there to be flaws.

Chances are, there might not be, but you know, if there are issues with it, it’s something you know, the mistakes that you find, is something that I can learn from.

The other thing to sort of keep in mind, is that you as a reviewer want to be critical about things, right? So question the decision that the developer is making.

Why did they name that variable that way? Is that a valid variable name, right? Why is this function name so long? Can this be abstracted? Right? So design decisions like that can be a good way to root out potential problems in the code.

But obviously, you don’t want to get too caught up in the minor details, so getting caught up on spaces over tabs which we’ve had problems in the past with before, in VIP, where some developers would reject code commits for using space instead of tabs, you know that’s a minor implementation don’t get too caught up on that.

Point it out, but it’s not going to be a blocker. But it’s important that coding standards and best practices are still followed, so it’s important that your team is following those that in your reviews, you’re actually flagging those and so on.

The other thing to keep in mind is as a reviewer, don’t worry about catching everything. ‘Cause you’re not. I don’t mean to brag, but I think I’ve reviewed about 20,000 commits on VIP. Of the many commits that I’ve reviewed on VIP there’s been stuff that I’ve missed and that’s naturally going to happen.

Because manual code review is not going to be perfect. Automated code review is not going to be perfect.

There’s no such thing as ego and emotion during code review. That’s the most important thing to keep in mind.

Things will get missed, things will go live that will break your site. But that’s, an opportunity to learn from so the next time you review your code you’re going to be extra conscious about it and try to find that mistake that you made and try and prevent it from happening again.

So that’s the other thing as a reviewee, you should sort of keep in mind. When a mistake is found, and pointed out to you, you should try and avoid making that mistake again. It’s a very important thing. You should be using it as a learning opportunity, right?

If you are making the same mistake over and over again. Chances are there’s something wrong. Either with your processes or with how you’re developing. That’s something you should work to change.

Never focus on the negatives.

As a reviewer, if you find the same problems over and over again, that’s when you need to question what’s going on with this developer? Why are they not sort of picking up the problems that I’m seeing? Another thing I sort of do, and I mentioned this earlier with not making it personal, try to keep in mind try to stick to the positives, right?

Never focus on the negatives. What’s a good example? It’s important to start a phrase with: How can we do this better? Instead of this is dumb, this is stupid.

So again, avoiding the personal attacks, trying avoid getting too emotional about things and staying focused on this code could be optimized more instead of this code will break your site, things like that.

I think that just about covers it. That’s sort of one of the biggest things I wanted to go over. But also, I guess it’s ultimately important to find something that works for you.

Code review is, it’s something that’s near and dear to my heart because I’ve been doing it for the past three years as a reviewer, it’s the best way to learn best practices and learn new code.

I’ve actually learned more new WordPress functions by looking at other people’s code than I have through just following news and following WordPress codex and things like that.

So it’s a great opportunity for reviewers to sort of look at how other people code or how other people think when they’re approaching problems.

And as a reviewee, it’s a humbling experience and a great opportunity to learn. And ultimately, it’s a great way for your team to actually write better code and build a more cohesive unit to ultimately do cool stuff.

Thank you.

Q: It’s easy to think that if you don’t review everything, then you should just give up because if you’re not reviewing everything, then the problem is going to be in the spot you didn’t review.

So, I think that maybe some of the thought process behind not everyone here doing code reviews I think it’s something that I think everyone wants to do so I was wondering if you could provide tips is there any sort of lightweight code review process? Is there anything that doesn’t require every commit to be reviewed by somebody else?

A: So that’s where I would look at post-deploy commits or post-deploy reviews so reviews don’t necessarily have to block things from going out but you still take the opportunity to go back at some point.

Let’s say you have a work week, you set aside two hours in the week Friday or something where you as a team, get together and review each other’s code, and look at various commits and stuff.

So to give you an example, on WordPress.com, the platform, we have about a 120 or so developers. I may be fudging our numbers. We have a lot of developers pushing out code daily. We probably have anywhere from 60 to 100 to 200 commits going out every single day and we haven’t really actually found a good mix, or good flow for us what makes sense for a code review.

So we end up relying on post-deploy code reviews where the idea is certain developers will take some time on the side, a couple hours a day, a couple of hours a week to sort of look, skim through commits that people have done.

They’ll just look through the log to see a commit message or if there’s a particular feature they’re interested in or that they’ve worked on in the past to sort of give it a quick skim and see if there’s something that they can flag for the developer to work on.

So it doesn’t necessarily have to be a very time intensive or blocking process. Ideally, you want to get to a point where it does become integrated into your development flow but it doesn’t necessarily have to.

To be honest, spending even an hour a week is a perfect starting point.

Q: Is there a good size team for doing code review? Like if you have fewer people,are there better methods? Like for smaller teams, to do it so it’s not interfering, so it’s not just like back and forth constantly?

A: Again depends on your type of workflow and your team dynamic.

In that case, it’s like if you’re using like Git for example it’s a simple pull request is probably a great way to go.

If you’re working on a feature, send a pull request and have the guy sitting beside you say can you take a quick scan. Or if there are specific things that you are worried about, have them look it over and point out specific things.

Like I’m not really sure about this particular function, I’m not sure about how this class interacts with this feature, can you just take a look at it.

So it doesn’t necessarily have to be you’re reviewing the whole commit, just skimming through something and seeing if anything jumps out.

Participant: I have a small addition. So one thing that I find really helps out if you have a definition of the process so for example if you have code review documentation, like what kind of code structure you need to keep, templates defaults you need to use also speeds up a lot of reviews because you can automatically assume the person is following the structure, because they technically know about it.

The easy way to speed it up is to also just I mean ignore JavaScript and CSS, because if you have a lot you can just ignore CSS. If your quality assurance team passes it and it looks fine, also JavaScript if you really don’t have time.

A: I mean for CSS especially, as a code reviewer when I look at the VIP code, I basically ignore CSS, because from my perspective, I care more about the security and performance.

So you’re right, there are things you can sort of ignore, if you are a designer and like reviewing CSS, then go for it. But also, like you said, standards are really important, and processes are really important.

Especially, as you grow as a team, again doesn’t necessarily have to be super formal and super strict, but it helps to have some sort of definition in place so you can follow, your team knows what to do.

So they’re actually trying to have their code reviewed, instead of pushing it live.

Steph: Out of curiosity, how many people here have had Mo review their code?

Participant: He’s the best!

How many of you have had code rejected by me?

Participant: How many people want to beat Mo up after this meetup?

Participant:I’m in

Participant: Actually out code was reverted 2 min before the meetup.

What I usually tell people at like VIP workshops and stuff is that your ultimate goal should be to make me so happy that I would never want to revert that code ever.

We actually revert code once a day. The interesting thing is that if you have some sort of code review process, we actually notice when VIP’s adopt some sort of code review process, internally, so they have someone on their team review their code before it comes to us.

The quality, there’s a significant increase. The number of issues we have to flag, the number of reverts that actually end up happening to that code goes significantly down.

It’s a testament that code review can actually work and keep us happy and keep your code getting deployed much faster.

If you’re not on VIP, still a great opportunity to make sure your team is working together, make sure your team is writing good code. ‘Cause the last thing you want is to push out a security hole and all of a sudden has your homepage hacked the Syrian army or whatever.

See the presentations from previous Big Media & Enterprise WordPress Meetups. For Big Media & Enterprise WordPress Meetup groups in other cities, see the full list on VIP Events and join your local group. 

Want more information about WordPress services for media or enterprise sites? Get in touch.

Ephraim Gregor from USA Today presented “World Cup and WordPress.com VIP”  at a recent Big Media & Enterprise Meetup in New York City, now with full transcript. 

Hi everyone, I’m Ephraim and I’m from USA Today Sports media group. USA Today Sports Media Group is basically a subgroup within the USA Today proper, and we formed about two, two and a half years ago with the purpose of essentially improving and consolidating USA Today’s fairly extensive sports offerings.

Now, when we first started that when we first started that, basically we looked at all our current acquisitions, as we acquired a lot of little many one off, that we thought would be a good acquisition.

It had some interesting moments and so we essentially looked to WordPress for both unified code,easy to use editorial tools a good plugin architecture.

We first of all looked at the code base which was basically pretty much everything under the sun and more and decided that we needed to consolidate, improve and move to one code base. It had some interesting moments and so we essentially looked to WordPress for both unified code, easy to use editorial tools a good plugin architecture and after developing some independent WordPress, we then moved to VIP.

VIP basically allows us to spin up very rapidly and develop across one central theme which we call Lawrence and develop many many small sort of look and feels that we develop and integrate and display modular systems within the WordPress.

We first of all looked at the code base which was basically pretty much everything under the sun and more and decided that we needed to consolidate, improve and move to one code base.

As it says, we have 3-6 styles and we’re adding more every single project with additional integrations as we go on. Sports, specifically, as a data-driven architecture is essentially, interesting because not-only do we have the sort of standard article content-driven approach, we also have to deal with fact that we are trying to deliver, ideally, real-time data about every single sporting event we’re going to report.

In general, right now, our platforms tend to be divided into specific sub categories so we have to have one platform that can deliver soccer, one platform that delivers baseball, one platform that delivers fighting stuff.

So that’s certainly a challenge. So what we’ve done is essentially built off a central theme with multiple plugins to then allow us to turn on and off various sorts of external systems that can deliver this data into the WordPress flow and then deliver that to our users.

So recently I was the lead dev on the World Cup offering we have put up for obviously a sporting event that’s happening right now. What that was, was interesting for several reasons.

First of all, we had to integrate both vendor and internal data to display that with the latest scores, articles, stuff like that. We also had to basically develop a system in place to allow us to display that to the users while maintaining editorial control over that.

A lot of the data was driven by third-party vendor based out of the UK. We also had the problem of essentially turning this into one of our first hub sites. By which I mean, we have a lot of content spread throughout our network. and we wanted to basically flow that content into our own, into World Cup, while also maintaining the fact that these are external links to their own sites and maintaining that sort of multiple umbrella we have.

So what we ended up doing is leveraging both VIP’s offerings and our own, to extend to plugins and syndication things, to build that out into an experience for users that would allow essentially the mobile WordPress flow of content generated by authors directly syndicated to the user, into content distributed across all of our sites both WordPress and non-WordPress and display to the user within the whole post flow, while allowing the user to go to that and go to an external site.

It was interesting. Other things we implemented was also basically increased sort of data migration we had because we basically had the challenge of both integrating the vendor, as mentioned as well as our own data, which we get from various vendors, editorial-driven, code, all bits and bobs.

Generally, the general architecture approach we take for data is to have it stored in external databases and have that be their own CMS that we manage internally as opposed to trying to put that within the WordPress architecture.

We also are starting to move slowly onto other divisions within USA Today, and are seeing a good thing and wanting to get a slice of that pie.

While there is some content that definitely fits, like the custom post types, taxonomies and stuff like that, generally for sports data that’s somewhat unwieldy. So we generally prefer to spin up our own either Mongo or MySQL based solutions.

So our goals going forward is to basically continue operating and migrating our solutions onto the WordPress VIP platform I don’t know the exact count of sites we have right now. I think it’s either between 15 and 20 with more spinning up every week.

We also are starting to move slowly onto other divisions within USA Today, and are seeing a good thing and wanting to get a slice of that pie.

So we are moving Life, Entertainment, that sort of thing as well. Obviously none of this affects, like if you go to USAToday.com. As a whole, that is not WordPress, that might be something in the future. But right now it is a separate platform, but there’s a lot of little subsections that are very much looking and keen on the WordPress as a platform.

We’re also continuing to improve Lawrence as keeping that as a core modular theme, which we’re iterating off and adding new sort of API integrations for our own content and data driven by others, and we’re pretty sure that we can develop pretty much anything within this platform.

So I’m out of time but I will take questions now.

Q: Brad from Alley Interactive, what’s Lawrence named after?

A: Lawrence is named after, it was developed by a bunch of guys in the LA office originally, and apparently there was a vendor who just randomly runs into the building and offered sandwiches and his name was Lawrence. I don’t know what to make of that, as a member of the New York office, but it is what it is, any other questions?

Q: How do you interact this USA Today sports group with the other properties?

A: Reasonably siloed. We obviously have some dealings with the other offerings as well as the USA Today central group, but as I said, most of the sports stuff is a little bit outside of that field. Certainly our biggest integration is moving basically flowing content across both all WordPress sports media group offerings into the other systems and vice-versa, so that’s our biggest integration and we’re looking for like similar sort of promotional stuff like syndication, stuff like that as well.

Is there any other questions?

Q: Rohit from Forbes, so obviously you’re using WordPress on the backend, so first question is WordPress also feeding the front-end of the sports system?

A: Yes.

Q: And then you mentioned other divisions within USA Today are also looking to make the move over…The main USA Today website using php or something?

A: The main USA Today website is actually a system not too dissimilar from yours actually. I believe that we have a proprietary CMSin it, I believe an ASP, that drives a front-end based off of Django.

Q: So now as you’re looking to move some of the divisions over, is that going to be an API system to connect with them or is it going to end up being completely moved over to WordPress?

A: We are actively working on an integration system to sort of marry the two systems together. Presto is what it’s called. The main USA Today CMS is architectured with an API that we can use, and that’s something we’re definitely looking to utilize for our other divisions. It really depends.

I don’t believe there’s any call to use WordPress exclusively as the front-end facing instead of Presto, that does fairly well architectured out for us to use that site. However, we do have people looking into trying to spin up their own sort of mini sub groups with more exclusive content and that is definitely looking to pull in with Presto and WordPress-driven data to use on the front-end and that is generally hosted by WordPress.

Anyone else?

Q: Hey, James, Athletics, I was curious just if you could rattle off some of the other sites running on this?

A: Sure, let’s see, our oldest one is For The Win, which is, which originally was the one we launched originally to cast WordPress as a platform in general.

It was not VIP and it was self hosted on Amazon and that was fun. We also have the […] Entertain This, we have College, we have High School Sports, which actually just launched. We have America’s Markets, we have […] and a few others that are currently in development. I actually don’t know off the top of my head the entire list.

Q: […] The other divisions looking to use WordPress, is that really driven by your group, your developers?

A: A combination of both, we originally chose WordPress for it’s ease of editorial
and for it’s ease of editorial tools and our editorial department was so enthusiastic about that, so once that started going, we as developers preferred this as a platform as we felt it was more modular and our group drove it and the editorial folks within our division also wished to continue using WordPress as a platform choice.

Even though there was obviously some hiccups along the way, about various capabilities but you know, we continue to extend our Lawrence to basically cover anything needed. Just so I’m clear, USA Today Sports media group actually contains both editorial and engineering, we’re not engineering exclusive.

Any other questions?

Q: Matthew, Athletics, when you talk about integrating Sports, […] Mongo DB, are you ingesting that in PHP or on the front-end?

A: Generally php, we haven’t really had a need yet to have to do our own live streaming front-end, which would obviously means we couldn’t use like caching like WordPress would provide, so that is something we’ll definitely do in the future. But for now, most of the data we’re ingesting, if not like vendor-driven, widget-type thing, is just generally in the php, but with the VIP server calls.

Q: Steve, the question is are you unifying your archives?

A: Um, I don’t believe at the moment. Potentially, generally, correct me if I’m wrong, most of the stuff, we’ve done so far has been very like trendy, up to date, we’ve seen like 30-40 articles published in a single day. So what’s old generally isn’t considered that much. I mean obviously as we move more and more of the main USA Today platform and that sort of stuff on to VIP, moving content from that system that we already have onto WordPress it’s something we’d definitely consider. But right now, it’s just not a priority.

Q: Let me ask a follow up question. Even in the active system (…) when you eventually […] content, do you keep that or flush it out?

A: We don’t get rid of them, we tend to have tentpole sites, which is World Cup is a great example. We have an event, World Cup 2014, and we put it up. Obviously it’s just really useful for World Cup 2014, but we don’t get rid of that content. Generally the strategy right now is keep the actual site archived and continue to iterate. We would probably eventually have a more hub-based solution which would have that old content flowed in,
using our existing tools to pull and manipulate content across our VIP offerings.

Anything else?

Going once, going twice.

Thank you very much.

See the presentations from previous Big Media & Enterprise WordPress Meetups. For Big Media & Enterprise WordPress Meetup groups in other cities, see the full list on VIP Events and join your local group. 

Want more information about WordPress services for media or enterprise sites? Get in touch.