 Hi Technically we're 15 seconds early, but I think we're probably safe kicking off now Welcome to building for a post-mobile world. It's not as quite as apocalyptic as it sounds from the title But a lot of this session is about the concept that the transition to mobile is no longer some sort of future event that we are thinking about or some sort of you know Wacky world that gets written about in wired magazine or something like that. It's here And if we are building a mobile site today We by the time it launches we're gonna be facing new sets of problems that are emerging on the horizon already So thinking about what the world looks like after mobile is no longer some crazy shiny new thing But just multi-device usage is just a reality is what this is all about So I'll do a quick introduction before we before I kick things off. I'm eaten On Twitter and Drupal org and all sorts of places. I'm with a company called lullabot I've been with them for about seven years doing Drupal stuff pretty heavily and We're a company that does like strategy and planning work design work Full Drupal site build outs and we also do teaching and training stuff both for You know large clients and for you know individuals and groups and stuff like that We've been again doing it for quite a while It's we start measuring things not in years, but in what Drupal versions we were using when we started So Drupal 4.5 represent anybody Anybody for yes Now we've got images. What else do we need? but Yeah, we work with a fairly large number of different clients ranging from tiny ones to To big ones media publishing education, you know small startups And well, this is sort of the the braggy big wall of logos But the the idea behind it is that in the work that we're doing with them We end up seeing a lot of these same patterns in terms of the problems They're experiencing with content, especially as they have to deal with The proliferation of devices the transition to mobile It's not so much that mobile phones are changing everything It's that they break all of our existing sites and it terrifies us all I'm going to attempt to ratchet up that terrified sensation for a little bit and what I like to call the shock and awe portion of the presentation You might want to leave now If you are just building sort of web app like functionality stuff It's not particularly content focused, but maybe using Drupal behind the scenes or whatever That's awesome, but there probably will not be a whole lot interesting to you here This is primarily about sites that are heavily content oriented and need to Maintain and keep their content updated and are trying to deal with mobile and a multi-device world If you are Karen McGrane or someone who basically goes around Talking about structured content and content reuse 24-7 you will probably also not find anything new in here But you're you know feel free to stick around and heckle And if you terrify easily it might be best just to step out of the room for like maybe the first third and have a friend Give you spoilers because there will be terrifying statistics Otherwise stick around and if you want to heckle me feel free to tweet with the hashtag post mobile That's it So Change how many people here have been hearing about the fact that mobile is important for a while Okay, cool That's good though. That's those are good things How many people here are working for organizations that haven't in fact? Built a mobile site despite talk about mobile being important. Okay, so there's a few hands, but you know that's good It feels like one of the common myths still floating around is that mobile is some sort of thing that will be happening off in the future Still like you know, oh, it's like taxes, you know, I'll eventually have to take care of that but for now It's not a problem. It's terrible financial advice The the idea that a shift to mobile is something that lies off in the future rather than right now is Just flat out untrue. It's a myth and it's dangerous if we Hold that. Oh, there's there's already someone heckling 45% mobile users someone in the back of the room just this is the opposite of heckling This is giving even better statistics than the one I have 45% of the traffic to one of the attendees sites Come from mobile users according to their Google analytics stuff. That's Fantastic And you may be saying oh well, but not my site, you know, and not most people site. That's exceptional Just as a little bit of background 88% of people globally have a mobile device Well, no wait, I'm sorry in the US and it mostly averages out to the to the first world in in Australia There are roughly 1.3 mobile devices for every person I was impressed when I looked that up that I kudos to all of you You're really just just well mobile 45% of those people use their mobile device to access the web That's a ridiculously high number when you consider the fact that only a few years ago The idea of a mobile phone that could actually look at websites without exploding in flames was a new and radical idea So that uptake is really really coming on fast even more interesting 17% of those people are mobile only users Literally the primary device they use to look at the web websites government service websites Everything is their mobile device and that also spikes when you look at specific demographics like you know anybody under 20 A lot of minority groups inside of the US I'm not sure I was trying to dig up some details here in Australia, but I couldn't find any more detailed breakdowns But there's a lot of interesting stuff about specific countries You know demographics and age groups that are even higher of using only mobile devices to to see the web I Don't know how to put it any clearer those numbers are going up not down and Especially for government agencies educational institutions Anyone who cares about the fact that someone could actually be locked out of the content They're publishing the fact that that rising number of people use mobile primarily means that you can't simply assume That it's some sort of convenience or some sort of adjunct you know that it's something that you have to account for and have to consider and also interesting is the fact that 90% of those people who use the mobile web Split their tasks and split their usage over multiple devices Now that goes a little at odds with the mobile only use but the idea is that even people who are using multi to multiple devices are using many of them together and That kicks the kicks the still ladder props It destroys one of the other common myths that there are somehow Special tasks that people do when they're Mobiling or that no mobile phones. Well, that's what people use when they're running through the airport You know when they really want to read something they use their computer. Oh, they want to do real work. Oh, that's you know They use other things mobile phones are what they use in Some sort of magical mobile context that will you know just push off And this is the kind of thinking that leads a lot to having a mobile site It is like the 10% of the most popular pages on our website We'll just trim those down and format them for mobile and stick them there. Well, that doesn't really bear out Google actually did some really interesting research last year a study with about 1500 participants, which is a pretty solid sample group of the people who use mobile devices 90% used multiple devices to accomplish a given task 77% of people watch TV while using a mobile device Which means that they weren't in fact running through an airport They were sitting on their couch or perhaps in the living room doing something and also Doing something at the same time on their mobile device They could have been looking up information about the show they were watching being distracted whatever But it was a multi-device usage pattern and there's even more interesting stuff 60% of those people started shopping on their phone. They looked something up They found a product and then they continued the same task by going to their PC and Purchasing that product that they found 25% of people searched for something on their P on their desktop PC and Followed up later by going and reading the same article when they had five minutes and they were just wandering around 15% of people Planned trips on a tablet and you know flipping through looking at pictures You know trying to find flights and then later booked on a PC You know, there's a long long article that Research paper that Google put out about all of this data But the long and short of it is there aren't any kind of Special tasks that people do on mobile There's just tasks that people happen to be doing on mobile because that's the device they have And then when you count for tablets that even muddies the water even more You know is a tablet a mobile device or is it a like a living room device? Who knows we'll call it mobile now because it's just easier, but that's another question. We'll talk about later Another issue that It's really Troubling I'll say is the fact that with the proliferation of devices Responsive design is getting overtaxed How many people here have been hearing a lot about responsive design, okay? I want to go on record and say it's good. Do not misunderstand what I'm about to say I'm not knocking responsive design The problem is is if we assume that Simply putting like a responsive theme on a Drupal website or doing a responsive visual design is going to solve all of our Content problems. We're putting way too much weight on what amounts to a set of useful CSS techniques This is Luke W. He's a Consultant and designer and he does a lot of blogging on mobile issues You know a couple of other friends got together and they pooled all of their devices and stacked them in a giant horrifying Display of just how many screen sizes are out in the wild right now It's funny and it's like oh they're geeks, but think about just how many Different screen sizes are represented in that one photograph of what happened when a dozen nerds emptied their pockets and their laptop bags That's an example of what responsive web design is being asked to deal with at this point It's a very very useful tool for ensuring that your site doesn't just Explode in flames when somebody is using a larger or a smaller device But the proliferation of viewports and devices is Really really a big challenge and we can't simply assume that responsive techniques and media queries are going to be able to Continually scale to handle all of those things for us. So that's another one to talk back Who here has worked with someone who said oh, no, no, no, no, we've got a mobile strategy. We're gonna make some apps Okay. Yeah, and you know and again, I don't want to knock apps. I have roughly 895 of them installed on my phone. I use them a lot. They're great The problem is when we start to think you know same as with the responsive design issue that it is some sort of like Magic sauce that we can just spread on our website and on our content and that will bam solve mobile problems An interesting thing is there's a lot of statistics coming out about how much time people spend in apps But it turns out about 75 or 70 percent of the time people spend in apps is either playing games Or using an existing social networking site Which means there isn't just some sort of like motherload promised land of like user Attention sitting out there that if you make an app bam, you're you know There it's it's gold rush time. You will be able to get it get people's attention and they'll use it There are 400,000 apps in the Apple in the iTunes app store with zero downloads just you know Yeah, this is this isn't the fun part the the happy part is coming later, I promise And to go along with that the average development cost for a feature-rich app Like you know magazines or you know an organization trying to publish their content in you know a reusable way Runs from about thirty thousand to one hundred and fifty thousand dollars the development costs and maintenance costs for the app itself and That means that if someone is thinking that just putting out an app is just going to solve a bunch of problems by virtue of now We have an app There's real costs associated with that and not just up front one of the biggest challenges is that apps require Content to unless you're just making like angry birds or something like that You're going to need to maintain the content that will be displayed in that app and unless you're planning up front It's very easy to get into a situation where you've now developed two forked versions of your content One that you're publishing on the website and one that you're publishing for your app now You know, we're mostly Drupal people in this room. I'm guessing and you say no no no no Never never never do that. No, we can just put nodes into things. Yeah, that's not a problem, but I I've also seen a lot of sites that have different pools of content on the site one intended for mobile one intended for the website and Editors have to maintain both of those in parallel. That's content forking You now have two separate independent pools of content often with duplicates that you need to keep track of and maintain and The time investment for the actual content editors to do that is it free either. That's an ongoing cost So that's definitely an important consideration and that applies to making a dedicated mobile website You know the we'll just take the 10% of the really important pages and make a website out of it, too Anytime you're make you're carving off some sort of special thing just for mobile You have to acknowledge that that's at the very least likely if you don't plan to prevent it it will happen just via inertia and The one that The one that's really sobering is that these new publishing channels new places where our content shows up or new places where people want to go and get the content that we're working with as Individuals in his organizations those just keep coming and people just keep coming up with crazy weird ways of Tying into content that's out there. This is I am not kidding This is the BMW iDrive. I believe it is a car with Twitter and Facebook You're all thinking someone's gonna die. This is just this is a terrible idea and I would agree but Lo and behold it's out there and they've been working on tools that allow you to put rich content into an automobile This is the refrigerator that I believe Samsung introduces every year the internet refrigerator It's great idea, you know, okay I can put recipes on there, but it's also just got a web browser and social media and recipe reviews If you're doing any of those kinds of things with you know with content Well, here's a channel where people may actually expect to be able to look at that stuff This is Drupal.org on my Xbox in my living room if you thought If you thought transitioning your design to be touch-friendly was a pain Friendly with dual analog stick controllers is even more annoying for rollover menus and You know the okay So Microsoft rolled out internet Explorer to everybody who owns an Xbox. That's fantastic, but Why do I care, you know, what what are the odds of that actually being used? 40 million people Have paid subscriptions to Xbox live globally right now in the US. We've got a bunch of different cable providers for cable television Xbox live has twice as many as one of the largest cable providers in the country and the PlayStation Network has twice as many as Xbox live those are people with web browsers who have those things in their living rooms and some of them are actually starting to use them to surf the web Like it or not This is out there and all of these different channels are Only coming faster and faster people are finding newer and crazier things to jam web browsers into people are coming up with new Devices little weird glowing blobs that sit on a nightstand and can receive pings from Twitter and like start blinking You know No, seriously. I think Someone was showing me that my boss Jeff Robbins at Lullabot. He loves keeping track of those things He has several little weird glowing blobs that can receive pings from Twitter Loves that stuff and they are part of the ecosystem that we have out there now Yes press releases are not likely to show up on the glowing blob on the nightstand But at some point almost all of the content that we have if someone actually cares about it Which hopefully we're making content that people care about They're going to want access to it on another device Karen McGrane in a recent article on a list of part. I think put it really well She said that people don't want Different content or less content or content that's been tailored for the device that you're on They want the same stuff presented in a way that they can find it and navigate it with the device that they're using but They imagine it as a window onto a thing that they want access to not a separate little Container full of its own content. You know if you have If you've got two separate websites one that's for mobile with a little pool of content over here and one that's on desktop The minute somebody decides oh well I want to go and read that article over. Oh well the URLs are different or oh this one all the URLs start with M. So I'll go to my desktop machine. I've got this nice little pillar of content Striped down the middle of the screen. Nobody likes that For better or worse The content that you create the content that you build and publish has to be able to adapt to these changing and emerging channels That was the shock and awe portion. This was the the bitter pill if you've been if you've just been thinking Okay, we finally got the site to look okay on an iPhone Yeah, there's There is a lot coming The good news the fantastic news is that there are actually solutions to this problem This is not just you know, this is not about Congratulations our new product can reformat your website for mobile or something like that The White House in the US Dries actually mentioned a couple of a couple of initiatives that the White House has been doing In in actually making have pretty heavy use of Drupal One of the interesting things that they've done is put a really heavy emphasis over the last several years on making sure that Government data is accessible and and open to people who want access to it Rather than focusing on trying to throw up a new website that presents a particular Chunk of information in a form that's going to get stale after two years Just figure out how to make the act make information open and accessible first and then figure out how to present it after that hurdle Has been crossed They actually released a digital government blueprint late last year and they said that rather than thinking primarily about final Presentation they want to emphasize an information-centric approach that just you know focus on getting the content right Make it available and deal with the rest as an adjunct to that and that's a really important Philosophical shift for those of us who came from like Publishing or a marketing background I did my time in the marketing minds before I started working you know in in technology and You know that was all about you made static files. You made brochures You made these things there were artifacts of a bunch of decisions and you know written You know written pieces and it stayed where it was and that's that's not the way things are working anymore So the question is is how do we actually do that? What are the actual concrete steps that organizations are taking to try to? Achieve that end of making their stuff available and then dealing with presentation later the first and biggest challenge the thing that has to be a baseline priority is Prioritizing the idea of cross-channel reuse and what that means is when we look at all of the different Places where our content may need to appear in whatever form We need to make sure that we're trying to reuse the same underlying piece of content on all of those channels Rather than creating a different one for each one of those channels So I have a fun little icon-based illustration of this. This is a vault. It contains all of your awesome ideas Those are all of the places where you want it to go or at least three representative ones print mobile desktop stuff like that a lot of organizations Very quickly get into this situation They've got their ideas and they've got people working on writing different chunks of content for each one of those different channels It gets turned into concrete documents Maybe if you've been in publishing you probably have watched the scenario where there's a print CMS for the magazine And there's a digital CMS for the website And then there's some sort of horrible monstrosity that someone hand-coded over a long weekend to drive the mobile website But all of those are just separate things that people have to put content into they may be reusing content But they're copying and pasting from one to another Essentially creating parallel documents that have to be maintained independently Now some organizations try to solve this by saying excellent. We will just tell one person they have to do all of it We will just add new steps to their workflow for each channel. We want to publish, too For some values of works that works But the problem is is you're basically trading how much gets done for how many channels it gets done on You know a person who's being told to do all of that stuff They're not going to be doing as much the throughput of all of your content and your publishing and the work that you can do drops Dramatically as editors have to deal with that and every new crazy thing that gets hot and everyone says Oh, well, we've got to have a social strategy or we've got to have a what's it strategy or whatever That becomes another one of those channels that those overworked writers and publishers and editors have to deal with and that's not cool This is what we want to get to a workflow where every one of those channels that we're publishing to is a different permutation of that underlying piece of content now This is probably not really radical if you're used to working with Drupal the concept of nodes And you know, you know, we even have things like you know build modes for nodes where you can say, oh, I've got the teaser I've got the primary view of the content and stuff like that We're already doing a lot of those things But it's still important that we remember the high-level issue here is we need to prioritize that principle of We're using the same underlying piece of content across all of our channels as much as possible Because that's the only way to deal with this multi-device proliferation A really cool example of an organization that's doing this in the US is NPR national public radio So anybody heard of cope there? Okay. Yeah a couple of hands going up It's like the the granddaddy of all structured content case studies it stands for create once publish everywhere and It's sort of the internal system that they've built to accomplish those reuse goals This is an example of an NPR story on their desktop website It's about some teenagers who figured out how to like do printable solar panels using like maker tools awesome This is the mobile version. It's a responsive site. So, you know, you pull it on a mobile browser. It's cool It just adjusts the layout appropriately. That's their actual iPhone app the same story in their iPhone app You can see at the bottom. They've actually got actually got playback controls because this is an interview so you can play back the audio And they're using all the native Happy features that they can but it's the same article This is the Android app same thing You can see that there's some different design decisions that have happened there They're using the native Android like navigation buttons instead of the iPhone standard You know row of various clickable bits at the bottom But same content Here is a partner website Minnesota public radio It's sort of a sister station to the NPR website, but they pick up and syndicate stories from NPR Here's the same story being displayed on their website This is a microsite They have for the particular show on NPR that carry that article low and behold Same thing being used on that website. This is their YouTube channel They push the video of it to YouTube and have the same basic description This is what happens when I paste a link to it into a Facebook post It automatically pulls in a preview image a short tailored chunk of text that describes the article in the number of characters that Facebook says They have to use to describe that all of these things are just different views on the same Underlying chunk of content that NPR maintains and publishes internally. It's a single Resource in their CMS. They're not using Drupal. It's all homegrown, but the principle is one that we can still leverage ourselves But how do they do that? That sounds tricky The way they accomplish it is actual meaningful structure in how they've modeled their content And this is where I sort of you know mentioned the idea of things like build modes and content types and you know Fields we're used to describing a lot of our website content in those terms but there's an important distinction in Using those things simply to model a particular design that we were handed or we came up with and Using those tools in Drupal to model the underlying meaning of a piece of content in a way that we know is going to be used to Remix and reshuffle individual elements to come up with a particular appropriate way of presenting it Rather than okay scrap it and let's rebuild that for a new design I think I like to think of it as sort of the difference between a jigsaw puzzle and 10 gram puzzles. Has anybody ever played around with 10 gram puzzles? It's basically just like little triangles and squares The whole idea is that you can technically make anything out of it whereas a jigsaw puzzle Well, it's a particular picture and it's broken up into little pieces But if you try to assemble anything other than that picture you're sort of out of luck Example would be a kitty cat We're internet people so we got to have a cat in the presentation somehow But you can also turn it into a rabbit if you want to and there's all kinds of examples of people doing tan Grim art I like to think of it as a useful analogy for how structured content can be used if we break things down into pieces That we know are going to be used to in in various kinds of remixes of our content We think about it differently than just stuff that needs to go over here in this design or things We will need in a call-out block if we're thinking about them as structural elements rather than Presentational elements we get that remixing capability This is a little nerdy But this is the actual underlying structure of what NPR stores in one of their cope articles They've got the high-level structure for what things that they care about what things their system models the story Like a given article or story is for them the single most important piece of content They have they also model something called a program Which is like a show that they're running that may have lots of different stories associated with it or a Series if they're doing a bunch of different stories that sort of build on each other and they also have blogs But those are just things that they use to group stories That's really their key asset and they have a bunch of different fields that they've modeled on that and I won't drill Into all of the details, but some interesting examples are Subtitle title and short title. They've got three different kinds of title broken out not because one is displayed on Mobile we had one client who actually had title iPhone title web title and RSS title broken out in their content But the problem is is well what happens when you add yet one more channel? Are you gonna add another title and PR has Tackled this by saying we want a title a subtitle in a short title We're gonna write one for devices that have a very very tight constraint on how much they can display and we may Want to use it there, but we're not going to talk about which device or what presentation style We're gonna talk about what we're putting in it and what it means and how it relates to this to this particular story They've got teasers mini teasers the Facebook preview text that you saw when I pasted that in there That was the mini teaser. That's what they expose via Facebook's open graph tags They show the full teaser when you look at you know An article in a listing on their web page So if you look through there's a whole bunch of stuff in here thumbnail publish date stuff like that They also have more complex elements like audio that can contain a number Showing how many seconds long the audio is a link to the mp3 a description of the audio file itself They've got images. They've got pull quotes the pull quote can contain attribution for who said it stuff like that But these aren't I mean this isn't some sort of magic template for what you should go and model on your site But they're an example of how a particular Organization looked at one of the key content types they built and said what's really in this What's the stuff in this chunk of content that matters? And how can we start carving out little meaningful bits of it in a way that will allow us to effectively? remix a given story For different purposes We'll just see So you've got structured content you've got all of these different ways of displaying stuff that you can at least theoretically accomplish But the additional challenge is okay. Well, we've got a CMS that can store all these things We've you know gone into a back room argued for two weeks. We've got structured content now And we want to reuse everything But how do we actually get it to all of those different things in a way that doesn't end up? Cloning and forking all of our content anyways And that's where the concept of decoupled delivery comes in this this idea Goes by a lot of different names. Some people call it web services. Some people call it API's some people call it feed You know we want to give feeds to our partners or whatever But the whole idea is that the management and the creation and the organization of your content shouldn't be inherently tied To how you're presenting it now we use Drupal which is about as coupled as it gets in terms of managing the content and displaying the content but still well a little later We'll talk about some of the ways that we can still leverage this effectively But the idea of decoupling our delivery from our management means that when we start building things on the edges Like a new app that displays our content or whatever We're not retooling the underlying foundation of our site Building something cool on the edge that can consume that content and NPR, you know still rolling with this example All of that structured content that they've got is exposed at API dot NPR dot org If you go to that site you can create an account you can get yourself an API key for free just like you know Being a Twitter developer or something like that and then you can just go to API dot NPR dot org and start writing queries Against all of NPR's content. You can say I would like field I would like the title and teaser fields in NRML format which is just a particular XML format they use sometimes you can also say I wanted in Jason Or I wanted an atom or I wanted in just flat HT I wanted in pre-formatted HTML. You can ask for it in a bunch of different ways and I want article ID Whatever that's actually a real article and what you get back is Structured HTML that particular query is this is actually the result that you get back from NP from NPR's API And you can see it's a lot of the same stuff that we were talking about It's got you know different links the the full link of the native story on NPR's website If someone just wanted to click and go to it the API link if you just want to say Oh, well, what's the link that I could then check to get all of the data associated with this you can do a bunch of stuff It's got the title the long teaser the mini teaser because that's what we asked for you could ask for all of the fields You could ask for articles between one date and another date instead of requesting one by ID number The whole idea is that they've untethered Having content from displaying content by putting this API as a middle layer and all of these different examples Are pulling from that same API. They're just writing queries. Sometimes they're caching the results They may save them locally on the iPhone app so that you can actually read them after you you know when you're offline or something but that concept of using those that API as their gateway between Stuff we need to you know stuff. We're experimenting with you know the iPhone app the new website that we just launched And their core content is a really huge thing for them So what's the payoff, you know, they invested a lot of time and energy in building this system They you know, they've clearly put a lot of person hours into building and maintaining it And for them it really has paid off. Well They recently did an interview with I think it was Mashable where they were talking about some of the end results and for them in in like one year following rolling out the API They were able to double their audience Because it gave them the flexibility to work with advertisers and other traffic, you know traffic generating partners in much more flexible ways They were able to launch 11 new products that used NPR content like you know apps and you know widgets for other people's websites and stuff like that and they did a full site redesign in 12 months with a very small constrained dev team and Having that API was the only thing that allowed them to do that it allowed them to build on top of a known System for pulling what they wanted and what they cared about Remixing it as needed in a design that they could come up with without having to worry about Re-architecting all of the underpinnings of it every time they had a new endpoint they needed to work with so the takeaway is a structured content be Reusing that structured those structured content assets and see exposing them in some way so that Another tool out there can consume that content and utilize it without you having to rebuild your course System those three principles together are really really key to dealing with this whole like multi-device explosion thing So it's it's a it's an icon of a happy bouncing baby. He's going to explain how we're going to do this with Drupal so Some of you may be excited Others may be thinking this sounds like a Monstrous amount of work and this sounds like I'm going to have to write views handler plug-ins and learn how to do things with XML and Jason Maybe I'll have to learn how to configure rules module. Who knows The good news is actually that Drupal is pretty well positioned to do a lot of this stuff You know, I mentioned earlier that our community is actually pretty used to dealing with things like structured content And is familiar with the concept of a core thing being displayed in lots of different ways in different contexts and a lot of the tools that we've accumulated over the years are Actually really well suited to this approach We're just not all used to using them in that particular way And that's the shift that we need to start getting used to if we want to leverage this stuff so The first really important principle for doing this in Drupal is when we're modeling things like Content types fields relationships between content types We need to make sure that as much as humanly possible. We're modeling the meaning of the content What's in it and what it's used for and why it's important to the organization? Not just the appearance that we're envisioning in the design that we're currently implementing, you know Photoshop-driven content modeling tends to go off the rails pretty quickly when you get a different photoshop file six months later Anybody who's done like database modeling or was involved in like the semantic markup wars Or has been cornered in a bar by Morton at any point is probably familiar familiar with some of these basic concepts of like Modeling semantic structure in HTML rather than modeling the appearance and using CSS to style it database administrators talk about you know How do you model core business objects and you know? Treat the data model rather than just fire hosing stuff into a giant table These are all concepts that you know different disciplines have used And I think we can start leveraging a lot of that of a lot of that learning when we talk about working with our content types another useful tool is thinking through how a Design or how a plan for a website is going to be filtering sorting Searching through how do we envision a user going through the website and Locating the stuff that they care about if there's a web if there's a page that we say oh well This page will contain all of the news articles by a given user's friends That are in you know involving subjects that they care about Okay, well, that's you know, I think there's probably four people in the room going oh no no that's gonna be three weeks But From a content modeling perspective, we can immediately learn things that we're going to need in our content model We're gonna need authorship because things by a person's friend implies that there's an author We get that for free in Drupal, but that's something that you know is being modeled We're gonna need things like what topics do does someone care about well That means we need to attach topics to a given piece of content, you know Those are things that we can start extrapolating From the views that we have and the listings that we have and how we envision people getting at stuff Use those things to discover what the content model needs to bring to the table Before we even talk about you know how we're going to skin it Build modes again are a useful starting point when we're thinking about different ways something could be presented If we look at a content model that we've got you know the fields and the structure of a content type and we think Huh how many interesting and useful build modes could I make out of this in Drupal to present this content in a good Nice way it's still very HTML centric because it's you know We're spitting out web pages, but those build modes can be really really useful And we also use them for things like the search indexes and the RSS feeds and stuff like that Another one is if you see recurring markup all over the place in body fields like here's the giant Chunk of stuff we always paste in when we need to do a poke quote or when we need to put the photo in a given article Those are often Indicators that there is something structural that we're always doing with a given type of content that it might make sense to Split out into a given field because there's recurring meaning there that if the design changes Well, God help you because now you've got 8,000 articles that all have heavily design-oriented markups splatted into a body field And it's a lot easier to redo the template for a field than it is to go through and search and replace Handmarked up HTML inside of a body field. That's I Don't think that should be news to anybody who's been working with Drupal, but you know It's it's an important thing to keep to keep an eye open for and yes This is also where the pre scheduled tickets sold an advanced rant about whizzy wig editors comes in One of the biggest problems is that whizzy wig editors now Not all whizzy wig editors not all whizzy wig editing, but at least most use of a whizzy wig editor When it's not carefully controlled Leads to design being jammed into a chunk of content body content And that's bad because with any kind of multi-channel publishing the what you see part Is not going to be consistent and reliable from one device to another The what you see is going to be radically different on a tiny screen or a black and white Kindle or Any one of any what number of the different channels that we can push stuff out to so if you put a Giant table in the middle of a node body using a whizzy wig editor Well, that's problematic because that table is not going to look good on anything other Than a machine with a monitor at least this wide and you know Sometimes that's unescapable, but the advantage of whizzy wig editors The what you see is what you get breaks down when you're going to be pushing out to a bunch of channels and that's Problematic I like to call it the the problem of dream weaver fields Basically the you know, this is the body field and we've enabled every possible button on the whizzy wig editor Because someone just said I need to do this crazy thing and paste my Microsoft Word document in there Just let me okay Great. This is the dream weaver field. You can go use it problem is is that kills reuse content built in that way is fundamentally un Remixable you can't leverage it in the ways that we've been talking about sometimes. It's absolutely necessary But if it is Understand and acknowledge that those chunks aren't going to be something that you can really effectively leverage using any of these approaches my My usual preference is like to if someone needs whizzy wig editing and wants it make sure that there's that it's stripped down and only Allows really basic HTML formatting, you know, let them do headings basic styling Emphasis strong or bold tags links things like that, you know stuff It's basic and structural But make sure you haven't left like you know table editing and the ability to paste random CSS and things like that in You know that that kills any kind of remixing ability because you end up drifting towards Structure being jammed in as design oriented HTML We've also found it really useful a lot of the whizzy wig editors that are out there allow you to build custom plug-ins You know, you can add your own little button to that whizzy wig editor with some code It lets you insert canned markup if you want to you still need people to be able to insert stuff using a whizzy Wig editor wrap it in a plug-in for tiny mce or CK editor that lets people click I want the calculator widget there if you need that instead of just copying pasting a giant slab of HTML So in addition, and this is something that you're probably going to be hearing a lot of during the content authoring track I sort of buried the lead here, but Support content editors not just emotionally, but also with tools I Like to say that they're the most important users of any website that's content oriented even more so than any individual visitor Because if content editors stop working with content and publishing it and updating it and maintaining it the reason the visitors come starts rotting that content is no longer being updated no longer being published and You're out cold Anything that supports the work that they do and smooths the work that they do and ensure is that they can focus on doing what they need to be doing not necessarily Say trying to do design and layout in a whizzy wig editor is useful One thing that we found useful is trying to make sure that we identify tasks for the content editors Things that they do on a recurring basis not just Individual forms that as developers were used to you know Customizing and building the node form is definitely right for Tweaking and smoothing and improving and a lot of work has gone into that in Drupal 8 But it's also important to keep in mind in a large website That's been heavily customized and has all kinds of crazy stuff going on Creating a node is rarely a standalone operation often. They have to connect it to other things schedule stuff You know work with somebody else to make sure it goes into the right places on the site understanding that that is a comprehensive task and a workflow for them not just a Form that lets them insert things into the database is really important and figuring out ways to simplify things like managing Relationships between nodes and editing metadata can also really help there's modules out there They can do things like pre-populating keywords automatically on nodes by you know scanning the content and stuff like that Those are really helpful sometimes Accounting for things like you know multi-step processes that editors have to go through Though those are traditionally painful things. We've had huge wins just by having quick dashboards that we threw together with views for Editors that just said what content have you edited in the past month that is not yet published just show that in a view in the administrative section and They were overjoyed because that's a that's part of a workflow and out of the box Drupal doesn't do that I'm not saying we should can we should have that page in Drupal But look for those kinds of opportunities because often from a dev perspective It's easy to whip that up, but it's hard to do work without it there for an editor and also Tailoring and refining these kinds of things iteratively if you're someone who actually works in an organization Over the long haul not just doing like you know consulting or site builds you have a lot of opportunities for evolving and Iterating these tools that the editors have to use on an ongoing basis There's a lot of value for that You don't have to somehow come up with the magic awesome El Grande editorial workflow tool of doom and just you know throw it over the wall and say hurrah You can do you know get small wins it works. It makes sense The third principle is exposing and using data feeds apis Don't have to be super wacky and crazy and complicated If you have public information or public articles or stories that you want to publish and make available for reuse You don't have to bend over backwards and do lots of crazy stuff It can be as simple as using a tool like the views RSS module to customize Exactly what fields show up in the RSS feed and add additional things like media RSS feeds or geo tagged stuff to your RSS That's going out that can be reused and remixed in useful ways There's also a great module called views data source that lets you expose XML or Jason or Adam feeds But you can customize every little chunk of data that goes out in that view feed just like it You know just like NPR has done Well, perhaps not just like that There might be a little bit of custom code to do that level of stuff But still you can get a lot of stuff in in place just by throwing together useful views And if you've ever built a view with exposed filters where you can have filters and sorts and stuff like that that come in in the URL You've got something very close to the kind of API endpoint that NPR exposes their content with you can use views Views to build simple content API's and if you want to go further There's tools like the services module and the content API module that was built on top of services They're great examples you can even publish content to your website with those tools So you could have an iPhone app that lets you post and manage articles using something like the services module more complex to set up But there's already underlying tools to help support that you can also consume that data Not only on crazy iPhone apps and stuff like that, but in your own website You can use the feeds module to pull in those data feeds if you've got several sites that need to share content Set up a feed on one of them imported into the others and now you have a content API may not be as fancy as NPR's But you know you can get the job done and also you can simplify certain scaling and performance issues by exposing Cacheable content feeds and using client-side script to consume data from them and expose things like widgets of content of widgets of new stories and stuff like that in JavaScript on the on the client side of your own Drupal site you can consume that site's feeds if you want to go Super crazy lots of possibilities. The idea is expose lightweight feeds That doesn't have to be a huge engineering task You can just do it with views and then start utilizing them get used to that idea and you are Would probably say like, you know, let's say 75% of the way to having a useful multi-platform content reuse strategy That's something to put on the year-end report Drupal 8 also has a lot of really cool stuff coming down the pipe What the web services initiative the ability to expose JSON feeds You won't even need to have extra modules other than core to do that kind of stuff in Drupal 8 There's a lot of potential for it A lot of people are going to be talking about that this week, you know here at Drupal con 2 so pay attention to them but All of those things, you know, if you want to start do dealing with these ideas in Drupal the principles to remember that design neutral content models, you know you building content types that don't Assume that a particular visual design is the only thing they're going to be used for is a critical first part Exposing structured data feeds so you can reuse that structured content in cool ways when you want to and then building good editorial Tools to support the people who will actually be creating and managing that content because structured content also implies lots of fields Sometimes and figuring out how to smooth out the experience of you know editing and maintaining and working with that content is important So Building for a post-mobile world. What's the what's the high-level stuff one? Re-use your content The same piece of content rather than little forked off clones of it going in different directions That will dramatically simplify the management and maintenance work That is where a lot of real long tail costs for maintaining content comes from Put the purpose and structure of your content before the visual appearance when you're thinking about how to model it with content types and fields Tailor your editing workflow wherever possible the Drupal node form is you know, it's not a scary monster, but it's generic It's not in any way informed by the nature of the work that people working on your website need to do And there's great tools to build custom workflows around that take advantage of them and then expose feeds with that structured data to simplify Experimentation reduce the cost of coming up with a crazy Experiment for Android and stuff like that I think one of the interesting examples NPR mentioned was they now have a WordPress plug-in that uses the NPR API To auto publish stories from particular shows on any WordPress sites for NPR affiliates There is also an NPR Drupal module that does the same thing if you're setting up a website and you want to syndicate content You can pull in all of those discrete fields as a Drupal content type Display them however you want because that NPR API can be tied into all kinds of things They didn't have to rebuild all of their infrastructure in order to build that little experimental thing on the edge and reducing the cost of those Experiments means that you have a lot more slack when dealing with new and crazy stuff that emerges in the world of mobile or you know I don't know eyeball implanted browsing technology Whatever people come up with if you can experiment on the edges while your underlying structure stays consistent and reusable You've made a huge win. It's really really good to I don't know. I'm just repeating myself Good stuff If you're looking for some additional reading, there's three really great books I can highly recommend content strategy for mobile by Karen grain It's sort of a it's a great book to hand to like, you know, your your VP if they're trying to say I don't know why we need this. We've got a mobile site Yeah, I feel like I should like be wearing a Newsy cap or something when I use that voice But it's a really good high-level overview about the whys of some of the structured content stuff that we've been talking about The book content everywhere by Sarah Wow, I'm gonna mispronounce her name her name is Sarah and it's an awesome book I've pronounced it correctly on the podcast and that was the last time I think but it's it Drills a little deeper into some case studies and some good examples of how different businesses have tried to break down their content That way. There's also API as a strategy guide It's an O'Reilly book about some of the challenges and issues to deal with when exposing content API's for services and Any kind of API? It's you know by a couple of people who've actually done that on a lot of large organizations It's great stuff. There's also a bunch of links I'm not gonna bother reading through the links but if you want to copy of these slides go to lb.cm slash post mobile or Go to the Drupal con website and I believe these slides should be uploaded now. I believe we've got four minutes Maybe four and a half. We'll see if there's any questions Go for it. Yes That's a great question. It's because Drupal is so coupled and has HTML publishing baked in It's you know what it does out of the box. Do people get misled about what the nature of Drupal system is I think I don't think they're misled so much because for a long time Drupal has been a web Publishing CMS and there's a lot of other tools out there like that I think it's almost by by happy accident that we're so well positioned for the structured content shift You know if you go back to like tools like flexi node and how heck the node system itself, you know The Drupal community has been thinking about content in a lot of these ways And we're now starting to mature into a place where we can actually leverage that effectively It still takes work because you can easily build a highly coupled Non-reusable Drupal site if you know you aren't thinking about what you're doing But I do think that that's not something that's obvious to people who haven't been neck deep in structured content for a while Any other questions? Yes Yes The question was do we have any success stories for how Drupal has served as the back-end CMS while other systems serve as the front-end In that sort of decoupled approach I know this sounds like a cop-out, but The one most recent success story I can think of is totally NDA'd at the moment and I can't actually say what it was But I will say it was a very large a very large Sports thing that needed to deliver lots of content to lots of devices And they wanted to do this you know this sort of like multi-channel approach and Drupal is being used on the back end for all The content management stuff. They're using another provider to do video streaming But Drupal is the hub that organizes everything, but even the desktop and mobile websites Are it being generated by Drupal their? HTML JS they're basically a lightweight web app using you know basic, you know You know CSS and HTML 5 and JavaScript frameworks, but it pulls from Drupal So it's an example of that. Yeah, I gotta figure out when we can talk about that, but it's it's cool. Yes That's yes, the Yes, that's an excellent point. There is another project. We worked on the Martha Stewart living website Which is ginormous and extremely pastel colored and it basically they have two sites All their user-generated content commenting rating stuff, you know Building your own recipe book stuff like that and their primary editorial content server and They weave those things together When they actually put out their website all of the user-generated content is a Drupal site But a different Drupal site is pulling it in via content feeds to actually display for them It's a safety and security issue They never have to worry about users ever touching their editorial server, but they're using it basically like build your own Discuss commenting server in Drupal, you know, and I think that's that's you know one example There's a lot of different ways to slice and dice it, but you know once you've made that shift to Putting your content out there in a number of reusable forms you have a lot of opportunities to experiment with those kinds of things that It's startling you start seeing it everywhere. It's like, you know, you now have a shiny new hammer, and there are so many nails I think we're flat out of time So I think we got to close this up But I'm gonna be wandering around and and anybody wants to ask or chat or talk about, you know Cool cool examples of these kinds of techniques that'd be great and feel free to take a pony from the back table. You earned it