Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blueprints sidebar section for single-click Playground presets #1759

Draft
wants to merge 111 commits into
base: trunk
Choose a base branch
from

Conversation

adamziel
Copy link
Collaborator

@adamziel adamziel commented Sep 12, 2024

Motivation for the change, related issues

Adds a "Blueprints" tab to the sidebar for a single-click access to all the Blueprints from the Blueprints directory.

This PR builds on top of the redux integration and uses dataviews.

CleanShot 2024-09-14 at 10 14 08@2x

Implementation

This PR fetches the list of all Blueprints in the directory and displays it in the sidebar using WordPress data views.

Remaining work

  • Link to the Blueprints community space from the UI
  • UX decision – should the "preview button" keep spinning new sites? Or should it kill the previous Blueprint preview?
  • Talk to a designer to make this beautiful
  • Store the fetch request to the Blueprints directory in local cache
  • Fix CSS
  • Consider accepting Blueprint preview thumbnails in the directory

Blocked by #1731

cc @brandonpayton @bgrgicak @mtias

adamziel and others added 30 commits September 5, 2024 12:57
It confused me to see a type like:
true | 'not-available' | 'origin-mismatch'

All values are truthy so you have to know to compare
directly with true. And at that point, it's clearer to use
the string literal "available" instead.
@brandonpayton
Copy link
Member

This is such a great idea.

An idea: create a single temporary Playground called "Blueprint preview" and reset it with the last selected Blueprint every time.

Since #1731 is keeping multiple temporary sites in-memory, this sounds like a good compromise to me. Perhaps we could create a separate temporary site (and notify the user) whenever they start interacting with "Blueprint preview". At that point, they aren't merely clicking through options but have started "trying things on".

@bgrgicak
Copy link
Collaborator

I'm wondering if using the blueprint gallery will be the best thing in the long term.

This section is technically Playground Apps. You go there and add a WordPress-based app to your Playground.

The Blueprint gallery is more about showing the technical capabilities of Playground while this could be much more.

Imagine going to Playground.WordPress.net or your locally installed PWA and seeing all your apps there.
You have a note-taking app built from the post editor and a search plugin.
You have a development environment, a collection of code, and SQL editing plugins.
You have a RSS reader for everything that you follow...

To get more apps you just go to the apps section and install more.
Submitting a new app is just writing a blueprint which anyone can do with the help of GPT and our documentation.

@asirota
Copy link

asirota commented Sep 24, 2024

Can someone inspect the underlying json?

@bgrgicak
Copy link
Collaborator

Can someone inspect the underlying json?

@asirota I'm happy to help, please open new issue and share the file with us.

@asirota
Copy link

asirota commented Sep 25, 2024

@bgrgicak sorry I wasn't more clear. I meant could there be a feature in this to inspect the json of the blueprint being previewed? Useful for learners.

@adamziel
Copy link
Collaborator Author

I'm wondering if using the blueprint gallery will be the best thing in the long term.
This section is technically Playground Apps. You go there and add a WordPress-based app to your Playground.
The Blueprint gallery is more about showing the technical capabilities of Playground while this could be much more.

To me, showcasing technical capabilities is just a convenient starting point for the Blueprints gallery. It can be both a source of demos and a source of powerful apps. Both use-cases require a central location, contributing workflows, integrations, ways of forking and remixing the Blueprints. Why split that in two places? Once we have powerful app-like Blueprints, we can just add a "features": true meta flag to show or hide then in the webapp.

Note all WordPress directories already work this way. There are demo themes like stacks, and there are powerful themes like TwentyTwentyFour. There are demo blocks and app-like block suites. There are demo plugins like hello-dolly or classic-editor, and there are app-like plugins such as WooCommerce.

And in an even longer term, we can propose Blueprints for WordPress core and it will already have an extensive Blueprints directory on day 1.

@bgrgicak
Copy link
Collaborator

To me, showcasing technical capabilities is just a convenient starting point for the Blueprints gallery. It can be both a source of demos and a source of powerful apps.

I agree, it's more about the naming, but I'm probably jumping 5 steps ahead.
We definitely first need some apps before we can start calling it like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blueprints Builder [Type] Exploration An exploration that may or may not result in mergable code [Type] UI / UX / User Experience
Projects
Status: Needs review
Development

Successfully merging this pull request may close these issues.

5 participants