Is this intended? When exactly is it there versus not there?
Maybe I’m just a creature of habit, but I find the flash a nice visual indicator of re-execution, which aids in understanding how the notebook functions, and can distinguish between a cell that is not running versus a cell that is running, but whose output isn’t changing. (But perhaps it is considered a distraction in a published notebook that isn’t about “how notebooks work”?)
Good question; I can see arguments both ways. I’m not sure how much the cell gutter flashing aids comprehension in read-only mode, especially when you can’t see the code for unpinned cells. But perhaps it would make sense to flash (or some other visual indication of active computation within the editor?) when code is visible.
Practically speaking the reason the flash isn’t visible in read-only mode is because the cell gutters are not rendered. The cell gutters are the buttons that live in the left margin that let you open and close a cell, and the flash is implemented as a right border on these buttons. But we could easily change the implementation to show the flash in read-only mode, so it’s a design consideration and not a practical one.
I also think maybe the flash should be gray rather than lime… I was excited to try all the new Tailwind colors but it looks too neon to me now.
Regardless of the technical reasons for the difference between read-only and editable views of the page, I really like the current distinction. For public read-only mode, de-emaphasising ‘cells’ as the units of notebook construction is a good thing. It allows the emphasis to be on the overall narrative structure.
For edit-based views, those cells and their interdependencies become more important, so it makes sense to show how updates trigger across the page.
My only reservation is that it takes notebooks further away from WYSIWYG into distinct “modes”, but maybe that’s the point.
If I’m writing a notebook about how notebooks work, or how this notebook works, or how to do a particular thing in notebooks, I may be surprised that this aspect of notebook function “disappears” when I publish. I suppose the fix is just to tell my reader to go into Tinker mode immediately. Or maybe it would be nice if I had the option to publish with Tinker mode turned on by default?
Also interesting to turn on Tinker mode and compare the timing of your flash with the “built-in” flash. The built-in flash appears distinctly after your flash. I had thought that I had noticed that in general the built-in flash in new Observable seemed “late” compared to in old Observable, but this helped me confirm it.
In old Observable the built-in flash looks pretty “simultaneous” with the update of a cell’s display. Whereas in new Observable the built-in flash looks like it is “after” the update of the cell’s display.
I’m not necessarily complaining, just noting the difference.
Thanks again for the feedback. There was a 150ms delay for the flash; I was worried about performance (wanting to coalesce sequential state changes) and the flashes being too busy. But I see now that the delay makes execution feel sluggish, so I’ve reduced the delay to ~17ms. I’ve also changed the flash color to gray from lime, and the flash animations should now interrupt each other better, as when the cell transitions from pending to fulfilled and back again. Let me know what you think.
