DEV Community: Adam McKenna

Why developers need to challenge product and design

Adam McKenna — Tue, 11 Jan 2022 10:57:52 +0000

Rare is the developer who hasn’t had to “throw away” their code. For many, discarding months of hard work has been a common, recurring theme of their career.

This is how it happens: someone in management thinks they’ve identified a problem. They rally a bunch of people together — product owners and maybe a few designers — and collaboratively hash out a solution to the apparent problem.

Once all the decisions are made, and the solution is ready, a development team is assembled and they’re handed the product requirements. “Build this,” they’re told.

This is where the two different types of developers reveal themselves.

Consider the first type of developer: the complacent.

When presented with a set of requirements, the complacent developer gets straight to work without any fuss. They’ll ask questions to fully understand the requirements and debate the best technical architecture to implement them. But once that’s worked out, they’ll knuckle down for a while, emerging only once they’ve completed a system that not only matches the given requirements, but does so with clean, fully-tested and robust code.

Sounds perfect, right? There’s just one problem. Those requirements that they’ve meticulously implemented often fail to actually match the user’s needs.

Though the implementation may have been executed with the utmost proficiency, the developer may as well have been writing code for eskimos. That is to say, it won’t see the light of day because the fundamental requirements failed to cater to the actual user needs.

Thus, we begin to see the value of the second type of developer: the challenger.

Like the former, the challenger asks questions to come to an understanding of the requirements. But their line of inquiry doesn’t stop there.

Once they understand what’s being asked of them, they challenge it: Why are we doing this? How does this benefit the user? Where did this decision come from?

The challenger refuses to take on work that they know doesn’t fit the user needs, and they’ll more often than not take it upon themselves to propose alternative solutions. Even if they don’t propose a solution, the simple act of challenging a decision can spur the product team to think about aspects of their solution that they hadn’t previously considered.

In other words, the challenger doesn’t need to be a “designer” in order to improve the design. As with recovering from addiction, an awareness of a design flaw is the first step in creating a product that works for the user. More often than not, these flaws are easily rectified. But, a design flaw can’t be resolved if the designer doesn’t realise it exists.

It’s also not always the case that the “complacent” developer isn’t aware of the potential flaws in the solution they’re building. Often, they are. But, for whatever reason, they refuse to speak up, and may even moan among fellow developers about the oh-so-obvious flaws in the product that they’re building.

This is often because the design and product teams have historically refused to give the development team a platform to propose feedback or changes. Routinely ignoring a developer’s suggestions is possibly the most expedient route to converting a keen challenger into a complacent developer.

So, while to an extent it is up to the developer as to whether they challenge a solution or fall complacent, the rest of the team need to make sure that the developer has a platform to speak, and will have their voices heard if they utilise that platform.

As Donald A. Norman, director of The Design Lab at University of California, explains: “all things artificial are designed.” In that sense, anyone involved in building anything is a designer to some extent. Design isn’t just about building user interfaces or crafting interactions, it’s about creating an experience. It’s about understanding that the user is a human, and understanding all the nuances about being a human.

In that vein, anyone with a shred of empathy or even a vague understanding of human emotions will have something valuable to contribute to the design of any product.

By adhering strictly to job titles and shoe-horning people into silos — in other words, artificially prohibiting a developer from design — you only serve to cut your team off from valuable insight and resource.

Everyone wants to build something good. Nobody wants to finish the day at work acutely aware that all their efforts have contributed to a product that ultimately won’t see the light of day. But, no-one (well, most people, at least) wants to sit all day without anything to do.

That raises another thing to consider: wasted resource. It’s a simple fact of software development that there isn’t always development work to do. Sometimes, the team need to take a step back from development and reconsider the design, do more research, or consider the next steps on the roadmap.

But, in these hiatuses, how should developers utilise their time?

In my experience, developers are doled out busy-work or told to develop future features that haven’t yet been fully tested with users — that is to say, the requirements will change. When those requirements do invariably change, the development work is then re-done.

Yes, this approach keeps developers busy. But, is that really the best use of their time? I don’t think so. This problem is especially prevalent in government, when that time is paid for by the tax-payer.

A better approach? Recognise that even though their job title may read “Software Engineer,” “Frontend Developer” or “Dev Ops Engineer,” they have value as designers.

If you’re involved in product, include the development team in design. If you’re a developer, make sure your voice is heard. If there’s a flaw in your product’s design, let the team know. It doesn’t matter what your job title is.

A final word of advice to the “challengers” out there: while I advocate challenging the work of designers and product owners on your team, you must also respect that, just like your users, your colleagues are human. They also want to do the best work they can.

“When we are wrong, we may admit it to ourselves,” explains Dale Carnegie, author of How to Win Friends and Influence People. “And if we are handled gently and tactfully, we may admit it to others and even take pride in our frankness and broadmindedness. But not if someone else is trying to ram the unpalatable fact down our oesophagus.”

Fast as a Veyron: Achieving 100/100 on Google PageSpeed Insights and beyond

Adam McKenna — Sun, 23 Sep 2018 16:27:05 +0000

Article originally posted here.

During the years in my role as a web developer, I have built a variety of different websites and web applications, taking performance into consideration more and more with each project. I have built a number of supposedly super-fast applications, only to discover that Google didn't share my perceived optimism.

Upon typing the website domain address into the Google PageSpeed Insights (GPI) search bar, I would begin to bite my nails as Google began the heart wrenching analysis of said web application. Fear would turn to disappointment as I read the 'Needs Work' amber performance ratings of the desktop platform. Often, the disappointment worsened upon the discovery of the unspeakable 'Poor'red performance ratings that the mobile platform was receiving. Why were these seemingly fast websites performing so poorly in Google's eyes?

The reasons why I was unable to achieve 'Good' green ratings varied from project-to-project. Common examples include a lack of control over server-side performance; lack of time or budget to make the (seemingly) sizable performance improvements required or, in the early days of my career, simply a lack of understanding or inability to digest the sometimes-confusing GPI documentation advising how to configure and build a website to align with the tool's metrics.

Over time, I simply accepted that my websites would never be good enough for Google. "Anyway, the tool isn't a valid measurement of a website's performance," I concluded.

While my latter conclusion may hold some truth – there are certainly other web performance considerations outside the scope of PageSpeed Insights; for example, the tool fails measure website loading time (as demonstrated by Lucy Beer) and is even less accurate if you begin to consider user experience as a performance metric (but, this is a discussion for another time!) – I was wrong on the former conclusion.

Having delved deeper and deeper into web performance, attempting to ensure that every website I build is faster than the last, and embracing a variety of web performance techniques – both new and old – it was time to show Google PageSpeed Insights that my websites could be good enough. The opportunity arose in the form of a long-overdue redesign and rebuild of personal website.

With no constraints – i.e. in terms of budget, time or technology – I was able to embrace everything I have learnt and put performance at the heart of the rebuild. And, as the story goes, I was finally able to attain the dream: 100/100 score on PageSpeed Insights (and 'A' scores via WebPagetest, an arguably more comprehensive tool for measuring website performance and optimisation – which also measures loading time).

In this article, I will discuss my experiences in the pursuit and attainment of high website performance, discussing the abstract concepts and design decisions that helped improve the performance of my website, as well as walking through the various metrics that the Google PageSpeed Insights test is comprised of with practical examples.

Concepts and Design

Simple UI design

Though I have dabbled, I am certainly not a user interface designer. Yet, it seems almost common sense: the more content that is displayed on a website, the more content the browser is required to render and load. More content = higher load times.

In my experience, I have found a lot of web pages – particularly website home pages – to be cluttered with any amounts of seemingly arbitrary content, trying to cram in as much as the display dimensions will allow in an effort to promote every nuance of their service.

I have no doubt that some websites and web applications simply need to be complex, but does not mean that my laptop screen needs to be overflowing with a sea of hero banners, videos, animations and so on? I'm not so sure. As the saying goes, less is more.

So, I asked myself "what is the purpose of my website?" I had one objective: I wanted a website to post and display my articles. It was decided, then, that the website will serve to that end and no other.

I adopted a mobile-first design approach to design (and build) the website; starting with a simple navigation (a text-based logo and a handful of links); a very simple footer that promotes my social media accounts and, between the header and footer elements, a grid layout of articles. Nothing more. (Though I was feeling a tad rebellious and added images to the articles within the grid layout).

I knew – and intended that – my design would not require any videos, heavy-duty hero banner images or complex JavaScript or CSS animations. Just good old HTML, a few thumbnail images and a sprinkle of CSS and JavaScript. It's amazing what you can achieve with very little code these days.

Progressive Web App

I knew from the offset that I wanted to build the website as Progressive Web App (PWA). If you're unfamiliar with the concept of a PWA, I implore you to watch Nicole Saidy's talk: Designing Great Progressive Web Apps from .concat() 2018.

Long story short, though, a PWA is a regular website that has the added benefit of native mobile app-like interactions, including push notifications and offline support. Among the ever-growing list of reasons to build my website as a PWA was the significant web performance increases, achieved through the implementation of caching via a JavaScript Service Worker.

The nitty-gritty implementation details are out-of-the-scope of this article, but if you intend on building your website as a Progressive Web App, Google offer great documentation on the implementation of offline support and caching via a Service Worker.

The Application Shell Model

There are a number of ways in which a Progressive Web App can be implemented and its functionality leveraged to provide a great user experience and high web performance. The architectural approach that I found most appealing was the Application Shell Model.

The approach entails delivering a cacheable "shell" of the website user interface to the user – i.e. the website layout without content – and subsequently loading the content as it becomes available (we'll touch on some of the implementation details soon).

The PageSpeed Insight Metrics

Avoid landing page redirects

The first metric on the list is one of the easiest to avoid: landing page redirects. A landing page redirect is the process of a webpage redirecting the user to an alternative URL when they attempt to navigate to a given webpage URL. For example, if the user attempts to navigate to example.com, but is then redirected to m.example.com.

There is a reason this metric is still evaluated as part of the GPI. The implementation of landing page redirects has a handful of common and practical use cases.

The most common use of landing page redirects is the redirection of users who navigate to a URL prefaced with 'www.' to the 'non-www' version of the website, or vice versa. For example:

adammckenna.co.uk redirected to www.adammckenna.co.uk
www.adammckenna.co.uk redirected to adammckenna.co.uk

While this is a nice touch – and supposedly has positive connotations for SEO – it will slightly impede the website performance for those unfortunate enough to browse to the version of the website that is being redirected from. But, while I personally avoided this redirect in my website, there is certainly a valid use case for it – especially if SEO is a major concern.

Another common use of redirects is the (now-medieval) practise of redirecting mobile users to an entirely separate website built for mobile users, which is typically hosted on an 'm' subdomain. For example:

adammckenna.co.uk redirected to m.adammckenna.co.uk

Before the mainstream adoption of responsive web design, the practise of redirecting mobile users to a separate website was commonplace. Nowadays, though, it is frowned upon by the entire web community and everyone unfortunate enough to have experienced a redirect.

Not only does this practise cause performance issues in terms of redirects, it has a plethora of negative implications (see also). The verdict is clear: the 'm' subdomain is a relic of the past.

As such, I built my personal website as a responsive website, following the principles – well, the ones that are still relevant – established in Ethan Marcotte's ground-breaking book, Responsive Web Design. No 'm' subdomain redirect.

There are a number of other use-cases for redirects – for example, you simply cannot avoid a redirect if the website has several domain addresses for the same website or if the website is available in multiple languages – but, unless absolutely unavoidable, I would suggest leaving the redirects on the top-level shelf.

Eliminate render-blocking JavaScript and CSS in above-the-fold content

When a browser requests a webpage, it begins to build up a DOM tree. Before the page can be rendered, the DOM tree must be fully built. Seems simple enough.

However, as part of the DOM building process, when the browser parser encounters an external <script> or stylesheet resource, it halts parsing the page until the relevant resource has been executed.

Further still, many websites rely on external resources hosted elsewhere – e.g. 3rd party JavaScript packages, Google Fonts or content delivery network (CDN) resources – and when the parser encounters these external resources, it must also wait for the file to download before it can be executed.

Often, scripts and stylesheets grow to become huge documents, leading to notable bottlenecks during the page rendering process. Combined with a lax use of Google Fonts and other external resources, render-blocking can start to take a large toll on website performance.

In my case, I was requesting a large stylesheet and moderately-sized scripts file – albeit both were minified (a process we will touch on soon) – alongside an external Google Font with four weights and an external Google Analytics script. Though my website's use of resources was light in contrast to many popular websites, even these resources caused substantial loading latency.

I needed a solution. I needed to load my resources asynchronously with the page rendering – but how?

Back yonder, this may have been a monumental task. Thankfully, though, we live in a decade wherein the HTML spec is being developer faster than ever. With each new release comes easier, more efficient ways to achieve complex functionality.

One such addition to the HTML spec is the new ability to preload content via the 'preload' value for the <link> element's rel attribute.

The new preload value has a number of benefits over its precursors, but ultimately it lets the browser load resources – those pesky stylesheets, scripts and external files – without blocking the rendering the web page's DOM tree. We can now natively load our resources asynchronously. What a time to be alive!

The syntax is amazingly simple, too (the following is an example from MDN):

<head>
  <meta charset="utf-8">
  <title>JS and CSS preload example</title>

  <link rel="preload" href="style.css" as="style">
  <link rel="preload" href="main.js" as="script">

  <link rel="stylesheet" href="style.css">
</head>

<body>
  <h1>bouncing balls</h1>
  <canvas></canvas>

  <script src="main.js"></script>
</body>

The <link rel="stylesheet"> and <script> tags are included as standard. But, before that, some <link rel="preload' as="x" href="y"> tags are also included for each resource that is being included. In the above example, we're loading in a style.css stylesheet and a main.js script, so we need a separate <link rel="preload"> for each resource.

If you're thinking this seems too good to be true then, well… you'd be a little bit right. There is one teeny, tiny problem: browser support.

As the time of writing, the new preload value is only fully supported in Chrome, Safari and a handful of mobile browsers. That means no Firefox or Internet Explorer (surprise, surprise) support, and even MS Edge only offers partial support.

Of course, since we have the regular references to the style and script resources, as well as the new rel="preload" meta tags, the resources will load regardless. We just won't see the benefit of preload – and this just isn't great news.

This is where loadCSS comes in.

loadCSS is a polyfill for browsers that do not yet support rel=preload, and can be implemented with relative ease.

Firstly, to use loadCSS, we need to include the loadCSS preload polyfill script somewhere in website:

<script>
/*! loadCSS rel=preload polyfill. [c]2017 Filament Group, Inc. MIT License */
(function(){ ... }());
</script>

Next, we need to include a slightly amended <link rel=”…”> tag. When leveraging loadCSS, it is recommended that a single <link rel=”preload”> tag is used, instead of using both rel=”preload” and rel=”style” tags as per our previous example, because otherwise the browser will only fetch the stylesheet and will not apply it to the page.

We can convert the rel=preload value to rel=stylesheet once the resource has loaded by leveraging the <link> element's native onload event. This also has the added benefit of reducing the amount of markup we actually need to write.

<!-— our local stylesheet. -->
<link rel="preload" href="path/to/style.css" as="style" onload=" this.rel='stylesheet'">

It is also recommended that the value of the onload attribute is changed to null within the onload handler (onload-ception) because some browsers will re-call the handler when the rel attribute's value is switched from preload to style.

<!—- our local stylesheet. -->
<link rel="preload" href="path/to/style.css" as="style" onload="this.onload=null; this.rel='stylesheet'">

<!—- we can also apply the same logic to external stylesheets, such as Google Fonts -->
<link rel="preload" href="https://fonts.googleapis.com/css?family=Muli:300,300i,400,400i,600" as="style" onload="this.onload=null; this.rel='stylesheet'">

Of course, we also need to think about those users who do not have JavaScript enabled and, since the onload handler requires JavaScript, we need a fallback. We can easily provide such a fallback via the <noscript> tag.

<!-— for users with JavaScript disabled -->
<noscript>
    <link rel="stylesheet" href="path/to/style.css">
    <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Muli:300,400,400i,600">
</noscript>

With that, loadCSS is ready to do what it does best: load our CSS. Here's our complete code:

<link rel="preload" href="path/to/style.css" as="style" onload="this.onload=null; this.rel='stylesheet'">
<link rel="preload" href="https://fonts.googleapis.com/css?family=Muli:300,300i,400,400i,600" as="style" onload="this.onload=null; this.rel='stylesheet'">

<noscript>
    <link rel="stylesheet" href="path/to/style.css">
    <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Muli:300,400,400i,600">
</noscript> 

<script>
/*! loadCSS rel=preload polyfill. [c]2017 Filament Group, Inc. MIT License */
(function(){ ... }());
</script>

With our small snippet of code, we are able to asynchronously load our CSS across a plethora of browsers, regardless of whether the browser supports rel="preload", and we can still deliver our resources to users who do not have JavaScript enabled.

Though confident that the stylesheets and scripts were no longer causing any trouble blocking the page rendering, I was not quite done with the above-the-fold issue.

My stylesheet was still a behemoth of a file, and there was no priority given to the styles that pertained to the above-the-fold elements of my webpage. For that, another solution was necessary. It's time to explore the Application Shell Model Architecture.

Prioritise visible content (via the Application Shell Model Architecture)

Instead of loading all of the website styles in a single request – potentially wasting valuable loading time rendering CSS that isn't even visible to the user initially, e.g. the footer, content from other pages, etc. – we can prioritise the styles for above-the-fold elements – i.e. any elements that will be visible as the website initially loads. In my case, my above-the-fold elements consisted of the website header, navigation and the 'article grid'.

This is where the Application Shell Model comes in. The Application Shell Model is one of several solutions to ensure that the delivery of visible content is prioritised to the user. As outlined earlier in the Application Shell Model section, the approach focuses on the serving the layout styles to the user first, then loading in the content styles secondarily.

We can take this a step further by ensuring that not only the layout styles are included in the prioritised styles, but we can focus on only delivering the styles for the layout that is above-the-fold. Doing so will ensure our prioritised styles are as minimal as possible, delivering the shell of the website to the user as fast as possible.

Enough theory. How do we actually implement our Application Shell Model?

The implementation was easier than you might expect. I simply needed to separate the styles that pertained to the above-the-fold elements, by removing them from the website's main stylesheet and embedding them into the <head> of the website. Those prioritised styles will be rendered straight away, while any styles retained in the main stylesheet, relating to content and elements below-the-fold, can afford to be rendered later.

It all seemed simple enough in theory. Then I remembered that I was using Sass; Liquid (a templating engine); build tools and task runners. Things got messy rather quickly.

I needed to embed specific styles from my Sass which, at this point, was being compiled into a single stylesheet. Thankfully, though, I had structured the website Sass in alignment with the Atomic Design methodology, which ensured that my styles were finely de-coupled.

To implement the separation of prioritised and non-prioritised styles, I needed to compile two stylesheets – one that would provide the CSS that would be embed in the <head> of the website, and another with the content and below-the-fold styles that would be loaded in afterwards via <link rel="stylesheet">.

So, simply enough, a second Sass file was created – creatively called 'inline.scss', alongside the pre-existing 'style.scss' master stylesheet. The file imports from the style.scss that pertained to the above-the-fold elements were moved to the 'inline' stylesheet to be embedded in the <head>.

A small problem: I had a handful of Sass 'settings' files that consisted of variables (for colours, breakpoints, etc.) and mixins. I quickly realised that both of the stylesheets would still require access to all of these 'settings' files, or else I would have to start hardcoding values.

Therefore, a third file was required – which I named 'master.scss' – which imports the Sass resources that were mutually required between the 'inline' and 'style' Sass files – i.e. the settings files – and subsequently imported the 'master' Sass resource into both stylesheets.

Great. Now that the styles were separated, I needed to figure out how I could serve from the <head> of the website.

The first obvious klaxon-horn-inducing solution I thought of was to just manually copy the styles into the head of the website. How elegant. While yes, it would functionally achieve the desired outcome, it would come with a myriad of implications.

This approach would be a nightmare to maintain since any changes in the relevant Sass files would have to be manually coped into the head. Hypothetically, even if it wasn't a maintainability nightmare, duplicate code would have to be commit to the Git repo, since the styles that would be embedded in the <head> would already exist in the respective Sass files. This solution would never be feasible.

The second solution devised was to leverage the project's task runner – which, in this case, was Gulp (though Grunt would have been ample for the task too) – to inject the content of the complied inline CSS file into the <head> during the build process. This seemed more realistic, and the implementation was pretty straight forward.

First, in the <head> of the website I included an arbitrary <link> tag that is replaced with the embedded styles during the Gulp build process:

<link href="inline.css">

I then created a Gulp task to replace the arbitrary <link> tag with the styles. The Gulp task leverages the file-system and gulp-replace npm packages. Gulp, and the relevant packages, can be installed via the CLI with the following command:

npm i gulp gulp-replace fs --save-dev

Let's have a look at the task:

// instantiate the relevant packages
const gulp = require('gulp')
const fs = require('fs')
const replace = require('gulp-replace')

// The Gulp task “generates” the header of the website; in my case it finds the 
// “src” header file (located in "_includes/header.html”), subsequently finds the
// “<link href="inline.css">” tag and replaces it with the contents of the 
// inline.css stylesheet. The generated header is then stored 
// in the "_includes/build" directory
gulp.task('generate-header', () => {
    return gulp.src("_includes/header.html")
        .pipe(replace(/<link href="inline.css"[^>]*>/, (s) => {
            let style = fs.readFileSync("build/css/inline.css", 'utf8')
            return '<style>\n' + style + '\n</style>'
        }))
        .pipe(gulp.dest("_includes/build"))
})

The CSS file to which the <link> tag href attribute refers to does not exist; the decision to use this tag was arbitrary. Any tag could have been used. For example, I could have instead included:

<meta id="embedded-styles">

Then in the Gulp task, the syntax replace(/<meta id="embedded-styles"[^>]\*>/ … could have been used instead of replace(/<link href="inline.css"[^>]\*>/ …. The outcome would have been the same: the tag being replaced with the content of my inline stylesheet.

And that's it! With that, the website's above-the-fold styles were embedded in the head, I included the generated header.html file in my .gitignore so there was no duplication in the Git repo and the entire process was automated. The remainder of my styles were retained in a separate style sheet that was being served asynchronously and no longer blocked the page from rendering.

In my experience, addressing the issues of render-blocking and above-the-fold prioritisation were certainly the most time-consuming and difficult aspects of the website performance optimisation process, but were certainly the most fruitful. If there is only one thing you take away from this article, make it these sections.

Enable compression

Okay! Now we have got the big guns out of the way, let's focus on some quick and easy wins, starting with compression.

In the context of PageSpeed Insights, compression refers to a nifty package called gzip which, despite the fact its website and logo look straight out of the 90s, is a very popular and commonly used package to increase website performance.

Gzip works on the server side, compressing website resources into a zipped format and serving them to the browser. In turn, the browser unzips the resources and presents them to the end user. These zipped resources typically have dramatically smaller file sizes, vastly reducing server download time.

For more information on gzip's technical details, and the interaction between the server and client browser, check out both this article and this article.

So, surely there are no doubts about the incredible benefit of gzip. All that remains is the lingering question: how the hell do I get it working with my website?

Since gzip is a server-side technology, the implementation actually depends on what software your web server is running. Chances are, you're working with Apache, ngnix or IIS, so here's some guidance for each platform:

Leverage browser caching

Let's move onto browser caching.

Every resource – whether a stylesheet, script, image or something other resource – that is requested from a web server by the browser when loading a web page delays the processing and rendering of the webpage, as well as consuming more and more of the user's data allowance. The latter can be particularly devastating to mobile users with limited data or expensive data usage rates – remember: data costs are often much higher outside of Europe, the United States and other 'western' nations.

When you consider that many of the resources used throughout a website are shared across multiple web pages throughout the website, the idea of re-requesting each resource every time a new page is loaded is a waste of time (in terms of processing and rendering) and data (let's help our users save some money!).

Instead, wouldn't it be easier if the resources that have already been loaded, whether in the user's current session, or in a previous interaction with the website, could be simply just re-used? That's exactly what browser caching allows.

To enable browser caching, a caching policy needs to be defined to identify how long a given resource should be cached for. You can tell the browser, for example: "I want .jpg, .png and .svg images to be cached for one year; HTML and CSS resources to be cached for one month…" and so on. You could even set a caching policy for an individual resource, if necessary.

Just like compression, the browser caching policy is operated server-side, meaning the implementation is dependent upon the software your web server is running. Here's some guidance for the big three platforms:

Unfortunately, we're not done there. Though the above steps will accommodate for 99.9% of your website's resources, there is one caveat: third-party resources. The browser caching policy for resources loaded from external servers is handled by the server that provides the resource. Often, this isn't a problem, as most CDN providers recognise the benefit of caching policy.

There is one organisation that, in the most ironic of fashions, seems to not recognise the benefit of a good caching policy. One organisation that offer a package that is enormously popular on the web. That organisation is Google.

Google Analytics, the widely popular web analytics platform, is served by an external JavaScript resource that, when validated via the Google PageSpeed Insights, will prompt an error for a rubbish caching policy. Google are invalidating the use of their own resource.

While this may seem counterintuitive, there is method in the madness. The caching policy for this particular resource is so lax because Google want to ensure that users are always using the latest version of their script, even if the script has just been updated. They do not want an outdated version of analytics to be cached in a user's browser for, say, three months, especially if the outdated script no longer tracks the user due to breaking changes.

Even with that in mind, there is a solution: a package called ga-lite. The package serves the Google Analytics script via the jsdelivr.net CDN with a more "performance-friendly" caching policy. So, instead of including the Google Analytics script in the <head> of your website, you include the ga-lite script:

<script>
(function(e,t,n,i,s,a,c){e[n]=e[n]||function(){(e[n].q=e[n].q||[]).push(arguments)}
;a=t.createElement(i);c=t.getElementsByTagName(i)[0];a.async=true;a.src=s
;c.parentNode.insertBefore(a,c)
})(window,document,"galite","script","https://cdn.jsdelivr.net/npm/ga-lite@2/dist/ga-lite.min.js");

// Replace UA-XXXXXXXX-X' with your own Analytics tracking code
galite('create', 'UA-XXXXXXXX-X', 'auto');
galite('send', 'pageview');
</script>

Easy! Now, in complete honesty, you won't find any notable performance increases from the use of this package, but if you really want to achieve a 100/100 score via PageSpeed Insights and you also want to use Google Analytics, then this may be your best bet.

Reduce server response time

In the past, server response time was a consideration that was completely out of my control: the stakeholder for whom the website was being developed often dictated the server wherein the website would be hosted. More often than not, the clients would opt for cost-effective shared hosting solutions provided by the likes of 123 Reg, GoDaddy and 1&1.

These solutions are great for many people and certainly have a wide target audience: they offer cost-effective hosting solutions and require absolutely no server configuration. But, for people looking to get the absolute maximum out of their web server, they are limited: these organisations typically provide very few server customisation or configuration options and offer average-at-best performance.

I recently went down an alternative route: cloud hosting via Linode. Linode, much like the service's main competitor DigitalOcean, offer a vastly different experience to the aforementioned services. They strip away the customer-friendly pre-configured web servers and provide users with access to a web server (there are varying specifications available depending on requirements) wherein the user is required to install and configure everything: the OS, the web hosting stack (in my case, Debian 8 with a classic LAMP stack).

Though this alternative route is certainly more work than the former options, there is one crucial contextual benefit: a significantly increased server response time. Even the most basic package that Linode offers has a significantly reduced response time when compared to the average GoDaddy or 1&1 hosting packages; a reduced server response time means that the browser can receive resources from the web server faster and will spend less time waiting for an opportunity to begin rendering the web page.

Opting for Linode over the likes of GoDaddy or 1&1 was a major contributor towards achieving the 100/100 source via PageSpeed Insights. (And no, unfortunately I am not being paid by Linode to promote their service – it's just a great service).

Minify HTML, CSS and JavaScript

Right – no more server stuff, I promise. Let's get back to some trusty HTML, CSS and JavaScript. In the eliminating render-blocking and prioritising visible content sections of this article, we already explored how we can write and structure our client-side code to optimise performance, but there is a much quicker way we can take that optimisation even further – minification.

Minification is the process of reducing and compressing the contents of a resource (typically HTML, CSS and JavaScript) as much as possible, while still ensuring the resource still functions as originally intended.

The process parses the resource and removes code comments, spaces, formatting, unused code and reduces the length of variable names, among other things. The result is a resource left in an almost unreadable state. But, while a human cannot (easily) read a minified resource, the browser has absolutely no trouble reading the resource – in fact, it reads it much faster.

After all, those comments, spaces, formatting and descriptive variable names are only there for the sake of code readability. Once removed, the file size is dramatically reduced, meaning the time required to request the resource from the server is reduced, reducing the time necessary to render the relevant webpage.

How can we actually minify our HTML, CSS and JavaScript, though? I remember, when I first discovered minification, I had stored two separate files: the source file and the minified version of the source file. Every time I made a change to a resource, I would need to manually copy and paste my styles and scripts from the source file into an online minification tool, such as CSS Compressor or JSCompress then copy the minified results into the minified file… and what a chore it was.

In more recent years, I have been using Gulp to automatically generate a minified version of my stylesheets and scripts every time a change is made. Sure, I still have two files, but instead of having to do anything manually, I simply run Gulp, edit my styles and scripts, and let Gulp do the hard work. My HTML pages are, of course, always requesting the generated minified versions of the files, while I continue to work on the source versions.

Let's have a look at my Gulp task for minifying my CSS. Alongside Gulp, I am leveraging gulp-shorthand, which merges and reduces the length of certain CSS declarations, and gulp-cssnano, which minifies the file. Gulp, and the relevant packages, can be installed via the CLI with the following command:

npm i gulp gulp-shorthand gulp-cssnano --save-dev

Let's have a look at the task:

const gulp = require('gulp')
const shorthand = require('gulp-shorthand')
const cssnano = require('gulp-cssnano')

gulp.task('css', () => {
    return gulp.src('src/css/**/*.css')
        .pipe(shorthand())
        .pipe(cssnano())
        .pipe(gulp.dest('build/css'))
})

Gulp works great for minification (along with a million other things) but there is an even simpler way to achieve site-wide minification of your HTML, CSS and JavaScript – and it doesn't even require a single line of code.

Answer: Cloudflare.

Cloudflare is a free service (with premium options) that offers so much that I won't get into the details of their entire service. But, among their many functions, Cloudflare serves as a powerful content delivery network (CDN) that serves as a middleman between the web server and the browser.

A CDN is a collection of geographically distributed servers working in conjunction to deliver content to users faster. Unlike a typical web server, the CDN can deliver resources from a server in their vast network that is most geographically close to the end user, significantly reducing request times for users that may be far away from the website's web server.

In addition to serving as a CDN, Cloudflare also offers several general options to increase the 'speed' of the website it is serving. Though most of these options are only available to premium users, free users get access to 'Auto Minify' features – Cloudflare will automatically minify your HTML, CSS and JavaScript with the click of a checkbox. No manual work; no code and no build tools. It doesn't get better than that.

As mentioned, Cloudflare is free and lets users serve as many websites as desired. It also offers a plethora of other useful features, including SSL, security and caching. In other words, it is a no-brainer. (And again, no, unfortunately I am not being paid by Cloudflare to promote their services – it's just a great service).

Optimize images

Phew. Almost there. While I may not have saved best till last – I've certainly saved easiest till last: image optimisation. Broadly, this recommendation is simple: ensure that the images used throughout a website have the smallest file sizes possible.

There are a number of ways wherein this can be achieved, and the steps different depending on whether the image is a bitmap (.jpg, .png or .gif) or a vector (.svg) image.

I have already discussed the optimisation of .svg images in a separate article, so I will not go into too much detail here.

Let's explore some recommendations for bitmap image optimisation.

The first step to ensure a reduced file size is ensuring appropriate image dimensions. For example, if an image is going to be used as the background for a <div> element that has a width of 800px, there is absolutely no reason for that image to have a width of 1920px. Surely an image width of 800px would suffice?

There are caveats to this logic, of course. The responsive web is known for being, well… responsive. It is often the case that the container that the image is a background of has no pre-defined width, and can range from a width of 0px to a width of 4000px (okay, that might be a tad extreme, but you get the idea). With that in mind, I advocate the approach generally and advise that it is applied as appropriate.

Once the bitmap has appropriate dimensions (or doesn't, whatever), there are a number of routes we can take to optimise it even further.

The first approach is manual optimisation via compression tools. There are a number of desktop applications available for both Windows (FileOptimizer, for example) and MacOS (such as the very popular ImageOptim), as well as a plethora of online compression tools (popular examples include ImageCompressor for .jpg and .png images; SVGGOM for .svg images).

Assuming that your project has only a handful of images, the manual approach should be manageable. But, what happens when you're working with a project that contains thousands of images, or maybe even tens of thousands? Unless you're planning on losing a few weeks of your life, you're probably going to be looking for an automated solution.

Once again, our trusty task-running friend Gulp comes to save the day.

In my project, I was able to create two Gulp tasks – one for bitmaps, one for vectors – that would routinely inspect the project directory and, when an image of the respective format was added to the project, would automatically run the relevant task, compress the image and save it to a 'build' directory.

One last time, let's explore the Gulp task. The task uses two packages: gulp-imagemin for bitmap minification and gulp-svgmin for vector minification. Gulp, and the relevant packages, can be installed via the CLI with the following command:

npm i gulp gulp-imagemin gulp-svgmin --save-dev

Let's look at the code:

const gulp = require('gulp')
const imagemin = require('gulp-imagemin')
const svgmin = require('gulp-svgmin')

gulp.task('bitmap', () => {
    return gulp.src('src/img/**/*.{png,jpg,gif}')
        .pipe(imagemin({
            progressive: true
        }))
        .pipe(gulp.dest('build/img'))
}) 

gulp.task('vector', () => {
    return gulp.src('src/img/**/*.svg')
        .pipe(svgmin())
        .pipe(gulp.dest('build/img'))
})

Beautify. Now, instead of having to manually minify all of those tens of thousands of images, you can sit back, grab a coffee and let Gulp do the legwork. What a great friend Gulp is.

Conclusion

So – there you have it. I have explored a ton of stuff that Google's PageSpeed Insights evaluates when rating a website's performance, providing examples from my own experience in achieving the precious 100/100 score.

If you have made it this far, you can breathe a sigh of relief – I hope you managed to learn something valuable and practical about web performance. If you have any questions regarding my experience or approaches, feel free to leave a comment, Tweet me or throw a brick through my window – whichever approach feels right.

If you want to explore my personal website (the basis for these examples) in more detail, check out the complete source code on GitHub and, most importantly, thank you for reading!

What on earth is User Experience?

Adam McKenna — Sun, 03 Jun 2018 22:36:03 +0000

Article originally posted here.

Unless you've been living your life as a member of the Uncontacted Indians of Brazil, deep within the Amazon rainforest, then it's likely you've heard the term "User Experience".

In fact, you've probably heard the term thrown around more than you would like. It seems as though everyone in the digital sector, and their hip dogs, are experts in this emerging field.

Go to any digital consultancy's website and you'll be barraged with promises that they can convert your old, clunky web application into a "seamless," or "forward-thinking app" with an "unparalleled" user experience.

What on earth are they talking about? Moreover, what on earth am I talking about? Putting the "bullshit bingo" aside, what does "user experience" actually refer to? Has the term become so overused that it has lost all meaning? Well, no, because it never had a clear definition to begin with.

Let's address the elephant in the room. What on earth is User Experience?

Definitions of User Experience (and the problem)

Here's the crux of the matter: a plethora of definitions do exist, but professionals, researchers, and experts in the field have been unable to agree upon a single definition.

For instance, in 2007 a collective of human-computer interaction (HCI) professors, including Effie Lai-Chong Law and Arnold P.O.S. Vermeere, convened in an attempt to establish a so-called "user experience manifesto."

Alas, the document was never complete, and even now, over ten years later, the digital sector is rife with disagreement, squabbles, and good old fashion quick-draw matches*.

At this point, I can almost hear the readers thoughts: "Well, I definitely know what user experience is! I'm a bloody three-time award winning web interaction designer!" Or, something along those lines. And, to be fair, they wouldn't be wrong. There are definitions floating around.

For example, the ISO 9241-210 standard, has a very clear, commonly-used definition of user experience:

[a] person's perceptions and responses resulting from the use and/or anticipated use of a product, system or service.

The problem, however, isn't finding a definition -- it's finding a definition that everyone can agree upon.

Well, why can't professionals just agree on a single definition, like the ISO standard?

Exploring the metrics

Well, although there are numerous factors, the main cause of frustration in the debate is the question of whether usability is a metric of user experience or not. After all, user experience is a subjective concept, whereas usability is, for the most part, objective.

ISO 9241-210 also have a definition for usability:

The effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments.

In the context of digital artefacts, such as websites, mobile apps, etc., usability encapsulates scads of factors: accessibility, performance, user interface considerations, and task completion time are just a few examples.

But, despite the objective nature of usability, could it still be considered a metric of user experience? After all, it's hard to deny that these factors contribute to the overall experience and feelings that a user has when using an application.

Take the following definition of the relationship between user experience and usability:

Usability, when interpreted from the perspective of the users' personal goals, can include the kind of perceptual and emotional aspects typically associated with user experience. Usability criteria can be used to assess aspects of user experience.

This definition, also sourced from (you guessed it) the ISO standards, argues that usability is not only related to objective metrics, such as performance and accessibility, but also includes more abstract metrics, such as the user's awareness, emotions, and feelings towards a given system.

With that definition in mind, usability and user experience require co-existence. The user experience of an application depends on an application's usability in order to elicit a positive emotional response from the user.

Can you think of many instances when an application has be unusable and you have felt positively towards it? Sure, these instances do occur, but they are few and far between.

In the same vein, can you think of examples when you have responded with positive emotion to an application because of how usable it was? I know I can.

The reliance that the two metrics have upon one-another is not all-encompassing, but it is certainly substantial.

Yet, if these metrics are so dependant upon one-another, why spend so much energy debating their differences?

The critical difference lies in the nature of each metric.

As stated, usability is, for the most part, objective.

If a task cannot be complete, you would know what the task was and why it could not be complete.

If an application has poor speed, you can perform a benchmark test and meticulously assess the performance of each line of code.

If a user with accessibility requirements cannot access a button with their keyboard, you would know what the button was and what would need to done to ensure that the user could use it.

Though not always the case, most usability issues convert directly into tangible tasks.

User experience, based upon the aforementioned ISO definition, is on the other hand heavily subjective. What metric could be more subjective than a person's emotions and subconscious feelings? If a user responses with negative emotions to a system that is otherwise usable during a user experience evaluation, the chances are that it will be difficult for both the evaluator and the user to quantify the perceived "issue."

A person's emotions cannot be quantified with a benchmark test. We cannot discover the 'line of code' pertaining to a user's emotion. If a user dislikes a system, that can be due to a negative association in that person's mind, or because the system does not cater to (or fails to consider) some aspect of the user's culture. Or, it can be a completely unrelated factor.

Of course, although user experience professionals have techniques to drill deeper and create solutions to the user experience issues that they discover, they face a different challenge to the team responsible for identifying and resolving usability issues.

User Satisfaction

It is hard to deny that user experience and usability have different natures. One is subjective and the other is objective. But, it is also difficult to deny that they depend upon, and are relative to, one-another.

A system with poor usability is likely to deliver a poor user experience. So, perhaps it is prudent to look beyond the definitions of both metrics and instead discuss the overarching issue: let's talk about the outcome. Let's talk about user satisfaction.

Because ultimately, if a system is usable, but a user has a negative experience - for whatever hard-to-quantify reason - then the user may decide to use an alternative application, even if their goals are achieved within your system. In this situation, the user has low user satisfaction.

Similarly, if the system manages to emotionally resonate with the user - again, for whatever hard-to-quantify reason - but the user cannot complete their goals, then their overall user satisfaction will be low, and they will seek an alternative application to solve their goals.

When discussing the user experience of an application, usability (and all the metrics that define it) cannot be neglected. The ultimate goal of delivering a great user experience is user satisfaction - and a user cannot be satisfied unless their goals are achievable with your system.

Applications exist to solve problems. But, without usability, a user cannot use your system to solve their problem. And, if the user's problem is not being solved, a poor user experience has been delivered, right?

Conclusion

There are many of us that work in the digital sector and have our own interpretations of what user experience is, and that's fine. The problem is the neglect of the aspects of an application that contribute to the overall user satisfaction.

As long as the user is ultimately satisfied with your product, you can rest easy knowing a great user experience has been delivered.

To do so, however, it is necessary to look at the bigger picture and, whether user experience professionals wish to accept it or not, usability is a vital piece of the puzzle.

So, instead of shunning away usability metrics during our user experience discussions, let's instead embrace them with open arms and consider the overall user satisfaction.

Thanks for reading.

References

Abeysiri, L. and Weerawarna, N. T. (2017) Usability and user experience towards an experience economy. Technology and Management (NCTM), National Conference on (pp. 81-86). IEEE.

Davis, F. D. (1989) Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology. The Management Information Systems Quarterly, Vol 13 (3), pp. 319-340.

Glanznig, M. (2012) User experience research: Modelling and describing the subjective. Interdisciplinary Description of Complex Systems: INDECS, 10(3), 235-247.

Kaye, J. J., Boehner, K., Laaksolahti, J. and Ståhl, A. (2007) Evaluating experience-focused HCI. Proceedings of the CHI 2007 Conference, Extended Abstracts, ACM Press, San Jose, CA

Law, E. L. C., Vermeeren, A. P., Hassenzahl, M. and Blythe, M. (2007) Towards a UX manifesto. In Proceedings of the 21st British HCI Group Annual Conference on People and Computers: HCI... but not as we know it-Volume 2 (pp. 205-206). British Computer Society.

Vermeeren, A. P., Law, E. L-C., Roto, V., Obrist, M., Hoonhout, J. and Väänänen-Vainio-Mattila, K. (2010) User Experience Evaluation Methods: Current State and Development Needs. 6th Nordic Conference on HumanComputer Interaction. ACM, New York, pp. 521-530.

Vermeeren, A. P., Roto, V. and Väänänen, K. (2016) Design-inclusive UX research: design as a part of doing user experience research. Behaviour & Information Technology, 35(1), 21-37.

Three Things I Learnt at .concat() 2018 (and other reasons to visit Salzburg)

Adam McKenna — Mon, 05 Mar 2018 11:37:23 +0000

This year, I was fortunate enough to attend .concat() 2018, a user experience and web development conference hosted in Salzburg, Austria - the home of Mozart and setting of The Sound of Music - at FH Salzburg, the University of Applied Science. The University of Sunderland sponsored my attendance as part of my studies.

The conference ran two tracks which, unfortunately, meant that all of the talks clashed, and I was unable to attend a handful of presentations that had caught my attention, including those by Ursula Sarracini, Rasmus Lerdorf, and Estelle Weyl, among others exploring concepts such as accessibility, PHP, and maintaining legacy codebases.

The day began with a delicious, vegan-friendly breakfast, followed by an endless stream of 30-minute presentations, all kicked off with a keynote presentation by Google engineer Danno Clifford: When Fast is Faster Than Fastest, wherein he discussed optimising the Chrome V8 JavaScript engine.

Interweaved between the talks was evermore food (authentic Austrian food, this time), an endless supply of freebies, barista coffee, and beers. The day was rounded off nicely with a keynote presentation by the renowned Sara Soueidan, discussing a host of applications for SVGs in her talk: the <svg> of .svg.

I had a great time at the conference, and I learned a great deal, too. I'd like to share some of what I learnt with you in this article. So, here are three things I learnt at concat() 2018.

No. 1: Practical tips for designing Progressive Web Apps.

Before attending the conference, I had some experience of the technical aspects of Progressive Web App (PWA) development. I'd implemented service workers for caching and offline support, theming, etc. But, I was not as well versed in the user experience and interface design aspects of PWA development.

Thankfully, Nicole Saidy stepped in to fill in the gaps in my knowledge. In her fast-paced talk: Designing Great Progressive Web Apps, Nicole talked through a checklist of tricks to ensure your progressive web app offers a great user experience.

Nicole rattled through some of the basic steps: app icons generated via Real Favicon Generator, and theming via manifest.json and meta tags.

She then moved onto the more complex aspects.

One of the main attractions of a PWA, she explained, is the ability to operate offline. To leverage this, Nicole proposed an "offline-first" strategy. This can be achieved with a number of steps:

Inform the user about the change in internet connectivity.
When the connection is restored, provide a means to retrieve new content.
If the PWA is data-heavy, provide a 'data-saver' mode.
If the PWA offers content, provide the ability to download the content. Inform the user of file sizes if a download option is provided.
Simple but effective: add an 'offline-mode' colour to the app. (To accommodate users with visual impairment, ensure other means to determine the offline state have been provided to the user - a label, for example).

Another interesting topic that Nicole touched on was Progressive Loading with an Application Shell Architecture - the concept of loading particular elements before the entire page loads.

With a 'traditional' website, everything is rendered immediately when the stylesheets, and other resources, have been loaded. Whereas, when leveraging the Application Shell Architecture, specific elements can be loaded earlier in the rendering process to create an impression of a faster loading website, even though the website hasn't actually loaded faster.

The best part of this effect, in my opinion, is the simplicity of its implementation. All you need to do is serve the applicable CSS via a <style> tag at the top of the page. The rest of the website styles can continue to be served via a stylesheet. The browser will automatically prioritise the styles served at the top of the page, rendering them while the stylesheet loads.

You can see this effect used across multiple Google products, including YouTube and the Google search engine.

Nicole covered plenty more in her talk, including 'PWA audits', iOS-specific considerations, 'micro-interactions', and a detailed PWA checklist that you can use.

You can watch Nicole's full talk on YouTube via the link below.

No. 2: You can use CSS Custom Properties today.

Though I had heard of CSS Custom Properties before the conference, I had no experience at all with them. At the pace that the HTML, CSS, and JavaScript specs grow - not even mentioning third-party technologies - I find it difficult to keep up-to-date with every feature.

That being said, the CSS Custom Properties spec looks a promising addition to the CSS language. Even better, it is fully supported in all modern browsers - you can start using it today.

If, like I was, you're wondering how on earth you can, then Mike Riethmuller has you covered. In his talk The Strategy Guide to CSS Custom Properties, Mike explored a host of ways in which you can use custom properties in your projects to improve the maintainability of your CSS.

At first, I feared that the new feature was an attempt to replace the variable functionality of pre-processors, such as SASS and LESS, but this is not the case. In fact, Mike explores how, and why, we can, and should, use both.

Concisely put, Mike argues that you should use pre-processor variables for theming, and CSS Custom Properties for values that will change within your media queries.

To learn the nitty-gritty of Mike's strategy, check out his full talk on YouTube below.

No. 3: Address your bias

It's a fact: we all have biases. As software developers, UX designers, and the like, this inevitably effects the applications that we build. However, this fact is not ample justification to let our applications reflect our biases: we need to address them.

Nobody understands that more, it would seem, than Ivana McConnell. In her much-warranted, antagonistic talk, Your Algorithm is Not Neutral, Ivana explored the concept of exclusion in our applications. Ivana called out a host of companies who failed to address their biases, and who had in turn released applications into the wild that negatively affected the lives of their users.

From a Pure Gym application that assumed all users with the title 'Dr' were male, subsequently disallowing a female into the changing rooms, to apps like AirBnb and Nextdoor that allowed racial discrimination, and Snapchat providing users with racist filters: users are being excluded and actively discriminated against.

Products should empower users, not exclude them. So, how do we approach inclusive UX?

You can discover a series of steps to do so in Ivana's powerful talk on YouTube, embedded below.

In a similar vein, Jenny Shen explored how we can design across cultures in her humorous, yet undoubtably thought-provoking talk, Build Bridges, Not Walls. Design for Users Across Cultures.

Exploring what culture is, and why we should care, Jenny provided a series of unintuitive examples that illustrated how users in difficult cultures react to design decisions made by someone unfamiliar with their culture.

Though I could attempt to reference her examples, I would not do them justice and I implore you to watch Jenny's talk at your earliest convenience. You can do so below.

A consistent theme runs through both talks: you have a bias and you need to consciously take action to ensure your user does experience the implications of your unintended, natural bias, which impacts race, culture, gender and social conditions.

Conclusion

The Concat() 2018 conference was a memorable day: thought-provoking talks from a host of great speakers; high-quality local cuisine, and some of the best coffee I have ever had provided by an on-site barista; lovely attendees and, of course, a fantastic team.

I have so many takeaways to think about from all the talks I watched, and a backlog of talks that I missed to catch-up on. The points I have discussed in this post only scrape the surface of the ideas circulated throughout the day, and I recommend that you watch the talks yourself and, of course, sign-up for next year's ticket... (fingers-crossed).

And, in that vein…

Bonus: Here's Some Other Reasons to Visit Salzburg

The conference was a fantastic opportunity for me to explore Austria, having never visited the country before. Though historically known for salt mining - Salzburg translates directly to 'Salt Fortress' - and more recently known as the birthplace of the world-famous composer Wolfgang Amadeus Mozart and the setting of The Sound of Music, Salzburg has a lot more to offer.

Scenery

Unlike many cities of the 19th century, Salzburg's buildings were spared knocking-down, thanks to a one-hundred-year period of economic neglect from the ruling Habsburg dynasty after the city joined Austria in 1816, ensuring the city was able to retain its distinctive appearance.

As a result, modern day visitors are able to experience picturesque architecture that is difficult to find in many other places in Europe. And, with Salzburg being surrounded by mountains and various other vantage points, there is ample opportunity to be awed.

Cuisine and Drinks

Salzburg has quite the offering of delicious cuisine, and is also the home place of a number of delicacies, including Paul Furst's Original Salzburger Mozartkugel and the Original Sacher Torte, the latter of which is available at the Café Confiserie Sacher (who never pass on an opportunity to remind you that they are offering not just any Sacher Torte, but the Original Sacher Torte).

In addition to treats, there is no shortage of authentic food, including beef goulash, spinach dumplings, and frankfurter sausages. Even the coffee stood out. A common option in Salzburg is the Melange: a filter coffee served with milk, whipped cream and, in most cases, a chocolate treat. All the coffee I tried in Salzburg was even served with a small glass of cold water.

Untersberg Mountain

A short bus journey away from the city centre, in Grödig, there is a cable car that you can take to the snowy speaks of Untersberg mountain. Though the cable car usually costs €25 for an ascent and descent, you can ride it for free with a Salzburg Card.

We were able to climb the mountain on a particularly clear day, after a full day of snow, and were able to enjoy the scorching sun, endless snow, and unforgettable views of Salzburg, Watzmann mountain and, the German Bundesland of Bavaria.

Caption: Unintentionally 'deep' photo of me enjoying the view.

No description or photographs can do the experience justice. If you find yourself in Salzburg, Grödig or anywhere nearby, this is an unmissable experience.

What have been your biggest learning curves as developers? #discuss

Adam McKenna — Mon, 08 Jan 2018 23:53:13 +0000

There are so many areas in Computer Science and the technologies that make up this vast sector can range from basic to outlandishly complex and difficult.

The web, for example, encapsulates just one area of the industry, yet in itself has an immeasurable amount of languages, frameworks, tools etc. I'm sure the typical web developer could rattle off 20-30 off the top of their head.

But, each and every concept/language/technology/tool required some form of learning to begin to us - whether basic or otherwise.

Tough learning curves can be occur for a number of reasons. Perhaps that language had poor or non-existent documentation; perhaps it was difficult to find support online or from peers for that tool; perhaps that technology required context from another technology to learn it effectively?

Whatever the reason and whatever the concept/language/technology tool, it is very interesting, and often surprising, to discover what people in the industry have found to be the steepest learning curves, and why this was the case.

And, perhaps by addressing and discussing some of the learning curves faced, we can begin to find solutions to the issues for future generations of developers.

So, what have been your biggest learning curves, and why?

Improve the performance of WebStorm (and other JetBrains IDEs)

Adam McKenna — Mon, 08 Jan 2018 19:56:45 +0000

Have you ever used WebStorm? What about PHPStorm, or, in fact, any of the IDEs in the JetBrains suite? They are an impressive collection of IDEs packed with features -- an integrated terminal, local history and VCS integration, "intelligent" imports, and much more.

But, does this feature-bloat come at a price? Absolutely.

The performance of WebStorm, and the other JetBrains IDEs, pales in comparison to the lighter text editors that are popular in the web community. Visual Studio Code and Atom come to mind.

Fear not! There are solutions.

But first, let's take a step back for those who aren't familiar with the IDE.

What is WebStorm?

WebStorm is a popular, powerful web development IDE. It is one of a larger collective of IDEs developed by JetBrains - formerly known as IntelliJ. These IDEs aim to offer the ultimate development environment for popular coding languages.

Other JetBrains IDEs include PHPStorm for PHP, IntelliJ IDEA for Java, PyCharm for Python, and ReSharper for C# (as a Visual Studio extension), among others.

Even Android Studio, which is technically a Google IDE, runs on the IntelliJ platform. With that in mind, most of the optimisations explored in this article can be transferred to other JetBrains IDEs.

But, as we mentioned, although WebStorm is one of the most powerful IDEs available, it’s certainly not the most performant. In fact, on older machines, it can be a machine killer.

Let's explore how to increase the load-time and performance of WebStorm by tweaking the out-of-the-box settings.

Optimising WebStorm's performance

Setup Config Files

We’re going to start by customising a few settings within the WebStorm directory.

But first, in order to customise WebStorm settings, we need to create some configuration files. We'll create two config files: idea.properties and webstorm.vmoptions.

To create these files, open WebStorm and go to Help.

Select Edit Custom Properties…. A dialog will prompt stating that the idea.properties file does not exist.

Click Yes to create it. The file will open. Now you can add the config settings. This file is used for customising WebStorm properties.

To create the other file, go again to Help and select Edit Custom VM Options....

A dialog will prompt stating that the webstorm.vmoptions file does not exist.

Click Yes to create one. The file will open. Now you can add the config settings. This file is used for customising WebStorm Virtual Machine options.

For future reference, these files can be found in the following directories:

Windows 7 / 8 / 10 - <SYSTEM DRIVE>\Users\<USER ACCOUNT NAME>\.<PRODUCT><VERSION>

OS X / macOS - ~/Library/Preferences/<PRODUCT><VERSION>

Improve the Performance

Now that our config files are setup, we can change WebStorm’s settings to optimise performance.

First, let's change some options within the webstorm.vmoptions file.

Open the newly created file, select all of the options and replace them with the following snippet:

-Xms1024m 
-Xmx1536m 
-XX:MaxPermSize=1024m 
-XX:ReservedCodeCacheSize=512m 
-XX:+UseCompressedOops

Next, we are going to remove IDE latency using an experimental property called zero-latency that was introduced in 2015.

To do so, add the following line to your idea.properties file:

editor.zero.latency.typing=true

We’re going to move on to generally optimising the usage of WebStorm by de-selecting unnecessary features. Doing so will reduce feature-bloat and increase system memory.

Appearance and Behaviour

To start, let’s disable automatic update checking and statistic sending within the Appearance and Behaviour preferences.

To do so, go to Preferences and select Appearance & Behaviour.

Then go to System Settings and select the Updates tab. From here, de-select Automatically check updates for…

Next, select the menu 'Data Sharing' from the System Settings and de-select Send usage statistics.

Editor

Now, let’s change some settings in the Editor preferences.

Within Preferences, go to the Editor tab and select Live Templates. De-select any templates that you do not use.

Emmet is a IDE plugin that helps improve HTML and CSS development workflow.

It's a great plugin, but it comes with many options that go unused and waste valuable system memory.

To remove these unnecessary options, go to the Editor tab and select Emmet. Browse through the options for CSS, JSX and HTML, and de-select any options that you don't use.

Intentions is a powerful feature of the JetBrains application family. It suggests solutions to problems that it detects on-the-fly as you code.

However, by default WebStorm has every option selected within the Intentions preferences window. It's unlikely that you will use every technology/language listed, so de-select the options that you do not use.

To deselect the options, go to the Editor tab, select Intentions. Again, de-select any non-applicable languages and technologies.

Plugins

Almost there. Next, let’s fiddle with our plugins.

Within Preferences, go to the Plugins tab.

By default, all of the native plugins will be enabled.

It is unlikely that you will make use of them all. Scroll through and de-select any plugins that are not applicable to the languages and technologies that you use.

Directories

During startup, WebStorm loads every directory (folder) within a project. However, some of these directions, particularly vendor directories like the node_modules directory, may never be touched within WebStorm. Loading these directories wastes valuable resource.

To disable un-used directories, within Preferences, go to Directories and set any directories that are not edited within WebStorm as Excluded.

Languages & Frameworks

Within Preferences go to Languages & Frameworks > JavaScript > Libraries and de-select any libraries that are unused.

If you are not using Compass to generate CSS files from your Sass, ensure ‘Enable Compass support’ is not enabled. To do so, go to Languages & Frameworks > Compass.

Tools

The Web Browsers section is used to quickly launch your project into the enabled browsers.

If you do not use this feature, disable it. To do so, within Preferences go to Web Browsers and de-select all browsers except your browser of choice.

Conclusion

So, that's it.

Now we’ve managed to clean up WebStorm, you should find a notable increase in start-up time and general performance so you can focus on the stuff that matters: web development.

Sources

How, and why, to clean SVG markup

Adam McKenna — Tue, 24 Oct 2017 19:50:52 +0000

You wouldn't think that the SVG format has been around for almost 20 years.

Over the last few years, the popularity of the format has grown so phenomenally that you'd be forgiven for thinking it was a recent innovation.

These days, it is common practice to provide your logo, graphics, charts, and the like as an SVG, instead of its pixellated bitmap counterparts.

So, where did this file format come from? The SVG (Scaleable Vector Graphic) format was brought to the table in 1999 by the W3C (World Wide Web Consortium). It's an XML based vector image format designed specifically for the web.

One of the many beauties of vector images, including SVG, is that they can be scaled to any size without a loss of quality. Bitmap images, on the other hand, such as .jpg, .png, and .gif, pixelate when scaled beyond their natural size.

Scalability makes the SVG format a natural fit for the responsive web. An SVG can easily be scaled for mobile, desktop, all the way to 5K displays, and everywhere in between and beyond.

Image source

An SVG typically has a smaller file size than any of its bitmap counterparts. An SVG also supports several interesting use cases that bitmaps cannot, including animation and interaction with JavaScript.

If you’re not yet convinced that SVGs are the future, I strongly recommend watching this Chris Coyer video or reading Chris’ book, Practical SVG.

Convincing readers to use the format is not the purpose of this article. Rather, this article is a guide for those who have already adopted SVGs, and want to squeeze a little more out of the format.

Let's explore how we can cleanup SVG markup, and why we probably should.

SVG Anatomy (SVG == Markup)

When you preview an SVG in a browser or an image viewer, it will, more or less, behave as a bitmap. You can see the image rendered. Of course, the SVG will be sharper, and won't pixelate if you zoom in, but beyond that there is little difference.

The difference is behind the scenes. SVG is XML-based. Behind every SVG there is readable, HTML-like markup. This means that you have readable line-by-line control, regardless of what tool churned out the file.

Heck, SVGs could be coded from scratch, and often are. But, most SVGs are produced in a graphics editor, such as Adobe Illustrator, Inkscape or Sketch. These applications often export their SVG markup with superfluous, and sometimes outdated, elements and attributes.

For example, here is the XML from an SVG icon created in Adobe Illustrator:

<?xml version="1.0" encoding="iso-8859-1"?>

<!-- Generator: Adobe Illustrator 19.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->

<svg version="1.1" id="Capa_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 60 60" style="enable-background:new 0 0 60 60;" xml:space="preserve">

    <g>

        <path d="M45.563,29.174l-22-15c-0.307-0.208-0.703-0.231-1.031 0.058C22.205,14.289,22,14.629,22,15v30c0,0.371,0.205,0.711,0.533,0.884C22.679, 45.962,22.84,46,23,46c0.197,0,0.394-0.059,0.563-0.174l22-15 C45.836,30.64,46,30.331,46,30S45.836,29.36,45.563,29.174z M24,43.107V16.893L43.225,30L24,43.107z"/>

        <path d="M30,0C13.458,0,0,13.458,0,30s13.458,30,30,30s30-13.458,30-30S46.542,0,30,0z M30,58C14.561,58,2,45.439,2,30S14.561,2,30,2s28,12.561,28,28S45.439,58,30,58z"/>

    </g>

</svg>

If you’re familiar with HTML, this will look quite familiar: it's just elements and attributes.

And, just like HTML, we can optimise it.

Let’s look at another example. This SVG markup is for a map marker icon generated by Sketch:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<svg width="39px" height="39px" viewBox="0 0 39 39" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">

    <!-- Generator: Sketch 39.1 (31720) - http://www.bohemiancoding.com/sketch -->

    <title>Hospital</title>

    <desc>Created with Sketch.</desc>

    <defs>

        <rect id="path-1" x="0" y="0" width="33" height="33" rx="9"></rect>

    </defs>

    <g id="Maps" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">

        <g id="Map" transform="translate(-483.000000, -779.000000)">

            <g id="Hospital" transform="translate(486.000000, 782.000000)">

                <rect id="Rectangle-57" fill-opacity="0.599999964" fill="#FFFFFF" opacity="0.5" x="0" y="0" width="33" height="33" rx="9"></rect>

                <g id="Rectangle-57">

                    <use stroke="#2D2D2D" stroke-width="6" fill-opacity="0.599999964" fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-1"></use>

                    <use stroke="#FF0000" stroke-width="3" xlink:href="#path-1"></use>

                </g>

                <polygon id="Shape" fill="#FF0000" points="19.7149758 19.5157005..."></polygon>

            </g>

        </g>

    </g>

</svg>

Sketch generated this simple icon with 21 lines of markup.

Relative to a typical HTML file, that is not many lines. But, for a simple icon, it's much more than necessary. Most icons that I work with are around 4-10 lines.

Why the bloat? There are several elements and attributes that are redundant and can be removed. Let's have a look at what they are, and why we can remove them.

What Markup can we remove?

XML Prolog

The first thing that we can remove is the first line: the XML prolog.

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”no”?>

Most XML documents begin with a prolog. A prolog is one or more lines of code that provide information about the current XML document and related documents.

If the SVG is going to be embedded within an HTML document or another SVG, which it most likely will be, the prolog is redundant and can be removed.

Leaving the prolog will have no effect to the user, but removing it helps keep your code clean and reduces file size.

The `<svg>` version Attribute

The <svg> tag comes packaged with the version attribute, indicating that it is using the latest version of SVG – SVG 1.1.

<svg version=”1.1″ … >

This attribute has no influence on the rendering of the SVG and can be removed.

XML Comments

Did you see Sketch's obtrusive XML comment?

<!– Generator: Sketch 39.1 (31720) – http://www.bohemiancoding.com/sketch →

Although in certain contexts, XML comments can be helpful, this particular comment is redundant. We don't need to know where the icon came from.

Many other graphic editors include XML comments when generating SVGs, and these comments can also be safely removed.

The `<title>` and `<desc>` tags

Next, we’re going to look at the title and desc elements.

<title>Hospital</title>

<desc>Created with Sketch.</desc>

You may not want to remove these elements. It depends upon the context in which the SVG will be used.

The title and desc tags are helpful for accessibility. The title element is displayed on hover in certain browsers. Both elements may also be displayed instead of the graphic if there is a situation where the SVG paths cannot be rendered.

If the SVG provides important context to the page, for example, a graph or chart, then you should keep the title and desc tags, and change their text content to convey the content of the graphic.

On the other hand, if the SVG does not provide important context, for example, an icon or logo, then the title and desc tags can be removed.

As I am working with an icon in this example, I removed the tags.

The `<g>` tags

The major clutter of the SVG markup in my example is the chain of <g> tags that serve as a wrapper for the SVG paths.

Most of the <g> elements have a transform attribute, among others.

<g id="Maps" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">

    <g id="Map" transform="translate(-483.000000, -779.000000)">

        <g id="Hospital" transform="translate(486.000000, 782.000000)">

            <rect ...></rect>

            <g id="Rectangle-57">

                <use ...></use>

                <use ...></use>

            </g>

            <polygon ...></polygon>

        </g>

    </g>

</g>

All of these <g> elements are redundant and can be removed.

Why Sketch decides to leave an endless trail of <g> tags in its wake is one of life's great mysteries. We may never know.

The `<svg>` `viewBox` Attribute

The <svg> viewBox attribute is a complicated concept.

I will not delve into it within this article, but I strongly recommend Sara Soueidan’s article if you are unfamiliar with the attribute.

<svg viewBox=”0 0 39 39″ … >

Once the <g> tags were removed, the positioning of the SVG elements was slightly off by 3 pixels. I adjusted the starting point of the viewBox to compensate.

<svg viewBox=”-3 -3 39 39″ … >

This isn’t ideal, but it’s better than the endless chain of <g> tags and their non-sensical transform attributes.

Although I did, you may not have to make any edits to the viewBox attribute. But, if you do, it is likely that you will have to use different values.

IDs

Most of the SVG elements were generated with an id attribute. The <rect> element, for example:

<rect id=”Rectangle-57″ … />

Unless you need to target these elements with JavaScript, these id attributes can be stripped out. The only instances where the id attributes are important are within the <defs> block.

In my example, the <defs> block looks like this:

<defs>

    <rect id=”path-1″ x=”0″ y=”0″ width=”33″ height=”33″ rx=”9″></rect>

</defs>

The elements within the <defs> are not initialised within this block, but rather they are declared for future use.

You can see the path-1 element defined within the <defs> block is referenced later in the markup via a <use> element:

<use xlink:href=”#path-1″ … ></use>

That means we need to keep the id attribute so that the <use> element can reference the <rect>. But, the id value path-1 is not descriptive. I renamed it to border:

<defs>

    <rect id=”border” x=”0″ y=”0″ width=”33″ height=”33″ rx=”9″></rect>

</defs>

<use xlink:href=”#border” … ></use>

The new id clearly describes the element.

What's next?

Okay, lets address the elephant in the room...

Why not use an automated SVG optimiser, like SVGO or SVGOMG?

It's true. There are a number of automated tools that will optimise SVG markup for you.

But, this can come at a cost.

In some cases, automated tools can merge all of the SVGs layers, making the SVG harder to work with in future.

To quote Sarah Soueidan:

[SVGO] can break the SVG as well as any structure you create in it for animation, for example. I use SVGO sparingly. Ai export is v clean.

Here is an interesting Twitter thread on the topic by Sara Soueidan et al here, which is also the source of the above quote.

Conclusion

And that’s it.

<svg width="39px" height="39px" fill="none" viewBox="-3 -3 39 39" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">

    <defs>

        <rect id="border" x="0" y="0" width="33" height="33" rx="9"></rect>

    </defs>

    <rect fill-opacity="0.6" fill="#FFFFFF" opacity="0.5" x="0" y="0" width="33" height="33" rx="9"></rect>

    <use xlink:href="#border" stroke="#2D2D2D" stroke-width="6" fill-opacity="0.599999964" fill="#FFFFFF" fill-rule="evenodd"></use>

    <use xlink:href="#border" stroke="#FF0000" stroke-width="3"></use>

    <polygon fill="#FF0000" points="19.7149758 19.5157005..."></polygon>
</svg>

We’ve managed to reduce the lines of code down to 9 -- over 50% of the lines of code were removed. That’s pretty impressive.

Now, you’re probably wondering what the point of all this cleanup was.

Well, clean SVG markup has a myriad of benefits, including:

Maintainability – your SVGs are easier to edit and maintain, without ever opening an image editor.
Speed – less code means smaller file sizes, smaller file sizes means a faster loading web page.
Animation – it becomes notably easier to animate SVGs when the markup is optimised and free from redundant tags.
Accessibility – image editors seldom focus on accessibility when generating markup. Having clean markup makes it easier to create accessible graphics.
JavaScript – understandable markup makes it easier to integrate with JavaScript. For instance, sensible, unique id attributes.

While it is true that an SVG minifier, such as SVGOMG, can do most of the leg work for you, it can also damage the quality of the SVG.

Do you have the time? Are you going to animate the SVGs? It's contextual and the choice is yours.

Thanks for reading.

Writing Baseline Accessible Markup and Styles

Adam McKenna — Mon, 04 Sep 2017 14:04:43 +0000

Article originally posted here.

Ah, accessibility... You'll find most developers you raise the subject to will begin drifting off, as though you've just performed a magic spell on them.

But, what is accessibility and why are so many developers uninterested?

Accessibility (a11y) refers to how usable an application is to all audiences. An accessible application is usable by anyone, regardless of physical, visual or hearing impairments. The experience is not compromised for any users.

That sounds like a lot of work. And it can be. That's one reason why so many developers are uninterested.

Most of my experience has been in development agencies. Within these organisations, the goal is to maximise profit: churn good products out the door in the least time possible. In this environment, accessibility becomes a nice to have. At least, that's the perspective of a project manager or product owner. Ask a developer and they'll say:

"Accessibility is boring. Who cares?"

That's another reason why they are so uninterested.

I disagree. I don't think it is boring. It can be rewarding and fun to create robust interfaces that can be used by a multitude of audiences.

But, whether it's boring or fun is irrelevant. Lets talk about who does care.

A study conducted in 2008 by the Disability Rights Commission found that over there are over 6.9 million disabled people of working age in the UK, representing 19% of the working population.

That's almost 1 in every 5 people.

The types of disabilities captured in this static vary dramatically. But, it does mean that 1 in every 5 website visitors may have a disability that your website should cater for. If they are blind, for instance, and your website has no support for screen readers, what can they do? They have been rejected from your product.

An accessible product is a more viable product. The more accessible, the more users the website can accommodate.

Not to mention the ethical implications, of course. If you are conscious of the implications of a non-accessible website, and you continue to avoid the implementation of accessible features, could it be argued that you are flat out rejecting users with accessibility requirements?

So, the answer to the question: who cares? The answer (should be): everyone involved in the project. Whether you're developing for the web, mobile, tablet, or a toaster. If your application has user interaction in any form, you must consider accessibility.

Thankfully, there is a lot of "low-hanging fruit" that can be snatched. With relatively little effort, you can make a massive impact to an application's accessibility. We're going to explore how.

We'll look at accessibility in your code. As such, factors including colours, UX design patterns, and so on are out of the scope of this article. That being said, those factors are as relevant to accessibility as anything covered in this article.

This article should also not be viewed as a comprehensive list of 'dos' and 'do nots', but rather a selection of considerations that I believe are important and easy to achieve.

Without further ado, lets crack on.

Testing Tools

As a developer, one of the main disabilities we need to cater for is visual impairment. We need to ensure that people who can barely see, or cannot see at all, can still navigate your application, find all the information they need, and interact with it with the same ease as any other user.

Most visually impaired users navigate the web with a technology known as a screen reader. A screen reader scans an HTML document, interprets the markup, and reads the information to the user. Screen readers are operated using a keyboard so that users can interact with links and other interactive elements.

There are a plethora of screen readers available, but the most popular screen readers, by platform, are:

Windows - NVDA
Mac - VoiceOver for Mac (built-in)
iOS - VoiceOver on iOS (built-in)
Android - Google TalkBack

The key to making screen readers useful is rich, descriptive markup and views. This is achieved by using semantic elements (e.g. <nav>, <header>, <main>, etc.) as intended, correct headings, descriptive imagery, hidden elements, usable elements, the WAI-ARIA suite and factoring in a variety of other considerations. Android and iOS also have their own tools for making elements accessible.

We'll explore each of these in turn.

Labels

You should always label interactive elements, including links, buttons (if the elements children do not provide an adequate description) and inputs.

You should also provide labels for links and tabs that have icons, but have no visible text.

Lets look at a real example. With the a tag, a screen reader will read the content within the elements opening and closing tags. However, this is typically non-descriptive. For instance:

<a href="about-us.html">Read More</a>

With this example, a screen reader will literally read "read more" to the user. How often have you seen this on the web?

It’s not very indicative of where the link leads. If the user was skimming through the page, the user would simply hear "read more, read more, read more…," with no understanding of what they would discover if they clicked the link.

How can we fix this?

On the web

Thankfully, on the web you can use WAI-ARIA to provide descriptive labels to links.

WAI-ARIA is an acronym for Web Accessibility Initiative - Accessible Rich Internet Applications. It’s a tool for providing markup with rich, semantic meaning. ARIA provides a library of attributes that you can use to enhance HTML elements.

One such example is aria-label. You can use the aria-label attribute to assign a specific value that will be read by a screen reader instead of the element's value.

<a href="about-us.html" aria-label="Read More About The Team">Read More</a>

Alternatively, you can use aria-labelledby to give the element another element’s value.

<h1 id="title">Read More About The Team"</h1>

<a href="about-us.html" aria-labelledby="title">Read More</a>

Android

On Android, the approach is similar. You can use android:contentDescription on an element in the same way as aria-label.

<Button
    android:id="@+id/some_id"
    android:src="@drawable/search"
    android:contentDescription="@string/search"/>

Swift

When writing Swift for iOS, you can use the accessibilityLabel from the UIAccessibility API.

self.navigationController.navigationBar.backItem.setAccessibilityLabel("back")

Forms and Input Placeholders

If you have form elements or inputs, don’t rely on the placeholder attribute as a label. The HTML5 specification warns against this as it does not work as a label for screen reader users.

It also disappears for regular users once the input has been populated. This makes forms difficult to revise once complete.

On the web

DON’T

<input type="text" name="message" placeholder="Message…">

Instead, you should provide an associated text label for every input. You should also provide the label first, and set the label’s for attribute to the name of the form element it refers to:

<label for="message">Message</label>
<input type="text" name="message" placeholder="Message…">

Android

Similar to HTML5, Android XML uses the android:hint instead of the placeholder attribute. It works in the same way, and should not replace a label for the same reasons.

DON’T

<EditText 
    android:id="@+id/edit_text" 
    android:hint="@string/aac_edit_text_about_label" />

Instead, add a TextView label for inputs and add the labelFor attribute with the id value of the input it belongs to:

<TextView
    android:labelFor="@+id/edit_text"
    android:text="@string/aac_edit_text_about_label" />

<EditText android:id="@+id/edit_text" />

Swift

Swift for iOS is slightly different. You should also not rely on the placeholder attribute for UITextFields:

DON’T

let messageField = UITextField = UITextField (...);
messageField.placeholder = "Message…"

However, unlike HTML5 and Android, there isn’t a way to connect a label to an input. Instead, you should use the accessibilityLabel attribute directly on the text input:

let messageField = UITextField = UITextField (...);
messageField.accessibilityLabel = "Message…"

The placeholder attribute itself is fine across all three platforms, and should be used where necessary.

The problem is that developers use it as a replacement for a label. This is not its purpose. It should always be used alongside a label, not as a replacement.

Writing Good Labels and Descriptions

Providing labels and descriptions is important so that users understand an elements purpose, and the result of interacting with the element.

It's also important to ensure that those labels and descriptions are well written. A poorly written label can do as much damage as having no label at all.

The Google Material UI usability guidelines defines a set of rules by which to write good labels. These are ideal for most applications.

Lets explore these rules:

Be succinct

Keep labels short and ‘to the point’, ensuring the label is brief but descriptive.

DON’T

‘Logout Button. Logout of account adam@gospelware.co.uk and return to homepage’

‘Logout of adam@gospelware.co.uk’

Avoid describing control type in text

Labels should not describe the control type, whether it’s a button, link, field, etc.

DON’T

'Message Field.'

'Settings Button.'

Screen readers will announce the control type. Therefore, specifying the type will result in the type being announced to the user twice.

In our example, a user would hear “Message Field. Field” and “Settings Button. Button.”

'Message.'

'Settings.'

Instead, omit the control type. In our second example, the user will hear “Settings Button” and “Message Field”.

Avoid describing control state in text

For the same reasons, do not describe an element’s state.

DON’T

Accept Terms and Conditions is selected

Accept Terms and Conditions

Indicate what an element does

Describe what an element does when interacted with. Do not describe the element itself nor the properties of the element.

DON’T

Burger menu icon

Pencil icon

Show/hide navigation menu

Edit

Don’t mention the exact gesture or interaction

Do not discuss a gesture or interaction, describe the task instead.

DON’T

Tap to speak

Click to start

Voice search

Start game

Dialogs

Dialogs, or modals, are useful elements for conveying information. They are typically used to prompt a user for information, or to provide information that requires the user's immediate attention.

At the time of writing, there is no native HTML5 tag that describes a dialog, although common 3rd party JavaScript libraries and frameworks, including jQuery and Angular Material, offer pre-built accessible dialogs.

If you are not using a library or framework with out-of-the-box dialogs, you will need to use a regular old <div> tag with a few lines of JavaScript to prompt the dialog (this is out of the scope of this article).

A typical dialog might look like this:

<div class="dialog">
    Whoa, mate. You've made a mistake.
</div>

If the user encounters an error, ensure a label is provided and the <div> uses the role=”alert” attribute and value.

<div role="alert">
    <span class="close-icon" tabindex="0">x</span>
    The form has an error: you forgot to provide a message.
</div>

An element using role=”alert” will be displayed to a screen reader user when the element appears in the UI. The element would typically be displayed via JavaScript or CSS as necessary.

Both Android and iOS natively offer accessible dialogs.

Images - 'alt' Attribute

Another thing to consider for screen readers is imagery. Imagery used in an application falls under one of two categories: decorative or informative.

Decorative images, on the other hand, serve no purpose other than aesthetics. These images should be ignored by screen readers.

Informative images present information to the user. They need to be delivered to the screen reader in text form, otherwise the images information will be lost.

How do we solve this issue? This is where the alt attribute comes in.

If the image provides relevant information, for example a graph or info-graphic, you need to use the img tag with an alt attribute. The alt attribute will describe the image's content. For example:

<img src="political-graph.jpg" alt="Nationwide results at a glance: ...">

Of course, you should input data of any notable complexity into a table or similar layout, and rely on images for basic data.

Decorative images include icons, logos, and backgrounds. Serve decorative images using the background-image CSS property where possible.

If the image cannot be served using the background-image CSS property, the image should be served using the img tag with an empty alt attribute. When the alt attribute is empty, the image is ignored by screen readers.

<img src="decorative-icon.jpg" alt="">

Headers

Headers are used across websites to indicate page and section titles. They are delivered using the <h1> to <h6> tags. Here’s an example of a website header hierarchy taken from a random website:

Source: gospelware.co.uk tested via seowebpageanalyzer.com

Only use header tags for titles. Do not use them for changing aesthetics.

Header tags should only be used in descending hierarchy and should not be skipped.

For example, if you use the <h1> tag, and need to use another heading below it, the next heading must be an <h2> tag, or another <h1> tag. This applies at every heading level.

The document should always begin with an <h1> tag, and no other heading tags.

Hidden Descriptions

A user interface can provide a lot of context to information on a webpage. This information can be lost when the page is delivered as text via a screen reader.

You can combat this by using hidden elements that are displayed to screen readers, but hidden from all other users. This can be achieved with a small chunk of clever CSS:

.hide {
   position: absolute !important;
   top: -9999px !important;
   left: -9999px !important;
}

Empty states

An empty state refers to a short piece of text that informs a user that no data is present. Here’s an example from Outlook:

Empty states should always be provided in situations where data may be present, but none is. For example, a 'to-do' list or an email inbox.

This means that screen reader users know right away that there is no data. Otherwise, they may wait a while under the assumption that the data is loading or that an issue has occurred that has prevented the data from displaying.

Styles

Finally, lets briefly discuss CSS.

Any elements that are clickable should have a hover state that visually indicates to the user that the element is clickable. This can be achieved using the CSS pseudo hover selector:

.button:hover {
    background-color: red;
}

The hover pseudo selector only works for mouse and touch-based devices. It does not work for elements that have been selected via a keyboard.

As a result, if only hover is used, users who do not, or cannot, use a mouse or touch device will not receive any visual indication that the current selected element is selected.

To combat this, you should use the focus pseudo selector alongside any instances of the hover selector:

.button:hover,
.button:focus {
    background-color: red;
}

As a last mention, there is also a new CSS pseudo selector that has been proposed, but is not yet fully implemented, called :focus-within.

It lets you set styles on a parent element when any of the parent element’s child elements have been selected.

div:focus-within {
    background: yellow;
}

Although this is in an experimental phase, I am sure this will become widely supported soon. It serves as a reminder that the web is constantly becoming more and more accessible.

Conclusion

Perhaps it's true that accessibility is boring, and maybe accessibility is dull, and certainly accessibility does require more work.

But, it is important.

I truly believe anyone, regardless of any disability or ailment, should be able to enjoy the web - and mobile applications - just as much as any so-called "fully-abled" person. I’m sure you do too.

If you do agree with this sentiment, then perhaps it’s time you start to reassess how you feel about accessibility.

Thank you for reading.

An aside: accessibility is difficult.

Accessibility is difficult, even with these quick wins, but why?

I believe there are there two main factors that make accessibility difficult.

The first is a lack of understanding or awareness of the issues that make applications inaccessible, and the steps to resolve those issues. There is a plethora of resources online to identify commons issues. The best way, of course, is to do real user testing with your website.

The second is because it is difficult to empathise. This is an expansive topic. The best way to empathise is real use cases. Attaining feedback from real users with real disabilities using your application. Of course, this option is seldom available in most situations.

Thankfully, Eric Bailey, a Boston-based designer, has created a very useful website to emulate accessibility issues and help developers gain a bit of empathy. I highly recommend checking it out.

Sources:

Hi, I'm Adam McKenna

Adam McKenna — Tue, 25 Apr 2017 09:41:01 +0000

I have been coding for some years.

You can find me on Twitter as @AdamMcQuiff

I live in Newcastle upon Tyne.

I work for Zetec Digital

I mostly program in these languages: JavaScript, PHP, C#.

I am currently learning more about API development.

Nice to meet you.

DEV Community: Adam McKenna

Why developers need to challenge product and design

Fast as a Veyron: Achieving 100/100 on Google PageSpeed Insights and beyond

Concepts and Design

Simple UI design

Progressive Web App

The Application Shell Model

The PageSpeed Insight Metrics

Avoid landing page redirects

Eliminate render-blocking JavaScript and CSS in above-the-fold content

Prioritise visible content (via the Application Shell Model Architecture)

Enable compression

Leverage browser caching

Reduce server response time

Minify HTML, CSS and JavaScript

Optimize images

Conclusion

What on earth is User Experience?

Definitions of User Experience (and the problem)

Exploring the metrics

User Satisfaction

Conclusion

References

Three Things I Learnt at .concat() 2018 (and other reasons to visit Salzburg)

No. 1: Practical tips for designing Progressive Web Apps.

No. 2: You can use CSS Custom Properties today.

No. 3: Address your bias

Conclusion

Bonus: Here's Some Other Reasons to Visit Salzburg

Scenery

Cuisine and Drinks

Untersberg Mountain

What have been your biggest learning curves as developers? #discuss

Improve the performance of WebStorm (and other JetBrains IDEs)

What is WebStorm?

Optimising WebStorm's performance

Setup Config Files

Improve the Performance

Appearance and Behaviour

Editor

Plugins

Directories

Languages & Frameworks

Tools

Conclusion

Sources

How, and why, to clean SVG markup

SVG Anatomy (SVG == Markup)

What Markup can we remove?

XML Prolog

The <svg> version Attribute

XML Comments

The <title> and <desc> tags

The <g> tags

The <svg> viewBox Attribute

IDs

What's next?

Why not use an automated SVG optimiser, like SVGO or SVGOMG?

Conclusion

Writing Baseline Accessible Markup and Styles

Testing Tools

Labels

On the web

Android

Swift

Forms and Input Placeholders

On the web

Android

Swift

Writing Good Labels and Descriptions

Be succinct

Avoid describing control type in text

Avoid describing control state in text

Indicate what an element does

Don’t mention the exact gesture or interaction

Dialogs

Images - 'alt' Attribute

Headers

Hidden Descriptions

Empty states

The `<svg>` version Attribute

The `<title>` and `<desc>` tags

The `<g>` tags

The `<svg>` `viewBox` Attribute