1. When a user gets their password wrong, and are using email to sign in, send an email with either a one time login URL, or a link to your forgot password flow.
2. If you ask for verification codes and the length is fixed, auto submit the form when the last one is entered. e.g. See Stripe SMS codes component
3. If you perform a password reset, and the user has verified their password twice - allow them to login from this screen, rather than redirecting to the login to ask them to fill details in again.
4. Show a caps lock warning on password fields
5. During signup, if you ask for an email first, perform a gravatar lookup to showcase their avatar and potentially fill in firstname / lastname. Other APIs are also applicable here to lower friction to signup.
6. Auto-focus the first input field on forms.
7. Display password rules before users receive validation errors, preferably with a live strength indicator.
8. On long forms, preserve entered form data even if the session expires.
9. Allow users to toggle visibility of entered passwords and sensitive fields.
10. After errors, return focus to the first invalid field, and on mobile, auto scroll to it.
11. Trim accidental whitespace from email inputs.
12. Use appropriate keyboard types on mobile for specific fields (email, numeric code).
13. Allow swipe to close menus on mobile, using touch down events etc. rather than just tapping hamburgers.
14. Handle slow networks gracefully, and provide online / offline indication. Retry on failed requests.
15. If you email a user, ensure they know which inbox to check, many people have multiple inboxes.
16. Preserve filters and sorts. Users spend time configuring views. Respect them on next visit.
17. If you ask for country of birth. Use the users current browser settings to either appropriately find the most likely country, or at least start the dropdown close to it.
18. Long dropdowns, for the love of all things holy. Make them searchable
19. Provide feedback with 100-300ms.
20. Use verbs on buttons. If I see another button with 'Submit' on it, I might scream.
21. Empty states should be educational. No reports? Create one now.
22. Modals are a design smell. Too many modals feel claustrophobic and interrupt flow.
23. Undo is often better than 'Are you sure?'

First things first:

The lambda layer - WeasyPrint is BIG - I hit size limits with deployment, so having a separate layer built helped keep the size down.

The following repo Cloud Print Utils was a useful resource in building the lambda layer out. This was a key part of the puzzle. Once you've output your lambda layer zip file, the rest is just hooking it up to serverless for deployment.

Once the lambda layer was built out I referenced like below inside serverless.yml - a layer builder was created in Github actions which pushed the artifact up.

configValidationMode: warn // serverless deployment complains without this
provider:
  name: aws
  runtime: python3.12 // WeasyPrint needs 3.12
  timeout: 30
  tracing:
    lambda: true


functions:
  generatePdf:
    handler: handler.generate_pdf
    layers:
      - { Ref: WeasyPrintLambdaLayer }

layers:
  weasyPrint:
    name: lambda-weasyprint-layer
    description: WeasyPrint and its dependencies
    package:
      artifact: layers/weasyprint.zip

The lambda itself was relatively simple. The crux of it was this method. Return the PDF as bytes so it can be written to S3 via an S3Client. Weasyprint does the heavy lifting here.

 def generate_pdf(self, html_content: str, css_path: str) -> bytes:
        try:
            css = CSS(filename=css_path)
            html = HTML(string=html_content, base_url=self.static_dir)
            return html.write_pdf(stylesheets=[css])
        except Exception as e:
            raise

The end goal was to map every single street light in NI, courtesy of this tweet from Wesley Johnston of NI road blog fame: https://twitter.com/niroads/status/1742885280569274471

Currently most of the datasets that you see listed will come with an Irish Grid reference system, which uses Eastings and Northings.

This is a different system to that in use elsewere in the UK, which requires some conversion. I initially had assumed that this webservice might do the job, but alas - no dice. The final Python code to take the dataset and perform the conversion is shown below.

Hopefully its of use to some of your poor souls currently having to wrangle the local Government Open Data datasets into something that you can plot on a Google or OpenStreetMap map.

Of note here, is the pyproj package, which takes the work out. The rest is reading the csv, and writing it back out.

https://epsg.io/29903 Irish Grid

https://epsg.io/4326 to WSG84

import pyproj
import csv

def ingrs_to_latlng(easting, northing):
    crs_irish = pyproj.Proj(init="EPSG:29903")
    crs_wgs84 = pyproj.Proj(init="EPSG:4326")
    lng, lat = pyproj.transform(crs_irish, crs_wgs84, easting, northing)
    return lat, lng

def process_csv_file(input_file_path, output_file_path):
    with open(input_file_path, mode='r') as infile, open(output_file_path, mode='w', newline='') as outfile:
        csv_reader = csv.DictReader(infile)
        fieldnames = csv_reader.fieldnames + ['LATITUDE', 'LONGITUDE']
        csv_writer = csv.DictWriter(outfile, fieldnames=fieldnames)

        csv_writer.writeheader()
        for row in csv_reader:
            easting = float(row['EASTING'])
            northing = float(row['NORTHING'])
            lat, lng = ingrs_to_latlng(easting, northing)
            row['LATITUDE'] = lat
            row['LONGITUDE'] = lng
            csv_writer.writerow(row)

# Replace these with your actual file paths
input_file_path = 'your_input_file.csv'
output_file_path = 'your_output_file.csv'

process_csv_file(input_file_path, output_file_path)

The recent changes at Twitter related to their API pricing is one such example, with Reddit very closely following suit - (apparently inspired by Musk). Both of these platforms right now have Network effects that mean they no longer need to provide comprehensive APIs to third parties. The data that the rest of us willingly provide for free is valuable, so why make it easy for others to grab that data and build on top of their service?

At their infancy APIs provide growth vehicles for many online businesses. Tweetdeck for example was born out of api provision for twitter, which was later acquired. A metric ton of other apps across the web have historically integrated with the generous offerings via their API. However not every app which provides a new interface to a service meets a similar fate.

Many of you will have read this week that the stand alone client app Apollo for Reddit did not share such a fairy tale acquisition ending.

The developer APIs for Facebook prior to the Cambridge Analytica scandal were extensive and designed to do also provide additional growth for the service and many developers optimistically built applications on top of all these public apis, before they got canned.

Fundamentally, if an API is free or low cost, developers need to remember that they are often just a marketing tool to help reach the market.

Since the dawn of time this trend has been apparent. Business provides a shiny API, developers get a hard-on and build on top or it. Tons of applications using that api in turn help introduce a new audience to the app. Company turns API off, keeps the audience.

Which takes us neatly to ChatGPT and OpenAI. Can we guess what their strategy looks like at the moment?

And here we all are, expecting those most deliciously simple APIs to exist until the end of time. Now maybe I'm wrong, maybe I'm old and jaded, but given the API is a loss leader currently given the cost, at the very least the pricing cog of pain at some point in the future is going to need turned. At its worst, it goes away completely having sucked the river of data dry in the process.

From their perspective the API is not only going to be a brand building exercise to reach the mass market but also one designed to ingest additional information and improve the underlying model. How many businesses are going to end up providing the keys to their Kingdom off the back of that? As the saying goes fool me once..

Thankfully many open source AI frameworks are out there providing alternatives and competition, which is undoubtedly helping at least for now to keep OpenAI on their toes, but for those blindly building on their platform without looking at the road ahead the great AI API reckoning is only a matter of time.

“The thought process that went into building these applications, Facebook being the first of them, … was all about: ‘How do we consume as much of your time and conscious attention as possible?’”

And that means that we need to sort of give you a little dopamine hit every once in a while, because someone liked or commented on a photo or a post or whatever. And that’s going to get you to contribute more content, and that’s going to get you … more likes and comments.”

It’s a social-validation feedback loop … exactly the kind of thing that a hacker like myself would come up with, because you’re exploiting a vulnerability in human psychology. The inventors, creators — it’s me, it’s Mark [Zuckerberg], it’s Kevin Systrom on Instagram, it’s all of these people — understood this consciously. And we did it anyway.”

The proliferation of ‘retention’, ‘engagement’ and ‘time spent in product’ as valid business metrics are not in any way helping us to provide better experiences. Tying ourselves to these Pavlovian metrics is sailing digital products in the wrong direction and **its obvious that what is best at capturing our attention isn’t best for our well-being. 'Happiness' and ‘Task Success’ may be harder to measure, but are infinitely more powerful metrics in building successful brands than engagement.

The race to keep us on screen 24/7 makes it harder to disconnect, increasing stress, anxiety, and reducing sleep. Our children are caught in an endless cycle of checking their phones incase they miss out. We are replacing relationships with ‘like streaks’. YouTube and Netflix autoplay the next algorithmically crafted video, even if it eats into our sleep. That’s not even beginning to go down the rabbit hole of what is going on with algorithmic content creation. From James Bridle’s article earlier this month that caught significant attention.

On Youtube: Disturbing Peppa Pig videos, which tend towards extreme violence and fear, with Peppa eating her father or drinking bleach, are, it turns out very widespread.

In fact these sorts of engagement metrics are downright dangerous when abused and the Silicon valley giants have no interest in changing their approach. Algorithmic timelines designed to keep us glued to our devices have us smacked to the eyeballs on content consumption in a zero sum game of attention- whether it is healthy or not. Not only that, but these algorithms are also significantly impacting society.

How many of your have turned off notifications on the various social products that you use to sleep better, to concentrate, to stop you from picking up your phone whilst driving? Twitter’s notification timeline is a great example of how desperate these apps are for your ‘engagement’. The following is a quick list of the scenarios Twitter use when they send a notification:

1. When someone you follow tweets after a while.
2. When someone you have engaged with frequently tweets something
3. When someone you follow retweets someone else.
4. When someone likes a tweet you were mentioned in
5. When two or more of your followers follow someone else
6. When someone retweets you
7. When someone likes something you tweeted
8. When someone @replies you
9. When someone follows you
10. When there is new ‘Highlight tweets’ of people you follow

Facebook's list of notification settings also speaks volumes. When a product is sending notifications for external activity that you are aren’t responsible for in any way it is a pretty good indicator of a dark pattern in UX design. As gatekeepers during product development it is our responsibility to think deeply about the experiences we create and to consider whether they are positively impacting on our end users lives.

Anyone building digital products today should be taking a responsible stance towards building potentially addictive experiences. We need products built on true value, and genuine success of customers, not low barrier behavioural growth hacks that are damaging at best.

First of all, install Modernizr.

Either with yarn or npm.

npm i modernizr

Next step is install the NextJS plugin from: https://github.com/scottydev/next-plugin-modernizr

Add the plugin to your Next.JS config like so:

const withModernizr = require('next-plugin-modernizr');
module.exports = withModernizr({
reactStrictMode: true,
eslint: {
ignoreDuringBuilds: true,
},
});

Add your Modernizrrc file like so:

module.exports = {
"options": [
"addTest",
"setClasses",
"prefixes",
"domPrefixes"
],
"feature-detects": [
"svg",
]
}

In your _app.js dynamically load Modernizr on the fly:

function MyApp({ Component, pageProps }) {
useEffect(() => {
import('modernizr').then(() => {});
}, []);
export default MyApp;

Boom. That should be all you need.

Ambient Background Sounds Sometimes ambient background sounds help to block things out and help you concentrate even better than complete silence. The below are a couple of options.

URL: http://www.rainymood.com

Rainy mood does what it says on the tin, and is a loop of a rainy day / thunderstorm. It’s more of a white noise type soundtrack than it is anything else, but if you prefer simply listening to background sounds over music, its a pretty good place to start.

Perhaps the Sound of a Tropical Beach is more your thing? This Loop on YouTube is perfect for imagining desert island bliss.

URL: http://www.simplynoise.com

Simply Noise is a free online white noise generator, although there are some paid for tracks in there as well; (with a honesty payment policy so you can pay whatever you want) you will however need Flash player to hear them, at least on the website initially.

If you want to go down the slightly more involved root, Boodler is an open source soundscape tool that lets you mash together your own creation. Python geeks eat your heart out.

URL: http://brain.fm

One of my absolute favs online - brain.fm is a commercial service, with tracks that can very quickly put me into thinking mode. I'm a paid customer, and there's not only Focus playlists, but also ones for Relaxation and Sleep.

Spotify PlayLists Here are few Spotify playlists I’ve found on sharemyplaylists.com (a site solely dedicated to Spotify playlists) and have kept around:

Coding Music – Uptempo Electronica, Tycho, The Crystal Method

A soundtrack for coding – Mixture of Electronica, Moby, Massive Attack

Deep Focus – Much more chilled, includes Explosions in the Sky, Six Parts Seven, Shoegaze and Post Rock instrumentals

Coding / Programming / Hacking Slashing – Kosheen, Massive Attack, Phantogram, Thievery Corporation

Post Rock Coding – 65 Days of Static, And So I watch you from Afar, Metavari

Instrumental tracks for Coding – Includes some of the brilliant Trent Raznor Score from the Social Network, (you know, if you fancy pretending you are Zuck for an evening)

Other / Misc. Some other links I found on my travels if you can’t quite manage to find exactly what gets you in the swing.

http://whitenoisemp3s.com/sounds-like/rain

http://musicforprogramming.net

http://djbolivia.blogspot.co.uk/2011/04/music-to-code-by-volumes-1-3.html

Use semantic HTML elements.

HTML5 brought with it many new elements that are designed to be more meaningful. For example

<nav> <section> <article> <footer>

and others are now much more appropriate to use to give semantic meaning to your page than using <div> tags everywhere. These not only provide search engine robots with better understanding of your page architecture, but also make your code much more readable. In order to be backwardly compatible with IE 8, you’ll need to polyfill with HTML5 shiv. Yes, IE8. Because not every market has the latest and greatest browser and if you are building on high traffic websites you have to worry about that. 1% of 1,000,000 visitors, is 10,000 people you are potentially missing out on. Yes, it may be 2018, but those browsers are out there and good frontend code progressively enhances and caters for older browsers when it makes sense to do so.

Pick a CSS Framework.

Modular CSS provides you with a way to reuse blocks of HTML and CSS, so before you get started pick a modular framework convention like BEM, OOCSS or SMACSS. If you are building a site with more than a handful of pages, it doesn’t take long for CSS to become unmaintainable so sensible naming conventions and modularity are a must. Frameworks enforce those conventions that make you think deeper about the code you write.

Write CSS with reuse in mind.

Deeply nested overqualified selectors are also a code smell, not only do they suck for browser performance, (as the browser has to do several fetches over the DOM) but they add additional bytes to your load time and limit reusability. The best practise advise for your class selectors is to aim for two selectors deep at most.

.widget section table tr td h1.widget-title { padding: 10px 20px; font-weight: bold; font-size: 2rem; }.widget .widget-title { padding: 10px 20px; font-weight: bold; font-size: 2rem; } Use a Module Loader

Large applications often need to load core javascript, then additional page specific javascript for particular pages. My approach for this is typically to use RequireJS multipage, although I’ve worked recently on a project that uses a modified version of Paul Irish’s code which is also pretty elegant. The key here is, don’t load JS you don’t need for large applications until you need it, and load it on demand.

Use Modular JS / AMD.

Using Asynchronous module definitions (AMD for short) — provide a great way to write reusable javascript code. Once you are using RequireJS, it makes sense to go down the AMD route. Why AMD? AMD implementations allow developers to define dependencies that must load before a module is executed, so wave goodbye to function undefined errors that can result from Javascript executing in a more linear fashion. AMD implementations also load smaller JavaScript files, and then only when they are needed. Good reading over here. and here on the official requireJS site. I prefer this approach rather than CommonJS, for many of the reasons detailed here. Essentially in my opinion AMD has much more flexibility on the lazy loading and dependency management front.

Minify CSS / JS to trim the fat.

JS and CSS should be optimised before being deployed to production, so setting your project up for that right from the get go with deploy scripts and well battle tested devops is a good way to ensure that the code you deploy is as trimmed of fat as possible. There are a few options for doing this on the server side. For Java, there’s WRO4J, JawR YUI + Ant. PHP you can use the PageSpeed module from Google. This is available on Apache and NGINX.

Lots of developers these days are jumping on Webpack as the defacto standard in frontend bundling and optimisation. However, with great power, comes great responsibility, it’s easy to end up bundling all your dependent modules into one file and spitting out a 1MB+ file even with production switches, particularly if you don’t know what you are doing with code splitting. Webpack configuration is something of an art to get right, so if you are using it to do your compression of your code for production you need to be careful what options you employ, and work out if a module loader with post deploy compression will better suit your needs than a module bundler. Veera Sundar has a nice hello world post that is easy to follow on how to use Webpack with code splitting that explains the process and how to get your configuration right.

Make it Validate.

There was a time in Internet land when everyone and their dog explained the merits of HTML validation. Browsers today do a pretty good job of understanding badly formed HTML and for the record, it’s of no benefit for SEO. However there is something about valid HTML code that pleases me. It indicates that you are dedicated to your craft, attention to detail focused, and care about the multitude of browsers that may be chewing over your HTML. After all, if your HTML is valid, then there’s little excuse for an existing decent browser making a mess of your page, and you’ve also future proofed your application. It also makes your code that bit easier to maintain, and picks up any potential bugs that you might have unwittingly introduced.

Only use JQuery when necessary.

Less is more, particularly when loading sites on mobile 3G / 4G connections so getting rid of Javascript that isn’t necessary is an important frontend task. Whilst jQuery is well recognised and provides a useful layer over native javascript, it’s not needed on every project. See if you can get rid of it altogether on greenfield projects and swap in native JS instead.

Don’t rely on JS to fix CSS problems.

There’s often instances where you can solve frontend problems more efficiently with just CSS, for example, equal heights can be solved with Flexbox. Slide menus for navigation, again, don’t necessarily need javascript and can be performant into the bargain. Need a slideshow? Don’t automatically reach for the Javascript. Although some of these techniques rely on modern browsers, you can always bring your JS in afterwards to support the older browsers and move the execution and loading of those scripts out of the modern browser pipeline.

Defer JS Loading when possible.

By default JavaScript blocks DOM construction and thus delays the time it takes for your browser to first render. Scripts which are not critical to how your page displays on first render should be made asynchronous or deferred until after the first render. How do you do that? A bit like this:

<script src="bundle.js" async></script>

Previously to move JS out of the critical rendering path in older browsers, we all used to script inject. However, that is no longer considered best practice. Moving your JS loading to the footer, adding an ASYNC attribute to your JS should be sufficient to letting the page get on with its thing prior to your JS executing.

Provide a Jank Free Experience.

According to the site dedicated to getting rid of it, jank is any stuttering, juddering or just plain halting that users see when a site or app isn’t keeping up with the refresh rate. Jank is the result of frames taking too long for a browser to make, and it negatively impacts your users and how they experience your site or app. It’s important that as front end developers we understand the causes, how to diagnose and how to resolve Jank issues when they occur to make the web as silky smooth as possible. 9 times out of 10, when I’ve experienced Janky behaviour, it’s typically been to do with direct binding to window scroll events without debouncing, inefficient fixed position CSS or non hardware accelerated CSS animations. Anyway, understanding how to diagnose this is something of an artform in itself, with much of the Chrome Developer tools providing lots of ‘under the hood’ diagnostics to assist with it. Some additional reading. [1] [2] [3]

Use CSS Sprites to cut requests.

Performance is important and every byte you can save downloading resources is money well spent, not only because of the bandwidth saving, but the overall performance of the site for end users. Sprites are a great way to cut down on HTTP requests, and speed up your site. All of the icons and smaller images on your site should be added to a single sprite, and then background positioning used with CSS to show the image. If you aren’t already familiar with it, the following CSS illustrates how that typically looks.

.icon{ background:url(sprite.svg); width:22px; height:22px; display:inline-block; } .no-svg .icon{ background:url(sprite.png); /\*fallback for rubbish browsers\*/ }.icon .twitter{background-position:0 0; } .icon .facebook{background-position:-22px 0;} .icon .pinterest{background-position:-45px 0;} .icon .linkedin{background-position:-67px 0;}

One resource I’m a big fan of which complements this technique is SpriteCow, which does all the hard work of working out the position of your sprites and spits out some CSS for you.

Use SVGs for scalable graphics.

Modernizr is a thing of beauty, and I use it on pretty much every build. This allows me to serve SVG’s to browsers that support it, along with PNG’s to browsers that don’t. It’s also a great way to work out if you’ve got flexbox support or not. If you aren’t already aware (and you should be) Modernizr is a feature detect library that provides additional classes on the HTML element of your page that gives you the flexibility to do this. A bit like this:

<html class="js no-inlinesvg video" />

That means you can write CSS code like the below. One sprite is served to the browser that supports SVG, and another for those older browsers that will only show a PNG.

.myclass { background-image:url('images/sprite.svg'); } .no-inlinesvg .myclass { background-image:url('images/sprite.png'); }

Provide double density PNGs for retina displays

Double Density devices are becoming more and more widespread now, so often your PNGs are often going to look a bit ropey and pixelated on those devices. You should be serving an image twice the size, and detecting the high density devices with a media query and serving that.

/\* for high resolution display \*/ @media only screen and (min--moz-device-pixel-ratio: 2), only screen and (-o-min-device-pixel-ratio: 2/1), only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (min-device-pixel-ratio: 2) { .image { background: url(/path/to/my/highreslogo.png) no-repeat; background-size: 200px 400px; } }

Use REM or EM for sizing.

Great sites don’t dictate the font size for their viewers. Set a base font % on the HTML element in your CSS, then use REM units to set your typography to the correct size. If your design breaks when zoomed in the browser, then there’s px units used somewhere and the scaling won’t play nicely. Pixel density is one of the last things you can rely on with various user devices, so em-based units of measurement put the user back in control of legibility.

Don’t use Icon Fonts

Sorry all you fans of Font Awesome, but I’m not a fan. Required reading. Part 1. Required reading. Part 2. Oh and this:

• Font rendering is very inconsistent across platforms, so your icons can look pretty shit.
• The overhead of download a ton of icon resources to use one or two icons makes no sense.
• SVG support is sufficiently widespread, so the original rationale for using font icons no longer applies.

Don’t use them, Icon Fonts are performance cancer. Consider embedding whatever icons you need in SVG sprites as mentioned earlier.

Progressively Load Web Fonts.

We’ve come a long way from SIFR. Web Fonts now provide us with all kinds of of typographic joy, but they aren’t cheap from a performance perspective. Zach Leatherman is something of a web font pornstar and his article on font loading strategies is a must read for every front end developer. In fact, go read his entire blog on how you should be approaching font loading whilst remaining performant. Ebay also recently open sourced their font loading strategy and the linked article is also a good resource on how to improve performance.

When did reading stuff on the web become pay to play?

I’ll tell you when. When we all got greedy looking for the attention our blogs used to get until social media came along. Or when we got greedy looking for coinage off the onetruecontentsource™. If you enjoy reading on the web chances are you’ve been forced to login to Medium at some point in the last week.

Have any of you noticed the dark UI patterns. I bet you did. I’m guessing you noticed smart programmers / designers / internet celebs tweeting about how shit it is. Maybe someone you respect continually pointed out their accessibility failures. Maybe you nodded your head in agreement. Maybe you even retweeted it. Go you.

Just so we are clear. Medium takes your content, rolls it up into a pretty SEO friendly package for themselves and sells it. Oh, and turns us all into seals waiting for someone to throw us a fish in the process. If you are lucky, you might even get a cut. You know. Like the sort of cut artists get on Spotify. Profit share I think the cool kids call it.

So why is everyone still publishing on it? For what? More eyeballs? More attention? More reach?

Balls to that. If only one of you read this I’ll be happy. At least I own my own platform and I’m not being controlled by some monolithic publishing giant that can do whatever they want and sell whatever advertising they please ON YOUR HARD WORK.

Please. It’s 2019. Learn to market yourself and your content. Quit being lazy waiting for Medium to do it for you. OWN YOUR PLATFORM.

Oh, and don’t get me started on the mini publications that we all jump for fucking joy over being published on. How’s about no. How’s about we starting taking responsibility for the absolute decimation of the traditional web.

You know. That old internet that used to be open and free.