 Welcome to Track 2 and Track 4 of today and Track 2 in the afternoon and it's my pleasure to announce Dane Moore is speaking for us today. Dane is a front-end engineer at Tenor. He's been committed and passionate open source follower for over six years now. Completely self-taught from the ground up, Dane has managed to grab the attention of many award-winning agencies and media houses in South Africa, not to mention international brands such as Women's Health, Men's Health and the award-winning author Ken Follett. Here today to talk to you about developing WordPress with limited bandwidth, or full limited bandwidth should I say sorry. Please give it up for Dane Moore. Yeah thanks very much. It's quite an honour to be here. I don't believe any South African has spoken internationally at a word camp in the recent years so I'm very chaffed to be here and obviously to represent TenUp as well. Just so you guys know TenUp recently opened up their European division hit by Mr Gabe Karp, the TenUp team sitting in the middle there, just all the way of your hands. Here we go. So if you're interested in working with us and if you're looking for a new career move definitely come speak to one of us and I'm sure we can talk about it and make it happen. So the talk today is going to be on developing WordPress for limited bandwidth and I've spoken quite a lot of word camps before and I've learned two things. If a word camp is on a Friday and well this last day of the word camp is on a Friday or a Sunday there's no point of going technical because everyone just really doesn't care. So this talk is going to be a little bit more high level. I'm going to go into the business side of things as well as the engineering side of things. It's a lot of principles that we apply to our own projects at TenUp especially from the engineering point of view and it's been quite a privilege coming from South Africa because I my past career experience I've always had to really consider these kind of things when it comes to building websites for clients whose majority usage base is actually living in rural conditions or more poorer areas who don't have iPhone 8s and iPhone 10s and don't have the bandwidth to watch Netflix and run background videos on their sites. So let's get into it. I'm going to skip this part because everyone really knows who I am. So what is our problem here today? As engineers and agencies at Build WordPress we have sites for clients all over the world. How much time and effort do we put into problem solving the vast majority of users worldwide that can actually use our features on a website? It's quite a tricky thing if you think about what we do every single day especially from a front end perspective when we're building features that involve things like Parallax. Parallax is a very, very, very heavily driven feature that we add onto websites expecting everybody to know or if sorry expecting everybody to use it and be able to absorb it. But when it comes to building websites for people that can't access it are we actually thinking about those scenarios? And it's not really a mindset that a lot of developers truly, truly think about. So let's just break it down a little bit more. There's four problems that I've identified that contribute to this massive problem. The first is consideration. When you are dealing with clients who have a user base worth of Google Analytics, for instance, that whose major portion are not actually using the latest technology, the latest browsers, et cetera, how do you start to break down those challenges? And consideration is one of the biggest things that we can actually look at in terms of breaking down with the client themselves as people who know more about web what that actually is. So are we spending enough time with our clients ascertaining how much of their user base is able to use the features that you want to build? And that might not necessarily mean every single feature on your website, but it definitely means being a little bit more selective in terms of what you put into your website, how you build those features, and how much time you spend extrapolating them. Then skills. And this is kind of like really got out of the woodwork for maybe the last five to ten years. A lot of new developers don't have the skills of the past generation. So I'm just out of interest. Who's an engineer, a web developer here? And who runs agencies and businesses? And who, this is going to be a horrible question, who was building websites in the 90s? Oh wow. So you guys will know that building things with tables and using old sets of CSS and HTML and building for a majority of browsers that didn't support things like JavaScript and everything like that. You're probably used to that, right? You're probably already in your workflows. Yeah? Cool. For the most part. This is stuff that's just what the whole talk's about. But for the new kids on the block who are used to writing every single feature on Earth with jQuery or who can easily find a snippet on the internet that they can copy and paste into a file and it can do whatever they want to do. Do they have the skill set? Do they experience progressive enhancement? Have they built features? Have they tested those features? Have they even tested their website without any JavaScript enabled? Generally not. It's not something that clients can really afford to do, considering the amount of time it takes these days in terms of UAT and QA to be able to fix that. So there's a big gap to make up in terms of the new generation of developers that are starting to use new technologies. The third thing is inconsistencies. So when it comes to browser vendors or the engineers here, what can relate to me when it comes to using Chrome and Firefox and Safari, you build a CSS box model in one and it looks different in every single other browser. So I'm going to use tools like browser stack to get around that, but it would really help at the end of the day if all those browsers could get together, all the browser vendors could get together and actually decide on one standard, one web engine, something that would help us to actually smooth out all those inconsistencies. And then the final one is data and infrastructure. In this, I had quite an interesting experience the other day. I went and bought a SIM card in London or somewhere in London. I'm very confused about this place still. And I got five gigs for 20 pounds or 15 pounds or something like that, which has exploded in my mind a little bit because in South Africa five gigs would probably cost me close to like 80, 90 pounds. So in the greatest scope of Africa, it's even worse and I've got some stats to show you on that, but in the more developed world data and infrastructure is much faster, much better and we're not actually used to it when we come from down in the deep south. So let's just take a little bit of time to look at some stats. These are from 2016. They were the latest ones I could find, but currently over three billion people are online. It's not even half of earth, think about it. So I'm not entirely sure where that three billion comes from in terms of how it's split up per country, but I went a little bit further and picked up that 137 million people in the Europe and US have disabilities, so that's, they might be blind or hard of hearing or they can't use a mouse properly. So that's something to consider and you're probably going to be answering yourself the question now while I don't have 137 million people coming to my website and this is a global stat, but there's definitely a portion of people, especially if you work on big scale websites or news websites, that you're probably not even aware of because we can't track who's got a disability when it comes to Google Analytics and all of that. The second one is a bit of a scary one. 68,500 people run JavaScript-disabled web browsers. Now that also in the whole scheme of things, maybe on your website it means one or two people, but on the global scheme that's still a hell of a lot of people that are actually running with no JavaScript and if you consider how much of our web experiences are built using JavaScript even to just improve web accessibility, it's quite a scary figure. The last one is an interesting one. 1.5 billion is the wedding of the population that by 2050 will struggle to access websites and that just simply means that with the growing population all over the world, maybe we're all staring at screens too much, too much Netflix, too much Spotify, is that actually aggravating how we access websites in the future? Is it going to become a bigger problem for our generation or the future generations? So a couple more stats just to drive my point home. 23% of web accessibility-related litigation was won in court since 2000. So in layman's terms whoever took a website to court since 2000 has had a reasonably good chance of winning and there's been a lot of work lately and a lot of stories about potential users coming to websites to get information, not being able to get that information and creating a lawsuit against those companies. It's quite a scary figure. Then 70% of mobile screen usage increased from 2009 to 2014. Also huge. Has anyone actually built a fully functioning website that can actually use a screen reader? Do you want to have you tested it? Did you read out the website? Nice, cool. 54% of adults who have a disability go online. So half the people that may be difficult in hearing or can't see properly are going online to get information. Another really, really scary stat and these stats are so easy to dismiss when we've got tons of features to build and deadlines to meet and code to write and all of that. So it's definitely something to keep in mind. The last two are even more scary. So more hard of hearing users in the United States than the population of Spain. I don't know what it says about the United States. The last one then is there are more users who are blind or low vision than the population of Canada. So these are obviously global websites that I'm throwing at you now. But I don't know how many people live in Canada but that is a hell of a lot of users. It's a hell of a lot of people that is front-end engineers or is web agencies. We're simply ignoring because it's actually easier to build features for people that can already access them and can access them in a full experience. So this talk is getting into more of why we should at least start considering these people even if they might not come to our website in the next month or the next two months. It's definitely something to stop building into our workflows as engineers. So when we come to Africa and you must remember Africa is still a developing country. Many of the countries in Africa, the large populations of people there are impoverished. They live on, I'm sorry, actually this is a bit of an outdated slide, but they say $1.90 a day. It actually works out to 70 pence a day that they live on. So I mean I'd probably go through 70 pence of data in a minute. So their whole lifestyle is based on that 10% of the world in terms of internet usage comes from Africa. There are a hell of a lot of people on that continent. They want information, they're hungry for it and if we're ignoring them and not providing them ample opportunity to get that information then we're doing something wrong. One more, two more scary figures, the last one scares the most out of me. 134% is how much more it's expensive to buy data in Africa compared to Australia and Brazil. 134% is a hell of a lot. So we've got a population that exists there and in many other countries like South America and India where it's more expensive for them to buy data, which means they can consume less and if they're really only living on 70 pence a day it makes the whole mix a hell of a lot more complicated. The last one, which I've put blinders on to myself as well, is if you actually go look at the global stats in Africa, Opera shares 20% of the market after Google Chrome. Who's tested their website on Opera recently? Opera, I totally agree with you. This particular stat was Opera, it wasn't Opera Mini, I wasn't checking mobile stats there but I think the mobile stats for Opera Mini would be even higher in Africa considering the amount of feature phones they use there. So it's not, when you come to building websites for bigger clients, clients in Europe, clients in America, it's not even on their radar, traffic that comes from Opera is minor in the whole scheme of things if you compare it to Safari and Google Chrome and Firefox. So how do we start solving these problems from a business point of view? And I'm going to go through these in detail. So the first thing we need to do is question and question as much as you can. In projects that have discovery phases those should be extended as much as possible to actually get to grips with what the data is telling us. We live in 2018 and every decision we make should be driven by data. If you're making decisions based on assumption, it's not going to help because you're going to miss out a lot of people and if you don't want those stats to increase, then we've got to start questioning more. It also provides a really, really difficult situation for engineering down the line where we haven't been made aware of such development that needs to happen. To make a feature progressively enhanced is, and I'm sure you guys will agree with me, using CSS hovers and CSS focus and all of that in a browser that might not support JavaScript adds a heck of a lot of work, especially when it comes to more complicated features. Like I said before, definitely data first. So if we are not considering the data that our clients have given us, then it becomes really, really difficult to prove to them at the end of the day that they're wrong. Not that you want to be proving clients wrong and telling it to their face, but at least we need the backup there to be able to totally give them complete and utter credibility to allow us to build features how we need them to be built and carry on that way. I mean, third to last is understanding. It's a really big thing for me at least as a front-end engineer is to be able to understand how and where the pitfalls of this kind of development exists. So I can't knowingly as a front-end engineer completely ignore something like UX and completely ignore back-end just because I want my features to work in the latest browsers. It all needs to work as one unanimous system and if we don't manage to get it that way, then it'll eventually just create blockages and more potential hard situations down the line. And then the last one which just leaves off of the next point is collaborating. It's not like compared to development, collaborating with human beings is sometimes a hell of a lot harder than writing good code. So if you've got a multi-talented team with multi-specialisations, you need to be very, very aware and very, very willing to be able to work with people to actually get to the point where you can make pertinent decisions with regards to building features and working with the client and with your engineers to be able to work through the difficult situations of building more complex, more solid features on your website. And then I'll mention parallax videos again. So the build here and I just wanted to elaborate on this a little bit more. A lot of UX gets ignored when it comes to build and it's a bit sad because UX really, really leads the way for engineering most of the time. Spending time on bells and whistles and bells and whistles in this case are overloaded features that hasn't really been thought out properly from a user experience or even a user interaction point. This part here can make building applications for people that can't even use them in the first place, a hell of a lot more difficult. Every single feature that you create needs to be well thought out from the ground up first and will figure out what the rest of the world can use afterwards. So as long as you're making sure that it's accessible and that you have a way of people on a feature phone being able to access and get the information that they want, you're doing your job. If you're building super fancy new features with the latest CSS technologies in HTML5, you're only really pleasing even though it's a large, probably part of your user base, you're pleasing people that probably don't care too much about it anyhow. So it's a very, very, a balance needs to be struck with regards to that. And then engineering, progressive enhancement is a lost art. I'll tell you that much. I recently had the, I'm going to go, a pleasure of actually building and progressively enhance features. And it was, as much as it taught me, it's not something that I've ever had to do before in my career. I've always, there's never either been time in the project or maybe the clients haven't been aware, but the skill, I suppose, the expertise and the experience that it required to actually make sure that those features worked and they were tested took a hell of a lot more time than I definitely originally expected. And it taught me a lot. It actually conjured up this talk because it was something that I'd never, ever, ever, ever considered in my own development workflow. So it's a good learning experience as well. And sadly enough, there doesn't seem to be a hell of a lot of information on the internet with regards to how to build those kind of techniques into your development workflow, what you should be doing, should you be doing progressive enhancement or should you be invoking graceful degradation, there seems to be a little bit unsure in general as a principle. CSS, who uses, does anyone use SAS here in their projects? That's good. Does anyone use a methodology on top of SAS? You want to shout out some methodologies? Atomic. These are really, really, really important in terms of your build phase. So without just writing pure SAS, you can get very, very, very bloated. You end up nesting infinitely and complicating code hell of a lot. If you apply methodology on top of it, like we've done our SCSS, which has worked really well for us, BEM is another one, SMA CSS is also really good. And obviously, if these principles are spawn of atomic design, which is a really, really interesting way of going about things, if you can couple these methodologies with technologies like Webpack and Grunt or Gulp, that's your choice, then you actually end up building more smart, more variant, more dynamic websites with more reusable code. You stay dry at the end of the day. And it's a lot easier for new engineers to be introduced to the project, considering that the code base is clean and easy to understand. And that solves a hell of a lot of problems from an HR point of view as well. The other side of it is also just to go back to basics for a while. There's no need to write over-inflated dense code to get the same effects that simple code we get. It's a programming mentality that definitely spawns from back end. But when it comes to JavaScript and HTML and CSS, if you keep it clean and you keep it simple, then that's ideally what we want, and it's a lot easier to be able to reuse that going down the line. Thirdly, definitely understand your stack. So I was actually having a chat with some hosting guys earlier, and they thought it was quite funny that I was a front-end engineer and had no idea what the whole server might be or what HTTP2 might be, but I do actually know what those technologies are. It's not about me being a front-end engineer, not only writing HTML, CSS, and JavaScript, and it's not about back-end engineers only knowing PHP. Everyone needs to work together and understand the entire stack right from the server to the very last bit of compiled code that gets appended to the DOM when the website page request happens. So if you can work in a unanimous team like that, it makes things a hell of a lot better. You solve problems a hell of a lot easier and a hell of a lot quicker at the end of the day as well. And then lastly, it's just about testing. I've always thought of development, especially when you are working on a component level, sort of like an iceberg. The tip of the iceberg is what it looks like. It looks really, really simple, but when it comes to actually ensuring that that particular component works and you've tested it and cross-browser has happened and maybe you've tested it without any JavaScript enabled in the browser, the amount of time you're spending on those components actually ends up being a hell of a lot more under the surface, ensuring that those components are accessible is another big thing, especially when it comes to feature phones. So definitely from an engineering standpoint, there's a hell of a lot more going on underneath the surface. I don't know how much time I have left. Two minutes. 15, sorry. Thank you. So I'm probably going to end a bit early on that note. If you have any questions, then you can go wild, but I hope that's given you a little bit more insight into how I'm starting to think about my development and engineering from a front-end point of view and also maybe open your eyes a little bit in terms of who you're actually starting to provide these kind of services to. Definitely have the conversation with clients. Definitely check the data and yeah, thanks. Yes, thanks a lot, Dane. Has anybody got any questions at all? Any questions whatsoever? Hang on, there's one down here. It's probably a silly question, but how deep do you go with this in terms of progressive enhancement? Do you strip it all the way back to a text-based layout? So there are browsers that render just text now images and they generally don't do JavaScript either. It's a great way of getting past pay balls, by the way, because people don't have the engineering skill like you're saying, but how far do you personally strip this back? It's an interesting question because obviously all of this takes time. So I guess from a client perspective, you don't want to be spending all your time going all the way back to a text-based browser like links or something. If there is no data to support going back that far, then don't go back that far. If there is data to indicate that there are a number of users with JavaScript disabled, go back that far. I generally keep it there. Data should always be the first thing. Cool. Thank you very much. Anybody else? It's a question of the back and then at the front. Typically, what kind of subject matter website would you be building? Because I would expect you wouldn't need to build a luxury brand website to be deliverable on a low-powered device. Are you typically working for governments or charities, that kind of thing? What's your client base? I'd say a lot of 10-ups clients are mainly based in media and they are relatively well-known brands. You can ask the guys in front of you if we do any charity work, I'm not sure. Generally, this stuff can come down to brands with a lot of traffic hitting their websites. You've got a lot of different users and a lot of things to take into account. It's high-scale websites most of the time. What kind of data allowance would somebody have if they're earning 70p a day? Probably nothing because they've got to buy water and bread. I can tell you from the travelling in Africa and all of that, a large set of the population. In South Africa as well, 80% of Africa is rural. There's only a few cities that have been built up that have the infrastructure and not even close to the infrastructure of a place like London. In many ways, we're very far back in that. I walked into a boot the other day and there were no tellers and I was like, what? Did someone go on strike? If you're not in a built-up area, you're not going to see smart phones. You're going to see a lot of feature phones, a lot of older phones. Most of them are consuming data on a mobile level. They don't have laptops. They don't have computers. They don't have smart TVs. Browsers like Opera Mini are basically the default on those feature phones. That is optimised to consume more data. It strips out images and all of that. If they are getting information from those phones, it's largely text-based. It will probably go far enough for them, but they're not sitting on YouTube all day watching their music videos. There was a question here. Just a general one. Given the sort of communities growing reliance on JavaScript and stuff like React and stuff like that, do you think it's going to be much harder in the future to be able to do these progressive enhancements? I think from React side and the whole world going in that direction, front-end engineering world going in that direction, I think that as long as you're keeping in mind when it comes to building interaction, if it can be done in CSS, do it in CSS. If you can't do it in CSS, then it becomes a UX issue. How does that component work when there is no JavaScript enabled? If you actually think of it, it's quite scary that these frameworks like React and View and all of that are starting to gain such popularity and they're all JavaScript-based and we're still living with legacy software that doesn't support JavaScript at all. Hi there. I came in a couple of minutes late, so I don't know if you answered this question, but what's your strategy for working with content creators so that they know or avoid putting things in their content that might not work as well? Could you explain a little bit more in terms of what they would be putting in their content? So like iframes or pasting JavaScript or pasting CSS code or video? I hope they won't be posting JavaScript into their content. Especially from WordPress aside, with the exception of Gutenberg right now, which I think is going to solve a lot of problems, the current editor using OMB technology really helps users that aren't code related to have those kind of things within their content. I would say, and I'm not 100% sure, it might be a really good ticket to open up on core, but I don't know what the the JS, no JS compatibility is like for OMB. Someone would have to give that a good try. If the browser doesn't support the video tag or if there's an iframe that's heavily dependent on JavaScript, that's obviously a third-party problem and we can't do much about it. But generally, it's more a case of actually educating the content guys as much as we can to know exactly what could be harmful and what would work. Is there any more questions? Because I actually have one, really. Go for it. OK, so do you put anything into the WordPress dashboard at all to kind of reduce a load of loading things in the admin? Because I think the admin page is actually quite heavy itself, so if you haven't got that much data, loading and reloading admin sections could be a bit slow and it could cure quite a lot of data. Do you do anything in that side of things? One of the biggest gaps with WordPress has always been the amount of crap that dumps everywhere in the DOM, especially from the front end. You see guys actually writing functions to strip all that stuff out, stuff that most WordPress developers, they don't even know what it does. It's just existing there for some obvious reason. In terms of the dashboard, I don't think we do anything particular about optimising that from what's being loaded up in there. It's probably a bit of a delicate place to do that kind of thing, especially with WordPress being so concentrated with themes and plugins for users. I think you could probably cause a hell of a lot of damage doing that, but it's definitely a path to look into. Cool. Is there any more questions? Nope. Right, big round of applause for Dane. Well, thank you very much.