 So welcome to our session. We're gonna get started. It's 1045 on the dot. So any lay stragglers will have to dance into their seats This type this this session is called an introduction to basic algebra. So I'm just kidding. So this is time inks big move to Drupal, which is a very compelling topic, of course If you know anything about time ink When I say big move to Drupal, I really do mean it's a really big move. These are all the different titles and brands That time ink is consists of so all these brands are moving to Drupal, right? So over the next year Or sorry since well over the last year Myself with that innovation PwC and timing have been working together to develop a strategy to get all these brands onto Drupal You know in a somewhat sane manner. So we're here to talk to you about that today kind of talk about various aspects of that that process starting with the background and Into development and processes and all those things. I'll show you the agenda right away here But just to introduce the panel here. We have Matt Muratello Who's the director of internet content support at time ink? We have Tanner Durham Who's a technical consultant on the project and we have myself Scott Bell senior creative lead at app innovation? Technologies and Kevin Moll senior developer app innovation as well And we've come to you from various points on the globe here on the continent anyways and meeting here in Austin So it's pretty cool to talk about it So the agenda we have for today is we're going to cover the history of the digital CMS is at time ink We're going to talk about how and why Drupal was selected Talk about the creation of the DCMS playbook, which Matt will talk about Tanner is going to go into some of the tools and processes that use throughout and Then myself and Kevin are going to tag team and we're going to we're going to talk about the editorial user interface that we developed Why things were just you know why things were designed a certain way and how things were developed? So a little touching on some development there So I'm going to pass it over to Matt. He can get started giving you some background Thanks Scott. Welcome everyone so History of digital CMS timing so timing has been producing websites like most other media large media companies and publishing companies since mid-1990s and we have gone through a variety of platforms early on we were early adopters of vignette platform and Built a custom CMS editorial UI on that For those of you that are familiar with vignette. We started off really I believe with vignette version 4 But when we adopted version 5 it really stood around for a long time. We did upgrade to version 6 For those of you that are familiar. It's a tickle based Application allows you to create templates using tickle But realize that you know when we got to the you know mid 2000s that we were limited by the platform. There were certain things that it just didn't do So at that time decided to start building a homegrown CMS which we named tips And at the same time actually built a much nicer Extended user interface on top of that that was based in flex in this application called tips which was very access LT based and Really actually at that point had vignette version 6 and tips living side-by-side There are certain things that tips does very well, and there are actually certain things that vignette even till this day He does very well. We actually still have some of our largest sites on vignette people in EW and actually others not to forget anyone but as Time went on during the 2000s We we started to get this even more complex mix of technologies because titles wanted to Have the ease of a blogging platform and be able to just blog content out there as quickly as possible So wordpress even came into the mix so you would have a site You know like people calm that would have subdomains that were actually pointing to wordpress And that added an additional level of complexity Even though it gave the editors the ability to quickly get content out there on their blog The complexity came when you wanted to make all of these things all of these sites all these technologies Look like really one thing people dot-com or EW dot-com or in style or cooking light and What you wound up having to do was there was some manual work that editors would have to do to go and Take the content that they published in wordpress or somewhere else and tout it in the main platform which was vignette or tips so there we wound up in a Complex environment heterogeneous, you know mix of technologies required a lot of custom integrations in addition to CMS I also manage our search technology and making search Pull together all of this content and really having that I mean That's the one place that you really have to make it all seem as if it's coming from one Technology one CMS a lot of custom integrations a lot of feeds going back and forth So how we selected Drupal is our digital CMS so about 18 months ago Pwc came in-house and worked with us to review the CMS landscape review all the various CMS Platforms that currently out there wordpress Adobe CQ Jumla even I think was in the mix at one point, but of course Drupal as well Since we already had in-house experience with Drupal 6 and 7 And since Drupal is such a modular great platform to build upon Drupal actually wound up becoming our choice And we decided to use Drupal as the core of a larger platform that we refer to as DCMS Not a very exciting name DCMS But one that works for us and it's really stuck at this point Scott will actually touch upon that more later But now that we decided upon Drupal we started to think about some of our larger enterprise requirements What were the things that we really needed to extend Drupal to do to meet our needs? So I have here active active active Being able to have Drupal running actively in multiple data centers so that if there is some sort of a failure one data center we can easily shift over to another and Really make sure that we don't skip a beat for our editors so that they can continue to publish our Content and get it out there so that we could have a Fast time to market was a very important thing two other things that as we were working with PWC came up as being important features of This new platform was the ability to embargo content And also contextual preview and we came up with some interesting solutions for that Using Drupal so content embargo, you know We have some sort of you know person of the year for time comm that you know We want we were going to announce it on TV and we want to publish that Bundle of content at the same time that somebody's announcing it You know we want to make sure that that stays within the confines of the CMS and isn't accidentally published beforehand But along with that we want to be able to preview it In its sort of natural form Be able to click off as you're linking or click on links as you're previewing pages to see exactly What users are going to experience once we publish this bundled content? So we actually adopted a module that was created as a part of the LSD initiative SPS to do that So that leads us to the playbook we quickly realized that we needed to really define What the DCMS platform was going to be we really had to work IT and the title management the brands really we had to partner together to come up with a shared vision What did they want from a CMS would we want from a CMS and really we're all one thing, right? So so what collectively did we need to build into this platform to make sure that it gives all of our brands have a diverse Collection of content or a diverse, you know variety of content they publish We have celebrity sites then we have something like my recipes that publishes recipes How do we make sure that we build a platform that meets all needs? So we decided to come up with a playbook nipple implementation guide something that described the technology stack but also the Modules that you would use contributed or custom the platform the search technology and Even went a little bit further During PWC's engagement They reviewed all of our content types and actually found that we had something well over a thousand content types If you just looked at all of our various CMS platforms and and the content types that each brand had spun up as they've evolved So part of that effort was to rationalize those content types and try to really find out What's the what's the essence of each one of those and we came up with you know about a dozen? content types that really are the base you can extend them you can Customize them to your needs, but we wanted to make sure that we had some sort of a standardized data metadata schema That would allow us it gives us a number of benefits It gives us benefits when it comes to building modules and contributing Code within the company and sharing from one brand to another but it also allows us to do things like share content with those other systems You know if we know that our data structure is going to be you know a certain structure a certain list of fields And we know what the data types are associated with those fields We could then have some external system interact with us and port data may be back and forth So that's it's an exciting new thing for us, and we're actually already starting to reap the benefits We once again Kevin and Scott are going to touch on that a little bit later So we standardized content types. We also had a list of curated modules created custom modules and release that Internally and had sites already built against it and launch. So it's a very exciting time a lot of people in this room Actually, they're from time just call out to that had a part to do a part of this You know that we could have kind of done that without their help. So On that note actually going to hand off to Tanner dorm Tanner and I you know we actually started working on this together and At the point that we completed the playbook said, you know what it's time for us to actually start implementing this So he's going to talk about how we did that Hey So as Matt was saying I came onto the project around the time that they kind of put this vision in place where they decided to use Drupal They decided a lot of things about how they wanted to Have a distribution. They wanted to have the titles be able to extend that distribution and I do think it's worth pointing out here that You know, I was really fortunate to work on this project And I was fortunate to work with Mark Sam Petty and his engineering team on a lot of these tools and processes I see Seth Schneider's over there. He was a real key player in all of this. So You know, it was one of the most talented and thoughtful engineering teams. I've had the pleasure to work with that at time So like I was saying the mission here was the the title specific Development groups. So the way things were organized when when I showed up at time is that they had Different groups. They might have a group of developers working on three or four brands Depending on how things were split up. So they had these, you know teams that were kind of Disperate, but they you know, they all were working together as best they could but they all had their own Missions that they were taking on and so part of the idea here was we we had a Drupal center of excellence you know, it's kind of a lofty title for our centralized group there and We were charged with taking this playbook and evolving it and working with the titles to you know, make it make sense and to get standards in place that we could evolve and give the titles what they needed to Be able to publish the software and the content that they were trying to get out the door so everything around this kind of process you'll see is is The concept of a base distribution that can be extended by the individual titles as they need to extend things So the the kind of first thing is this like just a little kind of house cleaning things You know we had a jump box in place and you know, I've seen other places do this I think this works great where instead of giving everybody access to all of the boxes You give people access to a jump host and from there they can run Drush commands using aliases out to any of the boxes the dev or the qa or whichever boxes They happen to have access to and then something that was done here that I haven't seen anybody else do is that because of the security concerns that they have at time where you know, they have contractors like me and consultants and you know, they have different levels of security and they're very thoughtful about the security process You know drush is a really powerful tool if you give somebody full access to run, you know any drush command so they put a limited drush in place called ti drush for time ink drush and That that way they could dole out kind of a subset of drush easily to you know certain groups of people And so kind of getting into more than nuts and bolts here of build process and how this was set up We were using drush make and we would independently version control drush make from the rest of the of the files in the in the Repositories and this is kind of another key strategy here that evolved was that we were going to have independent repos for independent pieces of code like modules and whatnot so drush make had its own it have its own repository and it would be Version controlled by the engineering team So as updates security updates, for example came out for Drupal and they wanted to upgrade Drupal core That would be a release to this base drush make file And then the titles would maintain independently for their brands a drush make file to add modules on to the base distribution and All of this is done. Everybody was adopting get flow, which is a really nice thing to see I've said I don't have a lot of time to go into get flow here, but if you're not familiar with get flow I Highly encourage you to look into it. It's it's definitely can be a game changer when it comes to version control with get but like I mentioned here before we had independent repos and By applying separate version control to each module This gives the titles the ability to work better together, right? because if There's a custom module example for doing image management Kevin and Scott are going to talk about some of the image management custom image management image management assets that are in place for this editorial tool and Say sports illustrated for example wanted to evolve that for some specific need they had well because that module is Independently version controlled instead of just version controlling the entire sites directory for example like you know We tend to do on a lot of Drupal projects They're able to Make a tag on this module kind of and take it to the next version without Impacting anybody else so they can update their drushmake file to point to this new version of this module that they created And then because it's all in the same repo that everybody's referencing Everybody would have access to that tag so they could start running builds against that tag And then they could decide if that was a feature that they needed or didn't need So that was kind of setting them up for for the success here And the custom modules would be in an independent repo Hosted at the the timing get repository, but for contributed modules. We were using Drupal.org so if you know you were using a standard version of a Drupal module That was available on Drupal.org then we would just point those make files to that And so there's just get flow for those of you if you're Like I said, this is definitely worth looking into Jenkins It's kind of where a lot of this stuff starts to tie together So Jenkins would run on a utility server and this puts the titles in a position to literally run a build with the push of a button So remember they have their drushmake file of All their modules that they've kind of added on top of the base distribution So they're pointing to a specific tag of the base distribution They have their own drushmake file where they've added modules to that custom modules can trip modules, whatever and They push a button to run a build and Jenkins will take a build Put it all together and then you can from that point pump it out to a dev environment QA environment Production environment you can run some other automated processes in the process. This is all open source free stuff And for bonus points with this kind of process You can add thing which you could do all of this with Jenkins but thing allows you to kind of abstract some of the complexity out of Jenkins and into thing Where you just have Build files where you have simple XML documents where you can put your drush commands and your Unix commands that need to run To automate the build into an XML file and again, this was enabled time to abstract The titles from the base distribution. So there's the base distribution Build XML file where there were certain things that would always run as part of every build But then there was a different There was an add-on a title could add things to that. So if the title wanted to Add certain things to a build certain specific type of cache clears or whatever They could do that through their custom build that XML file on top of the distribution and And the last piece to this puzzle is the master module and I think this is like one of the most Utilized modules maybe It's a really fantastic module. Nobody here contributed to the master module. Did they nobody in this room? Okay. Well, if you ever I'd be happy to buy anybody that contributed to this module beer because this is a really good module and what this will allow you to do is This module it gives you a way of configuring what modules should be on and off for your Distribution so and as you do deployments with Jenkins, this is one of the things you can have it run Have the master module run and it'll give you a report on what modules are installed What module according to your list and you can do this by environment? So for example if you want to have the views UI turned on in Dev and QA but often production you can configure all of that in your settings file for the master module You run drush commands and the master module will go through and it will It will turn on and off whatever modules you have set for those environments in your settings dot PHP file And we used include files, so we had a base file and then again we had the titles where they could you know manage Beyond the base with their own Master file settings file that was included into Settings dot PHP and this just works super slick You even get reports and Jenkins of if you're perhaps you have something Have a module that's missing you have modules that are turned off you have modules that are redundant You can even configure this to Save have modules that you always want turned on that cannot be turned off you can add those to To be Always on like for example at time. We're using the L that module so to sign in you need that So we could we could actually configure that so that there's no way for a build to turn that off even accidentally You couldn't you couldn't turn that off so Super powerful module for managing deployments and if you have to if you have a situation where you have You're using update hooks and stuff to manage builds. I would encourage you to look at the master module So here's just a Little overview of the whole process here. So you've got the little developer in the girl in the corner here She's making commits to git She can go to Jenkins and push a button say she's working on build 17 Jenkins will run the drush make and go out to drupal.org and all of the custom get repositories and package up a build and then Once that's finished, you know, she might have a report there might be an error She can iterate on that But then let's say that she gets a build that she likes She can push it out to development for testing and in that process run the master module So it'll turn on and off whatever modules you have configured So you could have the develop module on and development for example, and then when you go to qa it would it would be off Um And all of this is you know very automated very push button very You know just It's all done through a web browser, right? So She's done everything from the command line with git and through a web browser And all the way she can deploy all the way to production So it's an excellent process. I really enjoyed working on it with these guys at time The next thing we were going to talk about is the editorial user interface and scott and kevin are going to Lead that All right So of course tanner talked about all the different tools that they made for developers of the of the platform But there's a whole other side to this and that is all the editorial staff that exist at time And there's uh, there's a lot of them because there's a lot of different titles. They're constantly creating content And you know, they need a way to to you know move on to drupal from on some of these legacy systems without being too freaked out about it So that was the idea. We wanted to ease the transition of editorial staff on to drupal You know, it can be intimidating in your day-to-day workflow Especially when you've been working on a certain platform for many years To all of a sudden just make a switch and and author content within a totally different interface Um, so some of the business goals for the editorial user interface were to uh for teams to be a lot more cross functional So if there's editorial staff on one title that needs to work on the other There's a lot less training involved They'll log in and they'll see a very familiar interface. It's something very unified And of course, uh, you know overall On a lot of projects that I've worked on, uh, you know, you tend to neglect the drupal admin interface Because most of it's you know consumer facing. So it was really cool Project to work on where we got to focus primarily completely actually in the in the editorial user interface, so I'm gonna kind of talk about the processes of how we got to You know some of the decisions we made on the editorial UI and kevin's gonna chime in about how we developed some of those features Um, so to get the ball rolling we really needed to find some common ground amongst all the editors So like I said, we wanted the transition to be very easy. So we got some demos from the old some of the older systems Um, we found out what they liked about those previous systems previous systems things They didn't really want to let go of um as well as things that they did like or sorry didn't like so You know like bottlenecks in their workflows You know having to open up a new tab to do a totally different thing and taking you out of the authoring context Those are things we wanted to really um Resolve and things like automation as well Things that were you know traditionally manual that we could actually you know automate and save people a few seconds Because time to market is really everything in in this industry So we identified various opportunities for improvements and this kind of led to our development roadmap And how we prioritized the features that we were going to build into the editorial UI So things like cropping photos and and the ability to even just preview an article Even on a mobile device or anything like that embedding rich media into articles searching for content These are all the areas that we focused on throughout the development of the editorial UI So to get the ball rolling we created some wireframes and and you know nothing too crazy here I I mean I knew that Drupal has these forms and so I basically put them into a wireframe I'll show some examples and the idea was just to bring those to editorial staff to get the ball rolling so um content we focused on the content creation workflow in in the design phase As it is the core day-to-day workflow that they work in so Again, one of the main things was maintaining authoring context So when creating an article keeping the user on the article creation page without having to navigate away from that page But also while still needing the ability to add images to an article and in dcms Images are an entity type as well So it's not like uploading a file. You have to actually have you know all the metadata around that image You have to create a note right So we wanted to find a way a really easy way to keep the user in the authoring article context and and and creating images if they need to And also, you know dealing with just you know common sense type things like the logical ordering of form of the form itself The field grouping You know headlines are at the top bodies in the middle kind of thing We wanted to make it so, you know, it's very self-explanatory But we wanted to make it so it's second nature for an author to create an article See it kind of see it in their head, you know and kind of have a predictable result That what they were authoring on the screen was kind of going to you know reflect on the article in the same anatomy and everything So that was really important So the little bit of information architecture Phase was done there to determine the right flow of the forms Um and also understanding that sometimes design decisions are subjective especially when you're trying to Uh, you know Get consensus amongst a really big group of people some will like it one way some will like the other So we identified certain areas where we could make configurable. So there would be no fighting All right, so once we created the wireframes the conceptual wireframes again, mostly just a shot in the dark You know, here's something to get the ball rolling get the discussion going We brought them into workshops with all the editorial staff So we needed to start somewhere really So we brought these in and we wanted these sessions to be really interactive collaborative We encouraged staff to give us ideas. We just wanted to show them Here's how you might create an article in dcms as opposed to in vignette or in tips And and so we encouraged them to give us ideas. We definitely explained to them that no ideas were bad ideas But what we found was there was a common theme Among a lot of the different groups and that really helped us prioritize What features we needed to actually focus on in in the first releases And of course most importantly with having the editorial staff involved in this process It's a good way to get them excited about moving on to dcms to get the buy-in that we need From the editorial staff. So they're not too scared and also to give them a sense of ownership and pride about the product And and that things are moving in the right direction So that was really important We held various events at time ink to get to get the buy-in Things like the town hall demo, which I'll show some pictures of here. We did an open house We also did some really small branding on dcms itself because dcms is kind of a dry name So we we kind of popped some color into it So as you can see a lot of people showed up to this event No, this is uh, this is just rehearsal picture, but it's very similar to what we're doing here only, you know, this was more of a You know as a town hall demo. We did an actual product demo I had my my turtle neck on and everything and we walked through the entire, you know Workflow was a scripted demo We showed some of the cool features that that we wanted people to be excited about and also You know the features that they brought to us saying that well It would be really cool if we could do this and now we show them that we actually built it And they're seeing that they're you know, their suggestions are coming to life That was a really good thing for for that So a lot of editorial staff and management attended that We also did a a panel discussion at the beginning of that demo where we had various tech leads from some of the different titles Josh sitting over here to represent some of the other brands and and basically they were they wanted to give their input And how dcms will help their brands move on to the next level So that's that was the town hall demo A few months later we did a open house. So this happened on a friday Between the hours of 10 and 2 a.m. So we had a lot of people coming through here And basically it was a genius bar type setup So you can walk in and there's a lot of different, you know Genius bar stations with shiny max on and you kind of felt like you were walking to an apple store in a way everybody was wearing our dcms shirts and You know people would get ushered to a station and they'd get a 10 to 15 minute kind of personalized demo of the platform And again at this point we had already added new features and it was even more polished at this point So people became really excited about that and a lot of positive feedback came out of that So that's all about, you know socializing the the platform and getting people excited And lastly we did just some really quick branding on dcms You know, how do you make dcms a little more exciting? Well, you pop some color into it and you know, that's the name that stuck We actually tried to come up with some other names has stuck. Yeah Yeah, but dcms is the one that stuck you kind of you know if you say it fast, it's really easy to say Yeah, so So that's the that's kind of the logo and the branding behind it So now we're going to talk about some of the features of dcms So the key features here we focused on our form navigation entity referencing image cropping editorial search dashboard and of course some mobile components that as well So starting with the the form so here's an example of the wireframe that I I provided for the editorial staff and Like I said, it's a very overlooked aspect of of developing a site Now a lot of different content types, especially like recipes and you know The more they add on to a content type the longer they can get and that was one of the pain points Is that navigating these really long forms can be really cumbersome? You know it adds literally some seconds to your workflow, which is which is a lot when it adds up So long forms that require a lot of scrolling or clicking we developed this form navigation Which you can see along the left hand side now. This is uh, it's very basic We just use field groups. So in the field ui We set up the content type features to be field group basically in a very logical order And then we just you know pre-process the node forms Output this the field groups as a jump menu and when you click on one of the jump links It'll just scroll the page for you directly to the section This is really really helpful when you need to edit something Especially something that's already filled out that has a lot of images like a gallery You just want to jump right to the images section. You don't have to scroll You don't have to open up collapsed field sets Lot less clicking and just you know and it's helpful for developers too as we're testing and trying to add dummy content We we use this a lot and the developers even really liked it. So that's how I knew it was going to be good And of course we have a mock-up too. So we added some paint to these things as well So this is sort of a glimpse of what dcms looks like. It's very clean and concise. It's not really, you know Not a lot of eye candy here. It's supposed to just kind of stay out of your way But you know we have the ability to the form navigation here is on the top right So that was one of those things that was configurable because some people wanted on the left Some people wanted it on the top So the next feature we're going to talk about is entity referencing This is obviously a huge huge Focus for us a really big feature and a really cool feature. So ultimately Like I mentioned a few times the goal is to maintain authoring context. So by default Referencing in Drupal entity referencing in Drupal is set to an autocomplete So you can imagine that if you need to add an image to an article And you're needing to browse a really large library like time has a ton of images And you need to find that one image that you're going to attach You know an autocomplete field isn't going to help you So we needed to find a better user experience and user interface for getting to the image that you need So again, we provided this wireframe and very simple right very simple wireframe Put this in front of the editors and say, okay, how do you want to find content? How do you want to find the images? What kind of things do you search for? So using this approach we were actually able to get okay Well, we know the editors want to filter by certain things we so we added the filters on the left, right? We knew they wanted to have either a grid view or a list view So we added the toggles to toggle between back and forth. So here's the sort of a visual representation of what that ended up looking like so Of course if an image doesn't exist in the system, they need a way to create that entity really quickly without leaving that page So we gave them a drag and drop you drag images onto this hot spot You click save it automatically creates nodes references them for you. You're good to go. You continue authoring your articles So Kevin's going to talk a bit about the implementation of that right now So the overall goal for this whole thing was to make it Easy clean, but most importantly fast for content creators to create content And for most all of the titles at time this means adding images. So in Drupal terms that means referencing entities so Because it could get overwhelming with the amount of images that are going to be added to to these These sites over time. We realized right away the autocomplete wasn't going to work for us Especially for content types like galleries where you're adding 30 or 40 images at a time to a single node So having to go through and trying to remember even a slight bit of the title in order to find it in the entity reference search I mean, I'm sorry the autocomplete and then do one at a time for 30 images. We knew right away that this wasn't going to work. So We looked at contrib. There was a couple modules that we looked at entity connect was one It's a great module, but it still didn't quite get us to our goals of making it clean and fast So we developed a solution that was using c tool models so that we could keep the user in the context of creating that particular node We used views with the exposed filters to give that faceted search so they can easily find The image they needed based upon any number of features or attributes to the image And then we leveraged form apis ajax capability so that we would actually reference the images as soon as the modal closed Um, so this was a way that we That gave the content creators a very powerful way to to find all the images they need and easily connect them to the node so After we implemented this we actually realized that we could use this for not only images, but really any entity type So um, we configured it to be kind of smart So it would read the field settings for the field And if it was only a single value field, it would only allow you to reference a single value If it was a multi value field, it would allow you to Enter as many images as that field would allow It would also read the allowable types. So if you wanted to allow say text documents or images Then both of those content types would show up in the view so that you could attach or embed anything Or any type of entity so It was a really powerful way and it allowed us to achieve all of our goals of making a fast and easy way for editors to reference content Obviously, I mean we have we're limited in time So there's so much more that we could talk about on that just that feature alone But if if you want to ask questions later on we can we can definitely answer more on that one The next one is image cropping and editing So just a quick point here I mean editors need the ability to crop different images or images differently for each individual image style and apply effects So, you know when we were doing our workshops and doing our one-in-one interviews Obviously photoshop is used. I mean you're not going to really replace photoshop But for some of the smaller titles, you know They wanted to just have a quick way to sharpen something and change the crop on the home page tout or in the article detail page So what we have here is the image cropping interface So once you do select that image that you want to attach to the article through your entity reference You click a crop link and now you're open up you open up this interface. So along the left hand side there Those are all the image styles that are being pulled in That that are set to have the effect ti image crop on them. So now you they're available Across the top you have all the effects and you really just go one by one click Change your crop click change your crop add an effect click change your crop Super easy click save and then you just go right back into your authoring experience. So really quick way to do it And actually really cool Really cool discovery that we made along the way of building this that that kevin will talk about right now Yeah, this was a really fun feature to implement when we came up those with a solution for this We knew we needed to create an image effect that could be applied to core image styles Um, but we weren't quite sure how we were going to approach the ui We needed we knew we needed a place where all of the image styles for the particular image would be on one page And editors didn't have to jump back and forth and go to different tabs or move around It all needed to be right there. So, uh, we figured that in order to do that It was probably going to take us even up to a few weeks to define That that interface But as as we mentioned, we were building this system so that all these titles can collaborate They can share code. They can share features And during this we found out that sports illustrator was actually developing this feature So we were given a quick demo and kind of light bulbs went off in our head We all looked at each other and said not only is this Exactly what we want. It's better than we could have ever imagined and it was all done They designed that in such a great way that I almost had to touch nothing in the in the front end Ui code and all I had to do was slightly adjust The way that it worked on the back end to fit into our workflow So right then and there we saved weeks of development I think that was the first time that everyone actually saw the that You know, this whole project everything we're trying to do is actually happening already. So That was a really fun way and um So that interface was really clean It uses j crop to to manually select a the image that you need to or the part of the image that you want to display for that Image style and we also enabled a live preview So you can actually see and adjust it and see how that's gonna that's gonna come out Yeah, that was a really defining moment along the project I think I got a little bit emotional because I remember look, you know Looking around the room and all the different developers and being like, this is it This is what we this is what we're striving for we're building a community within time And it's going to benefit everybody. So that was a pretty cool moment And I think going forward now they have a lot of different community meetings that they uh, they you know They plan to do this more often. So that was very cool I didn't cry or anything All right, so the next feature is editorial search. So You're all familiar most likely with the admin slash content page now It doesn't really give you a whole lot of the box. It gives you a way to you know find a piece of content Um, you know, but it doesn't give you a way to search, you know in a multifaceted way So here's a wireframe of how we want it to do that again. This is something we put in front of the editors We said, okay, how do you want to find content? What are some of the filters you need on the left? How do you want to find it? And when you find that piece of content, what do you want to do with it? So, um, basically Across the top you have the different content types along the left you have different You know attributes of that piece of content as well So you could you could just basically say I want articles images and galleries that are published within the last three days Click and you have a list of them, right? And then you want to subtract galleries from that click It's gone, right? So you just keep you know, it's an additive and subtractive search It's a really quick way to get to the piece of content that you're looking for And then once you're there you can do anything you want to you can publish it you can edit it Of course you can do bulk operations on it things like that There's some really cool things under the under the hood on this thing. So uh, so kevin will mention those things So the main goal here was to keep the public facing site search separate from the back end editorial search This did two things for us. This allowed us to put content in the editorial index that wasn't that was either unpublished or not meant to be public facing This Also prevented us from having to put a status equals published on every search results page there Because as infallible as all of our developers are We all know that that can easily get left off By accident and all of a sudden you're exposing content that's not supposed to be seen by the public And so we kind of removed that from being a possibility The second part of that is also performance too We didn't want anything to inhibit the editors while they were trying to search for content So if there was some heavy traffic to the site and a lot of people searching and hitting the index We didn't want that to slow down the editors process of creating content So uh to implement this we chose uh to use the search api module with an apache solar back end We felt that this gave us a better use integration uh and with Exposed filters and bulk operations. It allowed us to create an interface that that closely resembled the mock-ups that scott had created And uh that the editors were expecting All right, so the dashboard The dashboard was actually one of the most probably the most requested feature That you know from the editorial staff themselves it was You know i had different groups during my interviews with them What is the first thing that you want to see when you log into dcms? And uh, you know, of course since there's so many different editors and different roles We got a lot of different answers actually You know if you're a senior editor you wanted to see an approval queue If you were a contributor you wanted to see your content and what status it was in right If you were a site administrator, you might want to see some analytics data or some reporting So, um, you know and some people might want to see social media. So of course we had to kind of You know think about that from a from a holistic standpoint figure out. What's the best way to implement a dashboard? So we created a wireframe again and just put some example widgets on there and and held the workshops and and Just got people to put sticky notes We gave them a blank piece of paper and said here create your dashboard right down the widgets that you want on it And and then we took some of those widgets and we created them Things that were that that were again repeated, you know things that we saw that were a common theme amongst all the editors So here's an example of the mock-up Sorry, actually it was already there The mock-up here. So again just a colorful thing. It's you know, it's drag and dropable. It's customizable It's kind of your you know, it makes you feel right at home when you log in At work and you set your dashboard up a certain way you log in at home. It's still the same way You know something so simple like that it goes a long way with the user experience Having things right where you left. It's like getting rid of your roommate that you don't like, right? so It's really cool things about the about the dashboard too that that the way we built it that kevin will touch on right now So to implement this we use the homebox module That's a module that allows you to have a per user configuration And allows you to order and resize blocks to kind of build your own little personal dashboard page One of our goals for this though was to create this in a platform agnostic way We didn't want people Having to be Drupal developers in order to create these widgets So we came up with a solution that Allow developers to create a widget with pure html and javascript Drop it in a certain directory And we would pick that up from that directory wrap it in a Drupal block and make it available to be put on the page So that was a pretty powerful thing there that Allowed anybody with any knowledge of html and javascript to create a widget So most of these widgets would integrate with third party services. So like facebook and twitter but we also We also created widgets that would integrate with services through apis and again The goal was not to necessarily need to put a Drupal block there But to put some html and javascript that would integrate with the service to get the The content that you needed to display for the widget. So for instance, uh, they had a content status widget where it would show you Which state the content you have created was in? How many articles things of that sort? But in the end if they needed to throw a Drupal block in there they have that ability as well And just one last thing on that too is that you know, it gives you the ability to use any sort of front-end templating language That you want as well. We built some of the widgets using handlebars Uh, we used did one using underscore So it gives you the lot of freedom there to to create these little apps within your dashboard in any way you want So a very powerful thing So the last thing that we're going to talk about real quickly is is mobile so In the words of time this actually revolutionizes how time publishes content today They can create content directly from various events with your mobile phone They can take a photo at the super bowl and they can create an article right away They can publish it right then and there or they can assign it to somebody who they know is working at their desk Or they can save it as a draft and pick it up later when they get home So, you know, we take it for granted nowadays, but this is something that's really really big and and the time to market Is everything thing, you know, it really rings true with with mobile. So It's a scale back interface. It doesn't give you all of the stuff that you need But it gives you, you know enough to get going right? So here's the wireframe of of the the mobile interface and when you log in you basically You land on your little scaled back dashboard. It's basically a view of all your content Now the great thing about the mobile device as well This is a mock-up of it Is that if you're out at a bar with your friends and you're having a drink and your boss calls you And he said you need to come into the office and edit this article really quickly because there's a really bad spelling mistake in there You know in the past you'd have to go into the office But now you can just you don't have to put your drink down. You just have to log in on one hand Have your drink in the other and you just make that change And so that's a huge win editors love that So, uh, yeah, basically node forms are optimized. This is basically just a sub theme of of the main theme that we used And that's all it uses user agent detection device atlas To determine what device you're on and feed you that theme Basically, I mean This note forms are a little bit scaled back because you don't always want to create an entire article Maybe you want to create a stub article or a draft or whatever it may be But this is where we utilize some field Collapsible field sets so you can you know if you want to start a headline just open up the headline You know create it and move on So very powerful very cool A lot of wow factor when we're you know doing demos and taking photos of people and creating articles on the live website It went over very well with the editorial staff Just one thing and and you can follow the content creation process from beginning to end All on your mobile device take a picture create an article and publish it out there without having to touch a desktop Yeah And and of course since we're we want to be very cross-platform and and mobile We also we're developing the milk carton version so you can actually update your website while you're eating your cereal So that's being released in the in v v nine or something so 11 v 11 So thank you very much. It's a very you know a lot of a lot of content to pack into an hour session So we wanted to save time for questions. Um, we know we went very fast. So, um, open up the floor to questions now And uh, thanks again Yeah, if you just want to use the mic here, sorry Sorry, have you been able to contribute any of the models you did the gallery the Yeah, so actually, um, so that is something that we've given thought to and something that we're working on You know being timing. Um, there are Approvals that we need to get and and to make sure that we're doing things in the right way Um, so we're working on it. It's the best answer I can give you Hi, I just wanted to say hi. Um, this is a very funny thing for me. I went back in 1995 I was one of the um timing digital. It was called timing new media back then Um, so when you speak of the history of cms, actually we did vignette one Way back That replaced flat html So this all comes full circle for me. I just wanted to say it looks great It's so good to see you using Drupal And it looks to me like you're you finally got it right Thanks Hi there, um, I I really appreciate what you were showing about How to add media attachments to a node. I'm curious if you've done work with Allowing them the flexibility to add that into body copy and and if so what approach you took In handling that Yeah, I mean the answer there is we haven't ended put it into body copy yet That is on the roadmap though, right? Yeah, basically, that's the best answer we can give you one thing we have done though is we've worked on Extracting when possible information from the actual image asset or Video asset if possible like xf or ipdc And allowing editors to take an image drag and drop it into dcms And if that information is there map it to fields So that the node is actually created as a part of just uploading the image, right? Great. Thank you Hi Thank you very much for sharing all of this. I think it was great I have actually two questions One is of the operational nature is basically how many people and how much time to take it to build all of this And the second question that I have is did you guys have any concerns about allowing? Pretty much arbitrary html widgets into Drupal to pick them up and what was the technical concerns and considerations there? Sure, so um, so it takes a lot of people actually to do this and has many of the people are here I can't thank them enough. They're you know Have been there, you know from the beginning You know, I have a team actually I had individuals from app innovation Tanner was working with me Jeremy sitting In the audience. He runs one of the development teams So really a very large group and really a lot of collaboration between us and the brands so And this process we really started 18 months ago. I would say So, you know took a while for us, but we really wanted to think it out and when I was talking about the playbook That's what that was defining how we do this As far as widgets you're talking about whether or not Like how do we go about accepting a widget or allowing people to correct like I mean What is the process like in general and what are the concerns considerations like limitations of the process? A little bit more in-depth about that if you sure can't please. Yeah, sorry, so um For widgets, um, we tried to make the dashboard as lightweight as possible Like we said, we wanted to make sure that people could develop widgets With just having a knowledge of html css and javascript There I mean it depends really is the best way I could answer that in that, you know For a particular brand if they have a an integration with a third party or even internally You know one thing we didn't mention is that we do have internal enterprise services that we want to integrate with as well If there's a specific concern for a brand at least it gives them the freedom to go and develop a widget So it really is Based upon a need basis if a brand has a need to integrate with a particular platform they can No, no, I'm sorry. Yeah, it's their development teams when I say the brands there's there's developers that actually work Okay, so that's not exposed to like producers or anything that it's basically developers who do that Yes, thank you and just to go back to your your first part of question I can tell you that the editorial user interface aspect and development of that was a team of About three of us developer two developers and a themeer over the over about seven months And of course, I mean Match team had a lot of stuff going on too But the actual theming and the development of those features that I was I was showing earlier It was it was a team of three people. All right. Thank you very much Do you guys have to translate any of your content? Do we have to translate our content? Right, is there a multilingual component to the content that people are putting on times? Sure, I mean if we talk about a title like people in espanol that actually is Is in spanish natively and translates you have translation in place for english, I believe bilingual So what is that process like for you guys? Do you have people on staff like manually creating them or using something like lingo tech or Do you have do you outsource the translations to other firms? We don't have any specific process in place to do translation that i'm aware of but you know It's something actually that is a little bit beyond my Scope so that's really something actually that the brands would want to handling on a title by title basis Sorry, okay. Thank you Two questions first. What did you guys do to accommodate the content approval process? I would assume that there's different level of Approvals within the organization from creating a piece of content to when it goes out to the public Yeah, so we we use state flow And we've basically built in a basic workflow. That's basic, you know draft Approved draft interview approved publish And that that workflow can be applied to any content type or not, right? So some some content types won't have that enabled But we do use state flow for that So sorry, what was the state flow state for okay? The second question is What type of user test you guys have done? To tailor the front end to your target audience that the reason why I ask is when I go on the sites I notice that at that navigation that burger bar And it says menu So did you find out that people didn't understand that that triggers the menu or on the on the mobile view? The the red ball on the left also says tap as well. So I think that's like, uh, you know The big guy. Have you guys done any type of user? Test to find that you know having those actions to call the reaction to spell out is actually more beneficial to your target audience We haven't done anything like a b testing or anything like that on design assets What we do is, you know, that's that was the purpose of a lot of the demos that we had and a lot of the workshops that we held And also we're in early release stages right now. So we're getting that feedback in real time basically And and we plan on it. But yeah, those are some those are some, you know design patterns that you describe that are, you know Ask different people. They'll give you some different answers on what works best Okay, but we find that just you know a little bit of training is all it really takes and and they're good to go on those ones So, okay, thanks Hi, uh, first and foremost, um, very impressive stuff. Um, and my question's more not I wouldn't be as technical as the rest, but I'm talking you explained the buy-in for for brands and editorial and what you went through to, um Kind of demo what you've been doing. Did you did you run into any difficulties at first? Or did you jump right to workshops and everybody was like, oh, this is great Um, yeah, well in my from my perspective, yeah, there was there was some difficulty for sure because You know when we're when we're giving them such a simplistic view of how to create an article There's a lot of concern over. Well, I'm not going to be able to do this anymore or How am I even going to do that? I don't see where that happens, right? So Again, it goes it kind of goes back to educating them along the way and explaining that it's somewhat a fundamental Fundamentally a different way to approach authoring a website So just by being really collaborative and open with them was one way to to get over that and then Matt, do you have any examples of things that were difficult? So I would say that, you know There were difficulties Given the diversity of the brands that we're working with They're trying to achieve different things with their sites. So making sure that we're listening Making sure that we're hearing their requirements was just a Big step. It was a big requirement for us to make sure that we were getting their information You know, it was Anything that is, you know, really worth doing, you know It's going to have some challenge associated with it and it was a challenge Okay, thank you Yes, you're showing a image management. How about video management anything that plugs into uh, yeah Yeah, we We use bright cove For most of our video serving So we didn't really get into that feature for this presentation But we did put a lot of effort and work and I believe that's still going on now to Have a fully clean integration with bright cove that way Editors and content creators are purely within the interface of Drupal Bright cove is almost abstracted From that process, but yet we can still leverage them to serve the videos and all of the content. So We did quite a bit of work on that. We just In the hour time we have here we weren't able to touch on it Okay, so it'd be something that you would taking the assets and the metadata from your bright cove and being able to Connect it in and related videos and presenting it The metadata and all of that information is put into Drupal and we actually use their Batch processing system to to throw the assets along with that metadata and it gets ingested into bright cove And we actually utilize the entity search user interface that we were showing for image entities for finding those videos Excellent. Thank you Hi, uh in the presentation you mentioned you guys were used doing like active active active states Is there any specific like at the database level the replication or clustering technology that you guys were using? We do have a clustering technology and and even though I mentioned active active active to just demonstrate some of the more challenging Requirements that we had. Um, you know, it's something that we're actually still working on. I can't say that we've achieved it You know, we've taken a different path since the pwc engagement Still on our roadmap still something that we uh, we think about but yes, we do have clustering at the database level We're currently active standby And working on an active active approach. Okay. All right. Thank you Hi, I've got a couple of questions. So when you're writing the The business case of this program. Did you have an expected savings you would make by having one coherent platform? so Yes, I would say I I don't have a I can't quantify that for you Um, but yes, I think just the idea that we would have a common platform across the company That you could share technical resources. You could share at many different levels including The the technologists the actual developers that are working on these sites Having that I think there's savings there. There's savings in being able to reuse Being able to have one brand create Functionality and then have another brand leverage it. I mean we saved money and time With the photocopying tool that we described earlier that You know sports illustrated was working on creating their photocopying tool They were following the playbook and that standardization really paid off for us It sounds like you really wanted to do portfolio management as opposed to project management Trying I guess yeah, and you didn't talk very much about migration or complex integration with external systems. Is that also to do or Um, so I would say though that like bright cove is a an example of a customization with an external system And that we have what we tried to do there was I mean there were really multiple things we were trying to achieve But one of them was to make the user interface experience Performant make it responsive So we didn't want somebody who's going to upload a three gigabyte video file to have to sit there and wait for You know the shipping and round trip to bright cove and then back again So we decoupled that so I mean that's the approach that we take and there's any number of Custom integrations that I wasn't able to get into as a partner has a couple maybe you can sure yeah I mean there was an LDAP integration. There was a ping identity integration for single sign on with aquia so there were a lot of um You know third party and local kind of within the enterprise integrations And they had an api for doing customer subscriptions Uh, there's an integration there. So there was a lot of integrations You know across the enterprise and with third parties as well. Yeah, actually I mean for our internal platform I mean alongside alongside our editorial user interface there are platform features that we've developed and Many of them are actually custom integrations with our enterprise services for polling profiles bookmarking Things we already had in place that now we wanted to hook into dcms Thanks fantastic How accessible is your uh The whole site both on the excuse me both on the front end and in the ui for the editors Accessibility. Yes. Um Well, there's some there's some cool features in place. I mean It's not it's not somebody wasn't our main focus. Um, but there are some cool things like You know keyboard shortcuts in place But I think that's probably the extent of accessibility. I mean, it's not really a public facing site So we kind of knew our target audience. It's a smaller group We knew kind of their demographics and how they how they like to work So what about in the public facing end? Are you guys required to be accessible or not? Well, that's it's a difficult question for me to answer. I mean, so I work for the technology group for it We create the platform and then we hand off to the brand. So once again, I'm going to have to Say that really that's probably more of a brand specific answer. Um Not not one I could probably really give you an adequate answer to here. Sorry Okay Do you have feet? Oh Thank you. Thank you. Is that it for our questions anymore? Thank you very much everybody. Thank you guys