Sharing early work is not a distraction

In my early teens, I would imagine creating amazing things. A better search engine. The best backup tool ever made. The perfect journal.

When I sat down to create them, I wouldn’t know how to progress further than the first few steps. My projects directory was littered with abandoned main.py files from bursts of inspiration.

As I repeated this pattern of false starts, I became self-conscious about it. Maybe I wasn’t good enough to finish my projects. Not capable enough. I know many share these fears.

I noticed that the biggest bursts of energy came when I shared creations with other people. Sometimes, just telling someone about an incomplete work-in-progress scratched that itch, and I’d lose interest in the remaining work.

I became frustrated with “taking the easy way out”, and viewed sharing too early as in opposition with completing it. I decided to avoid talking about projects because it was more important to finish them. For instance, promising to draw 30 shapes before releasing them publicly.

This worked.

I let the work do more of the talking. Shipping was an exciting release of pent-up anticipation.

There was a problem though: I’d attached my motivation to delaying gratification. The ups and downs and joys of the creative process became secondary to the final product. And I’d feel terrible when I made something really good and nobody reacted.

I missed opportunities to capture moments of inspiration. By the time I’d sit down to write I was cold: it was a chore of trying to remember the details, failing to catch the energy I’d felt earlier.

My original conclusion to delay gratification wasn’t wrong at the time, by the way. Because sharing was my driving reason behind creating things. But it was short-sighted. There other ways to drive projects forward. What was missing wasn’t energy, it was motivation and discipline.

There’s still a deep-rooted fear that pausing to write will leak energy better spent creating.

I know better, though. Sharing is a source of energy, just like it has always been.

(further discussion on Tildes)

Astro View Transitions

Astro 3.0 has been released!

When reading through the changelog, I’ll admit to getting a bit nerd-sniped by the new View Transition system, and spent some time tonight figuring it out instead of hacking on Coalesce.

A few notes from implementing it here:

Transitions feel really novel on the web

It’s amazing what a big difference a smooth crossfade can make. After using the web for almost 25 years, I’ve become accustomed to the flashy, stuttery transitions between pages. It’s what makes UIs feel like the web. I can still imagine the IE 6 “click” sound when pages flashed to white on transition.

I love how page transitions can be declared with just a little CSS. This is a really clever API. Tons of creative possibilities here.

This could significantly change the way we design web pages

Without the customary flash to indicate that a page transition has taken place, web designs will need to find new ways to indicate to users that they’ve moved. Native apps tend to use persistent navigation affordances like tabs and sidebars to address this. I suspect we’ll see more content-heavy site designs incorporate visual cues for where you are in the hierarchy (listings vs. articles).

View transitions are already changing the way I think about designing page layouts. For example, on my site, the color bars at the top have position: sticky so that they shrink out of the way when you scroll. This is also a cue that you’re at the top of the page. With a crossfade transition, though, it’s not always visually clear that you’ve warped to the start of a different scrollable space.

Chrome is leading with great DX

The Chrome Devtools for debugging view transitions is brilliant. I love how the ::view-transition pseudo-elements appear in the element inspector. As with many Devtools things, my only lament is it’s so buried that many developers won’t know it exists.

Image loading is a source of jank

Transitioning between images has some pitfalls: if the image displayed on the destination page isn’t cached, it won’t be loaded in the transition, causing jank. The departing image fades into a white rectangle, and the image pops in afterward.

This is a bit awkward with thumbnail galleries, since the thumbnail needs to be the same image as the destination (ideally you’d want a small quick to download thumbnail). I experimented with using a <picture> element in hopes that a high res version would be swapped in after transition, but there was still a white flash.

The best solution for now was to settle on a medium sized image used in both the thumbnails and destination pages.

Sometimes transitions themselves are jank

I haven’t figured out the best way to “key” transition targets selectively: I’m finding widespread use of view-transition-name creates undesired transitions in some cases.

For example, the thumbnail transitions in the video look great if both the start and destination positions are onscreen, but in many cases that’s not the case. For instance, my front page shows a fullscreen splash, which causes the thumbnail to zip offscreen. It’d be useful if there was a way to bail out of a transition based on distance or if the destination is out of viewport bounds.

Another case where I get undesired transitions is clicking links in the post index at the bottom of the front page. Because there exists a thumbnail with matching view-transition-name way up at the top of the page, there’s an extraneous animation when landing on the post.

I tried using both CSS and JS to control view-transition-name, restricting its use to when thumbnails were clicked. The problem was that this broke back button transitions since the front page doesn’t have a matching view-transition-name on initial load. It feels like making this more stateful or requiring more JS is a step in the wrong direction, so hopefully a viewport bounds restriction will be viable in the future.