 And without further ado, I'd like to introduce James, who's starting off the Lighting Talks, if you come to the stage James. Hi everybody. My name's James. I run a small wordpress business called Llaziwmpress and today I'd like to talk to you about automating your business. So what this means are various different techniques that you can use to implement this yourself. So what is business automation? Well, it kind of is what it sounds like. It refers to the strategy of automating various processes within your business and this is done to save costs and by that I mean reduce the amount of time that you have to spend on said process. This is usually done using APIs so we can connect to applications together and one of the applications responds to the action of another application. With good business automation you can reduce the amount of tedious admin work you have to do as well as being more productive. So, do you need to know how to code in order to set up these API integrations? Well, no you don't. You used to but now various services exist that are designed to provide an interface to the user for setting up these API integrations and this takes away the need for any technical coding. So, one of these services is if this then that. This is an API integration service. This is more geared up for automating various aspects of your personal life rather than your business. There's also Zapier or Zapier, I'm not too sure how that's pronounced. This is more of a business automation service similar to if this then that but more geared up towards automating your business. Elastic.io and It Does It are very similar services to Zapier. There's also CloudHQ which is a little bit different. This is designed to sync various folders across applications. So, an example of that could be you might want to sync a specific folder in your Google Drive with a specific folder in your Dropbox folder. You'd be able to do that with CloudHQ. So, I'm going to show you how easy it is to make a Zap and a Zap is an API integration from Zapier. That's what they call API integrations. For this particular example, I'm going to set up a Zap that adds any new Twitter follower that I get to my CRM. That way, I can start to leverage any social media following that I get. The first thing that I'd need to do is select the trigger app. In this case, it's Twitter. I need to select the actual trigger and in this case, it's going to be a new follower. We also need to specify what Twitter account that this app is associated with as well as the username. They're my credentials. We also need to test that this connection works. As we can see here, it's worked. We then need to select the action app. I use an application called Nimble. It's a social CRM. It's pretty good. I've selected Nimble there. We need to select the actual action. I want to create a new contact for the new Twitter follower that I get. Again, we need to select what account that this is associated with, so I've selected my Nimble account. You also need to map out the fields. Zapier does take care of a lot of this, but you need to make sure that there's nothing missing and all the information is correct. By mapping out the fields, you need to make sure that the fields match up. For an example, you need to make sure that the name field from Twitter matches the name field in Nimble. You need to make sure that the description field in Twitter is being used for the description field in Nimble and so on. Then you need to test that the Zap works, and in this case it does. That's it. Once that's set up, every time I get a new Twitter follower, they're going to be added to my CRM. This means I can start to do something with my social media follower. What else can you do to automate your business? What other processes? What other things can you set up in order to automate these processes? You could tweet new blog posts, so you could create a Zap so that every time you publish a new blog post, and I think a lot of people probably blog, that can automatically get posted to Twitter or Facebook or LinkedIn or any other social media that you want. You can store Twitter mentions from a specific location in a Google Sheet. Now this might be a really good marketing activity. If you're trying to target a specific location with your services or your products, if you can store or start to build up a Google Sheet of contacts of people that have mentioned you on Twitter from this particular location, they might be people that you could consider contacting. You can store recurring invoices, invoice expenses in an Evernote notebook. So if you have recurring invoices for a particular service or product that you use, you would want to keep a record of all them, you can create a Zap to automatically send any invoice that you get to your email address to Evernote. You can create toggle projects from new Trello boards, so if you use toggle to track your time, but you use Trello to organise your projects and your workload, you can set up a Zap that will automatically create a new toggle project ready for you to add time to whenever you create a new Trello board. You can also create Google Calendar events from Evernote Reminders, so if you use Google Calendar as your main calendar and you don't really use Evernote Reminders, you can make sure that you don't miss any because they'll be automatically added to your Google Calendar. So just to recap, business automation saves time and therefore money. There's no coding required and there's lots of possible ways to automate your business. There's literally thousands of possible API integrations. It's just a case of using your imagination a little bit and finding out what works best for you. And I'm going to take any questions after everybody's done the talk, so thank you. Thank you very much, James. And next, where are you hiding, Keith? We've got Keith Devon who's going to be talking about responsive images. So thank you, Keith. Hi, everybody. So my name's Keith. I'm going to be talking to you about high-performance images in WordPress. Where'd the WordPress effect go? It's been cough. It's in WordPress. What happened there, Diane? So my name's Keith. As I said, that's a bit about me, but we really don't have time for that because I've only got 10 minutes. So the problem with images, what are the problems that we're currently facing with images today? First up, we're using too many of them. Secondly, the images that we're using are too big. And a more recent issue that we're having is device pixel ratios, so things like retina screens and how we handle that. So this gives you a quick example of the average web page content weight distribution. And as you can see on the average web page, 64% of the page weight is images. So there's a problem there and a big, big opportunity for optimization. So how can we fix it? Well, there's some techniques that we've been using already and there's some newer techniques coming along. Some of these are being phased out, things like image sprites, a technique that we use to save on HTTP requests, kind of being phased out replaced by things like icon fonts. There's choosing the right format for the image, so whether you're using a GIF for paying SVG or whatever. Then there's image optimization, which is to do with the size, the physical size and the compression of an image. Lazy loading and responsive images, and it's those latter three that I'm going to be talking to you about today. So first up, image optimization. What is it? It's a technique to reduce the file size of an image. There's kind of two main types of compression that you can use. There's lossy compression, which eliminates some pixel data, so this will actually change or degrade the quality of the image slightly. There's lossless compression, which actually just compresses the pixel data, so the image retains its quality and it can also lose some metadata that you don't necessarily need. There's no single best configuration when it comes to image optimization. It's all about the image that you're using and there's different ways that you can do that. And luckily there are some online tools available. So I want to give you a quick example. This is going to be a bit small for you to see probably. This is a picture of some potatoes that I took on my iPhone. The image is 4,000 by 3,000 pixels. It's 2.1 megabytes. So the first thing I did, I ran it through a lossless compressor, so like I say, that's just compressing pixel data, not losing any image quality at all. And you can see the iPhone actually does a pretty good job already because the lossless compressor only saves me 6% of the image size. Next I ran the same image through a lossy compressor, so the quality is slightly less, but you can see there's a bigger saving on the image size, so I've saved 15% in this case. My final example, I ran it through a lossy compressor, but also reduced the actual physical size, so in this particular website I've decided I don't need a 4,000 by 3,000 pixel image. I'm cutting it right down to 1,200 by 900, and I've got a 90% saving on that image, which is absolutely huge. So like I said, there are some online tools available that you can use to help you with this. A personal favourite of mine is called Kraken, so it's at kraken.io. There's free and paid versions, there's actually like a web interface that you can use, or there's an API that you can use. It has lossy and lossless options, and there is a WordPress plugin available called Kraken Image Optimizer. Now the WordPress plugin does require a paid plan, I think they give you like 5 megabytes for free, which obviously isn't much, so you'll need to be on a paid plan for that. So that's image optimisation. Next up, lazy loading, so what is it? It's a technique that loads images as they come into view. It saves on initial page weight and HTTP requests. It does rely on JavaScript, there are lots of JavaScript libraries out there to help you already, and there are also some WordPress plugins available. So this is an example of lazy loading in action, hopefully this is going to work, and the quality is not great. It's the BBC News website. When you first load the page, it loads approximately 50 images, and as you scroll down the page, you'll see that new images get loaded into view, and by the bottom of the page, it's loaded about 105 images, so it saves the initial page load of saved 50 images, so that's obviously a huge performance win for the BBC guys. Next up, responsive images. For me, this is where it gets really exciting, and I wish I had a lot, lot longer to talk to you about this. Started off with the responsive images community group. It's a group of developers who came up with this specification that actually got included into the HTML spec. It kind of comes in two flavours at the minute. One is the picture element, and the other is the source set and sizes attributes, which you add to the image tags. The source set and sizes that we're going to talk about today, mainly because there's more use cases for that. So, what are they? Well, they're used to save bandwidth by loading the appropriate image depending on the context, and by context essentially mean the viewport width or the width that the image will be loaded. In this case, it's kind of important to note that although we're giving a browser a hint as to which image to load, we're not actually making that final decision. That decision is up to the browser in the end. So, here's an example. I've got a fairly standard looking image tag there. I've got the source. I've got an alt attribute, but I've also got this source attribute in the middle. And as you can see, I've listed three image sizes of the same image, and beside each of the file names, there's the image width is also specified. So, an example one, say I have a smartphone. It's 320 CSS pixels in width. It's a slightly older phone, so it's got a pixel density of one. So, in this case, the browser is going to say I've got 320 pixels, and pixel density of one, 320 times one is 320. So, it's going to go and look for the image that is closest to 320 pixels in width, and in this case there's one sitting right there, and it's going to go and choose small.jpg. Hopefully. An example two, I've got the same size of phone, but this is a newer version, so say it's a retina display. It's got a pixel density of two. The browser is going to multiply 320 by two, come up with 640, and hopefully choose medium.jpg. But that all assumes that the images are going to be shown full width in the browser or in the viewport, which obviously isn't the case in real life. We often use layouts like this, where we want images to be displayed, say in a three column grid. In this case, we need to use a sizes attribute. And here I've just specified sizes equals 33.3 VW, VW standing for viewport width. So, you're telling the browser that when this image is displayed, it's going to be a third of the viewport width. That's easy. But then we've got another kind of real life scenario where often on mobiles we want a single column stacked view. So, how do we do that? That's kind of easy too actually. We use something that looks very much like CSS media queries. And in this case, we're saying anything with a viewport that's over 640 pixels, it's going to be in three columns. Anything under that, it's going to be in one column, so the 100% of the viewport width. So, can we use this stuff today? We can. IE is obviously doing its usual thing. But the rest of the browsers are pretty good. Opera Mini is a bit of a concern. I don't know what support is going to be like for that in the future. So, how does this apply to using responsive images in WordPress? Well, it actually started off with a plug-in from those guys that created the specifications of the responsive images community group, created a WordPress plug-in. And that actually got added to the WordPress core in WordPress 4.4. What does that do? It adds source set and sizes support to content images, so images that are added in the edit page or edit post screens whenever you click add media. Gives us a bunch of new functions to work with and a new default image size called medium-large. But there is no picture support currently because it's kind of a lesser use case and a little bit more complicated. This next slide looks like it's going to be really ugly. I thought we were 16 by 9, dear, dear. Okay, so if you can read the code, on the top line I'm getting an image from something like an advanced custom field. I'm getting the image ID, I'm getting the image source and the image meta. Sticking that all in a string which I'm calling image HTML and then I'm running that through a function called WP image add source set and sizes, which does exactly what it says on the tin and gives you something looking like this. So as you can see, the source is at the top, the source set is listing all the image sizes in WordPress and it even comes up with a sizes attribute for you. But that sizes attribute is actually a best guess and whenever you're building this into your themes you're probably going to want a little bit more control over the sizes attribute in which case you can use the WP Calculate Image Sizes filter. But even if you don't use that filter, just the default functionality is much better than nothing. So last thing, as I was doing my research for this talk, I found a plugin called WP Lazy Sizes. The data of image plugins as far as I'm concerned, in the short time I've been looking at it, handles lazy loading and responsive images, works out sizes attributes for you. It's not on the official repo but it's at that link which I will tweet out after this talk. I haven't quite used it in production yet. So download it yourselves, test it. I'd love to hear how you get on with it. So what do we learn? We have an image problem. We've got the tools to solve it. Optimise your images, lazy load your images, use responsive images. Thank you very much. Nice one. Next we have Christof taking on the unenviable task of comparing WordPress with Drupal. Hi. So he already spoiled my first line. So I'm a Drupal guy. And I do things like this. That's Marvin, the paranoid android who's also depressed, not because he's using Drupal. So I don't know all that much about WordPress but I've been looking a lot and thinking a lot about what are the main differences between our two systems. Not so much from a feature perspective because we can go on for ages about that, but from a core strategic and underlying architecture perspective and community perspective. First I want to start off with the architectural differences because I believe that Drupal is like Lego and WordPress is like the iOS with the app store. What I mean with that is that Drupal is this graphical interface for a bunch of APIs. That's a complicated concept. What I mean is that Drupal as a developer, when you're building a website, you can, without writing code, do a lot of really crazy things and build your own stuff exactly the way you want it to be. Exactly is a lot, but much more closer to what you want it to be like. And in WordPress, the way that I see it, it's more like these vertically really well integrated plugins that are written for a very specific use case. So it's kind of like APIs versus apps. And I think that's a really important difference between the two systems. Another thing is, and that's a really big one, WordPress is backwards compatible. Drupal is not. For some cases that might be really, really cool to be backwards compatible, because it saves you a lot of trouble when you have to upgrade. In some cases, it can be not all that nice when you have to write a plugin and you have to deal with lots of different systems. And Drupal, if you have the budget to rebuild your sites every four or five years, probably Drupal is going to be more interesting because you have a cleaner slate to work from. And developers like that about Drupal a lot, you know, the underlying thing is cleaner. But both have their pros and cons. And there's also really big differences between the two ecosystems, because this is the really big one, right? According to buildwit.com, WordPress worldwide of all the sites that run a CMS has more than 50% of the sites, which is insane, right? Often, I'll go and look at that graph and get depressed. But because Drupal has like 2%, which is tiny, but if you look at the top 100,000 or top 10,000 websites, well, WordPress still dominates, but the gap is a lot smaller and it's very interesting because Drupal has like 8%, if you look at the top tier of the websites. And that has a few implications because, first of all, I think here we have a very interesting dynamic, again using iOS and the iPhone as an example. I think here Drupal is more like the iPhone and WordPress more like Android, where WordPress has a much, much bigger market share in terms of installs and a number of sites. But in terms of the budgets and the amount of money that's being invested in those sites, I think Drupal, I don't have any data to support it, but I think Drupal has the upper hand. I think that Drupal might actually have a larger overall economy than the WordPress economy. I might be wrong, this might be flipping, we might be just head-to-head, but it's very interesting to see that. And one supporting thing that I found for that is that I think WordPress has a lot more freelancers. Raise your hand if you're a freelancer. Okay, raise your hand if you're working in a consultancy with multiple people. Okay, it's neck to neck. I know that this is changing now and I know that there's more people working for agencies now. But I think that this is a fairly new evolve like evolution. I think that in a recent past, most people just worked on their own and were building sites. And the budgets for websites were much smaller. I know that it's changing now and I've seen some stuff with some of the really large deployments. But in Drupal, we've gone that curve a little bit earlier. Now, I started to start kind of like us versus you and Drupal versus WordPress. But I don't think that we're really competing, at least not yet. I think that we are very different and I hope that I've shown you that in these slides and that there's very different cases to use either WordPress or Drupal depending on the project that you're running. And I think that we've done a really good job to fight against our real competitors and I think our real competitors are the proprietary CMSs. And basically what both of us have been doing is doing the Japanese Gambits. It's a strategy thing that Boston Consulting came up with. It refers to when Japanese car manufacturers entered into the American market and they started with these really cheap, crappy cars that then got better and better and better until they completely flooded the really expensive cars out of the market. And you can see what it has done to Detroit even today. So I think that what we've been really successful at doing both WordPress and Drupal is kind of like raising the tides and first the smaller proprietary CMSs got flushed and now the large ones are being flushed. And it's a very interesting dynamic. And key to this, and this is, I don't know if, well, I'm kind of a big advocate for this. Key to this has been our ability to mobilize the clickers. And what I mean with clickers are, you know, the people that they need to do something complicated, they need to build a system, but they are not necessarily developers. They are able to do stuff in the UI, they are able to do really complicated things and figure it out, make content architecture, all of those important concepts they understand, but they are not writing code. And to kind of mobilize them, get them into the system and then maybe in time turn them into themeers and people that make custom templates, people that make custom codes and their own plugins. And I think that's really important again because that's constituency, they need our help because the web is changing again, it's changing massively, like nothing we've ever seen before. APIs are coming, well, they're already here, but they're coming in a really, really big way. And specialized artificial intelligence and a bunch of other things that you can do once you start amassing data and start, like really leveraging the abilities of concentration of very specialized computing is really going to change the way we do business and in a lot of different places. And these people, like right now, this is available to developers. If you can write code, you can use APIs. If you can't write code, yeah, it's not that nice, it's a lot harder. And I think what we need to do is to help those people so that we can provide them with the plugins or the modules so that they can also take advantage of this new wave of computing that's coming. And I hope that I was able to convince you that there's a case for both our systems. And I would like you to think as kind of like a final take away that, like, how can we go from this Earth versus you, this zero sum game to a win-win game? Like, how could we work better together so that we can go to the markets and help a lot more people still and like give the power of CMS to all the people. Not just the developers. Thank you. Can I ask Keith and James to join us on the stage? And we'll take some questions now from out there. Has anyone got any questions? Hold on, we just need to get the microphones sorted here. Is yours working, Theo? I'll press the thing at the bottom, I hope that didn't... Yeah, I think you need to do that. Okay. A little flick. That's one. Yeah, there's a second button. That one. Okay, so I'm seeing some hands. We'll just go for the closest one, actually. We've got one just here. Just for the moment. Hi, thanks for the speakers. When I see these speakers, it's a bit of a gamble. You don't know what's going to come in, so it's great to learn new things. I have a lot of questions. I have a lot of questions for three of them, so I might ask all of them and let the mics go around. Just on the Drupal versus WordPress and the moving forward. I really like your talk. I tried to start using Drupal, but it just got a bit frustrated and lost. The project I was trying to set up with it was just slowing down, so I just said, okay, I can set this up in WordPress in a day. I wish I did have more patience to sit down with it. But just as it's moving forward, and I think it's a great argument, do you think the way Drupal and WordPress are moving towards using REST APIs that we can start to favour each other in some way in that way are? Do you have any comments on that? It's a very interesting question. Well, the move towards REST APIs, well, I think it's a big opportunity, but it also scares me a bit. Because I care, I'm a clicker. I never became a developer, and I got people that do development now in my company, but I think that we should never forget about our roots and make sure that we keep catering also to those people that cannot develop their own team and implement a front-end that's using those functions. But probably there's possibilities to leverage each other. I think that the specialisation, I think that for me at least, WordPress is kind of the mass market thing where you get an easy way to get a lot of people to use standardised plugins that are vertical silos. And Drupal is this more legal thing. I hope that answers your question. Yeah, it was just a serious question. Okey-dokey, hands up. We've got one hand at the back there. It's another question for Christophe. So, as you know, I work with Drupal as well as WordPress. What I'd be interested to find out, building on the question of the APIs, one of the really powerful things like you said about Drupal is the fact that it is a system of APIs, effectively you've got the field API, you've got all the other APIs. Now, with eight coming out, and it completely changing the way that things are done, and it moving towards symphony when a lot of PHP developers are moving more towards Laravel, do you think there's a risk with the rest API and the increasing number of endpoints that WordPress has that we might see a migration of developers from Drupal in two directions, one going in Laravel, one going towards WordPress because of the APIs? I think what I've seen, what I've heard in the market is that actually the other way is happening, that symphony developers are starting to use Drupal because, hey, it's also symphony. So, I don't see that happening necessarily right now. There's some fatigue with doing stuff in a GUI and the hardcore developers, they rather be writing code. That's always the case. But, no, I don't see it that way. I think it's more, I think it's a different place that the changes are happening. There's a lot of change and it's sometimes a bit scary. But overall, I feel pretty good about Drupal now. Drupal 8.1.1 is awesome. Any more questions? Any hands? Wave at me if I can't see you. Yes. Hi, it's a question for Keith. Can you get responsive background images? Yes, you can. That was one way that people started using responsive style images before certain sizes came along. The main issue with that is semantics because in your HTML, you've got a div with a background image rather than an image tag. So, from an accessibility point of view, it's not brilliant. From an SEO point of view, it's not brilliant. So, yes, it can be done, but basically you don't need to do that anymore. If it's genuinely a background image and not a content image, then by all means, do that. If it's a pattern background of some kind, then yes, do that using media queries in your CSS, but otherwise I would avoid that and use the new specification. I'm not seeing any more hands. We've got one here. We've got two hands here. We've got one just here. Just on the image, thanks again for your talk because I just ran into that problem last week where we had switched the domain to HTTPS and it wasn't loading the image. When I looked into it, I saw this source set which I've never seen before and it was referencing the HTTP. Do you know why that is? It was referring to the old... No. I haven't looked into it. I just somehow turned it off. Was that images that were being loaded and using ad media in the content editor? Yeah. I'm guessing it's probably a setting in your WordPress site so it's still referencing HTTP. It could have been when the media was added. Yeah, but no. It was good to know where this whole thing was coming from but I didn't really know why they'd started using image source. The other thing which I don't know if you mentioned was CDNs. Do you have any comments on CDNs which are good? No, I'm a WP Engine customer. I take a checkbox to enable CDN with them so it makes it that easy. I don't have a lot of expertise outside of that. Good. WP Engine, get some swag over here. There's a hand up just over here. Just a quick comment to Keith, hi Keith. I'm not sure if you mentioned an important piece about source set that it's a progressive enhancement so that slide you had with the IE, not supporting it, is not an issue. You can still use it and it'll just be ignored in IE. Yeah, that's a really good point. Thank you. I'd love to give a much longer talk on response images at some point but that was basically saying if you're using source set in sizes it's progressive enhancement so older browsers will still load the original source attribute, the image that's in there so they will still see an image. It just won't necessarily be an optimised one. Thank you. Okay, and final question. Final question just down here. Hi, another question for Keith. Some of my clients are photographers and they're really precious about their images but their sites take ten minutes to load the homepage. So what is like, they want to use higher DPIs and bigger sizes. Do you have any guidance on what I should do with them? Yeah, all of those techniques will help you. The responsive images thing works out the browser will work out the device pixel ratio and load the appropriate image. Yeah, if you're lazy loading, basically if you can use as many of those techniques as possible you'll get big, big wins, especially on mobile. Can I tell them that 300 DPI is the wrong thing to do? No, it's not so much about DPI. It's more the physical pixel size of the image that's being loaded. So if you're using responsive images your browser will work it out and load the appropriate asset if it's done properly. So you should see big performance wins. Fantastic, can I get a round of applause for our trio of lightning talkers? Thank you guys.