DEV Community: Jim Thoburn

Serving a high quality user experience, without being a server-side expert

Jim Thoburn — Tue, 14 Jan 2020 22:45:43 +0000

Recently an organization asked if I would help them create a web application for a voting contest. The contest would involve a showcase of organizations working to improve Los Angeles that can be voted for by anyone who lives in the city. The winners would collectively receive one million dollars in support. They wanted to host everything on the web and were expecting tens of thousands of voters to visit the web site.

It felt like a huge undertaking with a lot at stake–and that deserved a team of expert designers and engineers. A part of me wanted to tell them, “I’m not qualified to do all of this for you”, but I really wanted to work on the project–so the words that actually came out were, “Yes, of course!”

I had been part of teams working on projects like this one in the past, filling the role of user experience engineer. I knew that I could write high quality HTML, CSS and JavaScript to make a user interface for them. And I had been in the room with experienced server side engineers who were setting up things like servers and databases. Thinking about the qualities of a web application that I had observed those engineers putting effort into, I felt that I should focus on security, scalability and robustness.

I had recently learned about using GitHub pages and Jekyll to make a static web site or application that, by its very nature, would have these attributes.

Security: A folder of static HTML files served directly on the web is going to be almost unhackable. And the source code will be safely stored in a version control system, behind GitHub’s two-factor authentication.
Scalability: HTML files on a CDN are going to be lighting fast for lots of simultaneous visitors.
Robustness: HTML files don’t have moving parts and browsers are super-forgiving when it comes to interpreting HTML, so there’s almost nothing that can break and make the site unavailable.

I had also learned that it’s possible to extend a static web site with third-party services, to add features that may be missing–such as having the ability to accept and save data from visitors–for things like comments on a post and in my case, voting forms.

The basic pieces that I felt the voting application needed were:

Form that users can use to vote for their favorite organizations
The ability to save voting forms in a database, so they can be retrieved and counted
A way to for users to authenticate themselves, to keep the voting fair

The static user interface would be core of the application, showcasing the organizations and providing a voting form.

Netlify’s forms feature provided a way to save the voting data. It worked really well and was super easy to set up!

<form name="vote" data-netlify="true">…</form>

Auth0’s passwordless sign in service provided a way to authenticate the voters. They have an API that can be accessed with JavaScript, so it worked great with a static site.

const webAuth = new auth0.WebAuth({
  …
  redirectUri: `${window.location.origin}/vote/authenticated/`
});

const form = document.querySelector('form[name="vote"]')

form.addEventListener('submit', function(e) {
  webAuth.passwordlessStart();
})

Auth0 provides easy integration with other services like Twilio and SendGrid for sending text messages and emails that visitors can use to authenticate themselves, without needing to create a password.

Cloudflare provided a CDN to keep the web site fast for everyone and essentially reduced bandwidth costs for the project to just $20 per month. Their service was also useful for, things like true 301 and 302 redirects, which aren’t generally available for a static web site. And their service provides free HTTPS, which keeps the web site secure and private for visitors. Cloudflare also provides protection from DoS and bad robots with things like automatic CAPTCHAs. This turned out to be useful in terms of keeping the voting fair and protected from automatic form submissions.

The combination of GitHub and Netlify also made it possible to set up multiple staging web sites for each phase of the project, automatically deployed from a few core Git branches.

Build command
    jekyll build --config _config.yml,_config/staging.yml
Publish directory
    _site/

Discovering these services and putting them to use for each aspect of the project felt really empowering. And it left me feeling like it’s never been a better time to be designing and building on the web, with so many high quality tools and materials to work with. If there’s anything that you take away from this article, I hope that it will be–when you’re faced with a seemingly impossible project, you’ll tell yourself “I can do it!” 🙂

You can learn more about using static site generators to make scalable web products, from episode 54 of the “The Web Ahead” podcast.

If you’d like to see more example code, here’s the LA2050 project on GitHub, and a case study.

Improving UX for images while they’re loading on the web

Jim Thoburn — Fri, 06 Dec 2019 23:44:17 +0000

This post is about a few different ways that you can improve the experience someone has while they’re waiting for the images to load on your web site or application.

You can see a demo of these techniques by switching on network throttling in the developer tools for Firefox or Chrome, and then visiting this wildflower picture gallery:

Wildflowers of Joshua Tree (demo)

There are five ideas suggested here, but don’t feel like you have to use all of them! Some will be way more useful in certain contexts (especially lazy loading), and implementing even just one can make a big difference. In general, these techniques are useful for large images, long lists of images, and images that affect the layout of a web page.

Loading images lazily
Giving images an intrinsic size
Making a variety of image sizes available for differently sized screens
Showing a preview of each image
Making image descriptions available

Loading images lazily

This technique involves only loading images if they’re within the viewport or likely to be within the viewport the next time the user scrolls up or down. It’s super useful when applied to a list of images, where only a few are visible at a time.

This should make the first few images a user is looking at load more quickly–particularly on a slow connection. It may also save bandwidth and some dollars for users of your web product.

You can easily begin using the lazy loading technique, now that it’s built into the web platform:

Native Lazy Loading on CSS Tricks

<img loading="lazy" />

And if it’s not yet implemented in a browser that you feel is important to your audience, you can manually apply the technique by following a guide like this one, from Google:

Lazy Loading Images and Video, Web Fundamentals by Google

Giving images an intrinsic size

This will help browsers to lay out the page completely while the images are still loading, since it will know how wide and tall each image should be. Basically all you have to do is add a width and height attribute to each image and the browser will take care of the rest. You can learn more about it with this guide from Mozilla:

Media container elements and aspect-ratio, by Mozilla

<img width="1500" height="1000" />

img {
  max-width: 100%;
  height: auto;

  /* Browsers like Firefox now have a default rule like this one
    (so you don’t have to write this line, but it looks neat!) */
  aspect-ratio: attr(width) / attr(height); 
}

If you have a lot of images, you can use a tool like node-exif to automatically make the image sizes available to you as data.

"exif": {
  "ExifImageWidth": 1500,
  "ExifImageHeight": 1000
}

Making a variety of image sizes available for differently sized screens

Similar to lazy loading, this will make images load noticeably faster on slow connections and saves bandwidth for users and servers–and potentially some dollars for your audience and yourself.

You can get started by adding a srcset attribute to your image element and giving it a few image sizes at different widths. If you want to go further, adding a sizes attribute can make a big difference in download size too.

<img
  src="
    /images/500-wide/wildflowers.jpg"
  srcset="
    /images/500-wide/wildflowers.jpg 500w,
    /images/1000-wide/wildflowers.jpg 1000w,
    /images/1500-wide/wildflowers.jpg 1500w"
  sizes="
    (min-width: 35em) 50vw,
    100vw"
/>

The srcset attribute above is basically saying to the browser, “Hey! I have three different images for you to choose from, ranging from 500 pixels wide to 1,500 pixels wide. Please choose whichever one is best for your viewport size and device pixel ratio.”

And the sizes attribute is saying, “I’ve included a CSS layout for this page that makes images either 50 or 100 percent of the viewport width, depending on how wide the viewport is. Please consider this information too when you choose one of the srcset images. I’m telling you this information now–since you’re awesome and you have a lookahead preparser that needs this information to be stored somewhere in the HTML.”

img {
  width: 100vw;
  height: auto;
}

@media (min-width: 35em) {
  img {
    width: 50vw;
  }
}

Be sure to keep the src attribute that you already have on the img element. This will provide a default image for browsers that don’t understand the srcset syntax. Any size image will be a good choice–even a big one. (Modern browsers will skip the srcimage and download a potentially smaller image from the srcset instead.)

If you have a lot of images, you can use a tool like GraphicsMagick to automatically generate differently sized images. Or you can use a service like Netlify Large Media.

You can learn more in the Responsive Images guide from Mozilla or by listening to this Implementing Responsive Images podcast with Jen Simmons and Jason Grigsby.

Showing a preview of each image

This practice is about making images appear to load faster, by showing a colorful preview of each image while it’s loading.

The “Blur Up” Technique for Loading Background Images on CSS Tricks

If you’re already creating differently sized images for use in the responsive images technique, you can easily generate one more tiny sized image for use as a preview. I found that a 16 pixel wide image works well–especially after it’s optimized with a tool like ImageOptim.

Once you have your tiny images, you can embed them directly in the HTML for your page using data URLs.

<img class="preview" src=" data:image/jpeg;base64,/9j…EKyONpWJGxwSAuDj5qPEXQxv/9k=" />
<img src="/images/wildflowers.jpg" />

img.preview {
  filter: blur(100px);
}

Making image descriptions available

Most browsers display the description stored in the alt attribute while the image is loading.

<img alt="A lush group of plants with purple flowers, growing in the sunshine" />

Descriptions are also super important and helpful for people who experience your web product using tools like Voice Over.

If you have a lot of images, you may be able to get a head start writing descriptions by using something like machine learning. (I haven’t done this before myself, but would really like to try it!)

An example project

Here’s a project on GitHub that makes use of each of these techniques, that you can use a reference or starting point:

Picture Gallery 🖼 ✨ on GitHub

The project also contains example code for automatically generating images and width and height data.

More tips

There are, no doubt, many more ways to improve the user experience while loading images on the web. If you have a tip I didn’t mention or an easier way of accomplishing any of the ideas above, please feel free to comment. 🙂