Variety.com and Deadline Hollywood Launches: Lessons Learned – Now With Full Transcript

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.

Inside GigaOm’s Search and Alerts

Casey Bisson from GigaOm presented “Search and Alerts” at the recent Big Media & Enterprise Meetup in San Francisco.

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.

Using APIs to display sports data through WordPress with USA Today

Matt Harvey, Director of Product, USA Today Sports Media Group, presented how USA Today uses APIs and WordPress to display sports data in “Keeping the Score: Using APIs to display sports data through WordPress,” at the recent Big Media and Enterprise Meetup in San Francisco.

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.

Code Review For Teams – Now With Full Transcript

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.

USA Today’s World Cup – Now With Full Transcript

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.

Thought Catalog on Building a Massive Open Contributor Network – Big Media & Enterprise Meetup NYC

James Ellis, Jameson Proctor and Matthew Spencer from Athletics  presented “Thought Catalog on VIP: Building a Massive Open Contributor Network” at the recent Big Media and Enterprise Meetup in New York City. Their presentation included their author permalink plugin that is now available on GitHub.

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. We have upcoming developer and superuser training near you.

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

GlobalNews.ca Makes Embedding Media Easy with the Media Explorer

At the Toronto Big Media & Enterprise Meetup earlier this year, Keith Robinson and Imran Nathani from GlobalNews.ca presented their customization of the Media Explorer plugin. The goal: To make inserting and embedding media as efficient as possible for their editors.

The Media Explorer plugin was a joint project between WordPress.com VIP and Code for the People, which allows editors to quickly and easily insert tweets and YouTube videos straight from the WordPress dashboard “Edit Post” page. The plugin is easily extendable, and allows for you to include alternate media sources.

Twitter search

Media Explorer

The GlobalNews.ca team decided to customize and extend the plugin to include other video and photo sources that their editors commonly use. In doing so, they allowed their editors to centralize their workflow within the WordPress dashboard. Watch their 10-minute “Flash Talk” below to see their customizations in action, and then check out our recent Q&A with Keith Robinson, manager of digital products, and Imran Nathani, web development architect.

What was the thinking behind extending the media explorer?
Keith: We have dozens of active producers, and making it really easy for them to curate content into story posts is a big part of what we do. Anything we can do to make their job even incrementally easier has terrific benefits.

With WordPress, we want to get our producers comfortable with one user interface, rather than telling them to learn a new system or look in a different place for each new feature. There’s a lot to be said for simplicity and getting people to do almost everything they need in a post, and then press a button and move on.

It’s organized and simple. That’s exactly what we look for in a CMS.

When we first saw the Media Explorer plugin in the fall, we saw how easy it was to curate Twitter and YouTube content straight from within the post. It’s organized and simple. That’s exactly what we look for in a CMS. Imran pointed out that it was easily extendable and can be adapted for our own media. We’re trying to get as much rich content as possible into every story post, to hold readers a little longer, and Imran said, why not use the Media Explorer to do that?

By extending the Media Explorer plugin, editors can now easily search the NewsCred photo library without leaving the dashboard.

By extending the Media Explorer plugin, editors can now easily search the NewsCred photo library without leaving the dashboard.

The custom tool also allows editors to quickly crop images before inserting them into the post.

The custom tool also allows editors to quickly crop images before inserting them into the post.

What was the previous workflow like?
Imran: We’re a very video rich site because we’re a broadcaster, and with the way the video management was first integrated into WordPress, it was a separate screen. You had to go in and search in a separate interface, and then grab a short code and then bring that over into the story editor and cut and paste it in there somewhere. That may not sound like the most onerous workflow in the world, but it’s all about making things that much easier.

Embedding videos used to be a tedious process requiring multiple browser tabs. Now editors can quickly search and embed videos right from the WordPress admin.

Embedding videos used to be a tedious process requiring multiple browser tabs. Now editors can quickly search and embed videos right from the WordPress admin.

The custom tool that the GlobalNews.ca team built also lets editors create video players and carousels on the fly.

The custom tool that the GlobalNews.ca team built also lets editors create video players and carousels on the fly.

How has your tool evolved?
Imran: Our video producers are really localized, so we’ve given the producers an option to search video based on a specific region. For the first round of development, the user would just select a video and insert it. For the second round of development, we started thinking about groups of videos. This was mostly triggered by Rob Ford being on Jimmy Kimmel Live — we wanted to be able to show all the clips together. So, we created the option of a video gallery.

As for the NewsCred integration, sometimes the images that come through are really large, and our editors need to crop the photo to something that suits our site’s dimensions. So, we made it possible for editors to choose the photo and crop it, lower the quality for web, and then add it to the media library for use.

What’s the feedback from the producers been like?
Keith: Our video producers really like it a lot, and — the difference in the process before and after is pretty extreme. They’ve expressed that they really do find it a lot easier.

Since we’ve added this, there’s been more video going into posts, a lot more embedding of tweets right into the post. And I like that because it gets people away from using other outside tools to curate social media, and this allows you to do all the curation right within your post and house all of your own content.

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. 

One Theme, One Multisite, 30+ Unique Websites – Now With Full Transcript

Simon Dickson and Simon WheatleyCode for the People, presented “One Theme, One Multisite, 30+ Unique Websites” at the recent Big Media & Enterprise Meetup in New York City. We’ve shared this post previously, but we’re publishing it again now with full transcript below.

 

Okay, so I’m Simon Wheatley, my partner Simon Dickson is just over there and we’re from a company called Code For The People.

We’re one of the VIP partners and I want to talk to you today about a client who came to us, similar I guess to the Oomph guys,the Interactive One guys, just been talking about one thing, but dealing with many websites initially 30.

This is for a magazine publisher in the UK, so they wanted to move 30 of their titles initially on to this platform but they wanted one standardized theme, one standardized set of functionalities that they could use.

So our solution for them is based in a couple things that I’m going to talk about tonight one is the WordPress theme customizer and one is the way we’re handling layouts using widgets and widget areas so these solutions are things you can apply in other organization. You can have your WordPress themed cake made by my partner’s wife and you can eat it at the same time.

So you get in this way, using this customization but based on the standardized theme, you get to reduce maintenance and at the same time keep the editorial teams happy.

So I’m going to talk through three of the areas where we allow editorial control so obviously there’s colours, I’m going to talk about typography and I’m going to talk about layout.

So the first element, colour, we started off with the idea that we would have the user pick half a dozen colours and we would then do colour calculations based around on let’s find some complimentary colours let’s find some lights and dark equivalents and then we’ll be able to work out how of those six colours, we can deal with the header and the footer and the body post but that actually gradually became unwieldy.

So you get in this way, using this customization but based on the standardized theme, you get to reduce maintenance and at the same time keep the editorial teams happy.

We found ourselves adding more and more colour options to avoid a clash of dark colours appearing on dark colours or red appearing on green, that kind of thing and the solution that we arrived at eventually was that we split it into two colour palettes, so there are two colour palettes which we call palette A and palette B and then we split the page into three areas. We’ve got the header area which can have one palette assigned the body of the page which can have another palette separately applied to it and then obviously the footer which can have a completely different palette.

So there are three palettes there, with about 12 different areas and we’re just using the standard WordPress theme customizer to allow you to pick the colour for that we’re still doing a little bit of colour calculation, lightening and darkening and so on but essentially it’s the two palettes applied to different areas of the page. We don’t take the standard approach that some themes take of just injecting a whole bunch of CSS into the head. Instead, we’re using LESS with CSS Preprocessor.

Probably now looking at the fact that core have adopted SASS, we could be using SASS but at the end of the day it’s all CSS Preprocessing. It all really does the same thing, it’s taking variables from the customizer and injecting them into CSS and using that to build the final styles for the website.

It’s simpler and cleaner than shoving a load of overrides in your head. So that’s colours, let’s talk about typography. Obviously there’s a number of font services out there and we’re going to want to give 30 editorial teams a good choice of fonts for their websites.

So we’re using the Google Fonts API, there’s a wide wide variety of fonts there and we’ve built a custom control for the customizer so can pick say the open sans fonts and because we’re dealing with the API. We know that there are these variants and weights associated with that and then we can be applying a text transform so that you’ve got fully uppercased for the navigation, but you’re just capitalizing for the headers or whatever.

That’s the one customizer control, which has got three sub-controls within it we looked around and found a couple of those on the internet in the .org repository but they all seemed to be making a bit of a meal of it and we ended up making something that turned out simpler but works quite nicely.

It’s simpler and cleaner than shoving a load of overrides in your head.

What you’ll see we haven’t got there is a font size for each individual element. We’re not setting a font size for the heading and then font-size for the subheading. Instead, we’re setting a base font size and then we’re using multipliers up from that. So maybe 16 pixels or something and then the heading is 1.5x that and the meta is 1x that or whatever.

So let’s talk about layout. We started out with layout with some very grandiose ideas that you might recognize from other themes and options that you’ve got out there. We were going to allow the user to draw areas on the screen and we we’re going to then use those as widget areas and drop stuff into those and then we we’re going to magically work out how we calculated the break points so that you could you know have tablet portrait, tablet landscape.

Eventually we took a step back from that and realized we could accomplish pretty much the same thing but in a much much simpler way.

Eventually we took a step back from that and realized we could accomplish pretty much the same thing but in a much much simpler way. So if we look at the primary content area on the left there, we’ve got a grid of widget areas so we’ve got a widget area at the top spanning then we’ve got the two-column side by side and then we repeat the same again. But of course with the widget area in WordPress you don’t need to put widgets in it.

So if you wanted to have just a single column of news in the primary content area then you just put widgets in the double span that comes second in there. Or, if you want a two-column layout, then you can just use the top two. Every so often in the year, when you’ve got a promotional item, you can be putting that in your double span above those to columns, so it gives it a lot of flexibility.

Because it’s a known quantity, it means that we can scale down to the various breakpoints and we know exactly what we’re doing and we’ve got a really nice responsive website and that comes out really really well when you start actually putting content in it this website, the fields, they started building that yesterday at 11 o’clock in the morning and by 3 o’clock in the afternoon, they had a site, fully migrated, fully customized with all the old content in it from the old custom content management system and up and running, so it comes up through the breakpoints.

Nice shotgun advert there for the shooting season coming up.

And then the desktop, full desktop width…so let’s, just taking a look at this page, we’ve got one widget that’s controlling a lot of this stuff. So if you look at the news sequence of posts and the food and drink sequence of posts, they’re using the same widget, and that’s something that we call the post query widget which is essentially a wp query builder for those you who know what I mean by that.

It’s putting together a series of parameters by which you’re going to reach into the database, grab the post that you want and get to display them on the page so you can choose the post type that you want to display in the particular widget that you’re editing at the moment. You can filter it down by the taxonomies and then you can go to actually start displaying that.

We do that by breaking the sequence of posts up into sections, so section one here has just got one post in it, it’s a list with a large image. Section two, you’ve got two posts, smaller images, and we’ll show the author and we’ll show the date there. Then section three is just a text bulleted list without any additional detail in there.

What that comes up as is something like that so it gives you really quite a flexible display of how you’re going to pull the posts in and then how you’re going to actually show them on the screen and you could have all large images or all bullet points, pretty much anything you want

We don’t limit the number of sections there so another thing I wanted to mention was category archives so again, we’ve got a customizer control in there so select your category and then choose similar again to the way that we’re dealing with the query widget so similar, we look at the style that you want that in, maybe this category you’ve got some really nice images, maybe the review images you’ve got are great and you want to highlight that

So you’ve got the ability to customize the display on the category there, so I’ve whistle stopped through this we talked a little bit about colours, so we’re using the colour API a little bit of calculation, we’re using LESS in CSS Preprocessing there talked about typography, so we’ve used the Google Fonts API to allow you to choose a font we know from the Google Fonts API, what the variants are, so we can pick that and we can give you a transform, we’ve got the base font size we talked about layout, we talked about the post query widget and about the custom layouts for categories so has anybody got any questions?

Q: Are you guys supporting live previewing in addition to the standard customizer stuff?

A: Yeah, absolutely, so all of this stuff, I mean if you’re not familiar with the customizer, one of the great things about it is nothing is live until you click the save and publish so all of this customization is happening just for you personally so even with the LESS Preprocessing, that’s being piped off into a separate stylesheet which is only being served to the editor that’s actually doing the customization at the moment

Q: ( […] )

A: Yeah, we’re working with posts, obviously the built in post type which they’re using for articles, we’ve got a custom post type for events and for reviews as well so the post query widget that I showed you, you can say I want to see just reviews here or just events here and it will allow you to display those

Q: ([…])

A: Some of the titles that we’re dealing with are relatively low staffed So I don’t think that kind of title would be necessarily looking at clicks we have got an evolution of the post query widget which looks at Google Analytics and uses the Google Analytics API to evaluate what’s popular in a particular category so you can use that as the sort mechanism, but that’s not something that’s live on the site at the moment

Q: ([…])

A: Yeah, so the widget areas that are there for the, where are we, let’s skip back through yeah the widget areas that are here are exactly the same widget areas, they’re just, they cascade through with the different break points and we move them around so this is the full desktop width but if you can quickly scan you can see that the same widget areas are just linearizing basically as you move down through the sizes so it’s exactly the same stuff ([…]) absolutely yeah responsive break points any more for any more

Q: ([…])

A: At the moment, pre-3.9 the disadvantage is anything you do to a widget is live on the site immediately, post 3.9 widgets move into the customizer so we’re able then to choose the widget layout and mess around in the same way exactly the same was as I said for the rest of the customizer, you can change your colours, change your fonts it’s not live until you click save and publish so 3.9 is going to herald a grand new dawn in terms of that being able to get right before it’s live

Q: ([…])

A: The brief for the widgets was that it wasn’t so much of a manual curation process, so if we needed to manually curate this particular post into position in this particular area of the homepage

I guess you could get around that by hacking with tags, but it wasn’t a core part of the brief that we were able to do that, so using something like zoninator where you can precisely choose which post to go and in which order they appear in wasn’t a requirement we could develop a different widget that did something like that I think we would probably still stick with widgets we’re also looking at doing some work to customize

so you can take the homepage layout and then for a particular purpose maybe for a sponsorship section have all of the sidebars completely custom for that but hidden from normal view so It’s only when you’re editing that page that you go in and those side bars are only live when you’re editing that page, that set of sidebars so you don’t end up with this situation wherein the WordPress admin area, the widget section you’re looking at all the sidebars and there’s like 300 sidebars which one am I adding the widgets in and which one am I not we’re able to actually filter which sidebars are being shown for a particular purpose

Q: ([…])

A: Yeah exactly that principle yeah.

Q: ([…])

A: Yeah, so like I say, some of these are fairly low staffed publications so the key for them is probably that they’ll set something up and then they won’t touch it for a little while we’re using a plugin which is available on the .org repository called the customizer settings revisions which allows you to save what you’ve created so you might go like “okay, this is the Christmas layout” with all the pretty snowflakes and the lovely snowy red design and then you can pop back to that when Christmas comes around again or when Easter comes around or whatever you want to do thematically so we’re using that plugin for that purpose

Q: ([…])

A: So the ads are outside of the widget areas, they’re placed at various points in the page that we know how to deal with for again, for the responsive break points are we concerned about the responsive kind of nature of it and so on, yeah so we have, we haven’t got the ability to do the thing that really you only do to show your boss that the site’s responsive which is you know, move the site edges in and out and change the width of the page, the adverts won’t change at that point because they only change on page load, it will look at the width and then ascertain what ads you need and then load them at that point does that answer the question?

Cool. 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.

Building Quartz – Now With Full Transcript

Josh Kadis is the web applications technologist at Quartz. At our August Big Media Meetup, he gave a short “flash talk” on building qz.com on WordPress, which we’ve shared here and republished now with the full transcript below. Quartz just celebrated its one-year anniversary, and you can learn more about it by reading our case study here.

See Josh’s slides here.

 

My name is Josh Kadis, I work for Quartz, which is a business and economics site from Atlantic Media, which is the publisher of The Atlantic. We launched in September last year, and our most recent numbers for July were about 5 million uniques (views). My role at Quartz is I do the bulk of the WordPress work and then I’ve also been heavily involved in building the Backbone application that runs the front-end of the site.

If you haven’t seen Quartz, it looks like this. It’s a responsive web app, WordPress backend, publishes on JSON API, that gets picked up by the backbone front-end and the bar across the top under the word Quartz – that expands and that’s how you navigate between different sections and within a section you can navigate by scrolling up and down in the column on the left which we call the queue, or in the “item well”, which is the main content area on the right.

So the basic architecture is that Automattic and the VIP team host our WordPress installation, the Backbone files and our CSS and some other Javascript kind of stuff are hosted on the same CDN that’s used by the rest of Atlantic Media, which is like theatlantic.com, theatlanticwire.com and other non-WordPress sites.

WordPress publishes the JSON API, and we get all the backend post authoring and media and we have some custom backend stuff, like a post type that allows us to publish the newsletter through the MailChimp API from within WordPress.

We have a self-hosted system for reader accounts, which is what you would use for the commenting feature that we recently rolled out which is more for annotating individual paragraphs within a post, and then managing your subscription to the newsletter The Daily Brief and that kind of stuff, so that’s also WordPress.

We’ve actually found that the comments that come back are less awful because people get to the specifics of what they want to say about this specific paragraph instead of a general “you suck”. That’s kind of nice.

We have this division of labour between WordPress and backbone where WordPress handles what you would expect: generating the basic HTML markup which kind of gives the page the basic structure and is useful for search engines. WordPress publishes the JSON API, and we get all the backend post authoring and media and we have some custom backend stuff, like a post type that allows us to publish the newsletter through the MailChimp API from within WordPress.

The order of the posts you see on the homepage is not initially chronological, it’s manually ordered by the editorial staff, that’s the ‘Top’ post. So there’s a plugin that allows them to do that with a drag and drop interface from among the recent posts. Backbone also handles what you’d expect on the client side: fetching data from the API, deciding where and when to render it on the page, reflowing based on the device and on the screen size. We’re doing some offline reading with local storage and all of the annotation’s functionality is contained within the Backbone app and the entire thing can be turned on and off without even touching WordPress.

The URL and getting Backbone and WordPress to interpret the URL in the same way is really where the two things come together. The whole site relies on that or else the front-end and back-end are out of sync.

So we have these two things and where do they really intersect? It’s here: The URL and getting Backbone and WordPress to interpret the URL in the same way is really where the two things come together. The whole site relies on that or else the front-end and back-end are out of sync. So just to kind of quickly walk through it, if you haven’t written a Backbone app before, the router is the foundation of it, it essentially determines how the URL is parsed and then triggers a series of events that come one after another and ultimately result in stuff showing up on the page.

Good URL design is really a key to what we’re doing.

To work, the router reads the permalinks, and Backbone has some kind of build in syntax for how you read a permalink and decide what’s a variable within that and what’s a key. The permalinks come back to WordPress to run off the rewrite rules, and the rewrite rules run Quartz.

Good URL design is really a key to what we’re doing. So something like this: http://qz.com/107970 is the URL of the most viewed post of the history of Atlantic Media, it’s about bees. This is something that doesn’t have to run through a URL shortener, doesn’t get redirected, both Backbone and WordPress will understand this URL and parse out that single ID in the exact same way. Here is a little bit of code from the router, grossly over simplified.

Basically the router initializes, you give it this regex, it looks for these core sections: ‘Top’ – which is, I explained, is the manually ordered, “here’s what’s important right now” segment of posts. ‘Most recent’ is the latest one, ‘Popular’ we kind of calculated near real time using Chartbeat, ‘About’ is some static pages.

When the router recognizes one of these keywords from the regex and the URL, it triggers the core function which passes the particular one to this event which then gets triggered and a whole bunch of other stuff happens that results in a bunch of posts as you scroll through.

When you look at the WordPress theme, if you see rewrite rules, you would kind of recognize the regular expression: Top, Latest, Popular, About, and for both the front-end query, which is this first set of rewrite rules and then the API they both resolve to pass these two parameters, these two query variables to WordPress. API = true or false and then request = one of these things in this array.

For handling those two variables, we add_rewrite_tag request, we hook into query_vars and add API and then WordPress knows to look for those two things so that when the parse_request action comes around, we are able to, and in my oversimplification, I left out an if statement here, then we can fire up this qz API class and kind of pre-empt the main WordPress loops and that’s how we get JSON back without really needing to run through anything else that WordPress would do.

So this kind of enables us to go from a regular URL with a parameter like JSON tacked onto the end which is how in a lot of situations if you were building a JSON API on top of WordPress, you might do something like this and get back basically the same data structure that’s in the WordPress post object.

For us, we haven’t done that for a couple of reasons. We’ve gone with a custom API for clarity’s sake, being able to put all our endpoints inside API and then on the server side, we want to do all our processing of the meta data before we return it through JSON or else all that work needs to be done and that slows things down.

So for example, we’re able to return the URL to multiple sizes of the same image which we’ll ultimately be able to serve differently using this new SRC set attribute for different screen resolutions, stuff like that that is not necessarily apparent if you’re just reading the meta data straight out of the database.

So the Backbone side touches WordPress in a couple of other places. One is we need a way to keep track of version numbers, because they really are so separate. When we load the current Backbone version, it’s a different actual number than the WordPress version, so WordPress needs to know what’s what and keep one step ahead of the VIP team, really, because we put in a deploy to them, and we’re not sure when it’s going to come back so we want to know that as soon as it does, we’re ready and we’ll load the correct version of the application.

We’re also sort of separate from WordPress but still in Automattic, we’re using an Akismet API for kind of like profanity and spam filtering when annotations come in.

So in a second I’ll show you a quick shot of a plugin that enables us to do that. We’re also sort of separate from WordPress but still in Automattic, we’re using an Akismet API for kind of like profanity and spam filtering when annotations come in. Previews get pretty complicated in fact, with the Backbone app because it doesn’t know if the person is logged in to WordPress or not, it doesn’t know what permissions they have, so we need to sort of render some special Javascript in the markup that comes back initially from WordPress in order for Backbone to pick up that preview.

And then finally, there’s something that we’re working on that David in the third row in the red shirt is going to be working on soon, which is kind of figuring out how to keep the WordPress post templates and the underscore templates that Backbone uses, keep those in sync. It’s kind of hard right now, and ultimately doing a better job of that will allow us to load more of the application initially from WordPress, instead of having to process it within the browser in the Backbone app and then put it on the page.

So, this is a quick look at the plugin that manages the version number, essentially it allows you to stay on this auto-pilot mode that kicks whichever version is higher between the constant that’s set in the theme that can get committed to VIP or a setting that’s saved in the options table that you can set here so if for example you have a new version in the Javascript application that’s not making any adjustments to WordPress, we can just update the setting here in the plugin as soon as we put it on the CDN and we’re ready to push it.

But if we have stuff that’s sort of related to some changes in the WordPress theme and some stuff in the Backbone app, we put the Backbone app up first change the constant in the WordPress theme to sort of point to that new version of the Backbone application and as long as we’re sort of incrementing the number, the plug in will kick the higher number as soon as the new code with the constant is live on VIP.

This is just a quick look at annotations. You should all check it out, it’s really really nice. The responsive aspects of it are really cool and it’s just an interesting way of diving into the content. We’ve actually found that the comments that come back are less awful because people get to the specifics of what they want to say about this specific paragraph instead of a general “you suck”. That’s kind of nice.

TechCrunch and Non-Blocking WordPress – Now With Full Transcript

Alex Khadiwala and Nico Vincent from TechCrunch presented on “Non-Blocking WordPress” at the recent Big Media & Enterprise Meetup in San Francisco, California. We’ve shared this presentation before, but now we’re publishing it again now with full transcript below.Download the slides here.

Nico: Today, we’re going to talk about non-blocking WordPress. By non-blocking, we’re meaning asynchronous tasks. First of all, who is a developer in the audience here? Okay, so more than half, awesome. So we’re going to start by talking about non-technical stuff and then we’re going to go a little deeper, under the hood.

Basically the team right now is me and David Lake, as a software engineer and a project manager. Alex here was former development lead for more than a year. I want to give props also to 10up which is here tonight and John Bloch and Eric Mann who were really helpful in the redesign we did in the past year.

So the whole point of this presentation is to talk about having a fast website. Basically when you have a fast website, the user engagement is much better. I’ve heard that under 3 second websites, 40 percent of the people drop and only 40 percent of them will come back on your site.

The more they stay, the more pages they see, which is good for ad revenue and on a business point. Also, like Google and other search engines, like Google or Hummingbird penalizes when the website takes longer to load.

Also it’s good for the bounce rate and I know we’re hosting on WordPress VIP but it’s better for your hardware, when you have a really performant website.

I’m going to let Alex talk about our old TechCrunch to our new TechCrunch.

Alex: Yes, so our old site was really slow, it was about 17.4 seconds for a single page load. We’re part of the AOL network and from all the sites from AOL, we were the second slowest, pretty embarrassing against the peers.

Also, like Google and other search engines, like Google or Hummingbird penalizes when the website takes longer to load.

If you guys recall the old site, for the new site, after we finished the redesign, this is hearsay, but what we were told is that we were one of the fastest sites on VIP. I think Matt Mullenweg was kind of excited about that too which makes us excited.

Blocking is: a process that is blocked is waiting for some event such as a resource becoming available or the completion of an operation.

This little graph at the bottom, you can see, first page load of DOM complete, when you can start interacting with the page is about 2.9 seconds and after the first load, and second load about 1.9 seconds and fully loaded it’s 4.2 on the first load and about 2.3 seconds on the repeat, on the second load.

Basically when everything gets cached and such, definitely very exciting, pretty fast. So it’s good that there’s all these non-technical presentations so we can balance it out with a little more technical presentation.

We’re going to talk about blocking, basically, this is kind of a general definition of what blocking is: a process that is blocked is waiting for some event such as a resource becoming available or the completion of an operation.

The general idea is that you have a page request and it has to do a bunch of things before it can render the HTML and send it back to the user’s browser. So by architecting the page – one of the big things was to make our site extremely performant for all the reasons that Nico had listed off a moment ago. One of the big things that we did was try to identify anything that was blocking and push it off to an asynchronous task.

Some of the ways that you generally do it with other non-WordPress stacks are message queues, using something like Rabbit MQ or Amazon SQS to kind of send a list of tasks and then using workers, or in past I’ve used Gearman as a worker for processing things in a queue. Sidekick and Resque are big popular ones with rails apps.

Unfortunately these options are unavailable on WordPress but with a lot of help from 10up, we built out something that is referred to as a wp-Async-Task. What this is is an abstract class that we extend for different tasks that we wanted to make asynchronous.

So the nice thing is essentially it’s kind of starting a whole new thread to kind of do this work that you need done asynchronously.

So basically, it performs. When you make a request for something, if we kick off a second request back to the same site, which is a non-blocking HP request and it basically sends some information to the server and says do this task.

So the nice thing is essentially it’s kind of starting a whole new thread to kind of do this work that you need done asynchronously. A couple of examples of what we did on our site that you can see are CrunchBase.

We have, on most of our articles we have CrunchBase cards and you can kind of see – here Facebook and Snapchat as an example.This information all comes from the CrunchBase API. So imagine that one circumstance you’re loading the page, you have to get this information from CrunchBase.

Imagine that we have to go to CrunchBase, wait like a second or even half a second to get that information, for each of those different companies and then pull the information back and basically have it available then to render the page. It would be painful for the end user.

So what we do actually is we kick off an, if the information is not available, we kick off an async task, it goes and gets the information, caches it in our site, we basically store it in a taxonomy – a custom taxonomy for CrunchBase.

One of the big things that we did was try to identify anything that was blocking and push it off to an asynchronous task.

Then the next time that particular CrunchBase information is requested, it will be available to the page.So we then load nothing for the first request if it’s not available, then the next time the request comes through, it’ll be available for that page.

Another example is for recirculation. On the left rail of our site, we have some for example, we have tags and categories basically for that particular post and we pull in articles that are related just for recirculation purposes. Pretty much the same exact thing as a CrunchBase.

One nice thing that we do here as well is that when the page finishes, if the information is not available it does not render on the page. Instead it sets up, it just kind of writes a Javascript callback so that when that page finishes loading, that it’ll call back and try to get the information.

Basically, as far as images, we were just putting a 1×1 image on a CEN in the SRC attribute and then once the DOM was done loading, we were just using another attribute that we call data-srce and we were replacing the image source so that was super fast, seamless.

Again, it waits ’til the page is completely done loading, before it makes that call back, just for the best user experience. That’s it for my part, I’m going to pass it back to Nico to talk about some other things.

Nico: Alright, I’m going to talk about something we call the Lazy Loader. Basically on our front page and many of our different pages. We’re loading more than 100 assets, and it was a big part of us having a 17 second loading time.

We have different blocking API’s and the social buttons. Let’s say for a blog when you’re displaying 30 articles, you have to load a like button, a linkedIn button, a Twitter Button 30 times and these API’s are really slow and sometimes it’s a real hassle to finish the DOM to load with that.

Basically, as far as images, we were just putting a 1×1 image on a CEN in the SRC attribute and then once the DOM was done loading, we were just using another attribute that we call data-srce and we were replacing the image source so that was super fast, seamless.

And then like Alex was talking about, the tag accordion – basically all the accordion was closed so we were just loading the content as the page was finishing loading.

So once again, no one could see it and it was much better in terms of page load.

Also, our social buttons, they’re just like little images and as soon as you hover it, that would just trigger the loading, so these are examples that really really cut down our page load down from like more than 10 or 15 seconds.

Another example is caching, so here, basically what we’re doing, we’re having a refresh key that’s usually like 10 minutes and then when the refresh key is still okay and the data is still good we just returning the data and serving it. If it’s not the case, we only have one person that can trigger the refresh and then that will set the transient.

Another example, it’s a plugin actually, so you guys can check it out if you’re interested. It’s from another 10up person that used to work with us.It’s called the Live Cache.

So where you see the two arrows, it’s a little module on the homepage, when the stream is on and we wanted to be able to change the information there so the person wouldn’t have to refresh the page.

We tricked a little bit with a URL and a timestamp, so basically the browser will trigger a call to our backend every ten seconds based on a different timestamp and we will just get the information back if someone in the backend had refreshed it before.

I will let Alex here conclude on this.

Alex: So yeah basically, the point of our presentation was just to – it’s something you kind of have to do from the beginning and especially if you’re doing a redesign.

Just general idea, is you want to architect your site to asynchronously handle any heavy task to maximize your task performance.

Yeah,using a pattern like wp Async Task or things like the Live Cache plugin or just Javascript Lazy Loading or the 1×1 pixel source when you’re loading the page will definitely help improve the page performance.

One other note we’re told to tell you if we’re hiring, so we are hiring and if you are looking or know somebody that is looking in the Bay area, would love if you guys could email them now at dev@techcrunch as I’m no longer there.

Thank you guys so much and thank you so much to Automattic for having us present here.

Questions:

Q: How do you factor speed with features, it’s a balance, so how do you deal with those decisions? Is it just the feature set wins and you just figure out how to do it?

A: Pretty much. So a lot of our features are driven by editorial, and editorial typically is very opinionated and had a lot of pull. I’m sure everyone has dealt with that for any media site.

So I think most of the time, if it’s not them coming to us, it’s them going to the higher ups and talking them into basically adding a certain feature and then us kind of figuring out how to architect it.

It gives some interesting challenges, but it’s been great, it’s been fun. I mean, I think Live Cache was a good example with that.

Like one of the big things was working against batcache, because we’re on VIP and having batcache, we have to kind of come up with a way that we can make page requests back and get up to date information.

But without taxing VIP too heavily and getting passcode review on VIP.

Q: Just a follow up, it seems like you’ve built tools to help you quickly integrate speed into everything you build, rather than having to tackle it individually for each piece, is that correct?

A: For sure, just kind of abstracting as much as we can, to make it reusable and I will give props to 10up again for a lot of that.

Nico and I, like I started about a year and a half ago, Nico’s been almost 2 years now and we both came from non-WordPress backgrounds.

We started probably a few months into our tenure at TechCrunch doing the redesign, so it was a lot of stuff we had to learn. It’s kind of a different world doing WordPress development.

Participant:Can you go back on a slide? Two slides, one more.
Alex: The one on Live Cache?
Participant: Yeah, thanks
Alex: Cool.

Q: Yeah, just curious what your best practices are around caching, and content like that, what’s your TTLs and whether you’ve found any optimizations around caching that you’d like to share?

A: That’s a good question. So that’s a good question because we had issues with that plugin. It didn’t work for like two live events because first of all.

We were logged in and VIP has a different behaviour as far as refresh and cache for logged in users. When you’re just someone who’s chilling on the website, we we’re getting the headers from that cache.

Sometimes, so I don’t remember if it’s like too much or not enough, but sometimes we were having the right data from the back end, and then ten seconds later, the old data because of issues with cache timestamps.

Alex: Do you mind if I?
Nico: You want to chime in?
Alex: Yeah I’ll chime in for this one.

Alex: We were having an issue with Live Cache, you might be speaking of other assets…

Q: Yeah, I’d just like to hear general, just caching in general, what best practices you have for that like new content versus page speed.

A: Yeah, everything is basically, we said no headers from our side. Everything is kind of managed from VIP, all of our information, all of our content is through their CDN and through their hosting.

They kind of take care of that for all our static assets and such as far as the issue that Nico was just talking about.

One of the big issues with Live Cache is that basically you have to make the request back to the server with the right timestamp to make sure you’re getting the right text.

So for example basically we have these presentations that disrupt and they’re like 10 minutes long, which we’ve gone over a little bit but we’ll be quick.

When they switch presentations, somebody goes into the backend, in the widget and switches out the text. But, you have to synchronize the clock with the end user to make sure that they’re using the right, the same clock as you.

So our solution was to make that first request live_cache_check/1/. Fortunately the header on the batcache, the response is coming from batcache. It does have the proper timestamp so we use that to synchronize the clock and then accordingly all subsequent requests, which are every ten seconds will be based on that, based on the synchronization.

Q: So assuming no one messes with the clock between the first request and after that?

A: I guess, it’s valid, I mean just to speculate, I guess it’s OS specific. So it’s kind of relying on the timer within the browser and within the OS to kind of, as to the interval that’s been set.

Participant: makes sense, cool.

Q: Is the wp Async plugin, is that available right now?

A: Unfortunately not, we have it, we were looking, we were talking about like open sourcing that and I guess we just have to get it cleared by a few different people but I think it would be useful. We think it would be something useful to open source.

Participant: Sounds like it.

Alex: Yeah yeah, for sure. Cool, thank you guys so much.

Nico: Thanks.

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.