Leon Paternoster

Building a mobile-first university website: Use and report on Google Core Web Vitals

2022-08-13T17:22:00+01:00

I started work as ARU’s web manager on the last day of May. Since then I’ve gone through the usual round of introductions and getting to know the structure of a large organisation. It’s been fun – and hard work.

I’ve identified performance as the most important area to improve on the website, especially on mobile devices. There are several reasons for this:

Obviously, prospective students are an important audience, and, according to Google Analytics, more than 70% of visitors to our Clearing page use a mobile device.
ARU has a healthy international student cohort, especially from India. While we should be wary of making assumptions about connectivity and device usage (for example, Indian traffic has a similar level of 4G connectivity as the UK), we need to cater for the possibility that visitors from some countries will not be using a high-spec device on a reliable network, or will be more likely to use a mobile.
Websites that perform well on mobile are more likely to perform well on any device and screen. Additionally, visitors will use different devices in different contexts at different times. For example, student A may initially scout courses on a mobile during a bus journey. They may then apply for a course using a laptop at home.
Google likes sites that appear in their search results to perform well. Google search is the biggest source of traffic to ARU.
We generally score poorly in Lighthouse reports.
Better performance will mean more student applications.

In this post I’m going to start outlining what I’m doing in my role as web manager, rather than what I feel we can do technically or with the design of the website.

Start measuring Google Core Web Vitals (CWVs)

Are CWVs the only measure of performance? Nope. Are they a replacement for watching people use your site? No. Do they measure how quickly sites load after you click/tap on a link on a Google search results page (SERP) above everything else? Probably.

But I think they reflect how likely a site performs well. Reducing javascript bundle sizes, optimising images and reducing layout shift are uncontroversial optimisations.

More cynically, if most of our website traffic comes from Google, it makes sense to focus on how Google evaluates performance. And how quickly it loads after a visitor clicks/taps a link is important.

CWVs have traction. Developers are familiar with CLS, TTFB etc., while our SEO agency are saying we need to improve our scores. After all, their job is to get our courses appearing higher up SERPs. In turn, the marketing team is aware of the importance of performance. This is good news, as third-party scripts applied via Google Tag Manager (GTM) and the drive to use more imagery and video in the cause of “engagement” will lower our scores.

Image from Heydon.

Finally, everyone’s aware of Google and probably believes it knows a thing or two about performance – and why it’s so important. (Incidentally, just last week an agency sent a PDF ranking websites by their Lighthouse scores – it’s a smartish piece of marketing.)

Start reporting on CWVs

Lighthouse provides colour-coded performance scores, and even a pass or fail. That’s useful for the big, high-level reports I‘m sending out every month, along with Site Improve accessibility and QA ratings.

Is a score out of 100 anything more than a broad indication of how well a site performs across thousands of different devices? In thousands of different contexts? Probably not. But that’s not the main benefit of reporting Lighthouse scores. I’m hoping that raising awareness means that performance becomes more of a consideration when we develop a new feature, design a component, discuss the website roadmap or add a new script via GTM. If it does, that will only benefit our visitors.

How to report on CWVs

I’ve started by putting the home page through a Page Speed Test whenever I need a figure. It’ll fluctuate, but it’s better than nothing. I’m looking at services like Treo to automate tests, score over a period of time, and monitor different pages, regions, devices and network conditions.

The Guardian asks permission to show embedded Instagram content. Is this the future?

2022-04-09T13:59:00+01:00

I’m not sure how long The Guardian has been asking permission before displaying embedded Instagram posts, but I only noticed this today:

Most websites would just display the embedded Instagram content. Another (accessible) option could be to screenshot the post and link to it.

Facebook is particularly egregious when it comes to placing unasked-for cookies on website visitors’ devices. But those of us running websites have also been neglectful of the responsibility we have to protect our visitors who, after all, are just looking for some information or amusement. Ignorance is no defence – you still see social sharing widgets on international newspaper websites even though no-one ever clicks on them. And we’ve known for years they track all visitors.

Trust is a central element of any brand, far more important than a logo or tone of voice. 99% of your visitors may not be aware of how Facebook tracks them, or even be bothered, but that doesn’t absolve you from considering the privacy implications of what you do. We value your privacy is an empty statement if you’re not at least using no-cookie YouTube embeds, or if you’re adding a Facebook widget or pixel to your website.

One wonders at the cynicism the Facebooks and Googles of this world have engendered among website owners. Maybe that’s changing, or maybe in a few years organisations won’t have any choice in the matter – The Guardian is simply adapting to a world in which browsers don’t allow third party cookies and governments enforce opting-in.

Focusing your writing with a simple scaffolding technique

2021-07-11T12:18:00+01:00

I’ve been writing an article about advertising online over the last couple of weekends. It’s a subject I’ve been interested in for years, and I can offer some perspective as we place lots of Facebook ads at work (spoiler: they work really well).

I was fairly happy with it. I liked the tone I’d struck along with a few well turned passages. But it had got a little flabby, hitting 2000 words. More importantly, the point of it had become unclear, and I began overreaching, making less sense as I tried to draw the thing into some coherent whole.

Time to start again.

I’m not one for convoluted writing processes. I’ve looked at apps like Obsidian and struggled to find a use for them, preferring to simply draft something and refine it as I go along.

However, I sometimes use a structuring technique which dates back to my university and teacher training days. In this case it helped sort out my meandering article.

The article scaffold

The technique is simple. Instead of thinking in terms of complete sentences and paragraphs, you focus on your argument and its development through using basic chunking elements. These form a scaffold for your actual article.

You can use any text editor or word processor. Writing your scaffold in Markdown works particularly well as the elements can be found in HTML.

The elements are:

A title

Don’t sweat this too much in the beginning as you’ll probably edit it several times as you build your scaffold.

It should be the final element you edit before publishing, as it will exist in its own little world on social media or in your readers’ RSS feeds or inboxes. You’ll need to think about how it works away from your website.

At this stage it’s the briefest expression of your argument, which you’ll expand in the next element.

A standfirst (or TL;DR)

Summarise your article in a sentence or two. How would you explain your argument to someone in a few seconds? Assume they’re not interested in your subject.

The standfirst isn’t about justifying your argument in any detail – it should be a statement of what you feel is the truth. The evidence comes later.

It’s worth doing this as early as possible as it will largely determine your article’s structure. But be prepared to change it.

Sections

An argument will usually progress through several top level points. List them here as second level headings. Each should follow on from the last one, so you may want to begin the heading with a connective (but, however, additionally, despite etc.)

An article will normally consist of 3-5 sections. If you have more I’d suggest going back to your standfirst and reconsidering your argument.

Again, be prepared to delete, edit and reorder as you go along.

Bullet point sub-sections

Within each section you’ll make several points. This is the deepest level of your article, where you’ll present the evidence for your argument.

List every point here, as well as ideas for quotes and images, as bullets beneath the second level heading. Make use of nesting to create sub-sub points.

Your final article won’t need to reflect this nested structure. You’re making sure that each point is explicit, discrete and considered, and relates properly to the whole. In our prose we can easily smooth over inconsistencies and incomplete thinking with a flourish or writerly trick. Bullets don’t allow us this luxury.

The order of sections and sub-sections may shift as the argument develops.

I’m using Mardown as it makes the element structure visually clear. Word processors have an outline feature you could use.

Writing’s a fluid process

You can use this scaffolding technique at any point in the writing process. Sometimes it’s useful to dump your thoughts onto the page before trying to structure them better, sometimes you might want to start with a scaffold. You can switch between the scaffold and your draft at any time.

Not every article needs a scaffold. I tend to use one when I hit 1000+ words. Often, I’m not looking to write a well-reasoned argument when I post to my website.

Each element of the scaffold affects the other. For example, you might find a nested bullet point is unexpectedly important and warrants expansion, changing your section structure and the standfirst.

You’ll eventually reach a stage where you’re happy with the underlying argument and your draft is coming along nicely. At this point, you’ll move from the scaffold to the draft, with a more tightly argued, easier to read article in the offing. But be flexible – you can still change your argument at any point before publication.

Navigation submenus – what’s the best approach? Dropdown, hovers, clicks or keeping it flat?

2021-04-11T00:00:00+01:00

I agree with this post from Mark Root-Wiley which argues that dropdown navigation menus are best activiated when a user clicks the link (or, correctly speaking, button) rather than hovers over it. Adrian Roselli also writes really well on how to implement this UI pattern accessibly.

Adrian Roselli’s navigation menu item is clearly styled as a button that should be clicked, complete with animated caret control.

This came up at work recently, where the hover pattern has been implemented on an extranet. I predict it will cause problems for the normal reasons – affordability, dexterity and annoyance – especially considering the age of the audience using the website. Any testing, or even your own day-to-day experience, will demonstrate how frustrating it is to hover over a link to reveal a submenu, and then avoid accidentally triggering dropdowns.

But whether you’re using a click or hover pattern, you’re still creating a new set of problems whenever you implement any dropdown menu. That is, what’s the top level link/button text for?

Take Adrian’s menu. It asks two questions:

Can I click the “Blog” text? Is it a link to somewhere else or just a button label?
If it does serve as a link to a page, what should appear on that page if all the subpages are listed when you click the button?

Adrian opts to makes it a link to the website home page, which I feel is confusing as it’s labelled “Blog”, even if Adrian’s site is a blog. It’s also a fairly complicated set of controls to negotiate – a link/label next to a disclosure widget.

This lead me to follow Heydon Pickering’s advice on accessible menu systems when we developed the work site last year:

Where a site has a lot of content, a carefully constructed information architecture, expressed through the liberal use of tables of content “menus” is infinitely preferable to a precarious and unwieldy dropdown system. Not only is it easier to make responsive, and requires less code to do so, but it makes things clearer: where dropdown systems hide structure away, tables of content lay it bare.

The top level menu is eniterly flat. In the spirit of not hiding content behind disclosure widgets, you’ll also see as many navigation items as your screen’s width will allow:

No dropdowns or hamburgers. Note the main content consists of a menu of common tasks.

Feedback and testing have revealed no problems with this approach – it appears users are happy to delve into tables of content several levels deep, as long as the trail is clear enough.

The “Borrow” page on the Suffolk Libraries website. Navigation is essentially a table of contents presented as a set of cards.

However, I can see possible benefits in implementing dropdown menus well:

Increased discoverability of website subsections
Confirmation of what a website section contains, without having to click through to that section
Efficiency for users familiar with the navigation menu, where dropdowns serve as a shortcut to the content they’re interested in

I am, on the whole, very happy with using a flat, signposting system for website navigation, but what do you think? Do you see a use for dropdowns in some circumstances?

CMSs should allow component-based page creation, but does WordPress Gutenberg get it right?

2021-03-27T00:00:00+00:00

My former colleague Alice was bemoaning the lack of a way of dropping various components into a page using her current CMS. She’s right, I think; you’d expect any modern CMS to allow editors to build pages from smaller, self-contained elements, such as alerts, promo boxes, galleries and accordions.

Unless your pages follow a predictable pattern – on a blog, for example – you’re relying on the theme author to code a finite set of templates that will cover a set of requirments you need to predict when the site’s built.

This was one of the main requirements when we rebuilt the work website using Statamic last year. We ended up with a list of around 20 components we could drop into any page, ranging from simple alerts to more complex collection listings:

Building a page in Statamic 2

Some simple maths tells us we can create around 400 different page layouts based on shifting these components around. WordPress.com includes around 100 different “blocks” out of the box, giving editors even more possibilities.

Different approaches to implementing component/block UIs

Statamic and WordPress offer different ways for editors to create components. Statamic takes a more form-based approach, where the editor enters data into clearly styled fields.

The z-bar UI consists of a form where editors enter text into fields or use a standard file picker.

The editor doesn’t have any visual relationship to what’s rendered on the actual website:

A typical z-bar on the Suffolk Libraries website.

WordPress’s Gutenberg, on the other hand, attempts to make the editor look more like what will appear on the website. For example, this is the “cover” block (an image with some text over it):

WordPress doesn’t use traditional form fields. Instead, it attempts to give the editor an idea of what the block will look like on the website.

This would appear to be a good idea – tying the editing process to its output saves editors from flipping between the rendered page and the CMS. But having set up several users on WordPress, and trained a couple of editors in Statamic, I think it poses a few problems.

Firstly, filling in and amending traditional forms is a familiar, predictable process. You enter some text, select an element from a dropdown or complete a file upload dialogue. If you want to the edit the text, you head back to the relevant field and just fill it in again.

In WordPress, this process varies according to the block you’re editing, and can take some figuring out. For the cover editor it’s fairly clear, but involves an element of discovery – you click on the image, which reveals a toolbar with a ‘Replace’ option:

You have to click on the picture to reveal the toolbar.

The picture slider block works differently. When you click on the block, a different type of toolbar appears, with no ‘Replace’ option:

You have to click on the picture to reveal the toolbar, but this one is a lot different.

In my experience, less technically skilled editors find this frustrating, even when they have experience of using different CMSs, including pre-Gutenberg WordPress. In every case, I’ve ended up installing the the Classic Editor.

Secondly, editors can find it difficult to navigate around a page and add new content without a framework of clearly demarcated boxes and forms. Take this example of the verse block followed by a cover. Coming out of the verse block and starting a new paragraph involves a frustrating number of clicks:

Simply entering a new paragraph on longer, more complex pages can be surprisingly difficult.

I’m a really big fan of WordPress. It offers a free, fast way to get online and publishing to the indieweb. Half of the features I implement on this site, such as comments, come out of the box. It has a huge range of plugins, and is mature, stable software that handles updates and upgrades fantastically well.

But I think Gutenberg causes problems for editors who won’t be willing to learn how it works. There are some poor UI decisions to overcome. Perhaps more worringly, I think it may be misconceived – keeping content separate from its appearance allows users to focus on creating and editing; let the designer worry about how it ends up looking.

Of course, I could be wrong. My experience is limited to four or five people. Maybe tens of millions are happy with Gutenberg. But it’d be interesting to see how often the Classic Editor is installed.

Libraries as alternative

2021-03-13T00:00:00+00:00

How we think about the function of libraries in relation to other organisations that provide the same set of things can be complex. Especially when we consider the list of competitors, some of whom are frankly terrifying in their reach and resources:

Coffee shops (a place to spend leisure time)
Gyms (ditto)
Book stores (books, browsing experience)
Amazon (physical and e-title provision)
Google (provision of information)
The internet!

Libraries offer some unique services – free PC and internet access, for example. But these tend to be the services other organisations don’t want to offer because there’s no profit in them. While it’s really important we do this, we need a role beyond being a part of the social care system. After all, simply providing things for people who can’t afford them is a very narrow interpretation of what a universal service is. More practically: what role do libraries play when everyone has broadband and a device? How do you get the whole population engaged with and supportive of what you do?

This seems a difficult position for libraries. How do we compete with the internet? Perhaps Jason Fried provides a clue when writing about how Basecamp’s Hey! email service isn’t in competition with, say, gmail:

When you think of yourself as an alternative, rather than a competitor, you sidestep the grief, the comparison, the need to constantly measure up. Your costs are yours. Your business operates within its own set of requirements. Your reality is yours alone. An alternative to competition.

This makes perfect sense for an online product, and there are lots of services taking this approach. They often focus on the ethical aspect of what they’re offering – micro.blog is a nicer Twitter that doesn’t own your content, Hey! isn’t gmail and won’t track you etc.

This seems a powerful aspect of the library offer, and a route out of competing with the Amazons of this world. After all, our only motive is to provide the public with a good service, which is self-evidently more ethical than, say, Google. We won’t track you or sell your personal information to anyone else, our staff don’t work 10 hour shifts without comfort breaks, we’re built on a model of recycling things etc. etc. This is the basis of a good alternative offer.

But note the low numbers in Jason Fried’s post. He estimates Hey! will get 200,000 “alternative to gmail” users at most – at $99/year/user that’s an income of around $20m/year, which sounds great for establishing a solid business in a distinct, well-defined market, but that’s not what libraries are. We can’t settle on appealing to a small subset of the local population by offering a niche product.

I’m not sure what the answer to the competition problem is. Libraries as alternative offers a great way to market ourselves to new audiences, but what’s the bigger reason for using the library?

I’m not posting to leonpaternoster.com often anymore; subscribe to This Day’s Portion instead!

2021-02-28T00:00:00+00:00

As you may or may not have noticed, I haven’t posted anything to this site in a while.

That’s because leonpaternoster.com is really just a professional portfolio now.

I was lucky enough to be able to publish anything I liked here, but that doesn’t really fit in with the work vibe, and hasn’t for a while.

But! I do still blog at This Day’s Portion. Here you’ll find notes, links and posts on:

Building and writing on the web
Politics
Books
TV
More personal stuff
The odd photo (I am in no way a photgrapher, professional or amateur)

The frequency varies, with most posts coming at the weekend. In February I blogged 12 times, mostly 1-300 word efforts.

So if you are interested in subscribing head over to the This Day’s Portion RSS feed now.

Cheers! 👋

Marketing without tracking

2021-02-27T00:00:00+00:00

DF has been going in hard on Apple Mail not blocking tracking pixels over the last week or so. The relationship between the providers of what we consume content with (browser and email client/services) and the publishers of our content (Facebook, Twitter, Mailchimp et al) is a murky one but, as Apple has discovered, pushing privacy strengthens the brand.

Perhaps those of us working in marketing not only need to make sure we make ethical decisions when we use/choose our tools, but also the possibility we won’t even be able to use services that track every user move in the future. What will marketing look like then? How do we plan? How do we wean ourselves from the notion that data is somehow all important? That marketing is all about outsmarting and persuading people?

Why brand web pages?

2021-02-13T00:00:00+00:00

What price traditional visual branding? — Or rather, what value does carefully crafted branding have to users in a fluid, interactive medium where they want to do something? Where they feel in control of the flow of the experience? Where they can view the content in a million and one different contexts the author has no control over? Is it worth putting the same amount of effort into the visual brand of a web page as, say, a print advert? Could we put more resources into the actual content and functionality?

Adam Morse touches on this point when proposing a form of automated branding for digital.

In the past, you might spend 10-15 minutes picking a typeface and font size in Microsoft word in preparation for printing it out and sharing with others. But when you publish on Twitter, Facebook, Medium, you’re removed from this part of the design process. Even [on] your own website, you don’t have absolute control over how the typography will render for the end user. Chaos Design: Before the robots take our jobs, can we please get them to help us do some good work?

Note, he’s not arguing for no branding at all, more a version where AI makes decisions over things like colour combinations. However, Morse is the creator of an atomic CSS API, which basically says to front-end developers: “Don’t bother trying to create ‘semantic’ class names”, which I’d argue is the first step in removing the “artisinal” element from web design.

Would it be better thinking of web pages in terms of function and interfaces, and build them in the same way we might build a car dashboard? Dashboards more or less look the same and perform similar basic functions, but they work differently or just feel different depending on the car and how well they fulfil their purpose. The brand is derived from the experience of using the dashboard.

On the other hand, some still like the quirky visual nature of our sites, and how it aids the meaning of our words:

Among the many small violences of the social media platforms is the way they squash every contribution into the same rectangle, framed by the same buttons. They do this so they can assemble those contributions into a larger structure; a timeline. They prefer neat bricks; stackable, interchangeable. Heterogeneous, weird-shaped content won’t do… Foundation (part two)

I like the way good interaction looks, and I get easily annoyed at artisinal looking sites. But that’s just me. I’d be interested in any research on how important visual branding is to users. Even Nielsen says creating the right impression quickly is important, but what exactly creates that impression?

Static works

2020-05-03T00:00:00+01:00

I’ve been managing the Suffolk Libraries website for seven years, during which it’s been through three incarnations. The first two were built on standard PHP/MySQL database CMSs – WordPress in version two. The third version, built in 2016 and still used at the time of writing, is probably the most interesting. It’s a “static” site, built using Jekyll, a static site generator.

In 2016 this was revolutionary. As far as I’m aware, it was the first public sector/not-for-profit website to be built in this way. Static was the big new thing. From an organisational point of view the move was successful, I think. The web team has always consisted of just one (me) or two people, with no budget to speak of, and it’s responsible for everything web: hosting, designing and building the site, writing and managing the content and social media. All this with no large, cross-departmental council web team to provide support; yet, before the service was divested to an independent not-for-profit, the library was traditionally the most visited part of the Suffolk County Council website. In very practical terms, moving to static meant we didn’t have to worry about two things out of hours: the site falling over with a 500 error, or getting hacked.

Users also benefited. Most importantly, the Suffolk Libraries website is fast. It scores As across the board on WebPageTest, recording load times of under a second. I’ve accessed the site in plenty of Suffolk villages using a Moto G4 phone and a patchy 3G connection; it’s inherently accessible in a rural county with vast differences in income. Indeed, I would have liked to have written a progressive web app so certain key pages could have been served without a connection at all, but, alas, no time or money for this. Because our host offers some basic dynamic functionality (such as forms and build hooks for automated daily builds), users had just enough interactivity to find up-to-date information quickly.

Apart from the fact users could depend on the site being available at all hours – it’s not been uncommon to have 100% uptime over a month – it’s handled traffic spikes effortlessly. On Thursday 19 March our page views increased threefold over the previous Thursday. Our coronavirus page was served more than 2,500 times in a two hour period – unsurprising, as it contained important information on what we were doing about customer fines and we’d just announced we’d be shutting all our buildings. It was a good example of Eric Meyer’s call to get static:

If you are in charge of a web site that provides even slightly important information, or important services, it’s time to get static. Get Static

In short, serving a traditionally static site, enhanced with minimal features and javascript (mainly in the form of jQuery) has worked for us and users for over four years.

Static changed

Back when static was the new thing advocates often noted that it represented a return to the halcyon days of the early-2000s web – pre-CMS, pre-scripting and pre-databases. This was a selling point. After all, it’s simpler, faster and more secure to serve plain HTML than have a router assemble pages on the fly from data stored in a database, right?

If you buy this argument you need to accept its corollary: static pages are enough to meet most user needs most of the time. The Suffolk Libraries website proves this is true. So, if you’re publishing a blog or a site that just provides users with information, 90% of that can be done with flat HTML, and you either sacrifice some or all of the other 10% (probably forms or automatic updates based on variables such as the date) or you find another means. That might be some basic server side functionality (a la Netlify forms), or through javascript.

But static changed pretty quickly from around 2017, and I think we’ve lost an important strand of web development where we make sure our websites deliver important information as quickly as possible to as many people as possible all of the time. Coronavirus may have refocused our thinking.

Under the traditional static model, the heavy lifting of building pages from includes and local or external data is done when the website is compiled into flat HTML files, whether that’s on a PC or a server. This happens out of view (hence Jekyll, incidentally), completely separately from any user involvement. Javascript is used to enhance UI, perhaps through offering sorting or filtering functions. All the user does is download the HTML file and its assets.

Under a newer model (which even has its own Netlify-created brand name of JAMstack) much of this heavy lifting is moved to the user’s browser. Websites are created as SPAs, where HTML, CSS, data and javascript are downloaded in one bundle and the javascript creates pages based on user interaction.

Now, this is still static in that there’s no server-side scripting or database involved when users see pages, and it makes sense for websites where state needs to change often – for websites that behave more like apps. And it may make it easier to develop sites with predictable CSS “at scale”.

But the downside is that we lose two of the things static promised in the first place: speed and resilience. To go back to the Suffolk Libraries example, do we want to be in a situation where users download the whole of the React library on a Moto G4 in an area with a patchy internet connection in order to find out whether a library is closed?

There is no more reliable and fast way to provide users with content than by serving static HTML and CSS. This is an extremely powerful feature of the web, and something static once clearly promised. Static can mean static in the purest sense, and it’s something that works for developers and users.

Building a web that lasts

2019-12-28T15:35:58+00:00

How do we make web content that can last and be maintained for at least 10 years? asks Jeff Huang.

Another back-to-basics post bemoaning the death of the web. Maybe I sound skeptical? I don’t mean to – I agree with the sentiment, if not all the suggestions; maintaining just one HTML page seems absurd. I sometimes think these blogs are really just an expression of nostalgia, for a time when our limited skills were enough to stay on top of the web.

Yes, we want to generate new pages using a simple, robust templating system, even if that system disappears one day.

Perhaps the answer lies in making sure your CMS creates HTML pages from text files, rather than a database/API. Shifting text files is a lot easier than extracting them from a database. Jekyll, for example, uses Markdown stored in a folder. Copy the folder and you’ve copied your content.

I am all for resisting SPAs and complex build chains. I fit squarely in Jeff’s group of professionals who are able to get a website up and running, but aren’t paid just to do this. The nostalgia, again.

Whatever your approach, this is mainly a matter of will. I’ve used WordPress, Hugo and Jekyll over the years, and you can still find the first ever post I published over eleven and a half years ago.

I’m very glad I never shifted everything over to a service like Medium, but I am reliant on Github/Netlify at the moment. Netlify’s move to charging for more individual components (such as build minutes) concerns me. I’m therefore thinking of making the next logical step in an indieweb set up: old fashioned, paid for hosting. And if I want to be able to post stuff when and wherever I want, I’ll need an old-fashioned CMS, which won’t have such a complex set of dependencies as Jekyll. Kirby, probably; I expect PHP is as robust as anything out there, apart from HTML itself, of course.

As we approach the end of the decade, it looks like we’re returning to the set up we had at its beginning. Comforting, if nothing else.

Hiding accessibility on web pages

2018-09-01T00:00:00+01:00

I’ve unhidden my skip link (as you may be able to see in the top right hand corner of the page). Why? Well, if you hide a link and neglect to reveal it on focus, keyboard navigators experience a weird jump when they tab to it. It seems as if something’s broken.

Whether you still need skip links is perhaps a moot point.

You can get round this problem by hiding the link with CSS and revealing it when the user tabs to it. Lots of sites do this, including the New York Times (try pressing the tab key a couple of times and you’ll see what I mean).

This strikes me as an odd approach. The link won’t appear until you discover it accidentally, and then disappears when you tab on through the page. It’s confusing. As a developer, you’re also hacking CSS, writing extra code.

But there’s another question we should perhaps ask: Why hide it in the first place?

What harm does it do? If the majority of our visitors are using a screen and mouse to navigate around a web page, clicking the link will simply move them to the page content. This is expected behaviour, assuming the link’s been labelled logically (probably hard to argue with Skip to main content). Granted, users may pause for a second to wonder why it’s there – it’s perhaps something to interpret.

If some visitors use a keyboard to navigate, having a visible skip link is helpful.

The only other argument I can think of is that it doesn’t look good, or it’s inelegant, not minimal etc.

There’s a pattern when it comes to hiding accessibility features. On this page, most websites wouldn’t show you:

The skip link
The navigation menu on a narrow screen, replacing it with a hamburger icon, or a Menu button
The comment form honey pot field

It seems as if accessibility features are something to be hidden. Accessibility detracts from the ideal, default experience of a web page.

Don’t hide accessibility

There’s something dishonest about hiding things. It’s like the developer is ashamed of what they’ve placed on the page. We don’t really think our beautiful, primarily visual page is better than a usable, accessible design (that can still be beautiful)?

Rather than concentrating on how we hide and reveal page elements, it perhaps makes more sense to put our efforts into making pages accessible in the first place. In the same way that genuinely building mobile first should make our pages quicker and easier to use for everyone, building visible accessible elements will help make them more inclusive.

Kiosk testing: Different users, different results

2018-08-19T00:00:00+01:00

We don’t read enough about the results of kiosk testing, maybe because people don’t kiosk test enough. But Thomas wrote an excellent post on some last minute tests on the MoMu website, sharing his methodology and five findings.

I can’t recommend this testing enough. It’ll snag major usability problems, challenge your assumptions and help get into users’ minds. It’s also relatively easy to set up, so you can use it to test any website change, not just a whole new release.

You’ll want to test your “typical” website’s users rather than just anyone (although this is still useful in identifying problems that will trip anyone up), or, worse still, whoever’s paying for the site. We all want to build websites usable by anyone, and your marketing department will no doubt have a new audience to target (which is probably younger than your current audience). But if you run a website, you at least need to be aware of who is using it at the moment, and whether you’re going to confuse them with a change.

Which is why I found Thomas’s first finding interesting: Hiding navigation is totally OK as it contradicts lots of testing I’ve done. Now, kiosk testing can take some thought. On the MoMu website the navigation menu toggle button is very clearly styled with a nice big drop shadow, and uses a label rather than an icon. Perhaps the results would have been different if they’d used a standard hamburger icon.

The MoMu navigation menu toggle

Nonetheless, I suspect the Suffolk Libraries’ audience may have made a difference. It’s older, and perhaps less comfortable with toggles and switches, especially if they haven’t been styled clearly. We therefore use toggles very sparingly on our site. Off the top of my head, there’s just a search icon at narrow widths and accordions in event listings.

The point is you’re testing something in context. How well is it designed? Who’s using it? Does everyone experience it in the same way? Change any of these factors, and you’ll likely get a different result – even if some findings are more relevant to all users than others.

If users aren’t bothered about griddy layouts, why are we?

2018-08-17T00:00:00+01:00

Hidde de Vries posted some excellent thoughts on not bothering with complex CSS fallbacks for older browsers (in this case when using CSS grid):

I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.

Granted, what we mean by “content” is vague. A blog post is different from a list of trainers, which may require a more complex layout than a single column. But what always strikes me about these types of posts (which have been written for years) is that they don’t take the obvious next step and recommend ditching complex layouts altogether.

If users don’t care about a complex layout then why should the people making web pages? Why do we bother creating griddy layouts at all when it means more work and more code?

(Actually, a few designers have argued just this.)

Hidde acknowledges the main reason for implementing grids is to keep on-brand: Some brand design guidelines come with specific grids that content needs to be layed [sic] out in. In other words, it’s not users who demand grids, but marketing departments.

But that’s not a good reason, and something designers should resist. You could argue for making things look fancy for their own sake by referring to the world of advertising. Companies still pay for display adverts and TV spots because they communicate something about the the “brand” beyond its content and price. They don’t want to look cheap, and nor does your website:

… an ad can emit a powerful signal about a brand, regardless of information content. Online ads are cheap and easy to make, but the problem is, they look it.

But this is by the by. Even if we accept the Don Draper logic, a simple layout doesn’t have to look cheap. If your user is happier with plainer then that’s a good business reason for keeping it simple. Online, the interface is the brand, and your testing and feedback should dictate the layout you implement.

Note: That’s not a reason to discard CSS grid 😇 – I don’t mean to conflate a CSS technique with a type of layout. Any layout is quicker and easier to implement in CSS grid than by using floats, an age old CSS hack.

Getting round GDPR with dark patterns. A case study: Techradar

2018-08-12T00:00:00+01:00

Many news and big blog sites have introduced onerous and confusing popovers since the introduction of GDPR in May. Unfortunately, this will no doubt result in GDPR banner blindness, where users will simply click ‘Accept’, thereby allowing websites to install tracking javascript, just as they did before 25 May 2018.

This is not GDPR’s fault. The guidelines are clear. Websites have to:

ask users to explicitly opt-in to share their data
not use legalese or similarly unclear language

It would be very easy to design an unobtrusive banner that did this. Something like:

We can share your anonymised browsing history with advertisers so you get tailored adverts Share your browsing history →

Of course, no-one would ever click this link because no-one wants to be served adverts, or share their data with someone they don’t know. As a consequence, sites that rely on tracking and identifying visitors are getting round GDPR by the way they know best: obfuscation. They could rephrase this request to collect data by being honest about why they need it:

We can share your anonymised browsing history with advertisers so you get tailored adverts. We rely on the money we get from tailored adverts to pay our journalists. Please share your browsing history →

There are very few examples of sites doing this well. Smashing Magazine is one, although it recently moved to a part-subscription model for its income, so isn’t reliant on installing tracking cookies. The pop up is a minor annoyance which presents a simple binary choice (although you are nudged to accept cookies through the placement, colour and attached image of the Okay option, and the button labels could describe the actions more explicitly):

Smashing Magazine does opting in the right way

But old habits die hard. Techradar writes reviews of electronic things – it’s a useful resource if you’re comparing products. Here’s the popover they display when you visit their site. I’m sure they’re not the only website doing this sort of thing:

The Techradar advertising opt-in dialogue

There are a few dark pattern techniques at play here that make proceeding without opting-in difficult:

You only get to access the site immediately by clicking ‘I accept’ – the popover makes proceeding any other way impossible. Most users will therefore click ‘Accept’ without thinking.
The ‘I accept’ link is bigger than the link to not opt-in (which isn’t labelled clearly, of course). It’s labelled ‘Show purposes’ and set in pale blue, hard to see 12 pixel type. It’s easy to ignore. The design implies it’s a secondary, perhaps technical action.
‘Show purposes’ is confusing. I don’t want to see how Techradar uses cookies. What I want to do is not opt-in. Will clicking this link allow me to not opt in? Will I have to read more stuff in order to proceed without logging in? It should be labelled something like Don’t accept and proceed. I’m really having to think in order to make my way through this UI.

Unfortunately, clicking ‘Show purposes’ to not opt-in doesn’t end the process. Instead, it reveals the following:

The second popover. You're not done yet.

Another popover to negotiate, using the same dark pattern techniques. The primary action is not to not opt-in (we’re in the land of the double negative), but to accept the site’s cookies. The secondary, ‘technical’ option is to Reject all. Presumably that’ll do the job:

Another popover. Another small, confusingly labelled link to click.

I get the feeling Techradar really don’t want us not to opt-in. Again, the primary action leads us to opt-in, and the alternative is very confusingly labelled. Presumably, ‘Leave’ means leave the website? But I do want to read the article. Techradar have put me in a situation where it seems I have to accept cookies in order to use the site. Let’s see what happens if you do click ‘Leave’, though. Ah, success! Sort of:

Perhaps unsurprisingly, Techradar don't like adblockers. So they throw a popover at you.

At least the text here is clearer, and Techradar are honest about why they don’t want you to use an adblocker. Incidentally, we’d need to change our more straightforward banner:

This is an easy one. We’ll continue with our Adblocker, thank you. And we’re there. Of course, this being Techradar, we get a popover for our troubles:

Because I really wanted to sign up for a newsletter at this stage.

Technically speaking Techradar are getting explicit consent to collect visitor data. They’re obviously not operating in the spirit of the regulations, but I also think they’re in breach in at least two areas:

They make it seem as if you can’t use the site unless you opt-in. According to the ICO website, you have to Avoid making consent to processing a precondition of a service.
On the same page, the ICO says you must Be clear and concise. Although this is a subjective requirement, I can’t see how anybody could interpret this process as clear and concise.

Bearing in mind the murky history of online advertising, and some sites’ reliance on it as a source of income, it’s depressingly inevitable that organisations will find ways to get round the new regulations. The only way GDPR will achieve what it set out to do will be through prosecutions. If they don’t prosecute, people will just click or tap ‘Accept’ and the online advertising industry will carry on as before, while claiming it’s doing the right thing. I’m skeptical. If you’ve any interest in privacy and you’d like to keep websites fast, make sure you’re using a browser that puts you in control of trackers and cookies, and use an adblocker. Firefox (or, better still, Firefox Focus on a mobile) is the obvious choice.

Jekyll Tachyons starter theme for Jekyll

2018-07-28T00:00:00+01:00

Jekyll Tachyons is a starter theme for Jekyll that makes it easy to:

get started on a Jekyll project using the Tachyons CSS framework
remove unwanted Tachyons modules from your project, thereby reducing your CSS payload
choose to inline your styles in the document head or refer to a stylesheet, perhaps saving an additional request for a file and getting your ‘critical’ CSS served as soon as possible
set custom CSS breakpoints for -ns, -m and -l

Get Jekyll Tachyons on Github

Why use Jekyll Tachyons?

If you use Tachyons and Jekyll a lot it’ll save you time and effort setting up new projects. I’ve used it on a couple of projects (and to tidy up the work website):

It’ll also make it easy to remove unnecessary CSS. Tachyons is small (weighing in under 14k gzipped), but it’s still worth removing any CSS you don’t need, especially if you’re not gzipping.

If you’re obsessing over performance you might appreciate putting your CSS in the document head rather than referring to an external stylesheet.

As for Why use Jekyll and Tachyons?.. I’ve written about why I use Tachyons full stop, but this also provides a really quick and easy way to prototype HTML pages that share components such as a header and footer. Just edit your header and footer files in the Jekyll _includes folder and you’re away. All depends on how you work, of course, but I like getting into the browser as soon as possible.

Todo

Update to the latest Tachyons
Improve the docs

If you’ve got any questions/comments/bugs raise them on Github or contact me via Twitter or at leon.paternoster@zoho.com

The Adventures of Sherlock Holmes in HTML

2018-07-04T00:00:00+01:00

Original Sidney Paget illustration from The Man with the Twisted Lip

I made a website from the 1892 Sherlock Holmes collection The Adventures of Sherlock Holmes. 12 stories, some of which you may well recognise, originally published in serial form in The Strand magazine.

I’m not a huge Holmes fan, but these stories provided a few minutes’ Victorian pleasure. It can be fun reading Doyle’s character between the lines; protestant, conservative, anti-royalist, a streak perhaps of non-conformism, some romanticism. They have generated some excellent pastiches and adaptations: the best probably being Anthony Burgess’ Murder to Music, along with some of the Cumberbatch and Freeman BBC episodes.

So, bearing in mind my slightly meh attitude to the books, and the fact you can easily download them for free, why do this?

HTML is the best format for online books

What I mean is: I like the idea of navigating to a website and starting to read. You don’t need a new device or software; just your browser and a phone, tablet or PC (assuming the text’s been responsively styled). Pick up your reading at any time from another device.

The Sherlock Holmes stories seemed just right for this. They’re short (most can be read in 15-30 minutes), not too high brow and are freely available in pretty decent HTML on Gutenberg. Victorian readers would have bought the magazine every month; in a better world, you could possibly see modern readers subscribing via RSS, and reading each new episode in their RSS software (another advantage: HTML is infinitely portable). An attentive reader could also start (cross)referencing via the magic of hyperlinks to create all sorts of interesting rabbit holes.

The technical challenge

Behind the scenes I’m using my normal technical stack: Jekyll, Tachyons, Github and Netlify. The stories are broken down into a chapters collection, which can be used to automatically generate a table of contents, and to split the stories into separate pages. Disappointingly, I discovered only the first story, A Scandal in Bohemia, is divided into chapters, so this wasn’t really necessary, and reading is actually easier if you don’t split the text up into separate pages. Who knew – scrolling is better on a screen than flipping, although this may not apply if you were HTMLifyimg War and Peace.

(The table of contents did mean I got to use my favourite HTML elements, details and summary: semantic and accessible toggable content in pure HTML, I’ve no idea why these aren’t all over the internet.)

You can bookmark your place in the text by clicking on the # sign that appears when you hover over a paragraph. Unfortunately, the (excellent) anchor.js doesn’t work particularly well on mobile; so much so I’ve decided to hide (as in display:none) anchors on narrow screens. I may take Dmitry Fadeyev’s approach and add a bookmark toggle to the page so that anchors are either visible or not, regardless of the device. If you are reading across devices you’ll also need to use a cloud bookmarking service (Firefox has one baked in). This isn’t perfect, but it’s keeping it no-login-required pure ☺️.

(Note to self: this could be a good time to look into some sort of AWS integration for generating bookmarks on the fly.)

I’ve also been using a very simple “framework” I made a few months back. Jekyll Tachyons creates a basic Jekyll site complete with the Tachyons framework. Most interestingly, you can choose to place styles in the document head or in a separate stylesheet, and pick and choose the Tachyons modules it loads. I’m also using it on this site.

There are lots of possibilities here. I could index the text with Algolia to make it searchable and somehow categorised. If only I had the time to look into the potential of plain HTML and text.

Inclusive web design is web design for everyone, including you

2018-01-07T00:00:00+00:00

Heydon makes a good point about how we all, at some point during our day (or lives), need designers to make web pages accessible because we’re finding something difficult. We are all physically, cognitively, physiologically, socially or technologically hampered, whether that’s through a permanent condition which means we need to use a screen reader, or in a more difficult to define or temporary way. We may turn 46 and find our our eyesight isn’t what it was, or we get tired more. Our commute into work may get stuck in some godforsaken wood outside Ingatestone which has little or no mobile connection. We might lose our job and find we can only use a knackered, ancient desktop to get online. How do we design for these scenarios?

Ironically enough, the term inclusivity has been used to ghettoise easier to label conditions and states. Unfortunately, there are plenty of overprivileged fools out there willing to exploit any group they deem weaker than themselves. But web designers can and should – and they mostly have honourable intentions, I think – work to make their output truly accessible. If they don’t, they could be excluding anyone, even if you think you have a healthy, wealthy audience.

This isn’t just about putting a skip link at the top of your page, or using ARIA attributes correctly. It’s about a myriad of other little decisions designers and developers have to make in every line of code, such as: adding bullet points to long lists, underlining links, colour contrast, text size, using meaningful imagery, using thoughtful imagery, marking up content properly, thinking twice about using a library or webfont, using appropriate language, making content findable by search engines, etc. etc.

What would an accessible web look like? I’m sure it would look a lot different from how it does now ( – and am not unguilty, obviously).

Skinny Guardian

2017-10-05T00:00:00+01:00

Skinny Guardian was inspired by sites like CNN Lite and Thin NPR – news served with next to no styling. While this may sound (and look) unexciting I find a simple list of headlines an excellent way to get something to read quickly, and because they’re just HTML and CSS, articles load instantly. Perfect on a train or bus journey into work with a poor mobile connection, or when you want something quick to read during your lunch.

Skinny Guardian loads quickly on a phone

The Guardian has an excellent, open API, so the project gave me a chance to work with external, queryable data. I’d only used the Google Maps API in the past, copying some pre-defined templates and queries. With Skinny Guardian, I built my own API queries and wrangled the results into layout files.

The set up

Skinny Guardian uses Jekyll to generate static HTML files, thereby removing any database requirement. I use Netlify hosting for free SSL and a build hook URL, which means I can automate site builds once every 30m if I use something like a free Postman account to send the URL a POST request.

The site simply queries the API whenever it’s built, grabbing the 50 most recent articles and converting the json response into Jekyll data files with the Jekyll Get plugin.

I then use the Jekyll Datapage Generator plugin to convert the json into Jekyll pages that I can list and feed through layout files. Throw in the Tachyons CSS framework, and you have a fast, regularly updated list of Guardian articles to peruse and read.

Making it quick

There’s a bit going on under the hood at build time to make sure the site serves as quickly as possible.

I only use the Tachyons CSS modules the site needs – there are no hover effects, for example. This means the gzipped CSS weighs in at around 7k, half the magic 14k figure. So instead of making a separate request for a CSS file, styles are placed directly in the HTML document’s head, cutting down on load and display times. I also minimise the HTML and CSS.

All this means Skinny Guardian should load quickly, regardless of the quality of your connection. Ideal if you’re stuck between, say, Ingatestone and Brentwood on your commute into work 😄

Lessons learned from developing library self-service software: The launch date shouldn’t be the real launch date

2017-09-02T00:00:00+01:00

Although we’d like to develop products and services iteratively, the truth is organisations think in terms of strict deadlines, mainly because projects have finite budgets that have to be spent within set financial periods. We product owners need to think about how this affects our ability to make changes based on user feedback.

Browsers update regularly, making frequent, (mostly) small changes. This causes little disruption for users. It’s rare you’ll download a big update and find everything is completely different. This is is how we’d like to develop software over several years, such as our self-service system.

But let’s say you, unlike Google, have a finite budget to be spent by a specific date; consequently, you’ll have a set-in-stone launch date – like the ship in the above picture. The expectation is that the product will be ready, and won’t sink if it bumps into any icebergs.

If your best feedback will come from real usage, you might plan a beta phase, as we did when developing self-service software. This is useful, but there’s a big difference between a controlled roll out to four small libraries that are showing an interest in the new system, and installing kiosks in 44 libraries, including Ipswich, Lowestoft and Bury St Edmunds. Generally, staff aren’t particularly interested in the product itself. They just want it to not cause them hassle.

We unearthed user experience problems after I’d installed kiosks in the four beta libraries, problems I would have liked to have fixed more quickly. But we ran up against the big launch date curse of no more project money.

The lesson learned is therefore quite simple:

If you have an official launch date, reserve some money for further changes after this date. Say, at least 10% of the overall budget.

Note: It’s important this money is kept aside for the project. There’s little value in coming in under budget (besides some temporary good PR that’ll come back to bite you later in your career) if your product isn’t perfect – and it’ll never be perfect.

This also means gathering as much live feedback as quickly as you can, and preparing your developers to make changes fast. Wait too long, and the money’s gone.