Jeremy Keith's Blog, page 75

Offline itineraries with service workers

The Trivago website is a progressive web app. That means it

is served over HTTPS,
has a web app manifest JSON file, and it
has a service worker script.

The service worker provides an opportunity for a nice bit of fun branding���if you lose your internet connection, the site provides a neat little maze game you can play. Cute!

That���s a fairly simple example of how service workers can enhance the user experience when the dreaded offline situation arises. But it strikes me that the travel industry is the perfect place to imagine other opportunities for offline enhancements.

Travel sites often provide itineraries���think airlines, trains, or hotels. The itineraries consist of places, times, and contact information. This is exactly the kind of information that you might find yourself trying to retrieve in an emergency situation, like maybe in a cab on the way to the airport or train station. Perhaps you���re stuck in traffic, in a tunnel. Or maybe you don���t have a data plan for the country you���re currently in. Either way, wouldn���t it be great if you could hit the website for your airline or hotel and get your itinerary, even if you���re offline.

Alright, let���s think this through���

Let���s assume that an individual itinerary has its own URL. That URL is a web page of information, mostly text, with perhaps an image or two (like a map). Now when you make your booking, let���s have the service worker cache that URL (and its assets) for offline access.

Hmm ���but there���s a good chance that the device you make the booking on is not the same device that you���d have with you out and and about. Because caches are local to the browser, that���s a problem.

Okay, but of these kinds of sites have some kind of log-in mechanism. So we could update the log-in flow a bit: when a user logs in, check to see if they have any itineraries assigned to them, and if they do, fire off an event to the service worker (using postMessage) to cache the URLs of the itineraries.

Now that the itineraries are cached, the final step is to create a custom offline page. As well as the usual ���Sorry, the internet���s down��� message, we can say ���Sorry, the internet���s down ���but here are your itineraries���. (This is kind of like the pattern you see on blogs like mine, Ethan���s, or Mike���s���a custom offline page that lists cached URLs of articles you���ve previously visited).

That���s just one pattern off the top of my head. It���s fun to imagine the different ways that service workers could be used to enhance the experience of just about any site, but they seem particularly relevant to travel sites���dodgy internet connections and travelling go hand-in-hand. At Clearleft, we���ve been working with quite a few travel-related clients lately so that���s why these scenarios are on my mind: booking holidays, flights, and so on. But, as I���ve said before and I���ll say again, every website can benefit from becoming a progressive web app.

Ends and means

The latest edition of the excellent History Of The Web newsletter is called The Day(s) The Web Fought Back. It recounts the first time that websites stood up against bad legislation in the form of the Communications Decency Act (CDA), and goes to recount the even more effective use of blackout protests against SOPA and PIPA.

I remember feeling very heartened to see WikiPedia, Google and others take a stand on January 18th, 2012. But I also remember feeling uneasy. In this particular case, companies were lobbying for a cause I agreed with. But what if they were lobbying for a cause I didn���t agree with? Large corporations using their power to influence politics seems like a very bad idea. Isn���t it still a bad idea, even if I happen to agree with the cause?

Cloudflare quite rightly kicked The Daily Stormer off their roster of customers. Then the CEO of Cloudflare quite rightly wrote this in a company-wide memo:

Literally, I woke up in a bad mood and decided someone shouldn���t be allowed on the Internet. No one should have that power.

There���s an uncomfortable tension here. When do the ends justify the means? Isn���t the whole point of having principles that they hold true even in the direst circumstances? Why even claim that corporations shouldn���t influence politics if you���re going to make an exception for net neutrality? Why even claim that free speech is sacrosanct if you make an exception for nazi scum?

Those two examples are pretty extreme and I can easily justify the exceptions to myself. Net neutrality is too important. Stopping fascism is too important. But where do I draw the line? At what point does something become ���too important?���

There are more subtle examples of corporations wielding their power. Google are constantly using their monopoly position in search and browser marketshare to exert influence over website-builders. In theory, that���s bad. But in practice, I find myself agreeing with specific instances. Prioritising mobile-friendly sites? Sounds good to me. Penalising intrusive ads? Again, that seems okey-dokey to me. But surely that���s not the point. So what if I happen to agree with the ends being pursued? The fact that a company the size and power of Google is using their monopoly for any influence is worrying, regardless of whether I agree with the specific instances. But I kept my mouth shut.

Now I see Google abusing their monopoly again, this time with AMP. They may call the preferential treatment of Google-hosted AMP-formatted pages a ���carrot”, but let���s be honest, it���s an abuse of power, plain and simple.

By the way, I have no doubt that the engineers working on AMP have the best of intentions. We are all pursuing the same ends. We all want a faster web. But we disagree on the means. If Google search results gave preferential treatment to any fast web pages, that would be fine. But by only giving preferential treatment to pages written in a format that they created, and hosted on their own servers, they are effectively forcing everyone to use AMP. I know for a fact that there are plenty of publications who are producing AMP content, not because they are sold on the benefits of the technology, but because they feel strong-armed into doing it in order to compete.

If the ends justify the means, then it���s easy to write off Google���s abuse of power. Those well-intentioned AMP engineers honestly think that they have the best interests of the web at heart:

We were worried about the web not existing anymore due to native apps and walled gardens killing it off. We wanted to make the web competitive. We saw a sense of urgency and thus we decided to build on the extensible web to build AMP instead of waiting for standard and browsers and websites to catch up. I stand behind this process. I���m a practical guy.

There���s real hubris and audacity in thinking that one company should be able to tackle fixing the whole web. I think the AMP team are genuinely upset and hurt that people aren���t cheering them on. Perhaps they will dismiss the criticisms as outpourings of ���Why wasn���t I consulted?��� But that would be a mistake. The many thoughtful people who are extremely critical of AMP are on the same side as the AMP team when it comes the end-goal of better, faster websites. But burning the web to save it? No thanks.

: seriously, just give me a bloody opt-out from this knock-off web

��� Alex Russell (@slightlylate) January 14, 2017

Ben Thompson goes into more detail on the tension between the ends and the means in The Aggregator Paradox:

The problem with Google���s actions should be obvious: the company is leveraging its monopoly in search to push the AMP format, and the company is leveraging its dominant position in browsers to punish sites with bad ads. That seems bad!

And yet, from a user perspective, the options I presented at the beginning ��� fast loading web pages with responsive designs that look great on mobile and the elimination of pop-up ads, ad overlays, and autoplaying videos with sounds ��� sounds pretty appealing!

From that perspective, there���s a moral argument to be made for wielding monopoly power like Google is doing. No doubt the AMP team feel it would be morally wrong for Google not to use its influence in search to give preferential treatment to AMP pages.

Going back to the opening examples of online blackouts, was it morally wrong for companies to use their power to influence politics? Or would it have been morally wrong for them not to have used their influence?

When do the ends justify the means?

Here���s a more subtle example than Google AMP, but one which has me just as worried for the future of the web. Mozilla announced that any new web features they add to their browser will require HTTPS.

The end-goal here is one I agree with: HTTPS everywhere. On the face of it, the means of reaching that goal seem reasonable. After all, we already require HTTPS for sensitive JavaScript APIs like geolocation or service workers. But the devil is in the details:

Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR.

Emphasis mine.

This is a step too far. Again, I am in total agreement that we should be encouraging everyone to switch to HTTPS. But requiring HTTPS in order to use CSS? The ends don���t justify the means.

If there were valid security reasons for making HTTPS a requirement, I would be all for enforcing this. But these are two totally separate areas. Enforcing HTTPS by withholding CSS support is no different to enforcing AMP by withholding search placement. In some ways, I think it might actually be worse.

There���s an assumption in this decision that websites are being made by professionals who will know how to switch to HTTPS. But the web is for everyone. Not just for everyone to use. It���s for everyone to build.

One of my greatest fears for the web is that building it becomes the domain of a professional priesthood. Anything that raises the bar to writing some HTML or CSS makes me very worried. Usually it���s toolchains that make things more complex, but in this case the barrier to entry is being brought right into the browser itself.

I���m trying to imagine future Codebar evenings, helping people to make their first websites, but now having to tell them that some CSS will be off-limits until they meet the entry requirements of HTTPS ���even though CSS and HTTPS have literally nothing to do with one another. (And yes, there will be an exception for localhost and I really hope there���ll be an exception for file: as well, but that���s simply postponing the disappointment.)

No doubt Mozilla (and the W3C Technical Architecture Group) believe that they are doing the right thing. Perhaps they think it would be morally wrong if browsers didn���t enforce HTTPS even for unrelated features like new CSS properties. They believe that, in this particular case, the ends justify the means.

I strongly disagree. If you also disagree, I encourage you to make your voice heard. Remember, this isn���t about whether you think that we should all switch to HTTPS���we���re all in agreement on that. This is about whether it���s okay to create collateral damage by deliberately denying people access to web features in order to further a completely separate agenda.

This isn���t about you or me. This is about all those people who could potentially become makers of the web. We should be welcoming them, not creating barriers for them to overcome.

Global Diversity CFP Day���Brighton edition

There are enough middle-aged straight white men like me speaking at conferences. That���s why the Global Diversity Call-For-Proposals Day is happening this Saturday, February 3rd.

The purpose is two-fold. One is to encourage a diverse range of people to submit talk proposals to conferences. The other is to help with the specifics���coming with ideas, writing a good title and abstract, preparing the presentation, and all that.

Julie is organising the Brighton edition. Clearleft are providing the venue���68 Middle Street. I���ll be on hand to facilitate. Rosa and Dot will be doing the real work, mentoring the attendees.

If you���ve ever thought about submitting a talk proposal to a conference but just don���t know where to start, or if you���re just interested in the idea, please do come along on Saturday. It���s starts at 11am and will be all wrapped up by 3pm.

See you there!

Famous first words

What hath God wrought?

Mr. Watson, come here���I want to see you.

lo

Larry, can you get my razor?

GDPR and Google Analytics

Enforcement of the European Union���s General Data Protection Regulation is coming very, very soon. Look busy. This regulation is not limited to companies based in the EU���it applies to any service anywhere in the world that can be used by citizens of the EU.

It���s less about data protection and more like a user���s bill of rights. That���s good. Cennydd has written a techie���s rough guide to GDPR.

The Open Data Institute���s Jeni Tennison wrote down her thoughts on how it could change data portability in particular. While she welcomes GDPR, she has some misgivings.

Blaine���who really needs to get a blog���shared his concerns in the form of the online equivalent of interpretive dance ���a twitter thread (it���s called a thread because it inevitably gets all tangled, and it���s easy to break.)

It���s increasingly looking like GDPR is a massive scaled-up version of the idiotic and horrifically mis-managed ���cookie law���.

— Blaine Cook (@blaine) January 28, 2018

The interesting thing about the so-called ���cookie law��� is that it makes no mention of cookies whatsoever. It doesn���t list any specific technology. Instead it states that any means of tracking or identifying users across websites requires disclosure. So if you���re setting a cookie just to manage state���so that users can log in, or keep items in a shopping basket���the legislation doesn���t apply. But as soon as your site allows a third-party to set a cookie, it���s banner time.

Google Analytics is a classic example of a third-party service that uses cookies to track people across domains. That���s pretty much why it exists. We, as site owners, get to use this incredibly powerful tool, and all we have to do in return is add one little snippet of JavaScript to our pages. In doing so, we���re allowing a third party to read or write a cookie from their domain.

Before Google Analytics, Google���the search engine business���was able to identify and track what users were searching for, and which search results they clicked on. But as soon as the user left google.com, the trail went cold. By creating an enormously useful analytics product that only required site owners to add a single line of JavaScript, Google���the online advertising business���gained the ability to keep track of users across most of the web, whether they were on a site owned by Google or not.

Under the old ���cookie law���, using a third-party cookie-setting service like that meant you had to inform any of your users who were citizens of the EU. With GDPR, that changes. Now you have to get consent. A dismissible little overlay isn���t going to cut it any more. Implied consent isn���t enough.

Now this situation raises an interesting question. Who���s responsible for getting consent? Is it the site owner or the third party whose script is the conduit for the tracking?

In the first scenario, you���d need to wait for an explicit agreement from a visitor to your site before triggering the Google Analytics functionality. Suddenly it���s not as simple as adding a single line of JavaScript to your site.

In the second scenario, you don���t do anything differently than before���you just add that single line of JavaScript. But now that script would need to launch the interface for getting consent before doing any tracking. Google Analytics would go from being something invisible to something that directly impacts the user experience of your site.

I���m just using Google Analytics as an example here because it���s so widespread. This also applies to third-party sharing buttons���Twitter, Facebook, etc.���and of course, advertising.

In the case of advertising, it gets even thornier because quite often, the site owner has no idea which third party is about to do the tracking. Many, many sites use intermediary services (y���know, ���cause bloated ad scripts aren���t slowing down sites enough so let���s throw some just-in-time bidding into the mix too). You could get consent for the intermediary service, but not for the final advert���neither you nor your site���s user would have any idea what they were consenting to.

Interesting times. One way or another, a massive amount of the web���every website using Google Analytics, embedded YouTube videos, Facebook comments, embedded tweets, or third-party advertisements���will be liable under GDPR.

It���s almost as if the ubiquitous surveillance of people���s every move on the web wasn���t a very good idea in the first place.

Design ops for design systems

Leading Design was one of the best events I attended last year. To be honest, that surprised me���I wasn’t sure how relevant it would be to me, but it turned out to be the most on-the-nose conference I could’ve wished for.

Seeing as the event was all about design leadership, there was inevitably some talk of design ops. But I noticed that the term was being used in two different ways.

Sometimes a speaker would talk about design ops and mean “operations, specifically for designers.” That means all the usual office practicalities���equipment, furniture, software���that designers might need to do their jobs. For example, one of the speakers recommended having a dedicated design ops person rather than trying to juggle that yourself. That’s good advice, as long as you understand what’s meant by design ops in that context.

There’s another context of use for the phrase “design ops”, and it’s one that we use far more often at Clearleft. It’s related to design systems.

Now, “design system” is itself a term that can be ambiguous. See also “pattern library” and “style guide”. Quite a few people have had a stab at disambiguating those terms, and I think there’s general agreement���a design system is the overall big-picture “thing” that can contain a pattern library, and/or a style guide, and/or much more besides:

Styleguides, Pattern Libraries and Design Languages
Design Systems vs. Pattern Libraries vs. Style Guides ��� What���s the Difference?
Design Systems, Style Guides, and Pattern Libraries: Oh My!
What���s the difference between style guides, pattern libraries, and design systems?

None of those great posts attempt to define design ops, and that’s totally fair, because they’re all attempting to define things���style guides, pattern libraries, and design systems���whereas design ops isn’t a thing, it’s a practice. But I do think that design ops follows on nicely from design systems. I think that design ops is the practice of adopting and using a design system.

There are plenty of posts out there about the challenges of getting people to use a design system, and while very few of them use the term design ops, I think that’s what all of them are about:

Why Design Systems Fail
Tips for in-house teams in a free market software culture
Putting your design system into practice

Clearly design systems and design ops are very closely related: you really can’t have one without the other. What I find interesting is that a lot of the challenges relating to design systems (and pattern libraries, and style guides) might be technical, whereas the challenges of design ops are almost entirely cultural.

I realise that tying design ops directly to design systems is somewhat limiting, and the truth is that design ops can encompass much more. I like Andy’s description:

Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements.

Now, in theory, that can encompass any operational stuff���equipment, furniture, software���but in practice, when we’re dealing with design ops, 90% of the time it’s related to a design system. I guess I could use a whole new term (design systems ops?) but I think the term design ops works well …as long as everyone involved is clear on the kind of design ops we’re all talking about.

Needs must

I got a follow-up comment to my follow-up post about the follow-up comment I got on my original post about Google Analytics. Keep up.

I made the point that, from a front-end performance perspective, server logs have no impact whereas a JavaScript-based analytics solution must have some impact on the end user. Paul Anthony says:

Google won the analytics war because dropping one line of JS in the footer and handing a tried and tested interface to customers is an obvious no brainer in comparison to setting up an open source option that needs a cron job to parse the files, a database to store the results and doesn���t provide mobile interface.

Good point. Dropping one snippet of JavaScript into your front-end codebase is certainly an easier solution ���easier for you, that is. The cost is passed on to your users. This is a classic example of where user needs and developer needs are in opposition. I���ve said it before and I���ll say it again:

Given the choice between making something my problem, and making something the user���s problem, I���ll choose to make it my problem every time.

It���s true that this often means doing more work. That���s why it���s called work. This is literally what our jobs are supposed to entail: we put in the work to make life easier for users. We���re supposed to be saving them time, not passing it along.

The example of Google Analytics is pretty extreme, I���ll grant you. The cost to the user of adding that snippet of JavaScript���if you���ve configured things reasonably well���is pretty small (again, just from a performance perspective; there���s still the cost of allowing Google to track them across domains), and the cost to you of setting up a comparable analytics system based on server logs can indeed be disproportionately high. But this tension between user needs and developer needs is something I see play out again and again.

I���ve often thought the HTML design principle called the priority of constituencies could be adopted by web developers:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors.

In Resilient Web Design, I documented the three-step approach I take when I���m building anything on the web:

Identify core functionality.
Make that functionality available using the simplest possible technology.
Enhance!

Now I���m wondering if I should���ve clarified that second step further. When I talk about choosing ���the simplest possible technology���, what I mean is ���the simplest possible technology for the user���, not ���the simplest possible technology for the developer.���

For example, suppose I were going to build a news website. The core functionality is fairly easy to identify: providing the news. Next comes the step where I choose the simplest possible technology. Now, if I were a developer who had plenty of experience building JavaScript-driven single page apps, I might conclude that the simplest route for me would be to render the news via JavaScript. But that would be a fragile starting point if I���m trying to reach as many people as possible (I might well end up building a swishy JavaScript-driven single page app in step three, but step two should almost certainly be good ol��� HTML).

Time and time again, I see decisions that favour developer convenience over user needs. Don���t get me wrong���as a developer, I absolutely want developer convenience ���but not at the expense of user needs.

I know that ���empathy” is an over-used word in the world of user experience and design, but with good reason. I think we should try to remind ourselves of why we make our architectural decisions by invoking who those decisions benefit. For example, ���This tech stack is best option for our team���, or ���This solution is the best for the widest range of users.��� Then, given the choice, favour user needs in the decision-making process.

There will always be situations where, given time and budget constraints, we end up choosing solutions that are easier for us, but not the best for our users. And that���s okay, as long as we acknowledge that compromise and strive to do better next time.

But when the best solutions for us as developers become enshrined as the best possible solutions, then we are failing the people we serve.

That doesn���t mean we must become hairshirt-wearing martyrs; developer convenience is important ���but not as important as user needs. Start with user needs.

Heisenberg

I wrote about Google Analytics yesterday. As usual, I syndicated the post to Ev���s blog, and I got an interesting response over there. Kelly Burgett set me straight on some of the finer details of how goals work, and finished with this thought:

You mention ���delivering a performant, accessible, responsive, scalable website isn���t enough��� as if it should be, and I have to disagree. It���s not enough for a business to simply have a great website if you are unable to understand performance of channel marketing, track user demographics and behavior on-site, and optimize your site/brand based on that data. I���ve seen a lot of ugly sites who have done exceptionally well in terms of ROI, simply because they are getting the data they need from the site in order make better business decisions. If your site cannot do that (ie. through data collection, often third party scripts), then your beautifully-designed site can only take you so far.

That makes an excellent case for having analytics. But that���s not necessarily the same as having Google analytics, or even JavaScript-driven analytics at all.

By far the most useful information you get from analytics is around where people have come from, where did they go next, and what kind of device are they using. None of that information requires JavaScript. It���s all available from your server logs.

I don���t want to come across all old-man-yell-at-cloud here, but I���m trying to remember at what point self-hosted software for analysing your log traffic became not good enough.

Here���s the thing: logging on the server has no effect on the user experience. It���s basically free, in terms of performance. Logging via JavaScript, by its very nature, has some cost. Even if its negligible, that���s one more request, and that���s one more bit of processing for the CPU.

All of the data that you can only get via JavaScript (in-page actions, heat maps, etc.) are, in my experience, better handled by dedicated software. To me, that kind of more precise data feels different to analytics in the sense of funnels, conversions, goals and all that stuff.

So in order to get more fine-grained data to analyse, our analytics software has now doubled down on a technology���JavaScript���that has an impact on the end user, where previously the act of observation could be done at a distance.

There are also blind spots that come with JavaScript-based tracking. According to Google Analytics, 0% of your customers don���t have JavaScript. That���s not necessarily true, but there���s literally no way for Google Analytics���which relies on JavaScript���to even do its job in the absence of JavaScript. That can lead to a dangerous situation where you might be led to think that 100% of your potential customers are getting by, when actually a proportion might be struggling, but you���ll never find out about it.

Related: according to Google Analytics, 0% of your customers are using ad-blockers that block requests to Google���s servers. Again, that���s not necessarily a true fact.

So I completely agree than analytics are a good thing to have for your business. But it does not follow that Google Analytics is a good thing for your business. Other options are available.

I feel like the assumption that ���analytics = Google Analytics��� is like the slippery slope in reverse. If we���re all agreed that analytics are important, then aren���t we also all agreed that JavaScript-based tracking is important?

In a word, no.

This reminds me of the arguments made in favour of intrusive, bloated advertising scripts. All of the arguments focus on the need for advertising���to stay in business, to pay the writers���which are all great reasons for advertising, but have nothing to do with JavaScript, which is at the root of the problem. Everyone I know who uses an ad-blocker���including me���doesn���t use it to stop seeing adverts, but to stop the performance of the page being degraded (and to avoid being tracked across domains).

So let���s not confuse the means with the ends. If you need to have advertising, that doesn���t mean you need to have horribly bloated JavaScript-based advertising. If you need analytics, that doesn���t mean you need an analytics script on your front end.

Analysing analytics

Hell is other people���s JavaScript.

There���s nothing quite so crushing as building a beautifully performant website only to have it infested with a plague of third-party scripts that add to the weight of each page and reduce the responsiveness, making a mockery of your well-considered performance budget.

Trent has been writing about this:

My latest realization is that delivering a performant, accessible, responsive, scalable website isn���t enough: I also need to consider the impact of third-party scripts.

He���s started the process by itemising third-party scripts. Frustratingly though, there���s rarely one single culprit that you can point to���it���s the cumulative effect of ���just one more beacon��� and ���just one more analytics script��� and ���just one more A/B testing tool��� that adds up to a crappy experience that warms your user���s hands by ensuring your site is constantly draining their battery.

Actually, having just said that there���s rarely one single culprit, Adobe Tag Manager is often at the root of third-party problems. That and adverts. It���s like opening the door of your beautifully curated dream home, and inviting a pack of diarrhetic elephants in: ���Please, crap wherever you like.���

But even the more well-behaved third-party scripts can get out of hand. Google Analytics is so ubiquitous that it���s hardly even considered in the list of potentially harmful third-party scripts. On the whole, it���s a fairly well-behaved citizen of your site���s population of third-party scripts (y���know, leaving aside the whole surveillance capitalism business model that allows you to use such a useful tool for free in exchange for Google tracking your site���s visitors across the web and selling the insights from that data to advertisers).

The initial analytics script that you���asynchronously���load into your page isn���t very big. But depending on how you���ve configured your Google Analytics account, that might just be the start of a longer chain of downloads and event handlers.

Ed recently gave a lunchtime presentation at Clearleft on using Google Analytics���he professes modesty but he really knows his stuff. He was making sure that everyone knew how to set up goals���n���stuff.

As I understand it, there are two main categories of goals: events and destinations (there are also durations and pages, but they feel similar to destinations). You use events to answer questions like ���Did the user click on this button?��� or ���Did the user click on that search field?���. You use destinations to answer questions like ���Did the user arrive at this page?��� or ���Did the user come from that page?���

You can add as many goals to your site���s analytics as you want. That���s an intoxicating offer. The problem is that there is potentially a cost for each goal you create. It���s an invisible cost. It���s paid by the user in the currency of JavaScript sent down the wire (I wish that the Google Analytics admin interface were more like the old interface for Google Fonts, where each extra file you added literally pushed a needle higher on a dial).

It strikes me that the event-based goals would necessarily require more JavaScript in order to listen out for those clicks and fire off that information. The destination-based goals should be able to get all the information needed from regular page navigations.

So I have a hypothesis. I think that destination-based goals are less harmful to performance than event-based goals. I might well be wrong about that, and if I am, please let me know.

With that hypothesis in mind, and until I learn otherwise, I���ve got two rules of thumb to offer when it comes to using Google Analytics:

Try to keep the number of goals to a minimum.
If you must create a goal, favour destinations over events.

Words I wrote in 2017

I wrote 78 blog posts in 2017. That works out at an average of six and a half blog posts per month. I’ll take it.

Here are some pieces of writing from 2017 that I’m relatively happy with:

Going Rogue. A look at the ethical questions raised by Rogue One

In AMP we trust. My unease with Google’s AMP format was growing by the day.

A minority report on artificial intelligence. Revisiting two of Spielberg’s films after a decade and a half.

Progressing the web. I really don’t want progressive web apps to just try to imitate native apps. They can be so much more.

CSS. Simple, yes, but not easy.

Intolerable. A screed. I still get very, very angry when I think about how that manifestbro duped people.

����������. Recounting a story told by a taxi driver.

Hooked and booked. Does A/B testing lead to dark patterns?

Ubiquity and consistency. Different approaches to building on the web.

I hope there’s something in there that you like. It always a nice bonus when other people like something I’ve written, but I write for myself first and foremost. Writing is how I figure out what I think. I will, of course, continue to write and publish on my website in 2018. I’d really like it if you did the same.