Last month, I completed a major overhaul of the British Earways website. The design by Valerio di Lucente of Julia is almost entirely unchanged, the adjustments were largely performance-related and under the hood, geared towards modern browsers. Here’s brief rundown of the changes:
- Style the full-window player layouts using CSS Grid Layout + 100% height (not
100vhsince that can lead to unexpected behaviour on mobile browsers), and use CSS Scroll Snap w/ polyfill for scroll behaviour
- Achieve flexible typography and spacing with “CSS Locks”
- On non-touch screens, implement invisible DragDealer instances so that each player’s scrubber can be dragged
- On touch screens, add click event listeners that advance the relevant scrubber to the click target
- Use styled HTML5 progress elements for each player since these are easily manipulated via their
valueattributes and don’t require adjustment if the window is resized
- Use the Web Audio API to initialise each audio file and trigger the necessary state changes as the time updates
- Switch the audio
metadatato reduce the size of the page when it initially loads
- Update CMS to Kirby 3 (this was a joy, IMO the panel layout options make v3 much more client-friendly)
upload_max_filesizeto allow upload of large (150MB+) audio files
I ran in to one issue that isn’t yet resolved. Kirby copies all uploaded media from the private
/content folder to the publicly-accessible
/media folder. This copying normally happens almost instantly, even with very large files. On the BE site however, the copy is pretty slow. Since the site pulls the audio duration from the audio file itself via the Web Audio API, the displayed duration is incorrect until the file has finished copying. This is almost certainly related to some rate limiting done by the shared hosting company, a legacy from the preexisting site. It isn’t a huge deal since the copying always finishes eventually, but it isn’t the best behaviour. I’d like to raise the issue with the hosting company but don’t have high hopes, shared hosting providers use rate limiting for a reason.
At any rate, I’m really looking forward to seeing how DB uses the site over the next year and listening to the new mixes.
Just pushed an update to this site.
The Browse page is now mainly an index of taxonomies and archives (years, post formats, categories, tags). This new index replaces the opacity-based tag cloud. I kind of miss it, but it was problematic. Very hard to digest, and the lighter greys were way too low-contrast.
Besides the index, most of the changes are related to accessibility. I focused on making the tabbing experience a bit better, introducing a couple skip links. Note that I haven’t totally ironed out the tabbing… Most of my manual testing for this update was done in Chrome. I checked it briefly in Safari and it’s pretty weird, but I think it may have to do with the default Safari settings. I haven’t adjusted these yet, read more about Safari tab settings on a11yproject.com. Besides the tabbing, I also had a handful of links that weren’t suitably descriptive, particularly on the new term index. I added more
aria-label attributes where I could. See the “Using aria-label for link purpose” page on the WCAG wiki for more info.
- Chrome’s accessibility reference and devtools
- Firefox’s Accessibility Inspector and their blog post on Auditing for accessibility problems
- Are.na / Jon Gacnik / Accessibility
- Are.na / andré f. / web accessibility
- Are.na / Laurel Schwulst / Importance of Metadata in Web Accessibility
- GOV.UK – Make your public sector website or app accessible
- Galleries From A to Z Sued Over Websites the Blind Can’t Use, The New York Times, 18 February 2019
There are probably a million a11y optimisations I can / should still make on this site. Suggestions are very welcome.
Edit 08.11.19 – Added Mozilla accessibility blog post
Last Saturday, Sam introduced me to Chris Coyier’s talk on serverless-ness, The All-Powerful Front-End Developer. Pretty interesting and useful. I’m glad he leads it by breaking down the problematic nature of the word “serverless”! The following day was spent in agorama’s p2p workshop at furtherfield. Coincidentally, there is a lot of overlap in these topics.
I’ve spent the past few days wrapping my head around all of this, contextualising it against the sorts of concerns and projects we work with. Though I desperately want to get going with Dat, I’m starting with serverless because it may solve an urgent need in my day-to-day work. Right now, I’m spending much more time than I realistically can maintaining CMSs and hosting environments for older websites.
All of the below is a thought dump on the topic, an attempt to pick apart the meaning of and the use cases for a serverless website architecture.
Did some research on Chinese web font best practices a while back when working on Memory Machine for Tyler Coburn + Asia Art Archive with Luke Gould. It was an interesting challenge. This was my overall takeaway from the research:
- Self-hosted fonts are out, the font files are prohibitively enormous due to the number of characters
- The Great Firewall can cause issues with most font services, so no Google Fonts or Typekit
- If you need to render a mixture of Latin and Chinese characters and want them to use different fonts, the font stack structure and naming is critical (see article by Kendra Schaefer for more info)
- Bold and italic should never be used for emphasis on Chinese characters since it distorts their meaning