search

WordPress / block-directory

Block library: Timeline and plan: https://make.wordpress.org/design/2019/04/26/block-library-installing-blocks-from-within-gutenberg/
28 stars 7 forks source link

Design Explorations: Installing a block #7

Closed melchoyce closed 5 years ago

melchoyce commented 5 years ago

What should the process of installing a block look like?

melchoyce commented 5 years ago

I have three ideas here:

  1. "Shiny Updates"-style installation in-place. Likely whatever preview UI surrounds the block will fade, along with the "✔Installed" message, after a couple seconds. We could also show a notice here once installation is complete.
  2. Open a dialogue and show the "traditional" installation process. I included this because I wanted to cover it, but I think it's 💩
  3. Install the block in an external screen, opened in a new tab. This would take place in whatever WordPress block library management screen we end up with.

Installing

Questions:

There's a couple other technical questions pertaining to installation that I might ask in #8, where I plan on including some ideas for if you can't install a block, or if the installation fails.

melchoyce commented 5 years ago

@alexislloyd and @jameskoster had a good idea — what if we hid the installation process, and just proceeded as if the block was already installed? Then, on update/publish, we install the block behind-the-scenes?

kjellr commented 5 years ago

How would that effect the block preview then? Would the block preview still have an installation button on it? Or would it basically function as if it were installed?

melchoyce commented 5 years ago

It would function as if it were installed. Need to figure out if this is technically feasible (pinging @tellyworth)

mapk commented 5 years ago

what if we hid the installation process, and just proceeded as if the block was already installed?

I really like this route. Although I think it's important to still indicate that this block isn't quite yet installed. Maybe some messaging in the Inserter? My thinking is that if the user is editing a draft and decides to only save it and then moves to another page/post and tries to add this block there, they may not see it in their Inserter because it's not officially installed. This could cause confusion.

Another place we can display messaging is in the pre-publish slideout sheet. Something like, "These blocks will be installed upon publishing this post. (and list them all out there too).

tellyworth commented 5 years ago

what if we hid the installation process, and just proceeded as if the block was already installed? Then, on update/publish, we install the block behind-the-scenes?

There's some ambiguity here, but basically I think we should definitely aim for something like this. We're exploring some ideas where it looks like we might be able to essentially register and load a JS block within an isolated iframe, so as to safely(?) run it from source provided by w.org rather than the local site. Or in other words, insert a block that hasn't yet been installed.

There's still technical work to do in order to determine that it's safe and works, and things like the sidebar panel will complicate matters, but in general it looks promising for the idea that we could insert a live, mostly working "preview" block prior to install.

melchoyce commented 5 years ago

Another place we can display messaging is in the pre-publish slideout sheet. Something like, "These blocks will be installed upon publishing this post. (and list them all out there too).

Love this 👍

sarahmonster commented 5 years ago

It sounds as though this approach is going to be highly reliant on the technical constraints and implementation.

Would a previewed block look and behave the same as an installed block? How likely is a block install to fail? How long would a block take to install? How difficult is it to then uninstall a block?

An alternative option could be for users to just "add" the block to their page (thereby installing it, but we could use the term "add" if we're concerned they might be trigger-shy), and then reveal an option to immediately undo if it's not what they're looking for. It would be effectively the same mechanism as "previewing" a block, but it would ensure a 1:1 parity between the preview and live functionality, and if a block install failed, it wouldn't complicate the publishing process, which is already one that inspires some user uncertainty.