Why the web isn’t perfect
This is a guest post by Toby Osbourn, freelance developer and interim CTO for hire.
The majority of issues making our websites a poor substitute for what they could be boil down to communication between and within teams.
Excluding some new features of the web coming out (AMP, CSS Grid, updates to frameworks) the majority of the things we are building have been about for a very long time. This should, in theory at least, mean there should be no excuses for certain elements not being including in a web project.
Examples of this would include;
- Bloated CSS that hasn’t been minified or loaded in a way that makes things easy for the browser.
- Markup written in a way that allows for keyboard only navigation.
- A site structure and navigation that makes no sense to humans or machines.
- Pages that stand a fair chance of getting printed looking terrible when printed.
I could write a book on the stupid stuff we encounter on the web daily that have solutions that are almost trivial to implement. I picked those four examples in particular because solutions have been in place for these problems for many years and there are very obvious use-cases for them coupled with crystal clear guidance available for free online.
Developers are lazy
I also picked those four example above because on a small to medium sized team it would be hard to argue that the implementation of those examples would fall on developers.
I wouldn’t blame you then for deciding that the developers who don’t implement these things are lazy.
There is a joke that you want to hire lazy developers, because a lazy person will automate what can be automated and will find any excuse possible to make the computer do their work for them. We aren’t talking about that kind of lazy, we’re talking about slobbish. Of course there are some of these bad-lazy people about, this article isn’t for them. You should fire those people and work with professionals.
I’ve written this article because I don’t believe developers are lazy, I think in general they mean well but because things don’t get communicated and because there are too many assumptions in the work being allocated to people that things get missed.
So many assumptions
When I talk about assumptions what I mean is something like the following scenario (and believe me, I’ve seen this play out hundreds of times);
- Someone from the marketing team asks the development team to create a new contact us page.
- The specification is that it has to have an address, a phone number, and a contact form going to `sales@whatever.com`.
- Work happens and the contact page is uploaded onto a staging environment.
- Marketing take a look, there is some back and forth on the design or what information we want to collect on the form.
- It gets signed off and goes live.
If you’ve worked for a company on a marketing or development team you will related to this series of events more or less.
Lets talk about some of the assumptions that were never communicated in this body of work. This will be non-exhaustive but will hopefully give you a good idea.
First some knowledge that marketing should have shared with development;
- This marketing page is the first and only page that will have the company’s address on it. So we should use appropriate markup so search engines can display our information correctly.
- We do business in countries that use phone numbers way more than they use email addresses. Requiring an email address may be turning away important sales leads.
- This will be a really useful success metric for some of our campaigns, so we should track interactions with the form.
Now some of the assumptions the development team made and should have shared with marketing;
- That whilst up on staging the marketers would view the source of the webpage and make sure they are happy with the technical SEO put in place.
- That there are 3 systems already in place for storing information on people interacting with our system and this would be a great opportunity to tie the contact form into them.
- That when sharing their opinions on data that needs captured, the marketers knew that this could negatively impact conversion rates of the form being sent.
- That you could actually make the contact email go to several addresses if marketing wanted.
If you think I’m being cynical, these are all taken from real life exchanges when working out why something wasn’t build a certain way or why something didn’t perform the way we assumed it would.
What should good developers be doing?
Most of my work these days involves working with developers and managers to help shape their teams and see what they could be working on.
Aside from that I’ve been a developer my entire professional life (and a lot of my non-professional life). So if you are a developer and you are reading this, I’m not just some idiot who has pulled the following advise out of thin air.
`([-!#-‘*+/-9=?A-Z^-~]+(.[-!#-‘*+/-9=?A-Z^-~]+)*|”([]!#-[^-~ t]|(\[t -~]))+”)@([0-9A-Za-z]([0-9A-Za-z-]{0,61}[0-9A-Za-z])?(.[0-9A-Za-z]([0-9A-Za-z-]{0,61}[0-9A-Za-z])?)*|[((25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])(.(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])){3}|IPv6:((((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){6}|::((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){5}|[0-9A-Fa-f]{0,4}::((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){4}|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):)?(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){3}|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){0,2}(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){2}|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){0,3}(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){0,4}(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::)((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3})|(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])(.(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])){3})|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){0,5}(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3})|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){0,6}(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::)|(?!IPv6:)[0-9A-Za-z-]*[0-9A-Za-z]:[!-Z^-~]+)])`
The code sample above is one suggested regex for testing an email address against the most common RFCs related to email. It has nothing to do with this article but I want to now be speaking to the developers in the audience. That mess would make anyone’s eyes glaze over for a second or two.
The four things I’m going to list out are important, getting some HTML to appear in the browser and having that HTML render something that looks ok on your screen just doesn’t cut it anymore. To be honest it never did.
Until we take the business of making websites seriously we will always be a second-rate engineering discipline and will continually be stifling our own progress. Lets set high bars for ourselves so we can push the web forward.
1. Accessibility
Unless there is a specific team dedicated to accessibility in your organisation (that is incredibly rare) then it is the duty of any front-end developer to make sure the website they are delivering can be used by as many humans as possible.
Apart from the clear fact that it is the right thing to do it also increases usable traffic to the website and offers competitive advantages.
Getting into the technical details of what should be considered “accessibility work” is out of the scope of this article, but some of the things you want to be looking for are;
- Is markup communicative of intent
- Does your site assume certain types of input or is it agnostic to how someone chooses to view the site?
- Do people need to think a lot and retain a lot of information to find your site useful?
2. Findability
This is really technical SEO, but every other title was able to end in “ability” so here we are.
Again, unless you have a dedicated team of people who you pass stuff off to in order to do things like technical SEO before something goes live then this is your job.
Technical SEO is all about making your website easy to read for a computer, which normally has additional benefits for the humans reading your site. So don’t think of this as a dirty marketing task to please Google.
If you’re interested in this topic I have written what I think every web developer needs to know about SEO.
Here are some things you could be looking for;
- Is my page structure and information hierarchy sound?
- If I’ve had to use redirects, are they they correct type and have I made the chain as short as possible?
- Does the page load quickly?
- Have I went out of my way to make this page unfriendly to robots? (by explicitly blocking them, for example).
3. Printability
This is a fairly niche one, and I’m positive this won’t be a job role where you work.
People still print the web, and for more reasons than you can imagine.
I won’t go into too much detail about what you need to do technically here, for one reason because I’m mid-way through writing a book on print CSS, but here are the main things;
- Work out the likelihood that a page will need to be printed (your video tutorial, maybe not. You’re recipe, almost certainly).
- Work out what elements you will never want to appear in print (the menu bar, advertising)
- Test that the correct information is printed and your branding meets any guidelines laid out by your design department.
4. Maintainability
Maintainability is all about how much work will be involved should something need to change in the future.
I am a strong believer in YAGNI (You Ain’t Gonna Need It) so I don’t think over-engineering solutions is ever a good idea, but here are some things that you should consider the next time you write something for someone.
- Would a computer be better at making this change? (Changing the date on your footer on 1st Jan is an extreme example of this)
- Would it make marketings/editorials/someones life easier if they didn’t need to come to development for this
- Have I wrote something in such a way that I would need to explain it to the next developer? If so write a document in your team wiki/slack/whatever.
General Tips for Better Communication
I’ve spoken in specifics for a lot of this article. Here are some good general tips that can be applied to any situation when working in or between teams. Applying these is relatively straight forward and can help keep the quality of communication high.
- Be explicit in what you’re asking for. It is possible to give too much information to someone, but I’m willing to bet you are nowhere close to giving too much information in your requests.
- Lists are always a good idea. If there is some set of criteria your project needs to hit make sure a list of that criteria is available for everyone to see, it can be checked off as things are made and 6 months down the line when new stuff comes along you can reference the list to make sure you don’t break anything you already had in.
- Make sure you know what people want. Explain back to the person you are doing a task for what you think they want and the parameters of it.
- Make informed decisions. One thing this article doesn’t touch on is the 101 reasons other than poor communication that means things don’t make it into production. Just be sure that leaving something out is an informed decision and not just because it was forgotten about. Being explicit here wouldn’t hurt “We are going live without canonical tags” is a fine thing to have written down somewhere.
- Spot when things went wrong. Don’t assume that something that went wrong in the last project will magically fix itself in the next one. Act and improve.
This isn’t my job
You may be reading this and thinking “it isn’t my job to make sure developers do the right thing” or “it isn’t my job to make sure I understand what a marketer wants”
If that is how you feel please let me know in the comments so I can know to never try and work with you on anything.
It may not ultimately be your job to fix a broken process, but it is certainly your job to be involved in fixing it, be that by explaining the problem to someone who can fix it or working around the problem.
Communication is a hard problem, but if we all work together at being a bit better at it then our projects would run a lot more smoothly and more quality work would see the light of day.
