In this episode, I am chatting with Morten Rand-Hendriksen. As someone who has taken most, if not all his courses on Lynda.com – all I can say is WOW – this is awesome. Let’s get started!
Instructor, educator, speaker at LinkedIn Learning, helping people master WordPress, the web, and online communication.
Since joining forces with Lynda.com (now LinkedIn Learning) in 2010, Morten has 60+ published courses on WordPress, front-end web design and development, and web standards, reaching hundreds of thousands of viewers from all over the world. He also contributes to the web community as a public speaker, author, educator, web developer, and design philosopher.
If you’re a developer who’s looking to speed up their workflows so you can work less but bill the same (effectively increasing your hourly rate), WP Migrate DB Pro is for you.
Or, check out their blog at deliciousbrains.com. (Developers really like it)
This is one of the plugins I renew every year. It speeds up development time. It’s keeps my local and remote database synced during development, keeps my media files synced and is built by a team that I trust. —Jackie D’Elia
(Limited time offer – Coupon expires June 30, 2017)
@mor10 on Twitter
The Case for WordPress Telemetry
WordPress Theme Customizer
Creating Web Icons with SVG
Migrate DB Pro course on Lynda.com
A takeaway worth noting:
The guys at Delicious Brains make super awesome stuff for WordPress developers. If you’ve ever experienced the pain of trying to copy your WordPress database from one install to another – dev to staging and back again, you’re going to seriously want to check out their WP Migrate DB Pro plugin. It not only makes migrating databases easier, but by saving you so many hours, it effectively increases your hourly rate. Definitely a must for any WordPress developer working on client sites. Check it out deliciousbrains.com.
Open PDF transcript in a new window.
Hey, everybody. It’s Jackie D’Elia with another episode of Rethink.fm. This is Episode 15. I have my very special guest, Morten Rand-Hendriksen who is a senior staff instructor at Linkedin Learning. Hey, Morten.
Thanks for joining me.
Good to be here.
For those who don’t know you, and I can’t imagine there is a lot of people that listen to this show that don’t, is there anything else that you want to fill in about what you do?
Well, my main job is as an instructor at Linkedin Learning and Lynda.com, I also contribute to the WordPress Project in odd and unusual ways. I don’t really write a lot of code patches for WordPress but I ask a lot of questions about decisions that are being made. I propose things that should be done. I also contribute to the Community Project, like we’re working on something. I’m peripherally involved in a non-hard and heavy code sense in that project.
Well, before we jump into that, I’ve just got a couple of questions for you. How did you get started teaching?
At random. Let’s see. This must have been 2009, 2008, something like that. I was working on a project, just some random client project. My wife was, at the time, doing what eventually became vlogging. She was one of the first people in Canada to make a TV show on YouTube where she went around interviewing people. She was a producer at a TV show. Then she would take all the people that she couldn’t get on the show and do separate things on YouTube instead. She got invited to this event for Microsoft. We were like, “Yeah, whatever. We’ll go to the Microsoft event.”
Then at the event, they were handing out these little business cards with an activation code from new software that no one had tried before. It was an alpha, so it was very buggy. They said, “This is our new web design and development suite, it’s called Expression. We want you to try it.” Then I took one of the cards. I said, “Sure. I’m starting a new project right now, so I’ll try. I’ll just build the project on this new platform so I can really beta test it for me.” I started doing that and immediately ran into some pretty significant problems because it was an alpha application, so hardly worked at all. I was like, “I should really document what I’m doing here so that they know what I’m doing.”
I made a blog that was called, at the time, just Blog.PinkAndYellow.com because Pink and Yellow is my company. I started just blogging about this Expression Web and Expression Design application. I was literally like, “I try to do this, everything explodes.” The funny part was it was you color pick inside the application. Instead of color picking what’s on the screen, it would color pick based on the screen settings for your computers, it was these random colors. It was very odd. I was documenting all these things and just putting it in blog posts everyday. Then after a while, I started getting a lot of comments back. The comments were very odd because they were super specific.
They were like, “So when you experience the screen picking issue, exactly what are you doing? Where are you screen picking, inside the application or outside the application?” I’m like, “That’s a really specific question from some random person to ask.” I went in and looked at the IP address and then I noticed that almost all the comments on my blog had IP addresses in Redmond which is where the Microsoft headquarters is. I answered back to one of them and I’m like, “Well, maybe you should just call me instead of us having this ridiculous conversation on my blog.”
They called me and then I went down there to just show them what I was doing. That got me … Because of that, I became a official beta tester for Expression Web which was their front end publishing platform. From that, I started writing articles for them about Expression Web in addition to my blog. Then Pearson Publishing contacted the Microsoft team and said, “Hey, we want someone to write a book.” Then they pointed Pearson at me, so then I wrote a book. Then I wrote another book, and then another book. We released four or five editions of that book. Then finally, I made a video tutorial for Pearson under the Inform It Labels.
If you go to Amazon and search for my name, you’ll find all four books. The crazy thing is you can still buy these books even though the software doesn’t exist anymore. I keep getting royalties for it and I’m like, “You really shouldn’t sell this. This is not something …” I don’t think it’s even Pearson, I think Amazon acquired a bunch of these books. They just sit at a warehouse. They will just keep selling them until they’re gone. It literally started with a blog. It’s funny, if you go to my blog at Mor10.com and you go to the first blog post, that’s a blog post about me testing out Microsoft Expression Web.
You can actually read the whole thing, see all these comments back and forth, and see when I realize, “Oh, these are people from the team.” I think I even left a comment at some point going like, “Oh, you’re the actual development team for this software? Maybe we should have a chat.” It’s somewhere in my blog. You can still see it. It was, like I said, totally random. It all stemmed from my blog. Once I started actually writing proper documentation that wasn’t just me ranting about what I was doing in the blog but thinking very carefully about why am I doing these things, how does this actually work, I’ve just realized that this is actually way more interesting to me than building things is understanding why they are done a certain way and then figuring out how to explain it to other people.
Then from that, I went out to do a course. They asked me to do a course on Expression Web. When they asked me, I already knew that Microsoft was going to shelve it. I’m like, “Yeah. We shouldn’t invest any money in this. Just trust me on this. This is not worth your investment. I can’t say why but it will not be worth your investment so we should do something else.” Then they randomly were like, “Well, you seem to know a lot about WordPress. We have a WordPress course that’s outdated. Maybe you should do this because not a lot of people watch these WordPress courses so it’s not a big risk for us to let you do that as a first course.”
Then I recorded the WordPress essential training course. It was released in the second week of October 2010 I think. Then I got a call three weeks later that said that’s the first course to ever earn back its full advance within three weeks or within the first month of release. Since then, it’s always been one of the top two or top three courses on Lynda.com.
Okay. Well, as somebody who has watched probably almost every course you’ve made on Lynda …
That sounds awful.
At some point or another. I really have. I really have. Everybody who listens to me or have seen on other podcasts knows I’m a big fan. Just in Lynda courses in general, I mean, I’ve even shared with you, we were chatting. Ben Long is a photographer. He has got some great courses on Lynda.com. I was hooked on those when I was learning photography. That’s always been my go-to source for learning. You did the course for WordPress. I’ve noticed you’ve done a huge mix of other types of courses that are outside of WordPress. I’m just curious, what’s your mix of courses that you’re currently working on? How do you decide what courses will be coming out in the future?
I’m not actually a WordPress developer. I’m a front-end developer that happens to use WordPress a lot because it makes sense to people I build websites for. Because of that, my proficiency for WordPress is extremely high just because I’ve done so much work with it. I’ve been with WordPress for so long that I know how it used to work, why it’s working the way it does now. I can see where it’s going. My passion, my core passion isn’t specifically WordPress, it’s just general communication through the web.
You have an idea. You want to somehow convey that idea to other people in a way that they can access and understand whatever method they want to and then they should be able to communicate back to you and using web technologies to facilitate that communication. That’s what I’m interested in. A lot of that is just front-end development. Some of it is communication theory and user experience design.
Yeah. The course covers four or five different methods for doing the same thing.
Yeah. I’ll put a link in the show notes for it. I thought it was a great course. I like those courses that go outside the WordPress bubble and get you honed in on your skills on that level. Then you can look at it. I’ll jump to another question that I did want to ask you is on the 2017 theme, I’ve dug in and started looking at some of the code in there. Typically develop using Genesis, so some of the things didn’t apply in the same way. There were some really nice bits of code in there that I really liked.
You had done a course using social icons for a menu system instead of maybe using a plugin widget or something. I’m just curious what you thought about 2017 theme as a whole. I know you had one course where you actually pulled out some code out of there for navigation menu that you were swapping out from underscores. I’m just curious what your thoughts are on that.
The icon system that was built for 2017, so the system that uses SVG Icons not just for the social menu but for anywhere you want to use SVG Icons is a stroke of genius. It’s developed by Sami Keijonen from Finland. It is extremely robust and very easy to use. The tricky part is there is four or five different pieces that need to be stuck together for everything to work. You need to know there is a bunch of PHP in two different files, then there is some Java Script that needs to be hooked in and a bunch of CSS. When all these pieces stick together, the actual addition of any kind of icon within your theme becomes very easy. It’s built so that you can create custom fallbacks for each individual item.
You can say, “This icon needs a PNG fallback, so I’m going to provide a PNG fallback. And this icon, if it doesn’t display, it doesn’t matter, so I’m not going to make a fallback for it. This icon needs a text fallback so I’m going to create a text fallback for it.” It’s a really well-wired system which solves one of the main concerns that a lot of people have around icons which is what happens if people have old browsers because SVG isn’t fully supported, which is a whole other topic which is really odd.
If you go into the track tickets and you go into the chats and everything, you’ll see me very very aggressively trying to convince them not to do it because it’s bad practice. It’s honestly something we shouldn’t do. The argument that was made against it made for adding video headers in was everyone is doing it already. A lot of themes are doing it so we want to show people how to do it. My constant argument against it was simply, “I don’t care if people are doing something that is bad. It’s still bad. But this is still something we shouldn’t do.” There are a myriad of reasons why you shouldn’t have a video header, most importantly, just performance.
My concern is when we do things in WordPress we set a best practice standard. WordPress is big enough that when we make a decision like for instance, switch two SVG Icons, number of switching SVG Icons on 27% of the web. Then all of a sudden, that becomes a thing. When WordPress shifts responsive images, that basically … You can watch the graph of websites using ICG mark-up. It was pretty flat. Then WordPress shifts it and then it eventually had this super sharp line that went up because all of a sudden, it’s being used all the time. Then the browser manufacturers go, “We need to handle this stuff right away.” Right?
When we then jam video headers into WordPress, we’re basically telling people, “Video headers is a good thing to do.” It’s not. It will never be. It’s a bad … It’s blingy. It looks fancy but it goes against accessibility principles. It goes against UX principles. It goes against performance. It’s just a bad idea overall. The good thing is the original implementation of it was scrapped for something that’s far lighter.
YouTube backing was introduced to ensure that people can use an external video service to serve up the videos instead of just hosting them on your self-hosted site — which would be terrible and very foolish to do. Still, it shouldn’t be there. Now, it’s there. Now, it’s built into core so now everyone can do it. It’s an open source project. You can’t win all battles.
Yeah. You don’t have to use a video.
No, of course not. I don’t think a lot of people are, but I don’t think, on principle, we need to make more careful decisions about what we’re doing because it sets examples for people. When things like that get built into core, now it’s a feature that people will use. It will never be removed from core. Video backgrounds, which is what this is about, are purely visual elements that have no communicative value or purpose other than making things look good, right? That means if you’re adding a video background into anything on the web, you’re doing it purely to make your content look fancier.
Then you have to make a decision, is this something that’s important enough for the experience that I should force it one everyone who visits or should this be something that only loads if the visitor actively engages with it? You’ll see a lot of news websites for instance now. When they embed a YouTube video into their page, you see a screenshot of the YouTube video with a play button. Then you click on the play button and then it loads. Then you get the video container from YouTube. Then you have to click play again. People go, “Why are they doing that?” Well, the reason is if you put a video container from YouTube on your page, you’re downloading the video onto that page the second it loads.
They know that so they’re like, “No. We’re not going to impose on you the download from YouTube because you don’t need to buffer the first 30 seconds of that video unless you’re going to watch it. So we’re going to put a wall in front of it and say you need to interact with that wall to be able to open the video even if it increases the number of clicks necessary.” A video background is the opposite of that. You’re introducing a video component which is a heavy download and a heavy bandwidth component into the experience even though it has no communicative value. If you’re going to do that, you would have to then say, “What is the bandwidth connection of the person who is visiting currently on?” Which we can’t do because there is no system for it yet.
You’d have to ask, “Is the person able to choose whether or not to load this video?” They can’t. Are we going to defer the loading of the video until every other piece of content on the page is loaded so that it doesn’t slow things down? Well, that defeats the purpose of a video header because it needs to be there up the top. There are all these strategic and technical questions that come into play that need to be addressed properly. The team that we’re building 2017 took all these things into consideration and implemented it in a responsible way, that’s fine.
The problem is when we establish a standard like this, hand it over to other people who will not ask all these questions, will just do this without considering the implications of it. Unlike the team that we’re working on, 2017, someone might upload a 50-megabyte video, right, and make it play in the background or make it take over the whole page or force it to play with audio. There is a bunch of problematic things.
That even happens with background images.
People are publishing content, start uploading images and don’t pay attention to the size of them. But before we go onto that, let me just jump back and I wanted to ask you, you had written an article about the need for telemetry in WordPress and understanding who is using WordPress and how they’re using it. We had a conversation not too long ago about that.
Some really valid points you made were that most of the people that are making decisions about what we’re going to do next and what we’re going to add to WordPress aren’t necessarily the people that are using WordPress every day. Why you read that article and what do you think this means for WordPress going forward?
Telemetry projects or proposal stems from just observing ongoing conversations around features and WordPress core, which is every time a new feature is proposed or someone proposes removing a feature or something has changed, there is this conversation around, “Well, are people actually using this or are people to use it? How are they going to use it? Who is going to use it? Is this going to be something that everyone uses or just a few people use?”
It’s a weird conversation because there is a lot of theory going on. People are proposing or not even theory, there is a lot of hypothesizing going on where people are just throwing out ideas and saying, “Well, I think that most people would use it like that,” or “In my experience, this is how people use it.”
There is no concrete data to refer to. Then some user testing is done but the user testing is typically done internally in the active WordPress contributor community. User testing is announced on the Make Blogs which are only accessed by people who really care about WordPress core development. The people that things are being tested on skewer heavily towards advanced users who are involved in the process of building WordPress itself.
As a result, we don’t really know much about the people who use WordPress every day for things like publishing content because we’re not reaching out to them. We don’t have any way of talking to them. They don’t have any simple way of providing feedback back.
There is no button inside WordPress that says, “Provide Feedback,” right? You see that in a lot of applications. You have a little fly out, your click button and then you go to user voice or whatever. There is no such thing in WordPress. There is no easy way of providing feedback back to WordPress unless you know how the system works. It all came to a head during the conversation about whether or not to remove the underline button in the WYSIWYG editor. There was a proposal to simplify the WYSIWYG editor so all the buttons that are up in the kitchen sink at the top of your editor, which I am 182,000% for because the structure of the WYSIWYG editor made no sense.
For instance, the drop down that gives you hierarchical content order was underneath the kitchen sink so you have to know how to click the button and then know how to use it. That should really be the first item. The WYSIWYG toolbar got scrambled. I mean, moved things around and reorganized. In that process, questions were asked about each individual button which is justifiable to say, “What is this? What does it do? Should it be there? What should we do instead?” In some cases, we looked at a button and said, “Well, this button follows HTML standards so that should be there. This button injects some garbage CSS into the page itself. That should go, right?”
Then there were conversations about what are these buttons doing? We got to this underline button. The argument that came up was underline is too similar to link underline. Therefore, it’s confusing for user experience. To which I responded, “That’s a developer problem? That’s a problem of the theme developer not accounting for underline being different from the link underline?”
While that is the case, it is not because of the underline functionality itself. It’s because of theme developers not accounting for this or not providing best practices. The solution, if that is the issue, the solution is probably to create some packaged style that comes with WordPress that distinctly differentiates it from the regular link underlines. Then theme developers can overwrite that style with their own class. Right?
That would be the way to solve a problem. That’s not really on its own, a reason to remove the button. The response to that was, “Well, no one uses the button.” At which point, I and other people asked, “Based on what data are you saying this?” Then they’re like, “Well, no one used it. I’ve never seen it used.” I kept asking, “Where is the data to support this claim?” Then eventually, you come to this 80-20 rule. Well, 80% of the users need to use this before it’s valid. Otherwise, we shouldn’t have it in core, which ties back to the WordPress philosophy which is it wasn’t designed for 80% of the user base.
The 80-20 rule is a lie because we don’t have data on 80% of the users. We don’t even have data on 1% of the users. We can’t use that as a rule. Yet every single major decision that has been made in WordPress ties to the 80-20 rule and is used by everyone all the time. That’s when I said, “Well, if we’re going to do this, we need data. What we should do is collect anonymized telemetry about how WordPress is being used. Anonymized telemetry literally means track how many times people click on a certain button or whether or not people click on a button at all or how many themes are being installed and how many plugins are installed but not activated, just things like that.
Then build a system that truly anonymizes the information. The information that’s sent from your site doesn’t have any information about your IP address or anything else. It just has the core data about clicking. Then it goes into a system that further anonymizes it so that there is no way for anyone to see that behavior and then tie it to you. It would also include things like preventing the system from collecting actual keyboard input so you can’t store what people are actually writing. You can just see that they are writing something.
I made a huge proposal about how this could be done to fully anonymize it, how to make it opt in rather than opt out, how to secure it so that if people don’t want it, they can jut uninstall the entire feature and then it won’t be sitting inside WordPress core. It will actually be removed from the platform entirely, and how to handle the data when it comes in on the back end. Who should have access to it? Who can decide what to collect? The whole menagerie, just full coverage everywhere because I really think we need data.
It’s irresponsible to not have this data at this point because when we make changes to WordPress, we’re making changes for millions of people, millions, probably 10s or 20 or 30 million people will be directly impacted by any change we make. We can’t make those changes without knowing how those people are using the tools. The proposal was made and got shut down by Matt Mullenweg because his argument was it doesn’t fit in under the current three focus areas which are the editor, REST API, and Customizer, I think.
Okay. But those three things, wouldn’t it be really beneficial to find out who is using those and how they’re using them?
Of course. Of course. That argument is nonsense. I’d tell that to his face, that is truly not a valid argument against this at all. In fact, that is an argument for telemetry. I think what he meant was we already have limited resources. Those resources are allocated to working on these three things. If we do this, it will take up too much time, which is really unfortunate but that’s the nature of open source is a telemetry project is not as sexy as creating a better WYSIWYG editor. It’s harder to get people involved in building it. It’s much harder to get people involved in building it if there is no sign off from people higher up that will say, “We want to include this.”
Until we get sign off from someone higher up that says, “This needs to be done now,” it simply will never happen. That means WordPress development moving forward will distance itself further and further from the real user because the WordPress user base continues to increase. The increase in user base in WordPress is not an increase in people heavily involved in WordPress core development.
It’s an increase in people who use WordPress and will never interface with the WordPress community at large. They will never go to a Word Camp. They’ll never go to WordPress.org for anything other than to download WordPress. They might never go there at all. They will have no interface with the community. We have zero information about them. They are an entirely black box to us. Unless we have telemetry, that data will never be available.
It’s something that needs to be done. I don’t have the time or skills to actually build it. I have talked to a bunch of people who are very interested in building it, but at the same time, are weary of starting the project without sign off from someone higher up because this is a huge project that requires … It can’t be shipped in bits and pieces.
It has to be done right off. It could easily be something you spend a year on and then it just gets shelved in which case, you’ve just wasted your time, right. It’s really tricky and at the same time, extremely important. Come June in Paris, I’m going to make this a conversation topic with a lot of people to make sure that at least people have considered it in a more careful way and not just written it off as this is something that sounds like it’s too much work.
One of the questions I wanted to ask you is about the Customizer. We chatted about it. I see there is a push going to where you could edit your content in the Customizer, right. You’re doing publishing functions versus configuration functions. I’m just curious. Why aren’t they separating those things out and configuring the site or configuring how the site is going to work a completely separate thing than publishing content? I think if you want a WYSIWYG editor for publishing content, that’s one separate thing. I don’t understand why we’re mixing it all together. I’m just wondering, where do you see all that going?
What do you think? Why do you think that’s happening?
My reason would be is they want to compete with easy WYSIWYG editors.
Sure. Ignore that part. Why do you think they want to put it into the Customizer instead of somewhere else?
Those people that are building out the Customizer want to add all of those components there. I just think that even just splitting it off, I would love to see it when you open up WordPress, you have three buttons, publishing. It’s configuration. It’s administration. If you’re just a content producer, you have one button to click on, you’re in.
You don’t load all of this other code that isn’t even really being used while you’re publishing. You don’t need all of that other stuff loaded up in the dashboard. I’m just wondering, I mean if the goal is to compete with Square Space and other platforms that their goal is to make it easier for people to publish content as well, this seems like this is more of an obstacle than it is making things easier.
Yeah. I can only speculate here. I’ve observed a lot of these conversations but I can’t speak on behalf of anyone else. I can only speak on behalf of myself of course. One of the reasons why this is being tied to the Customizer is simply because the Customizer is already a place where you are making changes to settings and database. You’ve already solved all the issues around authentication and everything. When you open My Customizer, you’re basically opening a virtual space where you can see your website and make changes to it without anyone else doing. You’re running this instance of WordPress inside your browser essentially, right.
I think that the reason why a front-end editing, which is basically what we’re talking about, the idea that you can go into a post or page and edit content is being injected into the Customizer is simply because that is already a path that’s open. I know that what people want is true front-end editing, meaning you open the front page of your site, you go to a post or page. You can just start editing the content right there on the page. There are solutions in existence already that can do that. I’ve built some very simple demos of how to do it. One of them is making its way into Linkedin Library right now. There are ways of doing this.
A lot of the ways of doing this are actually tied to the REST API. The Customizer existed way before the REST API. There is still a reluctance to use the REST API for a lot of things, for various reasons. I believe that much of the reason for trying to push all this editing stuff into the Customizer is simply that it’s an existing modality people are familiar with or the developers are familiar with. They don’t have to build something new. That said, I am firmly in agreement with you that there is a separation of concerns here that needs to be established, which is the Customizer is for customization of the application. That would be the customization of the look and feel of WordPress on the front end.
Whereas content creation and editing is a separate thing altogether. That conversation I’ve been part of. Generally, people just choose to make the umbrella that is customization broader and say that customization includes customizing the content itself. To be fair, there are actual very clear crossovers there. For instance, let’s say you’re setting up a new site. You just downloaded WordPress. You set it up. You installed it. You’re going to start customizing your theme. Then you go, “Well, I want to have these four pages.” Then you go into the Customizer. You start building out your menu. Then you realize, “I don’t have the pages.”
You have to go to the back in the WordPress and create the pages. Then go back to the Customizer. With 2017 and 4.7, a feature was introduced that allows you to create a new page directly from the Customizer so that you can add it into a menu. Then you can go onto the back end and edit it. The next step of that would obviously be you create the page and then you edit the page. Right now, that editing happens in the Customizer pull out menus. Then it updates on the page. Then that confines it to the Customizer space, which justifies the argument that this is still in the Customizer.
Once you move that functionality over into the preview, so you’re not editing the content on the page itself, not in a little panel, the separation of concerns becomes very obvious. At that point, you’re like, “That specific editing functionality should exist on the front end.” Now, you could, in my opinion, do both. You could do it so that you can create content and manage content from the Customizer. That should be an extension of the front end editing capability. You build front end editing first. Then you migrate front end editing into the Customizer to allow people to continue it in the Customizer rather than forcing people to boot up the Customizer to do the front end editing.
That is a philosophical conversation that has to do with literal design philosophy, “What is customization? What does customization encompass? Is content editing part of customization? Is content creation part of customization? Where is the line between customization and just actual content editing? Who should have access to it? Who should not have access to it?” There is a bunch of very interesting conversations around that. Right?
Well, that goes back to just having the data so that you understand how people are currently using things. I would really like to know how many people when they are editing a page or using the visual editor versus the text editor. I have no idea. I know the use the text editor because I like writing HTML but I’m assuming all of my clients would never be in there. But I don’t know.
To that, there is this very interesting thing that was happening. You know about the Gutenberg Project, right? This project to redesign the content editor and WordPress to make it block-based. What they’re doing is something that looks very similar to what Linkedin Post has whereas you start with an editing page. Any time you hit enter, you get a new element and then there is a little plus sign. You click on a plus sign, you can open a thing that you can define, “This is a paragraph or a heading or quote or image or whatever.” It’s contextual so that you have the different types of content at the level you are working on them instead of in a toolbar at the top. Right?
It’s an interesting user experience idea. It has pros and cons. I’m not going to get deep into that. What’s important is part of the conversation that happened around the Gutenberg Editor was this conversation around what happens when you hit the return key on your keyboard as you’re writing content. This was one of those places where I go, “If there was ever a reason if there was ever a proof of why telemetry is necessary, this would be a good example of that proof,” which was a conversation around what happens when you hit the return key.
Where the majority of respondents said, “A Return key creates a line break.” Everyone who has worked with a content editor is just like, “Under no circumstances are you ever allowed to make the content editor in WordPress have returned a line break.” That goes against all standard conventions for content editing. That is only the case in a text editor. The text editor is the only place where hitting the return key just returns you to the next line in all content editors. Microsoft Work or Word Perfect or Office 365 or God knows what, everything, a Return key creates a new paragraph. Shift return creates a line break. This is the standard.
Then you got a ton of push back. People who said, “No, it’s not.” Then we have to actively prove it, literally go into Word and tape ourselves hitting enter just to see how paragraphs are created when they hit enter here. This is not new. This is not something people are making up. This is an industry standard. Then they were like, “What industry? I don’t think so. People can learn.” It’s like, no, no, no. You cannot design WordPress like this. If you ship a content editor in WordPress where enter is a line break, the ramifications will be so disastrous, right, because people would literally just go, “Oh, WordPress is broken now.” Then they would just abandon the platform.
It’s such an arbitrary decision. It just proves that the distance between a lot of the people who contribute to WordPress and the people who actually use WordPress on a day-to-day basis is so long and so vast that there is a complete disconnect about how things work, right. Then when you realize, “Oh my god, these conversations are happening.” Then you wonder, “What other unsaid things are being assumed about how people are using content editors?”
The crazy part is the people who were very adamant about return returning a line break had every reason to be. They’re not crazy people. They’re not stupid. They’re not misinformed. They have every intention of doing the best thing possible for the people who use the application. They simply work in an environment that doesn’t have the return key creating a new paragraph because they don’t create content.
If they do create content, they write it in Markdown where that isn’t the case. Their experience of how WordPress works is fundamentally different from that of other people and because they have no data to cross-correlate their experience, they just don’t know that it’s … When I say don’t know, people go, “Well, that’s ignorance.” It’s not. The world is too complicated. There are too many different people. There are too many different ways of doing things that a single person can’t have full knowledge of everything. You have to actively seek out other people that don’t fit into your particular bubble and then figure out how they do things and then take their disclosure of behavior as a true statement about the world as they see it rather than some misunderstanding of how things work.
Then see how, “Okay, so I know that I do things a certain way. I know other people do things a completely different way. How can we solve the issue for both of them or is one way more prevalent than the other? Should we then make fallbacks for the other one?” That’s where telemetry comes in. This is why telemetry is so important because if we had telemetry, you would very quickly see that the frequency of people hitting return twice to create … It would be astronomically high, right. You would have billions of double clicks on return. Whereas in reality, you don’t because the only place people would do that was if they were trying to make double lines and then it would just collapse on itself and they would stop doing that.
All right. Well, I’ve got one more question I wanted to ask you for sure that I wanted to get into this episode, which is, “What do you think developers who currently work in WordPress need to be focused on in the future? What do they need to be learning now?” I know that’s a broad topic depending on what it is that they do. If you’re a developer, you work with clients, you build websites or youR…