Journal

I learned something new today when developing in the Firefox Dev Tools console (although this applies to Chrome too)—something which was really useful and which I thought I’d share.

Basically, type $$('selector') into the console (replacing selector as desired) and it’ll give you back all matching elements on the page.

So for example, $$('script') or $$('li').

Similarly you can select a single element by instead using one dollar sign ($).

These seem to be console shortcuts for document.querySelector() (in the case of $) and document.querySelectorAll() (in the case of $$).

The other really cool thing is that the resultant nodeList is returned as an array, so you could do e.g. $$('li').forEach(…) or similar.

via @rem (Remy Sharp)

Here’s how to check the application you’re running locally on your MacBook on your iPhone.

It’s pretty much a case of connecting your iPhone to your MacBook by USB, tweaking some settings, then browsing to the application via a given IP in iOS Safari.

Here’s Bridget Stewart, a developer from Ohio, with some thoroughly enjoyable “curmudgeonly” thoughts on why your website doesn’t necessarily need a Javascript framework.

With websites taking a median time of 5.8 seconds to show primary content (source: HTTPArchive) and Google warning us that 53% of mobile visits leave pages that take longer than three seconds to load, it’s hard to justify stuffing the front-end unnecessarily.

Bridget’s article also contains this quote which I love:

First, solve the problem. Then, write the code.

Essentially, don’t select the tooling first—a principle I fully endorse.

Great article by Jake Archibald (developer advocate at Google Chrome) comparing ten F1 team websites in terms of performance. While checking for common issues he provides great insights into the tools and techniques he uses to test web performance.

Some points of note:

• He uses WebPageTest to gather the data on Chrome Canary on a mobile phone (Moto G4, a mid-to-lower end Android device) with a 3g connection;
• He doesn’t score on the amount of bandwidth used but on time to become interactive, i.e. meaningful content displayed in a stable way and reactive to a tap/click;
• “Caching is important”, so he takes the first load and second load score and adds them;
• He checks if any savings can be made via good-enough-for-mobile images resized to max. 1000px wide, for display at no larger than 500px (so it looks good on high density mobile devices).

A great resource from Dave Rupert, whose work on accessible components I’ve been meaning to write about since I saw his talk “The Four Devine Beasts of Accessibility” at An Event Apart last August.

It came to mind as I prepare to code a navigation menu with dropdown submenus in the most accessible way I can for a client project.

Dave has also written about the ideas behind creating these cards, and provided a few working demos.

Very cool, free, web-based tool which detects a photo’s background and removes it, leaving only the subject on a transparent canvas.

A Book Apart have a new book – Everyday Information Architecture by Lisa Maria Martin.

I love this promotional website for the book, created by Mat Marquis. It’s a really simple but striking design.

Here are a few website creation and delivery principles I’ve learned over the years. I’ll update this post as more come to mind.

Use the right tool for the job

When choosing software and development approach we should focus on:

1. benefit to the website’s users; and
2. ability to deliver the required functional requirements.

The decisions shouldn’t be led by preferences for a particular proprietary software, especially when that software is not the right tool for the job.

In addition, as developers who get excited about shiny new things, we need to be watchful about picking some new or unnecessarily complex approach just to make ourselves feel clever or to make development (allegedly) more convenient. Really good work usually results from finding the simplest, most elegant solution, which often comes from clever use of existing knowledge and standards rather than breaking those then having to rebuild them with custom solutions.

Start with solid foundations or pay for it later

Ask the client questions to ensure you are clear about the requirements. Choose the right system for the job. Take time to plan classes and database schema well. Write well structured HTML. By putting a bit of love into these initial steps, you will provide long-term stability. Conversely, rushing into development is a false economy and likely to have you chasing your tail for the rest of the project.

If re-launching, keep a reference to the previous version

When launching a new version of a website, first archive the existing site and make it available/viewable for reference at a new domain e.g. archive.nameofsite.com. This is always useful so that when someone inevitably asks “why doesn’t it do XYZ like the old site?” then you have a reference rather than just anecdotal evidence.

Aim for an early MVP then release often

Avoid shooting for a dream, all-powerful solution at first. Focus on releasing an initial solution that hits the main requirements and is “good enough” as soon as possible. Then iterate.

Friday releases are bad, m’kay

Avoid releases on a Friday, where possible, unless you’re all OK with i) working over the weekend to resolve any issues that might arise; and ii) the website losing money as a result of issues that weren’t detected until Monday.

Make it easy for you and clients to part company

Don’t use your own money to pay for third party services (hosting, web font services, etc) on the client’s behalf. That way, you avoid having to do awkward transfers of ownership (and generally making life difficult for your client) when you stop working together. Instead, you can still handle initial technical set-up and configuration for them, but use their credit card when initially setting up subscription payments.

Design with real content

First, start from a foundation of great content: well-written, engaging copy; brief and helpful microcopy; and high quality photography. If you don’t have that, you need to get it. Then, create a design based around the real content. When you commence design of any non-trivial project using dummy content you end up with something that might look OK on the surface with its idealised lorem ipsum line-lengths, idealised page lengths and grid patterns, and fake photos. But it may bear little relation to the real content the developer needs to fit in later and will unravel under pressure. This is not good design; it’s just pretty pictures. Good websites start from good content, with design that serves and showcases that content.

When designing responsive websites, flat design files aren’t enough

Designers and developers need to consider what happens at super-wide viewports, for example to full-width images. They need to discuss the implication of widescreen assets on performance. They need to consider how the design flexes between breakpoints – not just how it looks on three arbitrary 2019 device widths.

Good, straightforward coaching video by Tom Lodziak.

The effects of long pimps are a little counter-intuitive, but they are predictable.

• Chops come to you with heavy backspin.
• Blocks come to you floaty / spin-free.
• Pushes come floaty or with a little topspin.

So here are some tactics:

1. topspin your first shot, then when you get a chop back (it’ll be heavier-than-expected backspin);
2. push your second shot, then when you get a push back (it’ll be float or even light topspin);
3. attack strongly with a flatter topspin.

The recipe for success is to practice against players with long pimps!

Brooklyn-based designer and music nerd Rob Weychert has created a lovely “live music diary” website, featuring information about nearly every show he has attended. It’s browsable by genre, artist, venue, city, state, and year.

It also features a ton of interesting design, animation and layout features.

In Introducing Tinnitus Tracker Rob describes the initial concept and technology stack (Jekyll plus Javascript).

He has also recently written about how he used CSS Grid to create a complex, poster-style layout for gig listings.

Inspirational work!