At Make Do, we have recently moved away from having client projects split between BitBucket and GitHub to exclusively using GitHub, while considerably increasing our use of GitHub issues as part of the overall project/task management process.
One of the by-products of this is that the amount of email generated by the various projects we work on — some within the confines of our team and others with our B2B partners — has increased exponentially as a result of the increased activity.
Simply killing email notifications from all the various repositories isn’t really practical, given that you are then left in a situation where you are completely in the dark regarding their activity. Another solution is required to avoid having an inbox that is constantly overloaded with GitHub notifications.
One of the tools I’ve grown to love in recent months is Gitify, from Emmanouil Konstantinidis which has helped me keep up to date with the activity on GitHub whilst retaining some degree of control over my email inbox.
The app itself is built with ReactJS & Redux and is based on the Electron framework, which means allows it to be packaged up into a usable, native app. Gitify is also available on the Apple App Store and Google Play for use on mobile devices, however at the time of writing this isn’t available to install if you are a user in the United Kingdom and potentially a number of other regions. Fingers crossed this changes in the near future.
Gitify lives in your dock/menu bar and notifies you when there has been some kind of activity that justifies a notification based on your GitHub settings. The notification itself is very subtle; a basic visual notification as well as a simple tap/click sound that doesn’t break your concentration.
Upon clicking the icon in the dock/menu bar the app expands (see above) and presents you with a list of your notifications broken down by the user/organisation and repository from which they came. The UI itself went through a major overhaul in the last major release, and although I do miss the old layout somewhat, the current version works just as well.
In the settings you can control whether or not you see only notifications for issues/pull requests that you are participating in, change notification preferences, set how you’d like the mark as read behaviour to work as well as decide whether you want to load the app at startup and where you want the app icon to exist.
Gitify is a simple, effective and completely open source solution to the problem of GitHub Email Horror™ and I strongly recommend you give it a try if you would like to keep GitHub activity out of your inbox without falling behind on the action.
The ability to deliver the most suitable image, both in terms of dimensions and file size, depending on the viewport (that is, the width of the browser) of any given device is one that I am very glad we have.
But what about responsive background images?
In my experience using and building for the web, the typical implementation of responsive images focuses on inline, not background images.
While there are many examples of sites that use techniques to make inline images look and behave as though they are applied as a background, more often than not the definition of a background image on the web is one that utilises the CSS background-image property along with background-size and background-position.
Now, I understand that there are occasions where making an inline image behave like a background image is desirable e.g. where having the image such as a hero header accompanying an article indexed by search engines is of critical importance.
However in general I am not a fan of forcing an inline image to behave like its background counterpart for a variety of reasons that I won’t waste time dwelling on here. If you need to force an inline image to behave like a background image, I would argue that the designs need to be re-visited.
Over the spring, I worked on a particularly image heavy build that made extensive use of background images. This project was the catalyst for me going ahead and building a simple, re-usable solution that I could use on this particular project and add to Kapow!, our in-house WordPress development boilerplate.
Implementing responsive background images is a two part process.
First, we need to write some good’ol PHP to craft a WordPress template tag that will accept an image ID and a bunch of settings at one end, and generate a list of HTML data attributes at the other containing information that we can parse and use.
Before I briefly explain and introduce you to the code for both of these component parts, there’s an elephant in the room that needs addressing…
The whole point of responsive background images, as per their inline counterparts, is to deliver the most suitable image to the device requesting it. In the case of a mobile user, delivering an 80kb image as opposed to the 800kb version results in a huge data saving which is both beneficial and responsible.
The problem is that any subsequent attempt to deliver a more suitable image, after initially setting a default background image, results in two images being downloaded by the browser for each element; both the default image and the more suitable alternative.
Two images, more data, bad monkey.
Therefore, we need to start from a position of not having any background image associated with the element(s) at all, with suitable background colours in place to keep things in line with the design, or provide the appropriate contrast should any text be present above the element e.g. a hero header on a blog article.
Then we must dynamically update the CSS background-image property with the most suitable image available after checking our context — that is, the width of the viewport — bearing in mind that this can and will change size and orientation based on user input.
The PHP & WordPress Bit
In the GitHub Gist below you’ll find the code for the WordPress template tag I wrote to generate the data attributes on any elements that need responsive background images.
The template tag takes four arguments:
The post (integer) of the image attachment.
An array of image size slugs (string) such as medium, large, your-custom-size etc, and min-width breakpoint values (integer) in pixels e.g. 480, 768, 1024 etc added in a mobile-first order.
The slug of the image size you would like to use as the default fallback image e.g. large.
Whether you want to echo or return the data attributes, boolean true to echo (default behaviour) or false to return.
Here’s the code in question, which should be added to your functions.php or whichever file you use to store your template tags in the theme.
One important thing to note when you are passing image sizes and breakpoints into this template tag is that your image sizes (registered in your theme using the add_image_size() function) should be large enough to not require stretching by the time you hit the next breakpoint.
So for example, if you’re setting a breakpoint value of 480, and your next breakpoint is 768, you actually need the image size that kicks in at 480 to be 767px wide; the next breakpoint value minus one pixel.
This will ensure that the image you load at 480 doesn’t need to be stretched in any way to make it fit, which will reduce the quality of the image.
We are now done with the PHP & WordPress part of the implementation. Onwards!
The function extracts the media query breakpoint values and image URLs from the data attributes on the target elements, checks to see which images are the most appropriate for the current viewport width, and then updates the background image URLs for the elements where necessary.
The function takes a single parameter, which is a standard CSS selector such as .js-bg-img used to target the elements that have background images which need to be responsive.
Here’s the code in question which can be enqueued in a footer.js or similar file in the footer, as it will need to fire once the document is ready.
The function is fired on the initial page load when the document is ready, and is then called again 300ms after the viewport has stopped being resized, or when the orientation of the device is changed e.g when you change from landscape to portrait on a tablet. The throttle exists to prevent the resizing of the browser from killing the performance of your browser.
It is worth pointing out that this solution relies on Modernizr as a dependency for quick and easy viewport width checking. You could modify this approach to use window.matchMedia() if your scope of work for the project does not include supporting legacy browsers.
A Working Example
Resize your browser window (or change your tablet from landscape to portrait etc) and each time you pause/stop, you’ll see that the background images automatically update.
I am pulling in dynamic images from FillMurray.com in this example so it is possible that you will see brief pauses before each new image is loaded due to the fact that the data is being pulled from an external source; with self-hosted images this won’t be as noticeable.
I have embedded the pen below, but if you want to view the full page version in your browser you can do so by clicking here.
[codepen_embed height=”265″ theme_id=”0″ slug_hash=”NgyVeE” default_tab=”js,result” user=”davetgreen” preview=”true” data-preview=”true”]See the Pen Responsive Background Images by davetgreen (@davetgreen) on CodePen.[/codepen_embed]
This is a useful and time saving technique that I now use on all projects wherever responsive background images are needed. Feel free to use this code to make your life easier on your own projects!
As developers, we often encounter things that we would like to change, or have serious misgivings about during the development process. Sometimes it can be a small thing, at other times it could be something more fundamental.
I’m not just talking about things you spot during a run-of-the-mill QA/bug fixing sprint here. I’m referring to those things that get under your skin. Things that the professional in you identifies as being in the process of being overlooked or neglected.
After we identify these issues, we are faced with a decision: push back and express ourselves in the hope that something can be done about them, or sit on our hands and let them slide.
There will be times when such concerns are immediately acknowledged as common sense changes and will be resolved without resistance. At other times, these concerns will be knocked-back for a variety of reasons, not all of them convincing.
It’s these knock-backs that I’m keen to focus on here. The ones that can trigger an urge to “push back”.
I’m quietly confident in making the assertion that whether you work for an agency, as part of an in-house team or work for yourself you will be faced with these situations on a fairly regular basis.
Here’s a couple of points I want to make on the subject.
Your voice is important
Regardless of where/how you work, there is a strong chance that from time to time you will meet resistance from others in the organisation who are connected with the project.
Some of them may not be receptive to addressing the concern(s) you raised, and occasionally you may encounter someone with a long-standing history of believing that They Know Best™.
The latter is of course first class bullshit, and needs no further attention other than to recognize that this can often be a tricky situation to deal with. But then again, convincing others to listen to your concerns and ideas isn’t always plain sailing either.
The unfortunate thing here is that sometimes, there can be a Hierarchy of Importance on a given project, where certain project team members feel as though they “outrank” other members on the team in terms of the weight of their opinion.
More often than not it is those who have perhaps been involved from earlier on in the process, or indeed, more of the They Know Best™ brigade. It is worth saying as well that acting in a management or supervisory capacity does not entitle anyone to use that privilege as an excuse to “pull rank”. Neither of these justifications wash with me, nor should they with anyone else.
The opinion of every member of a team should be treated with equal importance and carry equal weight if the opinion being expressed is both reasonable and constructive. Yes, I understand this is an idealistic view, but it is the right one in my humble opinion.
After all, developers are the ones in the trenches, right? Why shouldn’t our opinion hold weight when we are the ones executing the concept?
We are writing the code and making the technology decisions, we are the ones watching the project evolve before our very eyes. Who is to judge that we are not suitably placed to provide constructive criticism and suggest positive change? Nobody, is the answer.
Of course, there comes the caveat that just because we are the ones getting our hands dirty doesn’t mean that we are always right when it comes to the things we push back on. That is a given.
There is a difference between tactically suggesting changes that can be justified, and putting suggestions forward that are made on a whim without any real thought or justification.
Pushing back during a project when it is both reasonable and constructive to do so should be encouraged, and the person should be treated with respect from all involved for doing so.
The client is not always right
…they just have some flaws in their grand vision.
Fortunately, the web development and retail industries are very different beasts.
The commonly used retail cliché that “the customer is always right” does not, and certainly should not apply to our industry. I flat-out refute any claim that the client/stakeholder should always be “right”.
Not only is this a poor attitude that will make your life harder in the long run, but it means that you miss out on important opportunities to build up their confidence in you through sharing your knowledge & experience. You will also potentially miss out on chances to guide the client into letting you make changes that could save you time or indeed, make the project more profitable.
We should be constantly looking at what we are building and striving to make it better: even if that means pushing back against the specific implementation of something that has been a big part of the client/stakeholder “vision”.
The best web projects are those that continue to evolve from the moment the scope is agreed right the way through the development phase. This is why Agile project management practices are awesome!
Granted, better is very much a subjective term, but when you’re looking at a particular aspect of a website and holding it up against something such as, say, the Web Content Accessibility Guidelines (WCAG) you have a clear baseline from which to determine what is better, and what is worse. This provides you with a solid reference point when it comes to building your case for change.
Holding ourselves accountable to common standards and best practices makes it much easier to build and sell these cases for change to our clients/stakeholders.
Even if they really don’t care about the technical justification, web standards or the best practices we will be perceived as people who care about delivering the best possible end product in a professional manner.
And who doesn’t want that?
However, this approach isn’t without its challenges. Here’s just a few of them:
Is this considered to be within scope?
Does the client have the budget?
Is there sufficient time for these changes?
Are there knock-on effects to deal with?
All very important questions that need to be addressed I’m sure you’ll agree, but I’m a firm believer that the earlier we communicate our concerns and push back, the less challenging these obstacles become.
Pushing back adds value
As digital professionals our raison d’être (that is, our reason for being) should be to deliver the best possible projects for our clients/stakeholders within the budget/timescale, which in turn should deliver the best possible experiences for our end users.
When we choose to open up a dialogue and question some aspect of what is being built or proposed, we immediately begin to add value to the project as well as to the relationship itself. The latter being just as if not more important when looking at the longer term picture.
Encouraging an honest, constructive and pragmatic discussion means we are delivering on one of our core responsibilities: to educate and advise. This delivers value just as mocking up a design or fleshing something out in code does.
After all, the client/stakeholder approached you (yourself or the organisation you represent) because you can deliver their vision or a variation thereof. Even at this very early stage there is an implication of trust being placed in you.
They did not have the resource to complete this task without you or another like you, and came to you with a budget/salary and a timescale asking you to execute this vision because they perceived that YouKnow What You Are Doing™.
This for me is the killer. You were selected to be part of tackling this project for the client/stakeholder, so you should first listen to what is being said, and then tell rather than ask them how things should be tackled, and let the conversation take shape from there. Indeed, sometimes advising that something should not be undertaken is actually the best course of action!
It is essentially about delivering value through the sharing of knowledge, expertise and best practice. And this value is critical to maintaining and increasing the level of trust between you and the client/stakeholder.
Of course, we are all just as imperfect as one another, so there are naturally going to be times where you make the wrong call. Fortunately for us, we get better with experience (or data!) and can reduce the likelihood of this over time.
We should never ignore the opportunity to push back when our gut instinct says it is right, because it is better to be seen trying to add value instead of bringing nothing to the table at all.
Some Useful Advice
There’s a number of things that can be done to make life easier in these situations. Here are a couple that I feel are important.
Push for early technical discussions
Getting a thorough understanding of the technical requirements early on in a project is a sure-fire way to reduce issues further down the line. Having proper technical input before concepts/designs are signed off (or even finished!) is an opportunity that should be taken whenever possible.
Encourage closer interactions between the design/project management folks and the developers when things kick off and throughout the rest of the project. This way you can increase communication and overcome any barriers or divisions that may exist.
You should make sure that kick-off calls/meetings with the client/stakeholder have sufficient time put aside for the discussion of how and why things need to function/behave.
This will provoke discussion around the technical challenges, provide an opportunity to make recommendations and prevent both parties from agreeing on a scope of work that has little if any genuine scoping. A list of a dozen bullet points does not constitute scope!
Focus on getting the ethos/culture right
For some developers, expressing themselves doesn’t come easily: especially when it means standing up for something in an environment where there may be conflicting opinions, tension etc. In fact, it can and often will be downright difficult, especially if you are a contractor!
For others, it comes as easily as discussing the faults of the latest blockbuster release at the cinema with friends, casually offering up alternative solutions. I count myself lucky that I’m more in this camp.
You can breed confidence by developing an ethos/culture where your development talent (whether that be in-house or sub-contracted) believes that they have the respect of everyone involved in the process, and that their input is invaluable to both the project and the business as a whole.
Confidence is exactly the shot to the system that is needed to encourage folks to speak up and passionately fight for change when they are working on projects. Speaking purely from my own experience, increased confidence has a direct link to improved code quality and better problem solving!
If you are a freelancer/contractor, respect yourself and your skills, knowledge and expertise. Arm yourself with solid research/rationale and most of all have no fear! Fortune favours the brave!
Pick the right battles at the right times
There are some battles that you will lose, no matter how hard you try to put forward a compelling case, complete with solid justifications and mountains of examples of it being done “your way” in the wild.
There will also be battles that you will have to step back from at critical points during the process, as they will potentially make it a more painful/costly/lengthily one for you, or cause damage to your relationships. In these cases aggressively pushing back without first assessing the potential risk to your relationship with your client, stakeholder or colleague is a bad idea.
So fight the battles that look like you at least have a reasonable chance of winning, and occasionally roll the dice to try to change hearts and minds for some of the less likely wins if you are truly that passionate about the issue.
As for the battles that you know you have no hope in hell of winning? Document your concerns, ensure that the client/stakeholder is exposed to these notes (email, Trello etc) and then walk away. Put the kettle on or pour a glass of something stronger. It just isn’t worth the time and effort.
Finally, it goes without saying that if you decide to heed my advice and push back more, this doesn’t mean that you should suddenly become Mr/Mrs Obnoxious overnight…that won’t go down well at all!
Make the most of grey areas in scope
As developers, the scope of work and designs for a given project are pretty invaluable; confirming exactly what we need to build and how it needs to look.
However, many grey areas exist both in the scope of work and designs that can often provide opportunities to use our creativity and common sense to exercise a level of control.
The most common examples of this are when designs depict a particular element in its default state, but provide no guidance as to how this is meant to work when open, active etc. Recently I’ve worked on several projects where the mobile navigation design and layout has been left entirely up to us.
It would be irresponsible of me to suggest that you shouldn’t be consulting with the client/stakeholder in these situations for some kind of clarification: of course we have to reach out.
However, I do feel that where detailed specifications or visual guides are missing, we should be taking these opportunities and tackling them creatively; doing things the way we feel they should be.
We shouldn’t be afraid to ask a question about something that exists in a grey area at the same time we show something we’ve already built to address it.
Although this point is a little tangential, I’ve included it because these grey areas can often be a welcome and creative/fun distraction on projects where there is little or no chance to push back successfully!
Why Push Back?
Agent Smith: Why, Mr. Anderson? Why? Why do you persist?
Neo: Because I choose to.
At the end of the day, nobody can force you into the habit of pushing back. Despite the couple of thousand words you’ve read spelling out my opinion and offering my advice on this subject, I nor anyone else can force you to make these choices in your day-to-day development life. You have to want to push back.
We as developers should be taking advantage of every reasonable opportunity we have to push for positive, constructive change in our projects. Collectively we have a responsibility to our clients/stakeholders and, perhaps more importantly, to our end users that should not be taken lightly.
So, let us fight for the things that we passionately want to change in our projects. Let us find ways around the obstacles, get past the well-worn excuses and believe in our ability to make a difference.
Because when we refuse to let things slide and fight for positive change in our projects, we actually end up fighting for a better web, one small piece at a time.
And that, ladies and gentlemen, is a pretty just cause if you ask me.
I’ve spent the last couple of weeks carrying out a number of updates to Kapow!, our in-house WordPress development boilerplate that we use at Make Do as a starting point for all new client sites, and as a result of this I’ve had to upgrade my local set-up to use the super-shiny brand new Varying Vagrant Vagrants (VVV) 2.0.
VVV makes the process of provisioning new local development sites a breeze, and I decided to take the opportunity to create a new local environment for WooCommerce plugin/theme development, testing and general tinkering.
Granted, I already have the wordpress-default site available, but I’m keen to keep that for building and testing vanilla themes and plugins: so the goal is to have two separate environments.
Forking the default provision script
VVV 2.0 pulls down a couple of GitHub repositories containing the provisioning scripts necessary to install the default wordpress-default and wordpress-develop sites when you run a complete provision: such as when you install or upgrade VVV.
The beauty of this is that the default site repositories can easily be forked and modified for our own use. I’ve forked the repository that is responsible for setting up the wordpress-default site and have modified it to change the local domain to local.woocommerce.dev, change the database to wordpress_woocommere and install the WooCommerce plugin using WP CLI, amongst other small tweaks. You can find the fork here: VVV WordPress WooCommerce
Adding the new site configuration
In your vvv-custom.yml file you should add the new WooCommerce site directly below your wordpress-default site configuration. Here’s how my file looks:
As you can see from the above Gist, in the new site configuration that I’ve called wordpress-default-woo I’m pointing to my fork of the default site repository, rather than the VVV version. You can call this site configuration anything you like, as long as it remains in the same format e.g. your-site-slug.
Provisioning the new site
One of the things I love the most about VVV 2.0 is the ability to provision a single site at a time, rather than having to endure the full provisioning process.
First of all ensure that you’re in your root VVV folder (mine is ~/Vagrant for example) and then execute the following command to provision the new WooCommerce development site, replacing wordpress-default-woo with the site slug that you’ve chosen:
A couple of minutes later you should see something like this:
Huzzah! As you can see from the output of the provisioning script, you will not only have a default copy of WordPress installed and configured, but you will have the latest stable release of WooCommerce installed and activated.
Now, if you visit local.woocommerce.dev in your browser and you were fortunate enough to experience no issues during the provisioning process you should be treated to this.
Now you have a totally separate WordPress environment complete with WooCommerce!
UPDATE: I’ve now tweaked the provisioning script to automatically install and activate the Storefront theme as well, providing a more appropriate base theme to work with.
If you’re looking for the slides from my “Why Switching to WordPress Coding Standards Will Make You a Better Developer” talk that I’ve given at WordCamps and local WordPress events, you can find them here:
Before you, things were not so good. I wasn’t happy, I really wasn’t myself and I was longing for change.
Although I was in a stable relationship and was doing all that was expected of me, I was frustrated, without hope or any kind of excitement or challenge, clouded by doubts about myself and wondering whether D-Ream was telling the truth about things only getting better.
Then I heard about you, and I decided to see what you could do for me, whether you offered anything I’d been missing out on. Sure, our liaison on that brisk November day was a brief one in the grand scheme of things, but it had a lasting impact on my life that I’m still thankful for today.
I’d been sceptical for a while, unsure as to whether you and your sort were worth giving my time and attention to. Were you really that good, that interesting and you know, fun? I just decided to open my mind and give you a go. What was the worst that could happen?
Well, you certainly didn’t disappoint.
You opened my eyes and made me realise that I could take a new path, one that would be full of fun and new experiences, complete with plenty of exciting opportunities and interesting people along the way, not to mention hard work! A path that would challenge and reward me in equal measure. I’d just need to be hungry for it and commit myself fully, holding nothing back.
I was keen to make an impression during that day we spent together, as I’d realised quite early on that it was a perfect time to roll the dice and see what happens, to see if the old proverb “fortune favours the brave” was true.
So I did my best to impress and be noticed, and it paid off. I ended up going for a few drinks in the evening, and took a chance. And as a result of taking that chance, I’m in a new relationship now, one that has completely changed my life for the better.
I’ve grown as a person these last 18 months or so, more than I thought I could in such a short space of of time. I travel more than I have in a long time, and have met so many interesting people along the way. I’m encouraged to do and try new things, and I spend so much more time at home than I thought I’d be able to.
Most importantly, my voice is heard and my opinion counts. I feel like I make a difference and that I’m not just there to serve a purpose until the next one like me comes along, unlike in my previous relationship.
All because of that one day with you.
Granted, it’s been a lot of hard work, but what relationship isn’t? We Make and Do so much, enjoying the good times and tackling the bad times together. We have each other’s backs and want to better ourselves, and that’s what matters.
After you led me to such a fantastic opportunity back in 2014, I’m so excited to be seeing you again later this year, but this time I’m in a position to help you make a difference to other people’s lives, the same way you made a difference to mine. Sure, you can be stressful at times and it’s been a while since anyone has seen you, but a little mystery goes a long way doesn’t it?
I just hope those people with whom our paths will cross with on September 30th, when we see each other again in Sheffield, who are in a similar position to the one I was in when I met you nearly two years ago, decide to make the most of the day and fall for someone or something new, because it is absolutely worth it. If you want it enough.
P.S If you’d like £20.00 off a standard delegate rate ticket to FrontEndNorth use the code DAVEFEN when buying through EventBrite.
One of the things I love about being a WordPress developer is the ongoing discovery of core functions that make my life easier, or empower me to implement more best practice in my code.
At Make Do one of my chief internal responsibilities as front-end lead is managing our workflow boilerplate Kapow! which we use as a basis for all new WordPress projects.
In the theme component of Kapow! I’ve been happily adding a script to header.php the old fashioned way, which contains various poly-fills and shims to provide enhanced out-of-the-box support for legacy IE versions 7 & 8.
Normally I would rely on WordPress core’s wp_register_script() and/or wp_enqueue_script() functions when introducing JS or CSS assets into a theme to follow best practice, however in this case the need for conditional comments has meant that I’ve had to stick with the old fashioned way. Until this week…
Enter wp_script_add_data() ! This function exists for adding metadata to a script. It accepts three arguments: handle, key and value. You can find the function documentation on the Code Reference. Another gem that I had absolutely no idea about!
The handle is the unique ID you assign to the script when registering and/or enqueuing e.g. legacy_ie.
The key relates to the type of metadata you’re adding and from what I can see conditional is the only documented value available for use. This tells WordPress that the script in question should be enclosed within a conditional comment.
Finally, the value is the content (in this case at least) of the conditional itself e.g. lt IE 9 to detect all versions of IE lower than 9.
This meant I could remove the script from header.php and add the script The WordPress Way as shown in the Gist below.
As you can see we enqueue the script (no need to register unless it’s a dependency that needs to be referenced elsewhere) and then add our script meta to introduce the conditional comments before hooking into wp_enqueue_scripts to invoke the function.
The script will then be added to the header rather than the footer as the wp_enqueue_script() parameter $in_footer defaults to false if not supplied.
And there you have it, a way to introduce scripts wrapped in conditional comments into your theme without polluting your template files.
As I write this I’m sat in a cafe at Manchester Airport with m’colleague Kimb Jones before we board our flight to Vienna for WordCamp Europe 2016.
We’ve managed to find a great AirBnB in the area which means we have a great base for exploring the area and getting to the venue, plus we’re sharing the digs with Mr Steven “Stompweb” Jones who runs the WP North East meet-up and is a Proper Chap™.
The event has been looming for a while now, and I’m super excited now that it’s finally here. I had the privilege of attending WordCamp US 2015 in Philadelphia back in December and the sheer scale of that event was mind-blowing. It looks like WCEU is going to blow that right out of the water!
I missed out on last year’s WCEU due to client work (quite rightly) taking priority, but this year the event falls right at the end of what has been a really busy period for Make Do, so we can take advantage of a couple of relatively quiet weeks between projects to get onto the conference circuit once again.
For me personally it’s also an exciting WordCamp as I’ve actually signed up for my first ever Contributor Day: something i’ve always wanted to do but I just haven’t pulled my finger out to make it happen.
Hopefully I’ll be able to get onto the Accessibility team (my first choice) as WCAG compliance is something that I spend a lot of time on given my front-end responsibilities, and I’m really looking forward to learning from some of the stalwart members of the Accessibility team. It would also kick-ass if I could solve some problems and contribute some code in the process!
Speaking of accessibility, I highly recommend that you stop by Track 2 at 12:00pm to see Graham Armfield‘s demo of assistive technology. I saw a similar demo at WordCamp Edinburgh 2015 and it was a real eye-opener.
I’ve already been through the schedule and it looks like I’ll be in Tracks 1 & 2 almost exclusively depending on whether I go to the Unconference. Speaking of Unconference, I’m toying with the idea of submitting my WordPress Coding Standards lightning talk to spread the word as I have been doing at local meet-ups. We shall see!
There are so many familiar and new faces that I’m really looking forward to hanging out with at WCEU over coming days, it’s going to be a blast!
I’m excited to confirm that I’ll be taking a positive step toward meeting both of these development goals this coming April when I deliver a lightning talk at WordCamp London.
I really enjoyed the event last year, and although I was already planning on attending again this year with the Make Do chaps, I’m stoked (I have no idea what this word is but I feel I should be using it) to be delivering a shorter version of a new talk I’m writing entitled…
“Why WordPress Coding Standards will make you a better developer”
I’ll be sharing my experiences with WordPress Coding Standards after I made the switch last Autumn, highlighting the features and benefits in the process. This is what the lighting version of the talk is going to cover as much as possible in the 10 minute slot!
The full-fat version will be delivered at local WordPress meet-ups and should be 25-30 minutes long. It’ll contain the same content as the lightning talk, but will then go deeper to actually run through the steps you need to get this working locally using the popular IDEs Sublime Text and Atom Editor on OSX. Maybe some Windows love too. Maybe.
Ultimately the goal of the talk is to convince you to make the change to your workflow, as I’m a better WordPress developer as a result. I strongly recommend it to anyone who builds WordPress themes or plugins for a living: especially if you work in a team.
I’m also excited to confirm that I’ll be delivering the full-fat version of the talk at WordPress Sheffield on March 8th and WordPress North East on May 18th after chatting with messirs Kimb Jones and Steven Jones (no relation!) at A Day of REST last week. Hoping to confirm one or two other local gigs in the coming weeks.
This week marked the end of support for legacy versions of Microsoft’s Internet Explorer, after it was announced that support for all but the most recent version (IE11) would be withdrawn from January 12th onwards. A patch was released on this date that will regularly nag users of these older browsers, asking them to upgrade.
Every single day since the beginning of January I’ve seen dozens of developers folk praising (and rightly so) this move by Microsoft. It’s a positive step in the right direction, no question.
It’s a sign that things are starting to change, and that one day, one day we’ll be able to liberate our front-end workflow and resulting code of all the various poly-fills, workarounds and practices that help make the websites and products we build look respectable in browsers like IE7/8/9 as well as IE10 to a much lesser degree. What it doesn’t mean is that we can down tools and forget about them.
Let the numbers guide you
I did a search for tweets on the topic and this one raised the exact question we should be asking ourselves at this time:
It’s good news for front-end devs that MS announced end-of-support for IE<11, but when will that affect our actual support requirements?
When will our support requirements change? What should be driving this decision?
The problem is, there a lot of developers out there that are heralding the end of support for legacy versions of IE as the end of a lot of their woes: as if a Magical Front-end Unicorn has swooped in and transformed the landscape overnight. ***
In the long term the landscape will be different, but right now we (both site owners and developers alike) need to be looking not only at the wider trends that are widely reported throughout the year, but – as James alludes to in the above tweet – the actual data for the sites we own or are building for our clients to ensure that we’re not delivering a poor experience for these users.
Data published by leading authorities on browser trends (such as W3Counter, Browser Stats, StatCountern etc) and articles such as Sitepoint’s 2016 end of year review all confirm that Internet Explorer versions 6, 7, 8 and 9 still have a collective market share of approximately 3.5 – 5% of the desktop browser market. IE10 has a larger share, however this makes sense given that it’s the most recent of the browsers that are no longer supported.
Granted, 3.5 – 5% is a small percentage, but a small percentage of a whopping great number of users. These older versions of IE are still being used by millions of people, so we need to be making informed decisions based on the available data.
A note on the market share
Back on January 6th I posted something on Twitter about this which I thought summed up one of the big reasons why older IE browsers are still hanging onto this market share. Heather Burns fired back an interesting reply stating that she knew of an NHS website that still has ~25% of its users using a legacy IE browser; a perfect example of why the decision needs to be made based on the available data that shows exactly how users are accessing the site(s):
Even if we, say, knock 10% off that figure to account for IE10, that’s still 15% of users that are accessing these sites via what many developers would consider to be a true legacy web browser.
The NHS is a great example of an organisation in one of the sectors I referenced in my earlier tweet that won’t be upgrading all users to IE11 overnight. Especially given the economic and bureaucratic issues they face when it comes to IT projects.
That patch I mentioned at the top of the post? It can be disabled by “enterprise” users: meaning any large organisation that has centralised control of software installed across a significant number of machines. There are hundreds of thousands (if not millions) of these organisations across the world accounting for many, many millions of users.
Make sure the pain is paid for
I, like many other web developers have become accustomed to catering for these older versions of Internet Explorer over the years. At both my former employer and at Make Do I’ve spent countless hours baking IE 7/8/9/10 support into boiler-plates that I’ve built to facilitate speedy and (relatively) hassle-free development.
As web developers we all know the pain that work to support these older browsers can cause. I’ve launched into expletive ridden, vitriolic rants about this work on more than one occasion, which is something of an understatement. We’ve all been that guy/girl on the edge, the computer programmer equivalent of Michael Douglas’ character holding the shotgun in Falling Down.
Granted, poly-fills have eased this pain a little, but it’s still painful and time consuming. Oh well, at least the client is paying for this support. Right? Right?!
Regardless of whether you’re working for an agency or as a freelancer, you should really be factoring legacy browser support into your quotes/proposals. If the client needs to support these older browsers then you need to be having a conversation about adding the required number of days at your usual day rate. Period.
Note: Don’t get me wrong, I’m still advocating that we look after these users, we just have to ensure that we as developers aren’t doing this for free.
If you or the agency you work for aren’t doing this, or you’re just throwing legacy browser support in as “part of the package” then you’re missing an opportunity to both increase your revenue and help contribute to the decline of the market share these browsers have.
Mark Wilkinson made an excellent point in response to a tweet of mine:
@davetgreen we must as developers charge for legacy support otherwise they will never go away
Quite right too. The web design/development community can help knock a few decimal points off those market share figures by making it clear that we won’t continue to offer support for free.
The increased cost of carrying out this work will (to a degree at least) lead to a decrease in support for these browsers when new websites and online products/services are launched. The result is that users of these older browsers will end up wanting the better, richer and more functional experience that comes with an upgrade and therefore a modern browser.
Furthermore, many frameworks,libraries and other resources that we include in our workflows are going to drop support in the coming weeks and months: some already have such as ReactJS dropping support for IE8 on the day support was withdrawn. This ultimately makes the task of providing support for older browsers using these kind of technologies more difficult as they continue to evolve, which is detrimental to the overall user experience.
Note: Naturally, progressive enhancement ensures we can still provide a usable, functional experience, even if that experience is considerably more “basic” than the “full fat” version.
Increased development costs combined with poorer user experiences should hopefully drive more organisations (directly) and users (indirectly) toward upgrading to the most recent version of Internet Explorer or indeed, other browsers like Firefox, Chrome, Safari or Opera.
The pace of decline in market share for these older versions of IE is going to speed up as a result of this patch and all the public relations surrounding the withdrawal of support. However, for all we know it could be another 12-18 months before it’s low enough to truly justify downing tools and abandoning practices. That said, I sincerely hope that I’m wrong and it drops off quickly!
*** The Magical Front-end Unicorn (MFU) has this power at its disposal, but chooses not to wield it. It’s the MFU Gotham deserves, but not the one it’s going to get right now.