 Hi Yeah, that creaking isn't gonna go okay Hi Welcome to building for the post-mobile world It's got a relatively cheeky and ambitious Subtitle basically going to be talking about why our mobile websites are doomed Why your future is full of structured content and how you can build stuff without going bankrupt? Well, hopefully or bankrupt Less bankrupt than you would otherwise. We know how web stuff goes Hi My name is Jeff Eaton. I go by Eaton on Twitter and most other internet places I'm with company called Lullabot. We do strategy design and development for relatively large sites lots of them about to press next and Sadly, it's a light gray So you're gonna have to trust me that there are the logos of awesome companies like, you know best buy and WWE and Martha Stewart and NBC We we we actually built God's website, but you totally can't see it because of the no The reason I usually show this slide isn't just to test the gamma levels on the projector but also to give a little bit of insight into the kinds of organizations that we tend to work with because we Tend to see a lot of similar problems. We've been building sites for companies like this for probably about seven years or so now and There's a lot of common patterns that come through both in the State they're in when we start working with them and the kinds of challenges that we end up finding as we work through and build out new projects for them Feel free to leave if a you don't actually manage or publish content You know, you might actually be in the wrong conference entirely, but you know, you're definitely in the wrong room If all you really work with is small static content It doesn't change a lot Drupal can be an odd, you know match for that kind of site But I yet people still build a lot of interesting stuff with Drupal It's just that the kinds of things that we're talking about in this session Are gonna be really really geared towards people who deal with large volumes of content or a lot of turnover in their content They they have to deal with the fact that that stuff that's getting published and put out there on the site Has real value and they need to keep managing it effectively on a day-to-day basis Also, if you have an infinite budget or unlimited staff resources or like a giant Intern-making machine that just keeps pumping out eager people who want to like, you know tweak your markup when you decide Things need to change. Yeah, probably, you know, you're good So you don't need to listen to this you can just throw bodies and dollars at any problem you've got Also, if you're retiring in 2014 You might actually just be able to wait out most of the stuff We're talking about and just have margaritas while the rest of us are trying to get things working on Google glass or whatever is Actually hot in like two years otherwise Please stick around and feel free to follow along or heckle on Twitter on the post mobile hashtag I'm going to be throwing out some statistics and a lot of references and if the Wi-Fi holds up It's going to be tweeting out the links to more information and background studies on some of the stuff that I'm referencing in this So the first thing that I think we're all sort of coming to grips with is the fact that mobile is not a New trend anymore People using mobile phones and mobile devices to get at the stuff that we publish is not something that you read about in Wired, it's something that you read about in readers digest at this point It's here I'm going to kick off with a quote from Karen McGrane who's excellent book Content strategy for mobile gives a really good overview a lot of the of a lot of these issues One of the things she said in a list of part article a while back was that people don't want different content or less content when they come to your site or to your properties with different devices what they want is Their devices to be able to look at the stuff. You've provided they expect that and they imagine the devices that they use whether It's a laptop or their cell phone or whatever they think of that is just a window onto this stuff that you have and they Users no longer consider it a problem with their device if your stuff doesn't work on it They consider that your problem and think you're broken. Well, maybe not you personally. They may actually like you But your site definitely broken It's a current crisis today for a lot of organizations because Frankly, lots of our websites just flat out don't work well on mobile and there's a lot of reasons for that that we're going to be getting into but the reality is that 57% of adults in the US currently use their mobile phone for browsing websites 15% of US adults use their phone for primary internet access That means that the vast majority of the web browsing that they do is just on their phone They don't just you know dash to and from the airport and occasionally like check their flight times it's what they really read stuff with and in different demographics that spikes way higher in certain minority groups and low-income groups or in like teens and Other other demographics. It's even higher percentages teen girls specifically like ages about 13 to 18 47% of them use a mobile phone as their primary internet access and web browsing device if your company targets that demographic Think about the fact that that's a higher percentage than the number of IE users Not IE 6 users or IE 7 users just people who use internet Explorer are outnumbered in that demographic by people who only use their Mobile phone to look at your site. It's no longer a feature that we add. It's just a Place that it has to work But it actually is a little more complicated even than just Everyone's now shifting to mobile at the same time We're seeing a rise in people who use quote-unquote mobile devices in ways that we didn't really expect a couple of years ago 75% of mobile usage like you know, oh, I'm on my phone I'll look something up happens at home or in the office where people have access in most cases to some other Internet accessible device but decide to use their phone because it's what they're holding or I'm on the couch Or I'm actually walking somewhere and I don't want to go to the go to my other room and look something up 90% of the people who use mobile devices also split tasks between Multiple devices in many cases for example, they'll look up a product on their phone and Then an hour later go and purchase it on their desktop machine Or they'll search for something and look at it on their tablet when they sit down or another Really common pattern was people who found news in the morning on their desktop machine And then while commuting on a train or something like that would go and read it on their phone Now what they're looking for isn't some kind of wildly different kind of content or a different Experience they want the exact same thing that just happens to be the device They're holding and one of the really chilling statistics is that 68% of the people in one of those studies Said that if they went to a website on their phone And it what didn't work they wouldn't bother going to the desktop website They wouldn't say oh, I should go check it out at home on my desktop machine. They just said whatever. I'll find another website and That's that's a real shift from what we were seeing even a few years ago The lesson to take away from this is the idea that parody Between what we're giving to people on a desktop site or a mobile site or a tablet site or wherever They're trying to get it stuff is no longer optional. They consider that again as you know Karen McGrane said these are just windows on to the stuff you have to offer and if the window they're looking at it through is blacked out They're not going to hunt around for a different one One of the things that we end up seeing a lot we work with a lot of large media and publishing companies There's been a real uptick in people who felt like you know, okay, that's great We can fix this by rolling out apps, you know who here quick show of hands Who has had a business stakeholder who's gotten super excited about apps? Yeah, okay sweet not alone It varies wildly depending on the kind of functionality that you care about but building apps isn't cheap Who here is actually paid to build an app? Okay, yeah, well Stack overflow actually did a survey of a bunch of different development shops and a bunch of people Collected their they're sort of compared their notes and the running average was somewhere between $50,000 and $150,000 to roll out a reasonably feature rich mobile app Now if all you're doing is piping in an RSS feed and presenting it or doing some geo location stuff You can do that, you know much lower cost But a lot of the excitement around mobile apps versus just a mobile website is this idea that it can offer so much more You can offer this incredibly rich deep experience with the power of your mobile device But that doesn't come for free and on top of it the idea of publishing an app isn't some sort of like you know Money fountain 60% of the apps in the app store don't get downloaded now a lot of them are fart apps That's true But it's not like simply putting it out there means that people are going to be just hoovering up your app And are going to be highly engaged users and stuff like that 50% of the time that people actually spend in apps is either on Facebook or playing games a Lot of the time that people spend engaged in apps is already being hoovered up by other groups or you know other Other organizations that have already gotten a real solid anchor in gaming and stuff like that It's very fragmented the time that you know people spend with that I don't want to belabor this point, but it comes up so frequently that like that is that's gonna be our silver bullet They can be a really important part, but they're not going to solve the underlying problems that are making these mobile and multi device issues problematic Who here is thinking? Ah, yes, but responsive web design. That's the solution. Yeah. Okay. There's some excited people now I agree to an extent, but the problem is responsive design is ultimately about providing one fundamental Set of HTML you're outputting one document and you're using nuanced complex CSS rules to decide how things should get shuffled around and moved around on the page based on screen size Perhaps certain other cues that you get from the device, but ultimately that kind of approach is really easy to push to its breaking point This is a terrifying image for anybody who's thought about what kind of break points they need on their responsive site It's a couple of people a Couple of sort of future friendly web design people who got together We're talking about some of these issues and decided just for kicks They would pool all of their mobile devices and laptops and tablets It's about a dozen people and I think they were able to represent something like 80 bajillion different screen sizes and For better or worse if we're really serious about trying to get things working well on the different devices that people look at We have to accept the point that or we have to accept the idea that There is an ever-increasing number of break points There is an ever-increasing number of device profiles that we can't simply sit on it and assume that Roughly iPhone and iPad sized things are what we're trying to target with our responsive designs forever Even devices like Google Glass are starting to push the boundaries of what constitutes a thing we should try to design for In theory, it's just another device But it not only has weird variations in screen size and the attention span of the people that are looking at it But also how exactly do you? drag On Google Glass how well do your nav menus work on Google Glass? It took so much work to turn that rollover drop-down menu into the little hamburger icon that you click on to make the menu pop down We're really proud of that and we're thrilled that we can do that with pure CSS But how exactly do you capture a hard stare? it's tricky and There's also devices that are starting to come into play that are Theoretically not desktop computers, but they're not even mobile devices My my living room television is the least mobile device you can imagine yet It has a copy of IE on it. Thanks to my Xbox It doesn't have click effect click mouse clicks or you know taps or anything like that it has two little joysticks and two triggers and The interesting thing is is one of the settings that they have in IE on the Xbox is pretend to be a quote mobile browser And it's useful because on a lot of sites it triggers the easier to read simpler layout But it's fundamentally a lie. We're just sort of piggybacking on oh people are trying to account for mobile Well, we'll try to use that to account for you know this you know desktop year this living room device but that isn't going to scale forever and You know admittedly there aren't a whole lot of people like you know doing their taxes on TurboTax from their you know Living room on the Xbox, but at the same time the number of people who actually have an internet connected Xbox in the country It's currently at about 46 million. That's more people than Comcast has subscribers I mean the general scale of things that's a potential distribution channel for content that is Pretty darn big and the reason a lot of people don't use it is very simple Websites are still kind of crap to use using a dual dual joystick controller. So why should they? so moving beyond this idea of Mobile device proliferation being a big crisis right now Another thing that's looming on the horizon what I kind of think of as tomorrow's really really big disaster scenario is the explosion of Publishing channels is anybody familiar with the phrase multi-channel publishing Okay, cool. I'm very excited people most of them I've already chatted with and we like hugged and we had structured content good feelings and everything So multi-channel publishing is basically this idea that instead of simply thinking of our website Or then you know saying let's get daring and let's say well There's our website and then there's apps and this is really where a lot of us are still living when we try to think About accounting for mobile it's you know well Let's make our website design work and then let's roll out apps The problem is that the real situation actually looks a lot more like this. It's not just apps in our website It's also social media channels that people are sharing our links through We worked with a couple of news agencies where like on certain on certain days where key events were occurring Upwards of 75% of their entire sites traffic came from mobile sharing where people were passing around links that referred to you Really key breaking stories Email who here has to send out a newsletter Okay, yeah, no one likes to it always like somehow gets shoved to the last horrible like task on the entire site Implementation that a sad developer has to go and implement and do the email system integration. You've got to send out newsletters every day But the problem is that's another channel where fundamentally our content needs to be pushed out And it has different constraints than the web. It has different constraints than a mobile browser. It's email It doesn't work anywhere and surely there's an important stakeholder who only has an AOL email address and it's got to work there Data feeds for for Partners that need to consume data from our sites. That's a really common thing We find with businesses that are selling, you know doing B2B sales They need other partners that they have to be able to consume the raw stuff from their website Print some of us actually have to deal with actual physical things with our content on it God bless all of you who are doing print and digital simultaneously. It's I salute you But the idea is that all of these different channels are having the same Multiplying effect on the work that we've got to do and the different kinds of Presentation styles that we need to account for and that's really really rough one of the reasons that it's so rough and also so expensive is That it's very easy for us to start forking our content where we start Subtly without even realizing it We're producing alternate parallel versions of our content for each one of those different channels Or maybe just for one maybe just for one of them and then that sort of creeps into one of the other channels And before you know it you've got a billion different copies of your content and that kind of content forking You know maintaining different parallel versions of everything for all of your different channels doesn't scale I like to think of this as sort of like the the perfect ideal case You know in ye olden days when there was only ever one publication channel or anyone needed to care about you had your idea maybe you know the Stakeholder has a nice conversation with the person who's going to write the copy and they write it and they make a Document and it goes into like your company newsletter or something like that or in you know more modern times It goes up onto the web page or our company's home page Who remembers those fine days when unironically referring to the home page really meant something The problem is that as these different channels start to multiply and we need to start accounting for those things It's very easy To start blasting out into that You know we maintain those multiple copies and suddenly you realize that that person sort of that sad sad person Whose responsibility is maintaining the 80 trillion different permutations of this document or God bless them Updating the document when the date for the event changes and then having to go out and blast that same change to all of them They can no longer produce the stuff that you need them to produce as quickly as you want them to so they're overloaded and Sometimes the solution is you know lots of amphetamines and you know someone with a whip cracking and stuff like that Other times those organizations that are just you know forced into either hiring up and You know just had throwing more bodies at this problem or just scaling back How much they can actually produce and actually put out there now some of us could probably manage to not Push out so much content, you know Maybe there's decisions we can make about whether or not it's really important to publish all of the stuff We publish but the idea is we should be making those choices strategically not because we just don't have enough bodies to maintain The 92 different permutations of our event that got sent out Karen McGrane in an article called a a separate mobile site no forking away Said that this is really one of the primary emerging challenges for a lot of organizations It's not even the cost of building those different things on the edge like a mobile site or an app or something like that It's the price of maintaining all of the different permutations of your content for those things That's a killer and it can increase geometrically like the cost of actually really running your business over time it sucks The interesting thing is that this isn't actually a new problem You know we're talking about it being we're talking about this problem in the context of mobile But it's really something that we've been with that we've seen and had to deal with well I use the royal we I mean people who deal with Content have had to grapple with this stuff for a long time One of the first one of the first instances that I think a lot of us saw firsthand was the transition from Print to CD-ROM who remembers like in Carter Yeah How crazy like those commercials about you know look at these five shelves full of books You can replace them with a shiny disc now the funny thing is is on the back end that was a Monumental Undertaking just think about how much of a pain it was to actually be like Grollers the first encyclopedia company says, okay Digital encyclopedia how are we gonna do this it was a really really massive undertaking and that was one of the first So things that like this current generation had to tackle in a large way that was visible to the rest of us Ah, but then there were the the online service wars I mean anyone have prodigy. I mean not had prodigy Yeah, some of us did a well. I was an aol guy, you know, you had to you had to like tile your bathroom somehow I joked because I love I Remember at the time there were a lot of organizations Newspapers Publications that we're trying to get on to online services, you know AOL keyword and why times go read the news And it was a big question. Which online service do we invest in putting our content in? Where's the biggest audience, you know, do we go comp you serve? Do we go AOL? What do we do? You know, I think four people drew the short straw and had to put their stuff on genie Thanks But the funny thing is is all of that ended up getting eclipsed as soon as the web really rolled around and suddenly all of that time invested in Tailoring content to these proprietary Weird goofy publishing systems that online services is cobbled together Suddenly looked archaic and goofy when now everyone wanted a website And then once everyone had a website you got the browser wars. Remember those fun days Please visit the internet explorer version of our site. Please. Oh, would you like to see the Netscape optimized version of our site? I think this is where like the current generation of web CMS and web publishing tools really sort of Found their legs like yeah, this is what we never want to see ever ever ever again We do not want to get stuck here. We'll just put our content in posts And then all this Netscape and IE stuff will be in templates and will be gold and Yet here we are. Oh Okay, so the mobile site this this is different. This is the time We're really going to just do it, you know, and we won't have to do this again I mean what could possibly come after mobile, you know, it's Well, yeah, you know, what could possibly come after AOL what could ever supplant such a dominant online service? The the key idea here is that we don't know what the next thing is It's not that we have to constantly chase trends and like desperately try to run after whatever the cool new thing is It's that if we don't plan for the fact that this keeps happening to us and that our content is Going to have to adapt itself to new and emerging channels different devices that we haven't even Haven't even predicted what kind of goofy input mechanisms They're gonna use these kinds of things are really important because if we don't plan for them And we don't work to make sure that the next transition isn't as painful as this one We're gonna keep paying to rebuild our websites to migrate our content to finesse it back into whatever the new Tweaks and hacks we need are in order to keep paying We're gonna keep rebuilding we keep doing this over and over and over and over again, and that's unsustainable It's just not cool all of the promises that we make in an open-source community about how much better it is And how bet how much better the ROI is, you know over the long haul the license for a high-end CMS and the cost of zero for downloading Drupal vanish into Insignificance when compared to the cost of trying to maintain a business over the long haul when you've got to do that kind of Parallel content maintenance and the cost of rebuilding all of your Customizations every three years when the new crazy thing makes your old approach completely invalid that just is unsustainable and it won't work So if I depressed everybody yet Yeah, it's this is like a classic three-part like Pentecostal sermon, you know, you got to scare everybody and then The good news is that there's a solution to this. It's not a I to be fair I did say please heckle There is a solution to this It's not a product It's not like some sort of magic wand that we can wave over things But there is a different way of approaching these kinds of problems that has proven itself in a lot of these past transformations Interestingly enough the White House has written some very very interesting stuff about this concept One of the white papers that they put out a little while ago Their digital government blueprint one of the fascinating sort of opening paragraphs basically says that rather than thinking primarily about the final presentation of their content their focus needs to be Ensuring that their data and their content are accurate universally available and Basically easy to repurpose for all of the different edges that people are going to need to access government information on now For the US government, that's a big challenge because they need to think not just about their customer base, but every American So the possible edge case scenarios of who's going to need to get access and who is who's entitled to access For to go to government information. They really have to sweat bullets about a lot of this stuff And if you look at data gov, they have some very very interesting stats on how people are starting to repurpose this generalized, you know Information that they're putting out there in terms of government spending How programs are performing stuff like that and that gives us the first bullet point on this list of some of the kinds of Organizations and kinds of large sites that have been forced to grapple with this problem in the past You know I mentioned the government, you know They deal with large quantities of data and people need to get at it in lots of ways and are legally entitled to get it In lots of ways Large enterprise businesses, although they're not necessarily known for being super responsive on the mobile front and on the Bleeding edge of how to present stuff have in many times been forced to deal with the challenge of having reams and reams and reams of internal documentation or Legal information or whatever that they need to hold on to and they need to be able to work with The problem is is not a lot of that information gets shared not a lot of it gets talked about Which brings us to a couple of other communities that have actually shared a lot more Knowledge about these kinds of challenges. One is technical writers. Was anyone expecting that one? I mean, you know, you were looking at my slide. So that's cheating But before the slide came up who would have thought technical writers But it turns out people who write say manuals and say have to worry about the PC version and the Mac version Of a manual and how do you write a document that stays accurate and in sync and has all kinds of things like well This is a tip versus this is a call out and this is the piece that should only appear in the windows printed version And this is a piece that should actually only appear in the PDF version that we output in order to put on the CE Rom And this is actually how it should be broken down when we put it on our website in the help section They've been dealing with a lot of these challenges for a long time Sadly, I'm not going to go too much into detail about the kinds of solutions they talk about But if you've ever wanted to write your own custom XML schema, you totally need to hang with those folks What I'm going to focus on a little bit more is examples from the news media in part because At Lullabot we've dealt with a lot of media and publishing companies So we've gotten a chance to look at some of this stuff, you know First-hand and hang out with some of the people who are doing interesting things and talk to them in this area But NPR's cope architecture is one of the things that I want to talk about real quick. Has anybody heard of that before show of hands Okay, cool decent representation The principle that they really focus on is that they only want to manage one Pool of content and that's sort of the first linchpin in this dealing with a changing multi-device multi-channel world NPR's cope architecture stands for create once publish everywhere. Well, it previously stood for that They're actually moving to Cape create anywhere publish everywhere, which is cooler and has superhero tie-ins But a lot of the but a lot of the principles that we're talking about here are still Consistent and are you know really at the heart of the way they approach things. They started with a small team almost a decade ago And they've been building out this system for a long time It's not some sort of thing that they just you know through Billions of dollars in a giant consulting team at they iterated it internally and it's worked really well for them And the key idea is that they want to use the same content across all of their publishing channels If you've ever looked at the different ways that NPR's content is actually available It's kind of staggering. They've got you know a desktop website And this is some cool story about some you know teenager who figured out how to make solar panels in his backyard It's got a you know audio text, you know transcript details And here's the same thing on a mobile browser on my iPhone It's actually you know same content. It's a relatively simple layout, but it's a new design. They just rolled out fully responsive Here's the iPhone app version. It's cool because it's an iPhone app It can take advantage of device features like playing the actual audio transcript and keeping it going in the background While you navigate around and do other things on your iPhone can't do that on the mobile web version But you know it's about it's about the capabilities that you can leverage in these different sort of endpoint channels The key is that that's exactly the same story as it's there on their mobile version The Android version Same deal. It's got a different design. It's got a few different You know it's got a few different features that are tailored to what they were able to do when they were rolling out the Android version Their partner websites like Minnesota Public Radio have the same content as well They can pull in any story from NPR and publish it if they want to They roll out micro sites for some of their most popular shows that publish just the content from those shows on those Separate micro sites with their own domains and their own branding and stuff like that They push stuff out to their YouTube channel So some of their content has video stuff that goes with it in addition to just audio content And you know, this is starting to become repetitive, but it's the same content If you put share a link from NPR on Facebook or Twitter or any of social sharing services It pulls in rich metadata with the same same basic text about the story thumbnail images stuff like that basically then what the essence of that story is is getting repurposed in all kinds of different places and They have it all in one centralized repository for that content They don't have different parallel versions of that they don't have someone madly copying and pasting stuff into their YouTube channel and Sending over a Microsoft Word file to the people from Minnesota Public Radio so they can make their own copy of that story Because again that doesn't scale that's the problem. They were trying to solve with that and it's worked pretty well No, it's all unicorns and like you know waving magic wands at this point, but it does work How to do that is a little trickier the really big key is that the actual Content that you have that you're managing in your CMS Has to be structured to allow for that kind of remixing Is anybody here familiar with the concept of chunks versus blobs Karen McGrane has talked about that a lot The idea is that you know We're very used to sort of just dumping dream weavery blobs of HTML into a big field and a lot of Design and formatting stuff starts making its way into say the body field of our article That kind of blob is fundamentally Terrible because when you start trying to do these device transitions everything breaks down It's all stuck in this big body field and you can't really restructure it effectively without just hiring armies of interns to go In there and change the markup. That's not cool structured content is a lot different We're actually used to this kind of stuff in the Drupal world. We've got cck and field API So we we roll with it pretty cool, but looking at how they've laid this out as a really nice instructive example In NPR's cope world There's one really key primary unit of content the story This was a huge debate into internally with them You know some people thought it was you know pages some people thought it was I think Broadcast you know a particular episode of a show or something like that What they settled on was the idea of a story and they purposefully settled on that because it seemed Medium agnostic although they were primarily a radio Radio's you know network at the time Calling it a story allowed them to capture what it was and treated the radio broadcast as just another place That this story went out the kinds of things that they track for each story are a title a Subtitle a short title, which is a little between a subtitle and the title teasers mini teasers for when they only have a tiny little bit of room Slugs like the kind of things that you generate, you know URL, you know short, you know customized URLs from text full html form-added text Image thumbnails publication dates this is all the kind of stuff that we're very used to seeing in like a Drupal site that we've built out But if you pay attention, it's it's nice to note that they don't have any kind of formatting Information here. They don't have stuff that goes in the right rail in their model for what constitutes a story They have a poll quote and on their main website that goes in the right rail But they're not trying to model a story as this thing that lives on our website They're modeling what the essential concept of a story is for their business and that makes a big big difference and NPR's model is pretty simple They've got a story and then they group them into like programs and series and blogs But this pops up to the level of how we define our content types, too We actually worked on a website called a tech guy labs anybody listen to Leo Laporte's radio show We we built out there the new version of their tech guy labs site I think last year and What the starting point for it was this was their content model? They had a wiki And it had served them well for probably about six years But ultimately it was just a giant pile of pages with hand markup You know the markup of what constituted an episode of their show had just drifted over time as different people came in And we're working on it and thought oh it'd be nice if we put this information in there So they understood yeah, this is terrible. This is the prototypical blob of content We need to figure out what what really we need to store The things that they ended up settling on It wasn't a huge content model, but it was things like okay. We've got a show We've only got one show on the site now, but we want to keep that there in case we ever roll out You know compared a second show or whatever so we want that to be tracked in our model But we also want this idea of an episode of our show because that's a fundamental Organizational unit that we have they wanted to break out all of the individual segments on a show like questions that people called in with Interviews that the host conducted with you know other other people that he had on the show News that he just talked about in a little segment on like oh Google just announced something So I'll chat about this for five minutes on the air breaking those things up into those different segments Wasn't just an exercise in purest You know content modeling for them it meant that when people come to the site They were coming because they say I have a problem with my printer I'm pretty sure someone has called into the show with a similar problem So I'll come here and look through the list of questions that are tagged with printer and I can find them now They're able to organize it in a much more Nuanced way they're able to remix those things so they can say oh well We could actually throw up a special custom page on our site for Questions related to Wi-Fi routers and that was completely out of the realm of possibility before with their blobby Content model the possibility of them rolling out an actual mobile app that pulls down all of the information from their site Is now within reach you know when we will when we when we rebuilt the site That wasn't part of the scope of what they wanted to do But it was on the horizon and they knew they wanted to be able to do that and building a model like this was a Step towards that even if they weren't rolling out the 95 million different possible edge Scenarios that they wanted to deploy to they knew that they wanted to start thinking about What our stuff really is and what's valuable about it? And how do we model it so that we can remix it in ways that people care about I like to think of it as Is anybody ever played with 10 gram puzzles? Okay, there's like you know six nerds in the back. Thank you Basically a 10 gram puzzle is like a geometric puzzle It's made out of a bunch of little squares and triangles and you can rearrange it into lots of shapes I like to compare that to sort of the blob version Just a picture puzzle a lot of our content types are built like a picture puzzle We've got them chunked up into different pieces and we've got a different fields and stuff like that But really they only make sense if you assemble them in the just-so way that the original design mocks Intended you can't really reshuffle your picture puzzle to be something else because that's not what the that's not what it was really You know, that's not what it was made for but a 10 gram puzzle. You can make a kitty I always need to sneak a cat picture in even if it's just that But you can also turn the same thing into a rabbit or a house or all kinds of stuff That's really the heart of the structured content Concept the idea that you break it up into these meaningful little chunks And even though each one isn't some sort of gem into its in and of itself You can repurpose and remix all of those individual pieces together in more ways than you could the tightly Design bound kinds of chunks that a lot of us are still used to building so the next step Brushing over all the work that goes into actually doing that. We'll just you know We'll treat that as an exercise for the listener for now But the next step after the idea of managing just one pool of content Structuring that content so that it can be remixed effectively in different ways The step beyond that is starting to work to decouple that central Pool of content that you have from the ways that it's being presented on the edge Now there's a lot of different ways that can play out sometimes that just means you know making sure that you're thinking of things in terms of Content types and views and the pages that display them in Drupal other times It can go really really far down the rabbit hole like NPR their cope architecture their end point their Delivery point for all of this content that they've modeled and structured is an API if you go to api.npr.org You can just submit random queries ask for stories by ID filtered by topic say what format you wanted in I wanted in Jason I wanted an XML. I wanted in NPR's custom and XML variant that they designed I wanted in just straight up HTML because I'm just gonna blast it right into my sidebar without even running it through jQuery You can just do this point it at the API and what you get back is Structured data with all of that same stuff that we were looking at in all of those screenshots of the cool different edge You know edge end points that they've built that's what those end points are pulling from the NPR Yeah, that's the Android version. You got to look carefully sometimes The Android version is just pulling from the same underlying data source as the iPhone version and that allows them to do a lot of interesting things So I promise that the whole idea was to be able to build these sites without with a little less Pain a little less suffering maybe a little less going bankrupt trying to do it all And in the case of NPR and the reason I like using them as an example is they've been at this for a long enough time That they've been able to see the fruits of this kind of approach It's pretty impressive in their case. They've got a small team and They've said that it's really allowed them to be way way more efficient They build the presentation they build the new endpoint the new app or the new Micro site or whatever that they need to and the content is already there It's already modeled with an eye towards remixing it for different audiences in different purposes and in 12 months last year I think it was last year might have been the year before that anyways They were able to double their audience through a bunch of promotional work They were able to launch 11 different products like different apps or different Micro sites or new channels that they were spinning off for their content to go out And they were able to roll out a whole site redesign with a very small team It's grown since the days when it was just four of them, you know in a small room trying to pound out this API But I think if I remember correctly, they're still in like the you know between 15 to 25 people range And when you think about all that they were able to accomplish, that's really really amazing So how do we actually do this? Does anybody sort of feeling like this at this point? It's like yay That's fantastic for them starting 10 years ago. I hope 2023 is gonna be awesome for me, too The good news is is we don't necessarily have to take 10 years. We can learn a lot of really good lessons from them But I want to take a quick look at how we can really start to tackle these things specifically inside of Drupal How we can leverage these lessons One of the really really important things is something I hinted at earlier this idea of modeling the stuff you've got not How you want to display it? The difference between what you have and how it's presented is really really significant A couple of rules of thumb that we tended to try to use when we're working with clients or we're working on sites is one when breaking out content types or fields or whatever Really try to avoid Driving that from the design to saying oh, well, okay. I've got a mock-up and that looks like it's bold That looks like it's italics. We don't want people have to use tags. So that's that's two fields We'll break that into two fields. Cool. We've got a content model That's not so good think about what the meaning of those different individual discrete elements are We know what does related stuff mean? Is that a sufficiently descriptive and meaningful field? Or do you want citations or do you want? Recommended reading, you know storing individual links versus having a big field to dump Stuff in can make a big difference capturing the meaning and the essence of the thing you're trying to build and then using the display the Formatting the templates and stuff like that that we build on top of it to sort of present that in a way that's appropriate is a big shift Anybody who's ever had an argument with a database administrator on what the database structure should yeah I see someone going oh god. Yes. I was trapped in that elevator Yeah, oh, okay. Oh, I'm so sorry the gentleman in the audience is in fact that database administrator you know We deal at a level that's a little abstracted from just pure database tables and columns in Drupal But the principles that database administrators have been arguing about for decades are really important They think about this kind of stuff and they've got a lot of really good thinking on it HTML markup purists are also good people to sort of you know buy a beer and ask them So why shouldn't I have the sidebar class on my div and they'll explain all kinds of fascinating stuff to you one thing we tend to see a lot is like Try to kill those dreaded like iPhone fields whenever possible It's very easy for like a content model built in Drupal to sort of slowly accumulate Cruft where well the site wasn't working very well on this particular output device So we just added four extra fields where the special mobile phone version of that field can just be pasted in That's not what we're talking about if the real problem is that people are entering in titles that are way too long to display on small devices Well, what you need is a short title and a long title not a title and a mobile phone title Because that short title is going to be just as useful when somebody decides they want to look at your news on like a pebble Watch or something crazy like that think of it in terms of what the differences between them are not how you're going to be outputting them Another one is to think when you're doing content modeling and you're doing your content type breakdown This model that I'm making how can I remix this? Can I look at these different fields and these relationships? And can I combine them in different interesting ways have I built something that has lots of fields? But it's still functionally so rigid that I can only really use it in one way Those are important questions to ask yourself. There's no real, you know Magic bullet for that, but I could probably fill another 60 minutes Just ranting with my friends about how to tackle this stuff But these are really important principles that we've seen a lot another one is Protecting your assets. Hmm. I feel like I'm giving like financial advice. That's not where I was going with it But that's also good What I mean when I say that is that all of the content on your website is not necessarily created equal Especially in Drupal where we have a lot of really rich Presentational stuff going on on a lot of sites. There's a difference between the core assets the content that you know Five years from now. We still need this it may look different It may be presented in a different form But we're gonna need this because this is the stuff that people actually come to us to get from our website That's an asset That's where a lot of the energy in you know the blood and the sweat and the tears of the content modeling stuff needs to focus on those chunks because they're what you're Gonna be stuck with for a long time and you don't want to have to rework them every time something new comes out structural content Sometimes this doesn't take the form of nodes. It takes the form of taxonomy vocabularies and stuff like that But in the case of that tech guy lab site an episode is something we would have called a Structural content type because it's used to organize things and help people find stuff and group them effectively Even if it's even if people say yeah, I want to come to see what the date on episode 542 was that's my purpose for visiting the site It's not really the primary thing they want to get at but it's very important for organization And the final category that we tend to you know, we run into a lot is pure Presentational content. It's like the stuff in the rotator in the header of the front page You got to manage that as content. You have to acknowledge that it's really content people write it They upload images to it. Sometimes they schedule it, you know, there's real Content he needs around that so it's not purely design But at the same time it tends to be ephemeral and it tends to be driven entirely by the visual design Needs or the promotional needs of a particular kind of channel you're working with the Presentational stuff for your app might be different than your desktop Site and that's okay because those things tend to come and go quickly and they're very tailored to different needs but Protecting those underlying assets and making sure that you treat your structure as an important tool for building out Navigation and structure those are really important things treating those things differently and Recognizing that you don't necessarily have to sweat bullets about making sure no one ever uses like a tag that you don't like in this stuff It's different than ensuring that that stuff is always safe The next step and this is sort of a transition to the kinds of NPR-ish world that you know that we were talking about a little bit earlier is Even before you go whole hog and build some sort of like you know Ajax powered angular JS node on the front end and you know acronyms on the back end kind of system You can still in Drupal start exposing and using Content feeds based on those kinds of structured content elements that you've built out and those don't have to be super crazy You know it can be as simple as RSS with extra You know media RSS fields rolled in so that you've got geo information and you know Authorship and you know biographical information tagged onto the RSS feed and media attachments You can expose JSON feeds with tools like views and views data sources There's web services tools like the services module and content API They allow really really really short time to implement You know it's short Implementation time solutions to rolling out a simple web service that lets External services whether it's yours or your partners get access to these assets and they're like pure Remixable form and you can also consume these different data feeds that you're producing if you need like a highly Responsive up to the second sidebar ticker of news happening on the website We get requests for this sometimes and it's really kind of baffling because it's like how often do you really post news articles? Maybe once every five minutes every ten minutes Why do you need an up-to-the-second news ticker in your sidebar people still ask for it? You could make that say a little chunk of JavaScript that pulls from your news feed instead of a Refresh on the page that constantly forces things to be rebuilt these are techniques that you can start rolling out Incrementally rather than trying to just rebuild everything whole hog and that incremental approach is actually why NPR refers to having taken ten years For this kind of transformation it's because they did it bite by bite by bite Rather than trying to launch some sort of moonshot project that did it all at once and Drupal 8 Which you may have heard a little bit about here so far today And you may be hearing a little bit about over the course of the week Drupal 8 has a lot of things that relate to this to the web services initiative and there's even work on twig It's the templating engine one of the interesting things I like about twig is that it's possible using JavaScript to render twig templates in the browser In addition to the server so in theory instead of coming up with all kinds of crazy ways to Prebake all of these assets into HTML before passing them to the client side You could theoretically have a website that just requests the underlying object for a given node and renders it into your themes templates on The client side because those templates can be rendered in either place. It's cool stuff So those core ideas, you know model the meaning and not the appearance Protect those core assets and invest your time in good solid structure for the reusable assets that you know are gonna stick with you Exposing and using content feeds so that you have those data sources. You can continue to experiment and iterate with the fourth one, it's really important is Start tailoring the editorial Experience that's something we hear a lot of it Drupal because it's a buzzword making Drupal easier and stuff like that But it's not just about making things more visually appealing or in some generic way simpler The real issue is that when editor when editorial people and content teams have to actually work on structured content sites It's very different than being tossed in front of a body field and told hey put your story online And yes, this is this is my pre-scheduled anti-wizzy-wig rant Yeah Team chunk down with blobs. No, okay. I'll stop The problems with wizzy-wig aren't just developer snobbery of around. Oh people just ought to use HTML Don't they know how tags work? It's not that it's not just elitism and the idea that oh other people should Just learn the stuff that I use for my job to do their job It's because a it privileges the device of whoever is currently editing the idea of what you see Is what you get depends on what you see being what everybody else sees And if we're dealing with a multi-device world if we're dealing with a multi-channel world that breaks down really quickly So it's very easy for the website even if it's structured nicely to start drifting back into the world where it's Really kind of built for the device that the editors use and that's a problem and dream weaver fields the giant bins Into which heavily formatted stuff get pasted those kill reuse because unless the people who are pasting in word documents and saying hooray It's still got the tables are conscious of all of the issues of structured data and How your designers are deciding to do deal with CSS related stuff and how what kind of media queries They're using unless all of your content editors are up on that stuff too That random markup they're pasting into that big old body field Isn't going to be on the same page with your clean and nice templates, and well, that's gonna break things Visual layout editors like spark and stuff like that are really cool Panelizer is also really cool But again as Larry Garfield talked about in the session You know there was a little bit earlier as Drupal a CMS the danger that they run is that they privilege that Immediate visual editing experience and if what if people understand I am changing the desktop websites layout That's not a problem, but if that's so come you know closely tied to the editing experience It's very easy to muddle the difference between the content assets. We're making and What the site happens to look like today? I tend to recommend all of us tend to recommend actually that if you have whizzy Editors you strip down the allowed tags that people are allowed to use keep it tight Keep it simple rely on the structured content in your templates to do a lot of the heavy lifting of the design and formatting and watch for Abuse like watch for the person who keeps insisting on figuring ways to get pink text into the site and you know Nipped it in the bud I won't spend too much time talking about this because we're almost out of time But you know those editors those content editors who are actually doing the heavy lifting every day are really some of the most Important people who will ever use the site because they can make or break all of the stuff that's going on their blood sweat and tears of building the content and Working with the CMS and dealing with that horrible crappy weird administrative view that somebody threw together in 13 minutes because it was Friday, but somebody needed to bulk delete comments Their work of dealing with that stuff is where the real action of content heavy sites happens They're like the people producing the stuff that people come because they want it. They're important building tools that Serve the the actual tasks and workflows that those editorial users, you know do on a day-to-day basis is important Don't force them to be visual designers by throwing visual design tools in front of them and saying you've got control now Congratulations remember to match the style guide Giving them control over things like priority and emphasis instead of just throwing them at a visual layout editor and saying You know just lay things out can do can go a long way and also planning for the long-term maintenance needs If you're thinking about content that you're going to be holding on to for five years, maybe ten years We've got clients who have content on their website That's 20 years old and it's important to them and they still need it if you have stuff like that If it's important enough to model and structure Well, you need to think about what kind of tools and what kind of governance processes you need to keep that stuff Good for the next five years. It could be deciding that's out of date Let's toss it, but there's going to need to be tools to support that to the editors So yeah, building for the post-mobile world the key issue that we want to get at here is Reusing and remixing your content instead of forking it off in a million different tailored and customized versions that you have to maintain Is an absolute must you can do that by putting structure and meaning in your content first Rather than immediately starting with the visual presentation and trying to extrapolate structure out of that You can separate those Reusable content assets from the more ephemeral presentation oriented stuff like the rotators and the little promo block That's only going to be up for a week. Don't worry as much about those Make sure you're caring for those assets and protect them from the random crazy stuff that's going on in all the support stuff and then expose data feeds to drive new channels so that you can experiment with With less expense so that you don't have to rip out the foundation of your site when you want to experiment on something new That you think might be useful reducing the cost of Deploying your content in new ways is one of the real benefits If you're interested in more There's a couple of books that are great reads content strategy for mobile by Karen McGrane Content everywhere by Sarah W. Who's name? I can't pronounce and I'm not ashamed to see Haha, I have the feeling the next presentation will also recommend these books But also API is a strategy guide is by Daniel Jacobson one of the initial architects of the NPR cope architecture He now works at Netflix as their director of I think API engineering It's good stuff And there's also a bunch of links. I'm not going to read these off to you But the slides are going to be going up pretty shortly and you'll be able to check these out. Anyways, good luck I wish you the best and go team chunk