WebApp Redesign #1561

adamziel · 2024-07-01T19:52:00Z

Now that Playground supports multiple offline sites, we need a UI redesign to actually enable using it. The redesign will also unlock:

Support Storing Playgrounds by default
Managing multiple stored sites
Multiple data sources and targets (e.g. local → hosted, GitHub → local, etc.)
Integrating the Blueprints builder into the Playground webapp (and open the doors to other integrations)

Done is

For this issue done means we have designs we're aligned on
For the overall project, done means we've implemented the designs, wrote a public announcement, and reshoot the Playground video tutorial for learn.w.org.

@jarekmorawski is exploring it.

adamziel · 2024-07-01T23:23:58Z

adamziel · 2024-07-02T10:14:16Z

Offline Playground support: Some PHP and WP versions might not be available when offline if they have 't been downloaded yet. We might need to somehow communicate that in the ux redesign, even if not in v1.

jarekmorawski · 2024-07-03T08:24:18Z

👋 I put together the first design draft for the new web app. It accounts for all the new functionality and reshapes WP Playground to work more like a site hub, aligning closely with the new wp-admin.

See it in Figma

Most notable changes

New PG toolbar on the front-end

I redesigned the top bar on the front-end to include a button for the new site management view. I also cleaned it up, removed some settings, and compressed all site-related options into a command bar-like UI at the top. There's no URL bar anymore because it can be accessed through the browser's regular UI.

pg_topbar.mov

Site management view

Users can jump to a new site overview screen by clicking a button in the new top bar. There, they'll be able to view all their sites (temporary, saved in the browser, and local) as well as perform actions, like adding or importing sites, previewing PRs, deleting sites, duplicating sites, and editing individual settings, e.g., WP/PHP version, features, etc.

New layout

The admin view borrows design cues from the upcoming WordPress admin redesign. It consists of three panels: a sidebar with a list of active Playground sites, a details area with an overview of site information and settings, and a preview frame. Users can resize the panels to accommodate their needs (handy if they want the preview frame to be larger or smaller).

Temporary site saving flow

Temporary sites are Playground instances that will disappear when users close the browser tab (storage type = none). They're highlighted in the new UI to make users aware of their unique behavior and wary of possible data loss. Contextual icons, tooltips, and notices make it easy to save a temporary site in the browser (or locally) and vice versa.

Other flows, including offline mode and site management actions, are described in Figma. Feel free to take a look and share your thoughts!

adamziel · 2024-07-03T14:05:14Z

Surfacing the design for turning on the offline mode:

This is the right direction, and I’d simplify this even further. We could only have two options there:

You have whatever you downloaded by visiting different Playground sites
You choose to download everything for working offline, and over time this keeps downloading new php and WP releases

I wouldn’t offer the option to download things granularly at all. It might be useful to some, but my educated guess is most people either want full offline support or they don’t.

adamziel · 2024-07-03T14:06:04Z

Aha, and the „libxml” etc checkbox can be removed as well. Let’s just ship the full-featured build.

jarekmorawski · 2024-07-03T14:55:35Z

Thanks, @adamziel. Could something like this work? When online, we'd show an icon and let the user know the components (name WIP) will be downloaded automatically, but we also show a button that allows them to save everything at once. When they go offline, we'll let them know that PG can only use downloaded assets.

jarekmorawski · 2024-07-03T14:55:40Z

Meanwhile, I put together a simple prototype to show how the user would transition from the PG site preview to the new app and vice versa. Let me know what you think.

pg_sitemanagement_ux.mov

bgrgicak · 2024-07-05T07:21:01Z

@jarekmorawski Thank you! This is exciting.

Here are some things that came up for me. @jarekmorawski let me know if you would like to schedule some time to chat about these.

Design feedback

First load

Playground is one-click WordPress, but this UI adds more clicks on the first load. Let's adjust the flow so the user gets a temporary site first without any clicks and can store it later.

Temporary sites

What's the goal of saving temporary sites? For regular users, this would quickly result in a lot of sites in the sidebar or would require them to maintain the list.
What if we don't show temporary sites in the sidebar?

This makes me wonder if the new settings UI is a blueprint builder. I see value in storing a temporary site blueprint in Playground and loading it with one click, but only if the user decides to save the temporary site blueprint, not by default.

We had multiple attempts at building one, but having it here makes sense.
If we do that, let's allow users to edit settings/blueprints directly in JSON like we do in the blueprint builder.

If we combine the ability to store blueprints with showing demos in Playground we have a blueprint gallery.
@adamziel if we have support to display demos here, we could move the blueprint gallery into the demo section.

Header expand/collapse

I would skip the header expand/collapse feature. The seamless mode is intended for integration where someone wants to embed Playground as-is and allowing users to customize Playground would break that. Also, it would create an easy way for users to download the site content which we want to avoid in case of premium plugin demos.

Changing URLs

The current website UI has an address bar that allows us to go to different pages by updating the URL. For example, if I'm not logged in I would change the URL to /wp-admin/ to get to the login page.

Because the Playground website is basically a browser inside a browser, we need to communicate to users where they can update the URL and make it easy.

Logs tab

I like the positioning of the logs tab.

It's missing the ability to search logs like we have today.

With the current data structure, it will be hard to implement the suggested UI because logs are stored as strings. To get info like date, we would need to parse these strings or change how we store data.

Other comments

Should we have a device icon, if we have a temporary icon? This would show up when someone would use device storage, on hover it could show the path.
Could we also design a warning when you try to refresh a temporary site?
Bug: We currently can't auto login users with custom usernames and passwords, we should fix this before building the UI.

jarekmorawski · 2024-07-05T13:03:45Z

Thanks for the feedback, @bgrgicak. 🙏 I'll gladly make the adjustments.

Let's adjust the flow so the user gets a temporary site first without any clicks and can store it later.

The redesign aims to default users to saved sites, which means that temporary sites created with 1-click are still possible, but are no longer a priority. Changing that will have a bigger impact on the flow, which aims to make it easy for users to create and manage saved sites.

What's the goal of saving temporary sites? For regular users, this would quickly result in a lot of sites in the sidebar or would require them to maintain the list. What if we don't show temporary sites in the sidebar?

We'd explore that. Having them in the sidebar makes it easy to find and save temporary sites they care about. Now that we default to saved, temporary sites will be outliers, so they're highlighted in the UI with the clock icon, while other site types are not.

This makes me wonder if the new settings UI is a blueprint builder.

That makes sense. I found the blueprint editor slightly confusing because it offers a different way to edit site settings, like WP version. However, I do see how it can give more power users more flexibility to add custom steps, load external plugins, etc.

Perhaps we'd tweak the flow to make the site settings the primary blueprint editing experience while still letting users access the JSON if needed.

Site -> Edit site -> Edit JSON

If we combine the ability to store blueprints with showing demos in Playground we have a blueprint gallery.

In my opinion, that should be a separate area in the app. I suspect users will not care about demos until they seek inspiration. In the future, we'd add a higher-level nav item and split the app in two:

Playground
- Your sites (admin)
- Gallery (demos)

The seamless mode is intended for integration where someone wants to embed Playground as-is and allowing users to customize Playground would break that.

Sounds good. I wasn't sure about that interaction anyway. 👌 Figma updated.

Because the Playground website is basically a browser inside a browser, we need to communicate to users where they can update the URL and make it easy.

I see your point. Could this work? cc @adamziel

pg_top_bar.mp4

It's missing the ability to search logs like we have today.

I didn't know it was possible. I'll add that to my to-do list.

With the current data structure, it will be hard to implement the suggested UI because logs are stored as strings. To get info like date, we would need to parse these strings or change how we store data.

I suspected that, but I think it can be a worthwhile effort, especially given our plans to turn Playground into a small-scale IDE. Parsing logs and code could come in handy for editing individual lines of code... maybe even inline, while viewing the page in Playground.

Should we have a device icon, if we have a temporary icon? This would show up when someone would use device storage, on hover it could show the path.

I considered that but decided to only use icons to highlight temporary sites. If we show icons for each site type, the UI will get noisy. It's similar to how some apps display notification badges for urgent alerts. If they displayed them for all notifications, nothing would be important anymore.

Could we also design a warning when you try to refresh a temporary site?

We already have one. It should be more visible in Figma now. 👍

Bug: We currently can't auto login users with custom usernames and passwords, we should fix this before building the UI.

💯 It'd be also handy to let users edit the credentials from within the app, much like the site name and other settings. Could come in handy for dev handoff.

bgrgicak · 2024-07-08T08:42:24Z

The redesign aims to default users to saved sites, which means that temporary sites created with 1-click are still possible, but are no longer a priority. Changing that will have a bigger impact on the flow, which aims to make it easy for users to create and manage saved sites.

I understand, but we should keep a way of auto-starting temporary sites. For example by passing a query string ?storage=temp.

Another idea is to modify the initial screen. The screen could be a popup that overlays a temporary Playground site.
If the user dismisses the popup they can star using Playground as-is with one click.

I'm probably overcomplicating here, but my point is that we should keep the Playground is one-click WordPress concept around in some way.

In my opinion, that should be a separate area in the app. I suspect users will not care about demos until they seek inspiration. In the future, we'd add a higher-level nav item and split the app in two:
Playground
Your sites (admin)
Gallery (demos)

Sounds good.

I see your point. Could this work? cc @adamziel

Nice, I like the URL input demo.

I suspected that, but I think it can be a worthwhile effort, especially given our plans to turn Playground into a small-scale IDE. Parsing logs and code could come in handy for editing individual lines of code... maybe even inline, while viewing the page in Playground.

I agree. JS logs should be easy, and we can find a way to parse PHP logs.

jarekmorawski · 2024-07-09T14:53:45Z

For example by passing a query string ?storage=temp.

I'd keep that behavior and let people specify when embedding a site. We'd also create a quick link, like playground.wordpress.new and use that allow users quickly spin up a temporary site.

From inside the admin, I'd experiment with defaulting people to saved sites because 1) it's just better UX since they don't have to worry about their setups 2) this may be the expected behavior given they're already in the admin 3) deleting a site is fast and easy.

Another idea is to modify the initial screen. The screen could be a popup that overlays a temporary Playground site.
If the user dismisses the popup they can star using Playground as-is with one click.

That's two clicks, isn't it? ;) I'd prefer to avoid modal and design a better path in instead. I think it all comes down to what @adamziel thinks and knows about Playground and how most people use it. He and I talked about defaulting to saved, but perhaps I missed a beat.

I agree. JS logs should be easy, and we can find a way to parse PHP logs.

Sounds good. I removed the custom styling from the design for now. We can revisit once we're reading to add the IDE.

adamziel · 2024-07-09T15:52:10Z

Thanks, @adamziel. Could something like this work? When online, we'd show an icon and let the user know the components (name WIP) will be downloaded automatically, but we also show a button that allows them to save everything at once. When they go offline, we'll let them know that PG can only use downloaded assets.

Yes! That's lovely ❤️ I'd just somehow tell the user they don't have all the files downloaded even if they don't hover/click the cloud icon, otherwise that's brilliant.

Meanwhile, I put together a simple prototype to show how the user would transition from the PG site preview to the new app and vice versa. Let me know what you think.

pg_sitemanagement_ux.mov

Really nice transitions 🎉 Here's two things that came up for me:

We'll still need the URL bar for navigation, but that's a separate concern.
I'd probably be afraid of clicking the "x" button ("wait, will that trash my site?"). What other icon could we use there?

If we combine the ability to store blueprints with showing demos in Playground we have a blueprint gallery.

@bgrgicak holy cow, you're right! And we could display that directly in Playground or embed it on w.org. Really nice. And with a more advanced git integration, you could contribute them directly from Playground.

I would skip the header expand/collapse feature. The seamless mode is intended for integration where someone wants to embed Playground as-is and allowing users to customize Playground would break that.

@bgrgicak I've heard a few people asking for the ability to transition between the fullscreen mode and the mode with settings. It does seem useful.

More thoughts coming later.

jarekmorawski · 2024-07-09T16:06:13Z

I'd just somehow tell the user they don't have all the files downloaded even if they don't hover/click the cloud icon, otherwise that's brilliant.

I assume we can detect they're offline? Maybe we'd display a highly visible banner at the top of the page.

What other icon could we use there?

Here's the updated design. It completely overhauls the top bar so we'd no longer need the show/hide button.

It does seem useful.

If it was just a handful of people, we'd add a keyboard shortcut. 🤔 The F key is the universally accepted standard, I think.

adamziel · 2024-07-09T17:03:58Z

I assume we can detect they're offline? Maybe we'd display a highly visible banner at the top of the page.

I meant a scenario when they're online and unaware they don't have all the PHP versions etc available locally yet.

adamziel · 2024-07-09T17:11:44Z

Perhaps we'd tweak the flow to make the site settings the primary blueprint editing experience while still letting users access the JSON if needed.
Site -> Edit site -> Edit JSON

This could be a good stopgap solution. Eventually, I'd like to default to a UI-based Blueprints editor and have the JSON editor as a secondary fallback / a place to paste the Blueprint into.

In my opinion, that should be a separate area in the app. I suspect users will not care about demos until they seek inspiration. In the future, we'd add a higher-level nav item and split the app in two:
Your sites
Demos

This seems similar to a "start new post with a template / pattern" flow, I wonder what learnings can we draw from that. Blueprints are just patterns for entire sites.

I see your point. Could this work? cc @adamziel

Definitely interesting! I'd make it clearer this button doubles as an address bar before the first time it's used. On the video you can see it says /wp-admin/ after the user navigates there, but initially there's no hint about the current page.

If we show icons for each site type, the UI will get noisy.

+1

Could we also design a warning when you try to refresh a temporary site?
We already have one. It should be more visible in Figma now. 👍

❤️

Bug: We currently can't auto login users with custom usernames and passwords, we should fix this before building the UI.

💯 It'd be also handy to let users edit the credentials from within the app, much like the site name and other settings. Could come in handy for dev handoff.

For the UI purposes let's assume that works as intended and use the UI as a forcing function to fix it.

adamziel · 2024-07-09T17:15:13Z

Another idea is to modify the initial screen. The screen could be a popup that overlays a temporary Playground site.
If the user dismisses the popup they can star using Playground as-is with one click.

Please no 😅 there's already too many popups on the internet. Let's default to a saved Playground site as @jarekmorawski said. The only question to me is – what should happen the next time I go to playground.wordpress.net? It could be either:

Opening the last saved site
Creating a new saved site

I think either option works provided it's supported by the rest of the experience. For example, if we open the most recent saved site, we should make a "create new site" button apparent. If we default to creating a new saved site, we shouldn't actually add it to the list of my sites until I make a change – otherwise the list will get cluttered. I'm fine with either option.

If it was just a handful of people, we'd add a keyboard shortcut. 🤔 The F key is the universally accepted standard, I think.

It's not a small part of the conversations I've had. I'd make an educated guess this interaction is useful and iterate based on what we hear back.

adamziel · 2024-07-09T17:19:51Z

@jarekmorawski Is this a screenshot of the most recent version of the homepage?

Could this be an arrow, like in a select box instead?

bgrgicak · 2024-07-10T05:26:25Z

I totally missed the point that we are now starting with stored sites and not temporary sites. In that case, it makes sense to add extra steps because you are creating something that will stay.

I would prefer to see the last saved site I worked on, or if there are multiple sites already, show the Your sites sidebar to make it clear to the user that they have multiple sites already and can choose.

jarekmorawski · 2024-07-10T08:30:56Z

I meant a scenario when they're online and unaware they don't have all the PHP versions etc available locally yet.

Do you think it's likely people will look for that in the UI? This information is only relevant for people who will use Playground in the offline mode, which I suspect will be the minority. I can't think of a solution that wouldn't add noise for everyone else. Ideally, the information about downloaded components and stuff would be somewhere in global settings, but we don't have enough controls to justify building a new screen yet.

This seems similar to a "start new post with a template / pattern" flow, I wonder what learnings can we draw from that. Blueprints are just patterns for entire sites.

Cool idea! What do blueprints look like? Are they visual? Does displaying a preview make sense? I think the answer is 'no' and I wonder how we can present blueprints in an attractive way and replicate the new page/template flow in wp-admin.

I'd make it clearer this button doubles as an address bar before the first time it's used. On the video you can see it says /wp-admin/ after the user navigates there, but initially there's no hint about the current page.

I think the default URL when the user visits the home page is just / so there's little to show there. 🤔 A single character with no further context may look like a bug and confuse people. Would it make sense to display something like /index or /home?

The only question to me is – what should happen the next time I go to playground.wordpress.net?

What if it opened the admin view? It'd give you an overview of all saved and temporary pages and make it easy to create a new one if that's your goal.

Is this a screenshot of the most recent version of the homepage?

If by homepage you mean the default admin view, yes. The screenshot you pasted illustrates what the layout will look like when the user resizes the preview frame. The site details panel is larger by default.

Could this be an arrow, like in a select box instead?

I'm open to trying that, but I have two reservations:

in Gutenberg (both admin and editor), chevrons are only used for dropdowns and all secondary actions are tucked away under an ellipsis
where should the arrow point? Given it's a dropdown, the logic suggests it should point downwards, but then the menu will always open above it, so it can be confusing.

bgrgicak · 2024-07-29T06:54:32Z

We started a discussion about implementing the new design. #1652

adamziel · 2024-07-29T12:34:49Z

I think so! But please take a look at the Figma and add comments there or here about things that don't feel right yet. Figma makes it easy to the big picture, especially now that I've organized the screens by flow.

Thank you – I left a few tactical comments. Overall it looks amazing – thank you so much @jarekmorawski, it's such a great work.

brandonpayton · 2024-07-31T04:24:39Z

Overall it looks amazing – thank you so much @jarekmorawski, it's such a great work.

I was just coming here to say the same thing. Thank you very much!

brandonpayton · 2024-07-31T04:25:52Z

❤️ I think it is thorough and well-considered overall.

brandonpayton · 2024-07-31T04:35:48Z

I left one comment about possibly keeping temporary sites in browser storage for a short time.

bgrgicak · 2024-07-31T06:02:45Z

We have a new issue for tracking project development.

I'm closing this one because the design is completed.

Thank you @jarekmorawski!

adamziel · 2024-07-31T09:35:36Z

I'll reopen and add it to the "Projects" section of the project board to have a high level overview of the ongoing work. @bgrgicak I assume we'll also need either a milestone or a project board property?

adamziel · 2024-07-31T09:37:05Z

Ah, #1655 is playing that higher level role. Alright, let's close this one.

@todo

… WebApp Redesign (#1731) ## Description Implements a large part of the [website redesign](#1561): ![CleanShot 2024-09-14 at 10 24 57@2x](https://github.com/user-attachments/assets/f245c7ac-cb8c-4e5a-b90a-b4aeff802e7b) High-level changes shipped in this PR: * Multiple Playgrounds. Every temporary Playground can be saved either in the browser storage (OPFS) or in a local directory (Chrome desktop only for now). * New Playground settings options: Name name, language, multisite * URL as the source of truth for the application state * State management via Redux This work is a convergence of 18+ months of effort and discussions. The new UI opens relieves the users from juggling ephemeral Playgrounds and losing their work. It opens up space for long-lived site configurations and additional integrations. We could bring over all the [PR previewers and demos](https://playground.wordpress.net/demos/) right into the Playground app. Here's just a few features unblocked by this PR: * #1438 – no more losing your work by accident 🎉 * #797 – with multiple sites we can progressively build features we'll eventually propose for WordPress core: * A Playground export and import feature, pioneering the standard export format for WordPress sites. * A "Clone this Playground" feature, pioneering the [Site Transfer Protocol](https://core.trac.wordpress.org/ticket/60375). * A "Sync two Playgrounds" feature, pioneering the Site Sync Protocol * #1445 – better git support is in top 5 most highly requested features. With multiple Playgrounds, we can save your work and get rid of the "save your work before connecting GitHub or you'll lose it" and cumbersome "repo setup" forms on every interaction. Instead, we can make git operations like Pull, Commit, etc. very easy and even enable auto-syncing with a git repository. * #1025 – as we bring in more PHP plumbing into this repository, we'll replace the TypeScript parts with PHP parts to create a WordPress core-first Blueprints engine * #1056 – Site transfer protocol will unlocks seamlessly passing Playgrounds between the browser and a local development environment * #1558 – we'll integrate [the Blueprints directory] and offer single-click Playground setups, e.g. an Ecommerce store or a Slide deck editor. #718. * #539 – the recorded Blueprints would be directly editable in Playground and perhaps saved as a new Playground template * #696 – the new interaction model creates space for additional integrations. * #707 – you could create a "GitHub–synchronized" Playground * #760 – we can bootstrap one inside Playground using a Blueprint and benefit the users immediately, and then gradually work towards enabling it on WordPress.org * #768 – the new UI has space for a "new in Playground" section, similar to what Chrome Devtools do * #629 * #32 * #104 * #497 * #562 * #580 ### Remaining work - [ ] Write a release note for https://make.wordpress.org/playground/ - [x] Make sure GitHub integration is working. Looks like OAuth connection leads to 404. - [x] Fix temp site "Edit Settings" functionality to actually edit settings (forking a temp site can come in a follow-up PR) - [x] Fix style issue with overlapping site name label with narrow site info views - [x] Fix style issue with bottom "Open Site" and "WP Admin" buttons missing for mobile viewports - [x] Make sure there is a path for existing OPFS sites to continue to load - [x] Adjust E2E tests. - [x] Reflect OPFS write error in UI when saving temp site fails - [x] Find a path forward for [try-wordpress](https://github.com/WordPress/try-wordpress) to continue working after this PR - [x] Figure out why does the browser get so choppy during OPFS save. It looks as if there was a lot of synchronous work going on. Shouldn't all the effort be done by a worker a non-blocking way? - [x] Test with Safari and Firefox. Might require a local production setup as FF won't work with the Playground dev server. - [x] Fix Safari error: `Unhandled Promise Rejection: UnknownError: Invalid platform file handle` when saving a temporary Playground to OPFS. - [x] Fix to allow deleting site that fails to boot. This is possible when saving a temp site fails partway through. - [x] Fix this crash: ```ts /** * @todo: Fix OPFS site storage write timeout that happens alongside 2000 * "Cannot read properties of undefined (reading 'apply')" errors here: * I suspect the postMessage call we do to the safari worker causes it to * respond with another message and these unexpected exchange throws off * Comlink. We should make Comlink ignore those. */ // redirectTo(PlaygroundRoute.site(selectSiteBySlug(state, siteSlug))); ``` - [x] Test different scenarios manually, in particular those involving Blueprints passed via hash - [x] Ensure we have all the aria, `name=""` etc. accessibility attributes we need, see AXE tools for Chrome. - [x] Update developer documentation on the `storage` query arg (it's removed in this PR) - [x] Go through all the `TODOs` added in this PR and decide whether to solve or punt them - [x] Handle errors like "site not found in OPFS", "files missing from a local directory" - [x] Disable any `Local Filesystem` UI in browsers that don't support them. Don't just hide them, though. Provide a help text to explain why are they disabled. - [x] Reduce the naming confusion, e.g. `updateSite` in redux-store.ts vs `updateSite` in `site-storage.ts`. What would an unambiguous code pattern look like? - [x] Find a reliable and intuitive way of updating these deeply nested redux state properties. Right now we do an ad-hoc recursive merge that's slightly different for sites and clients. Which patterns used in other apps would make it intuitive? - [x] Have a single entrypoint for each logical action such as "Create a new site", "Update site", "Select site" etc. that will take care of updating the redux store, updating OPFS, and updating the URL. My ideal scenario is calling something like `updateSite(slug, newConfig)` in a React Component and being done without thinking "ughh I still need to update OPFS" or "I also have to adjust that .json file over there" - [x] Fix all the tiny design imperfections, e.g. cut-off labels in the site settings form. ### Follow up work - [ ] Mark all the related blocked issues as unblocked on the project board, e.g. #1703, #1731, and more – [see the All Tasks view](https://github.com/orgs/WordPress/projects/180/views/2?query=sort%3Aupdated-desc+is%3Aopen&filterQuery=status%3A%22Up+next%22%2C%22In+progress%22%2C%22Needs+review%22%2C%22Reviewed%22%2C%22Done%22%2CBlocked) - [ ] Update WordPress/Learn#1583 with info that the redesign is now in and we're good to record a video tutorial. - [ ] #1746 - [ ] Write a note in [What's new for developers? (October 2024)](WordPress/developer-blog-content#309) - [ ] Document the new site saving flow in `packages/docs/site/docs/main/about/build.md` cc @juanmaguitar - [ ] Update all the screenshots in the documentation cc @juanmaguitar - [ ] When the site fails to load via `.list()`, still return that site's info but make note of the error. Not showing that site on a list could greatly confuse the user ("Hey, where did my site go?"). Let's be explicit about problems. - [ ] Introduce notifications system to provide feedback about outcomes of various user actions. - [ ] Add non-minified WordPress versions to the "New site" modal. - [ ] Fix `console.js:288 TypeError: Cannot read properties of undefined (reading 'apply') at comlink.ts:314:51 at Array.reduce (<anonymous>) at callback (comlink.ts:314:29)` – it seems to happen at trunk, too. - [ ] Attribute log messages to the site that triggered them. - [ ] Take note of any interactions that we find frustrating or confusing. We can perhaps adjust them in a follow-up PR, but let's make sure we notice and document them here. - [ ] Solidify the functional tooling for transforming between `URL`, `runtimeConfiguration`, `Blueprint`, and `site settings form state` for both OPFS sites and in-memory sites. Let's see if we can make it reusable in Playground CLI. - [ ] Speed up OPFS interactions, saving a site can take quite a while. - [ ] A mobile-friendly modal architecture that doesn't stack modals, allows dismissing, and understands some modals (e.g. fatal error report) might have priority over other modals (e.g. connect to GitHub). Discuss whether modals should be declared at the top level, like here, or contextual to where the "Show modal" button is rendered. - [ ] Discuss the need to support strong, masked passwords over a simple password that's just `"password"`. - [ ] Duplicate site feature implemented as "Export site + import site" with the new core-first PHP tools from adamziel/wxr-normalize#1 and https://github.com/adamziel/site-transfer-protocol - [x] Retain temporary sites between site changes. Don't just trash their iframe and state when the user switches to another site. Closes #1719 cc @brandonpayton --------- Co-authored-by: Brandon Payton <brandon@happycode.net> Co-authored-by: Bero <berislav.grgicak@gmail.com> Co-authored-by: Bart Kalisz <bartlomiej.kalisz@gmail.com>

adamziel added this to Playground Board Jul 1, 2024

adamziel converted this from a draft issue Jul 1, 2024

adamziel added [Type] Enhancement New feature or request [Type] UI / UX / User Experience labels Jul 1, 2024

adamziel changed the title ~~playground.wordpress.net UX redesign~~ WebApp Redesign Jul 1, 2024

adamziel assigned jarekmorawski Jul 3, 2024

adamziel moved this from In progress to Needs review in Playground Board Jul 3, 2024

adamziel moved this from Needs review to Needs Author's Reply in Playground Board Jul 9, 2024

bgrgicak mentioned this issue Jul 10, 2024

Cache Playground assets to enable offline support #1535

Merged

adamziel moved this from Needs Author's Reply to Inbox in Playground Board Jul 10, 2024

adamziel moved this from Inbox to In progress in Playground Board Jul 10, 2024

bgrgicak moved this from Inbox to Needs Author's Reply in Playground Board Jul 19, 2024

bgrgicak moved this from Needs Author's Reply to Up next in Playground Board Jul 19, 2024

bgrgicak moved this from Up next to In progress in Playground Board Jul 19, 2024

bgrgicak mentioned this issue Jul 19, 2024

Mount a directory from the browser #1482

Merged

bgrgicak moved this from In progress to Project: In Progress in Playground Board Jul 29, 2024

bgrgicak moved this from Project: In Progress to Project: Up soon in Playground Board Jul 29, 2024

bgrgicak mentioned this issue Jul 31, 2024

Web app redesign #1655

Open

bgrgicak moved this from Project: Up soon to Done in Playground Board Jul 31, 2024

bgrgicak closed this as completed Jul 31, 2024

adamziel reopened this Jul 31, 2024

github-project-automation bot moved this from Done to Inbox in Playground Board Jul 31, 2024

adamziel moved this from Inbox to Project: In Progress in Playground Board Jul 31, 2024

adamziel added the [Type] Mindmap Node label Jul 31, 2024

adamziel closed this as not planned Won't fix, can't repro, duplicate, stale Jul 31, 2024

github-project-automation bot moved this from Project: In Progress to Done in Playground Board Jul 31, 2024

adamziel removed the status in Playground Board Jul 31, 2024

adamziel removed the [Type] Mindmap Node label Jul 31, 2024

This was referenced Sep 5, 2024

[UX] Stored Playgrounds (no more data loss), multiple Playgrounds, UI WebApp Redesign #1731

Merged

Recover from an invalid local directory handle #1746

Open

adamziel mentioned this issue Oct 7, 2024

Skip Blueprint execution in the browser when persistent storage is used #1484

Closed

akirk mentioned this issue Nov 28, 2024

Force saving a playground via Query API #2037

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WebApp Redesign #1561

WebApp Redesign #1561

adamziel commented Jul 1, 2024 •

edited

Loading

adamziel commented Jul 1, 2024 •

edited

Loading

adamziel commented Jul 2, 2024 •

edited

Loading

jarekmorawski commented Jul 3, 2024 •

edited

Loading

adamziel commented Jul 3, 2024

adamziel commented Jul 3, 2024

jarekmorawski commented Jul 3, 2024

jarekmorawski commented Jul 3, 2024

bgrgicak commented Jul 5, 2024

jarekmorawski commented Jul 5, 2024 •

edited

Loading

bgrgicak commented Jul 8, 2024 •

edited

Loading

jarekmorawski commented Jul 9, 2024

adamziel commented Jul 9, 2024

jarekmorawski commented Jul 9, 2024

adamziel commented Jul 9, 2024

adamziel commented Jul 9, 2024 •

edited

Loading

adamziel commented Jul 9, 2024 •

edited

Loading

adamziel commented Jul 9, 2024

bgrgicak commented Jul 10, 2024

jarekmorawski commented Jul 10, 2024 •

edited

Loading

bgrgicak commented Jul 29, 2024

adamziel commented Jul 29, 2024

brandonpayton commented Jul 31, 2024

brandonpayton commented Jul 31, 2024

brandonpayton commented Jul 31, 2024

bgrgicak commented Jul 31, 2024

adamziel commented Jul 31, 2024 •

edited

Loading

adamziel commented Jul 31, 2024

WebApp Redesign #1561

WebApp Redesign #1561

Comments

adamziel commented Jul 1, 2024 • edited Loading

Done is

adamziel commented Jul 1, 2024 • edited Loading

adamziel commented Jul 2, 2024 • edited Loading

jarekmorawski commented Jul 3, 2024 • edited Loading

Most notable changes

New PG toolbar on the front-end

Site management view

New layout

Temporary site saving flow

adamziel commented Jul 3, 2024

adamziel commented Jul 3, 2024

jarekmorawski commented Jul 3, 2024

jarekmorawski commented Jul 3, 2024

bgrgicak commented Jul 5, 2024

Design feedback

First load

Temporary sites

Header expand/collapse

Changing URLs

Logs tab

Other comments

jarekmorawski commented Jul 5, 2024 • edited Loading

bgrgicak commented Jul 8, 2024 • edited Loading

jarekmorawski commented Jul 9, 2024

adamziel commented Jul 9, 2024

jarekmorawski commented Jul 9, 2024

adamziel commented Jul 9, 2024

adamziel commented Jul 9, 2024 • edited Loading

adamziel commented Jul 9, 2024 • edited Loading

adamziel commented Jul 9, 2024

bgrgicak commented Jul 10, 2024

jarekmorawski commented Jul 10, 2024 • edited Loading

bgrgicak commented Jul 29, 2024

adamziel commented Jul 29, 2024

brandonpayton commented Jul 31, 2024

brandonpayton commented Jul 31, 2024

brandonpayton commented Jul 31, 2024

bgrgicak commented Jul 31, 2024

adamziel commented Jul 31, 2024 • edited Loading

adamziel commented Jul 31, 2024

adamziel commented Jul 1, 2024 •

edited

Loading

adamziel commented Jul 1, 2024 •

edited

Loading

adamziel commented Jul 2, 2024 •

edited

Loading

jarekmorawski commented Jul 3, 2024 •

edited

Loading

jarekmorawski commented Jul 5, 2024 •

edited

Loading

bgrgicak commented Jul 8, 2024 •

edited

Loading

adamziel commented Jul 9, 2024 •

edited

Loading

adamziel commented Jul 9, 2024 •

edited

Loading

jarekmorawski commented Jul 10, 2024 •

edited

Loading

adamziel commented Jul 31, 2024 •

edited

Loading