Improve post preview load state

[sarahmonster]

This is split from #7602, since the preview experience isn't necessarily directly related to the actual experience of publishing, and to better separate those conversations.

From that issue:

Preview looks like this....  A few ideas could be to have an animation such as here: https://www.wired.com/2013/12/a-sandbox-for-experimenting-with-animated-typography-built-by-a-google-designer/. This has been talked about in other issues and it's worth creating one here to just focus on this and explore. Along with adding some flourish to this page of engagement also looking at the format. This is pretty flat as an end to the experience. Beyond any animation this screen showed above could do with some iterations itself. Could perhaps bringing in a better previewing to this all also be wrapped in? Thinking about this in stages may be the best, what can we get in for phase one. Then maybe having a preview modal or something on preview could be brought in later phases. I think it's worth in designs exploring freely then distilling back. Worth noting that exploring things like having this across all devices is important. What could be created that adapts well?

Things to consider:

The post-preview-button loading screen ("please wait, generating preview") appears when you click on the "Preview" button whilst working on a post. Since this screen will appear for a varying length of time for different users, we may want to consider what we can do to make it interesting or exciting. A fleurishy animation could be one approach, or we could try an empty-state animation to help with perceived loading time.

• Is the primary intent here to improve the perceived loading time, or to add interest to the experience?

  Both! Mostly improving perceived loading time but also engaging is good here.

• How much time (range) do we expect this screen to be visible for?

  This can vary but usually isn't long at all, it just 'could' be. Also having anything is better than even a flash of white blank screen.

• Do we also need to design for a potential failure? I've seen a few cases (my local install is currently doing this) where the preview screen appears and the post preview never goes away.

  This can vary but usually isn't long at all, it just 'could' be. Also having anything is better than even a flash of white blank screen.

• On a technical level, do we have access from this component to the post content or post meta?

[iandunn]

Is there an underlying technical reason why Gutenberg needs that interstitial about:blank page? The classic editor just loads the ?p=320&preview=true page directly. It seems like Gutenberg could do that too, since the blocks' save() functions have already been called at this point.

As a user, I strongly prefer the direct approach. Even if the interstitial were made more user friendly, it still feels unnecessary and unexpected. To me it actually feels like it slows down the loading process, even if it doesn't in reality, because it's injecting an additional step into the process. Users are used to pages taking a small amount of time to load, and the ?p=320&preview=true page shouldn't take longer than normal, so I'm not seeing any compelling reason to have an interstitial in the first place.

[sarahmonster]

I'm not sure about the underlying technical reasons for having an interstitial page here, and I'm certainly not opposed to jumping directly to the post as soon as we possibly can. My understanding is that, for some users, there's the potential for the wait time here to be quite long, and thus we're trying to implement a solution that would improve that wait time, whilst adding some personality to the interface.

So, broadly speaking, I think this could go in one of four directions. I've made some crazy rough prototype animations, focusing again on the mobile experience first and foremost. Apparently InVision is even worse than I was expecting at prototyping animations, so I think it would be best to choose a direction and then start prototyping in code for a higher fidelity solution.

Related: apparently if a post is published, there's no way to preview it from a mobile device. Filed as a separate issue: #8184

Skeleton loading

https://automattic.invisionapp.com/share/H3N5FVX427C#/screens

This is the current modern web app way of improving perceived performance, and it's probably one of the most effective ways of making the wait time feel less intrusive. As @iandunn mentions, any other animation here is going to call attention to the fact that there's a wait time going on, which could potentially be a cause of frustration. Skeleton loading helps ease the transition between screens whilst letting the user know that something is happening.

If the wait is likely to be quite long, we could try implementing a progress bar to indicate that we're getting there. Progress bars make users feel like stuff is happening faster, but we'd run the risk here of making a dumb progress bar if it isn't tied to any measureable, real progress, and I'm not sure if we have anything to measure here.

The major drawback here, of course, is that we don't really know what the users' site will look like. I've just created an abstract version of what a lot of sites look like here, but would that still work if a users' layout is substantially different? Maybe we could allow theme developers to include their own skeleton outline, but that still doesn't account for different variations of structure.

The most elegant solution, I think, would be to render either what we have of the post itself (ie, we already have all the post content and its layout, so we could just show that, maybe a little blurred out, in an empty frame)... if we have access to the post content/structure at this point.

Animated letters

https://automattic.invisionapp.com/share/6YN5G0JR9BH#/screens

This has potential to be a very pretty approach if implemented properly—drawing out all the curves and lines of the G. Now, the G may not have any meaning for the majority of users, especially if Gutenberg won't be called Gutenberg much longer. (#4681) That said, we've already used the logo in lots of places, and we could do it in such a way that, for people who've been following along or working on the project, it's a nice Easter egg, and for everyone else, it's just a pretty-looking G.

I looked into using shape morphing to create animations similar to the Anitype text animations, but I'm not sure it'd be possible to have that much fine-grained control over typography without using a third-party library, which seems rather excessive for a loading page.

We could try doing some simple type animations using the tools available in vanilla CSS—at the very least, we could do some rotations and scaling effects. In order to make it feel relevant to the project or the post, we may want to use the title of the post, or the first letter of the post... that way, the animation varies from post to post.

Infinite monkeys

https://automattic.invisionapp.com/share/4WN5GCV9TZF

.. because who doesn't like a monkey on a typewriter? Also, you know, moveable type, Gutenberg, infinite monkeys...

We could try an experimental approach here, pulling words or tags from the post content, and showing icons to reflect it. So for instance, you write a post about cupcakes and kittens, and your preview screen shows you an animated collection of cupcakes and kittens.

We'd want to consider how that would work for different types of post content, and the ways in which that could potentially backfire on us. We might want to create set iconny patterns for specific "genres" of posts, rather than trying to reflect the users' posts verbatim in iconography form.

Poetry!

https://automattic.invisionapp.com/share/ZUN5H6GR879#/310616645_Pre

This ties back to WordPress' roots of "code is poetry", and it's something we could do all sorts of interesting things with.

Can we make haiku out of their post? (This could accidentally go super poorly.)

What about using code poems? I've used a portion of Black Perl above, but there are lots of executable haiku, generative art, and other code poems—some of them even use JavaScript. We could even use it as a way to help people become more comfortable with JavaScript.

What if we crowd-sourced different poetry submissions, and showed a different one each time? It would be a way to allow for community contributions in a (mostly) non-code sort of way, fostering a bit of creativity, and potentially help people feel more connected to WordPress itself.

[hedgefield]

Wow Sarah, stellar work. I love the animated Gutenberg logo. It might lose a bit of meaning when the Gutenberg branding is eventually phased out after merge, but something like that looks really great. The infinite monkeys are a fun idea too.

[iandunn]

Kudos for the great ideas and mockups @sarahmonster :)

for some users, there's the potential for the wait time here to be quite long, and thus we're trying to implement a solution that would improve that wait time, whilst adding some personality to the interface.

I'm not personally convinced that that's a problem that we need to solve, or that we're in the best position to solve it. If the preview is loading slowly, then I would think that most things on their site are also loading slowly, including REST API endpoints. It's likely that the user is used to their entire site being slow. I'm not sure why this one isolated area of WordPress needs a workaround for that, while everything else would remain slow.

It seems like the most appropriate solution would be for the user to get a better hosting plan, rather than for us to add complexity to the code to work around something that's fundamentally outside the scope of WordPress.

---

Having said that, I think the skeleton loading would be the least intrusive approach, and would help the perception of speed the most.

I wonder if we could tweak that idea to make make the preview happen instantly, too. I'm thinking about something like this:

1) Wait until Gutenberg has fully loaded and is ready for the user to interact with. 2) Programmatically create have a hidden <iframe>, and start loading the ?p=320&preview=true page into it. It could optionally look similar to Calypso's popup preview, with the option to change the viewport size, or just be a simple desktop view. 3) When the user clicks the Preview button, programmatically update the content div with the latest version of the post (from memory, not via a slow REST API call), and un-hide the <iframe>

That way, all of the asset loading would occur in the background, while the user is writing the post. When they click the Preview button, everything would already be loaded, and the preview with the latest post content could appear instantly.

[sarahmonster]

Totally in agreement that a better experience for the user is a non-existent wait time entirely, but I'm not sure the exact technical constraints at play here. @mtias can perhaps give better context!

[sarahmonster]

Looping in @karmatosed for a bit more background here. 🙂

[aduth]

The technical reason is that in almost all browsers, window.open is blocked except in direct response to a user interaction (i.e. a click). Since previewing requires that we first save the post (at the risk of a race condition where the preview loads before modifications are persisted), we must initiate the window.open at the time of click, and then redirect to the preview when the save is completed.

This caveat is also documented in the component itself:

https://github.com/WordPress/gutenberg/blob/751a2fcdd7952fd4359984af292cc669cee065c8/packages/editor/src/components/post-preview-button/index.js#L64-L69

The Classic Editor does this as well; the main difference is that IIRC it opens the window to the current URL (the editor URL), and perhaps holds the load until the preview is ready. It's worth revisiting exactly what's going on here.

[aduth]

The Classic Editor logic occurs here:

https://github.com/WordPress/wordpress-develop/blob/c5d013bf95e520bfee7d13d9fce494173cd88f9d/src/js/_enqueues/admin/post.js#L388-L418

It's a bit more interesting than I first imagined:

• It uses target to initiate the popup
• It truly submits a form. I assume there's routing logic server-side to detect that a preview is being generated, and the response isn't returned until the save completes.

[karmatosed]

Anything we can do to reduce the time would be great, however sometimes loading maybe is needed and in that case I think skeleton loading works really well here.

[jasmussen]

This is completely delicous.

I dig the skeleton loading. A couple of questions about that, though:

Does it sort of match the theme itself? If the theme is highly stylized, perhaps scrolling horizontally (Shelf?), perhaps it is confusing if the skeleton is for a generic looking theme that doesn't match the actual theme at all. And related to this, if the skeleton is customizable by the theme, how do we do that technically?

Although I deeply, deeply love the Gutenberg logo being animated into being, it is just a codename and is likely to go away as Gutenberg just becomes "the editor". As such a spin on the WordPress logo, or a new more generic illustration might be a better choice.

Or it's an easter egg? Not sure.

[sarahmonster]

@jasmussen those were my questions too. :) I'm not sure the best answer yet, but I have some thoughts!

Skeleton loading is probably the best way to make the transition feel faster, but it's difficult to accomplish when we can't be certain of what the previewed post will look like.

So we could provide a range of generic static images/styles that theme authors could select for their themes, aiming to provide options for a variety of different potential layouts. We could allow theme authors to select one of these generic skeletons, or override it with an image of their own. This could be just a static .png or .svg included in the theme itself, and we could use some CSS magic to animate it nicely. This has the potential to fail rather catastrophically or feel very disjointed if theme authors don't follow a specific prescribed style. Overall, it feels like a lot of responsibility to pass on to theme authors, which I'm not sure would be the best approach given Gutenberg is already introducing a lot of new stuff to think about, most of which is more important than how the loading screen looks!

Alternately, we could try working from the inside-out, rather than the outside-in, and use the structure of the Gutenberg blocks to build out a skeleton load screen. This may be a more elegant solution here, and it would allow us to better represent Gutenberg, rather than trying to represent the theme. For people writing rich posts, this means that the skeleton would better reflect their actual post, making the transition between editing and preview much more elegant. And it'd be unique to every post, which would just be a nice touch.

However, this would require that we'd have access to a list of all the blocks (paragraph with drop cap, paragraph,heading, image, paragraph, paragraph, image, paragraph, video with caption, paragraph, etc) that the post is using at this interstitial stage, and my understanding/guess is that this wouldn't be possible on a technical level.... but I'd be delighted to be told I'm wrong!

[sarahmonster]

Based on the feedback here, it seems that the skeleton/progressive-loading approach is the preferred direction. After some in-person discussion/argument with @tofumatt, it seems as though it may indeed be technically possible, so I've tried experiementing with what that might actually look like in practise.

The central concept here is that we can convert a given post structure into its own unique skeleton, rather than trying to guess what the theme might look like, or burden theme authors with additional responsibility.

So the Try Gutenberg demo post, for instance, looks like this:

If we convert that into a skeleton, it might look something like this:

...making the transition between editor and post look something like this:

Doing this in HTML and CSS is actually pretty simple. Here's a demo: https://codepen.io/sarahmonster/full/vzZaNP/

The HTML markup is just a series of empty elements (<p>, <img>, <h1>, etc) that is then styled using CSS. We could write these elements to the preview page dynamically, by passing them to to the interstitial page, which is being generated here: https://github.com/WordPress/gutenberg/blob/45f65ddfe5cbc557c8114c1ea791362566e560e3/packages/editor/src/components/post-preview-button/index.js#L114 (Note: this will also solve the issue here of this text being un-translateable, since we're nixing text.)

We can make this as fancy or un-fancy as we want here—I've added some extra styling for cover images, for instance, and we may want to show drop caps and other things, but we could also scale it back to just bare HTML elements and simple blocks and have the effect still work. For long posts, we'd probably just want to represent the first ten blocks or so in the loading page, since that should be more than enough to give a view of "something is happening here."

Design and/or technical feedback on this approach would be 💯 at this stage, before I barrel onward! ❤️

[aduth]

In quickly digesting this notification as it came across here, without realizing it was in regards to previews, I realized this would be a great fit for needs which may come to be as part of "asynchronous parse", the complication noted in https://github.com/WordPress/gutenberg/pull/7970#issuecomment-413676120 where until a parse completes, we can't let a user edit (but we know there's content arriving to be parsed). A content skeleton could serve well in place where blocks list will be shown when parse completes.

Not super relevant to what's being discussed here, but noting as potentially being needed for reuse.

[sarahmonster]

Neat! I was thinking a skeleton-ified representation of the post could come in useful in other contexts to improve percieved performance, so I'd definitely like it if we could build these as reusable components.

[karmatosed]

@sarahmonster with UI freeze on Wednesday would be great to get something in for that or move this to phase 2. Could we have an update here please?

[sarahmonster]

I've been waiting on design or technical feedback here, but if it's good to go I'm happy to try to push it forward. I can definitely put together the HTML/CSS for each individual block for Wednesday, but I'll need developer help to actually implement it in the preview page.

If this is a priority over other things, are there are any developers who'd be able to take it on? I don’t know where it fits into the priorities, but I'd love to see it make it in!

[karmatosed]

Time wise I think we need to get something small in for this. Over the skeleton is there a loader we could add as an easy step for example?

[karmatosed]

A little idea for phase 1. Could we animate the Gutenberg logo?

[sarahmonster]

If we want to aim for a skeleton, I can (relatively easily, I think) add the existing skeleton mockup (not tied to the post content in any way, see above comment for a mockup) to replace what's currently shown during load. I have family priorities today that need to take precedence but I can see what I can get in place this evening.

I could also spend some time trying to make the G animation logo work (probably just via an animated GIF since CSS/SVG styling could be extra complicated) but that may take more time to implement.

[karmatosed]

Let's park the skeleton for phase one and look at a loader. A little animated logo or something I think should be our focus right now to get something small but delightful.

[tofumatt]

Why are we animating/using the Gutenberg logo? It’s merging into WordPress where presumably we want to just call it the WordPress editor? (There was an issue about deprecating the name “Gutenberg” but I’m on my phone.)

Won’t an animated “G” be pretty contextless for most users? If you have to add an animated logo, the WordPress logo seems more appropriate…

• Matt (Sent from mobile)

On 15 Oct 2018, at 11:53, Tammie Lister notifications@github.com wrote:

Let's park the skeleton for phase one and look at a loader. A little animated logo I think should be our focus right now to get something small but delightful.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[oandregal]

In https://github.com/WordPress/gutenberg/pull/10613 I took Sarah's code example and make it so we have a generic skeleton on the preview page. We can discuss there the specifics on how to tweak so it can be mergeable before Wednesday.

[karmatosed]

Thanks for input and push on this everyone. For 5.0 let's move forward looking at characters as per: https://www.wired.com/2013/12/a-sandbox-for-experimenting-with-animated-typography-built-by-a-google-designer/. Some criteria we need to think about:

• It should say loading as it needs to actually be recognisable what is going on.
• What could be done with just CSS animation on a loop?
• How can we make this super performant?

[tofumatt]

Animating letters in pure CSS is probably a mess and would need a lot of cross-browser testing. The example posted relies on two.js which alone is an extra 50kb; @nosolosw's PR is a few hundred lines of CSS/HTML (way less).

Rolling our own in an afternoon or even a few days, I would say, is not realistic. Using two.js for this animated letter (of what letter I don't know, but as mentioned using a "G" will make no sense to WordPress users who identify the letter "W" with WordPress, not "G") will not be pure CSS nor especially performant in terms of file size.

[sarahmonster]

If we say we're going to opt for a CSS-only animation of a letter and we want to avoid performance problems, these are the constraints we'd need to work within:

• We can only animate position, scale, rotation and opacity (reference)
• We shouldn't rely on a third-party animation library. Loading a third-party library solely for the benefit of a loading animation seems short-sighted and is likely to lead to longer-term issues.

This means a lot of stuff to make fun animations is off the table. Doing the sort of funky animations as indicated by the Google link just won't be possible without some serious hacking, which makes things more prone to breaking and may be difficult within a super-compressed timeline.

We'll also want to be sure any animation we introduce here doesn't cause issues for users with motion sensitivity or vestibular disorders.

We can include a "loading" text beneath the animation, but we'll need to be sure that it's translated and translateable. The current text is neither of these things.

So. With all that in mind, I've done a few things. They're pretty rough still, but they show the directions in which we could possibly go. They are here: https://codepen.io/collection/nbWvZx/#

@karmatosed if I could get your feedback here that would be super helpful, and I can work on these further. I'd also appreciate some technical and accessibility feedback (hello @tofumatt) to be sure these wouldn't cause any additional headaches. Using SVG could potentially cause more issues with performance/cross-browsery-ness than using a plain CSS solution, but it does open things up a teensy bit for us in terms of what-we-can-actually-do, so I'd like to be sure that's an okay path to take before running further along it.

[tofumatt]

The drawn one, if slowed down (it was slow at first and then pretty quick for me in desktop Safari), would be pretty accessible in that it's not too rapid or flashing. The glowing one is pretty but probably all of them need slowing down to be considered accessible.

Technically speaking it's not a lot of CSS to add to the lightweight preview page, though note we put that CSS inline and load it every time so however big it is we add to every preview load for every user of WordPress 5.0. That's probably gigabytes of data worldwide, think of the planet! 😉

For real though, it's not a lot of extra code and I'd be technically okay with it… even though I still think the animated G isn't well-contextualised and so will add more confusion than delight.

[karmatosed]

I really like the drawn one. I do think it should be slower so second that for accessibility. Could we however try text for translation? There was the idea of the word 'loading'.

[karmatosed]

One idea to swap out would be perhaps the 'G' for blocks. This would translate and could be along with word that is translatable of loading. Would that be easier and lighter to do?

[sarahmonster]

Could we however try text for translation? There was the idea of the word 'loading'.

I'm not 100% clear on the direction here. Did you want the word "loading" animated? All three suggested pens use the phrase "Loading your preview..." under the G:

I can mock up something with blocks instead, but time constraints are definitely a limitation here.

[karmatosed]

@sarahmonster sure, let me be clearer as yes we're chasing that UI freeze. Thank you for pushing on here. I have concerns over using a letter because in the future 'Gutenberg' itself may not mean anything. It's one reason we decided against using the logo. This is where going abstract perhaps but with a similar animation could be the best route.

If the 'loading your preview' is translatable then we are 👍 on that. The key here is we allow that and also have space for those.

Things I absolutely agree on:

• Should be pure CSS.
• Should not use a library.
• All the a11y feedback as that's crucial to not create motion issues.

[sarahmonster]

Okay, so since we're now switching to a block-based approach, I've mocked up some ideas:

https://codepen.io/collection/XvmRGW/#

I'm not crazy happy with any of these, but I figured that given the time constraints and uncertain direction it would be best to try a bunch of different things here to see if we can find something that sticks. I'm not opposed to trying to run with one of these, or to take something from an existing cc0 source somewhere and adapting it.

[karmatosed]

I like the first one but let's see what others think and take from there. I think it is an improvement over what we have now which leads me to think this could be an iteration point.

[hedgefield]

I like the first one too. The second one as well but it doesn't 'feel' like WordPress so much. The jumping lines one has a great energetic vibe to it.

[sarahmonster]

Just to be sure we're on the same page here—by "first one", we mean the drawing-itself-out-gradienty-box here? (Needs to be made to loop still.)

https://codepen.io/sarahmonster/pen/GYQOwK

Once we've reached a consensus I'll put together a quick PR. Are we still trying to implement this for the UI freeze?

[jasmussen]

Note, Github is acting up today. I posted one comment, but it was eaten, so now I'm rewriting this. In case you get two comments saying mostly the same, I apologize.

---

Stepping back for a bit, the ultimate future goal of the editing canvas is to be a preview itself. In such a future, a preview button that simply shows you the same isn't quite as useful, and perhaps the button then transforms to show you a preview on various viewport sizes — mobile, tablet, desktop.

But that won't make it to 5.0.

Given that as an ultimate goal, the super simple SVG-based solutions seem extremely promising in the ways of letting you know something is happening, while being engaging at the same time. The only thing that feels missing, is to feel more WordPressy. Perhaps we could go as simple as showing the WordPress logo being drawn? Here's a quick codepen: https://codepen.io/joen/pen/jepZrB

GIF:

[hedgefield]

YES, this looks fantastic.