adamziel
commented
3 months ago Closed adamziel closed 2 months ago
adamziel
commented
3 months ago adamziel
commented
3 months ago 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
commented
3 months ago 👋 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.
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.
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.
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 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
commented
3 months ago 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:
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
commented
3 months ago Aha, and the „libxml” etc checkbox can be removed as well. Let’s just ship the full-featured build.
jarekmorawski
commented
3 months ago 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
commented
3 months ago 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.
bgrgicak
commented
3 months ago @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.
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.
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.
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.
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.
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.
jarekmorawski
commented
3 months ago 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:
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
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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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.
Really nice transitions 🎉 Here's two things that came up for me:
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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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:
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
commented
2 months ago @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
commented
2 months ago 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
commented
2 months ago 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:
adamziel
commented
2 months ago This information is only relevant for people who will use Playground in the offline mode, which I suspect will be the minority.
This is a good point! My only concern is the minority who uses the full offline mode and assumes they're good for a plane trip when they actually aren't – it could be quite a frustrating experience. Maybe having another icon or four states of the cloud icon would solve here? I'm thinking of communicating these in a glanceable way:
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.
Today they look like this:
With a visual, Gutenberg-based builder, we could represent that as a series of blocks that fit in the site editor and may also have a visual representation on the frontend. This could also be useful for the Blueprint gallery or sharing Blueprints on your site. Perhaps it would be a series of rectangles on top of each other, or perhaps an "install plugin" step could be represented with the plugin's icon, author name, the plugin name, and a download link. That's highly exploratory.
I think the default URL when the user visits the home page is just / so there's little to show there
Agreed, I don't even mean that this / URL matters. I just want the user to understand they're looking at a navigation bar. /index and /home would be confusing since that's not an actual page – perhaps something like "🏠 Homepage" would work better?
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.
Do you mean the list of Playground sites or /wp-admin? Assuming it's the former, that could work. Still, it's similar to opening a modal every time and I'd like to save power users that click. Let's take a risk here, choose a sensible default (either a new or an existing site), and iterate based on the feedback.
If by homepage you mean the default admin view, yes.
Oh, sorry, I meant this screenshot:
I'm open to trying that, but I have two reservations:
Good point. 🤔 Let's try an ellipsis and see what happens.
jarekmorawski
commented
2 months ago Maybe having another icon or four states of the cloud icon would solve here? I'm thinking of communicating these in a glanceable way:
That could be a potential solution. I wonder if we could avoid this problem altogether and ask the user at some point if they want to download all components (maybe while creating the first site?) or just download them automatically and let users remove the downloads if they're never planning to use the offline mode.
Perhaps it would be a series of rectangles on top of each other, or perhaps an "install plugin" step could be represented with the plugin's icon, author name, the plugin name, and a download link. That's highly exploratory.
Interesting. Why are they called steps? Is there something consequential about their structure? We can dive deeper once we're done with the redesign. I feel that Blueprints and the Blueprint Gallery deserve a separate effort.
I just want the user to understand they're looking at a navigation bar. /index and /home would be confusing since that's not an actual page – perhaps something like "🏠 Homepage" would work better?
That's what I was thinking. I will make that change. 👍
Let's take a risk here, choose a sensible default (either a new or an existing site), and iterate based on the feedback.
Alright. I suspect that a new site may be a better option since that's what most people expect form Playground. Still, I think it'd make sense to utilize the URL at some point. Something like playground.new to spin up a new PG site in seconds could go a long way.
Oh, sorry, I meant this screenshot:
Yup! It's the home page, but it'd be a generic theme cover, too. Following Studio's approach, it's linked to the site's theme. The arrow button below allows the user to download the theme's zip file without accessing the wp-admin.
jarekmorawski
commented
2 months ago For reference, I got some internal feedback about the 'Save locally' notice.
The message can be dismissed, but the “Save locally” action is not suggested from other parts of the UI. If I accidentally close the message, how can I save the site in my local? The page’s CTA is about adding sites and it doesn’t relate to this task. I wouldn’t expect to see the saving action from the ellipsis menu.
I went ahead and tweaked the site details pane's header. It's more minimal now, but the Save action is more prominent on temporary sites.
adamziel
commented
2 months ago I went ahead and tweaked the site details pane's header. It's more minimal now, but the
Saveaction is more prominent on temporary sites.
Yay! Could it say "Local site" when there's no button? I'm worried about "wait, where's that button" reaction.
adamziel
commented
2 months ago V1 or 1.5 idea: let's offer a few ways of creating new Playgrounds using templates.
"Blueprint Gallery"/"Playground apps" to browse a curated set of Playground setups, like:
Key point: all would be regular Blueprints using regular WordPress plugins. No setup would be Playground specific. You could create the exact same WordPress setup outside of Playground. This way we'll eventually be able to ship those as desktop, mobile, cloud, and frontend apps as well as plugins for, say, VS Code.
Cc @brandonpayton @bgrgicak — let's ship the markdown documentation editor as a Blueprint and make sure it works outside of Playground. It will push us to make build a solid, reusable, WordPress-first foundation.
Vision and long-term ideas
Once we figure out merging Blueprints (probably quarters away), we could create a "Blueprint" block and easily create complex setups by inserting and configuring a few blocks.
@akirk the macro/variable-based builder you proposed could then be scoped down to creating a partially synced pattern from a few Blueprint steps and calling that a custom, configurable Blueprint step. We could distribute those using the existing block / plugin directories.
jarekmorawski
commented
2 months ago Yay! Could it say "Local site" when there's no button? I'm worried about "wait, where's that button" reaction.
You can see it in the Settings tab. Do you think it needs more prominence? I'm concerned about adding noise. There's a point we're introducing a default. As I chatted with Bero earlier, if we highlight all site types, the temporary sites (which carry the most risk to the user's data and UX) will stand out less.
jarekmorawski
commented
2 months ago I took another stab at the 'Save site' flow. The button in the header felt wrong, especially because it forced us to use icons instead of text buttons, which is less clear and accessible.
I tweaked the Site details section to include a save button displayed next to the site type. We'd then keep the notice at the top, but make it appear once (and never again if the user decides to dismiss it).
adamziel
commented
2 months ago You can see it in the
Settingstab. Do you think it needs more prominence? I'm concerned about adding noise. There's a point we're introducing a default.
I, for once, missed it. I am concerned about the noise, too, though. My only ask would be to co-locate the "save" button and the "local site" info, regardless of their exact placement.
adamziel
commented
2 months ago Oh, I posted before I read your other comment. Your idea is great – the notice is brilliant.
adamziel
commented
2 months ago Also I thought I'd mention – we don't have to use the word "Storage". I put it in there long time ago and it's a "developer UI" thing, but if you think there's a more intuitive language feel free to go for it.
adamziel
commented
2 months ago @jarekmorawski the linear nature of GitHub issues got me confused – do you have feedback on everything you posted so far, or did we miss anything?
bgrgicak
commented
2 months ago "Save as a Template" site feature that would enable starting from a specific state. This would technically export the site as a zip and freeze it in time. "Add Blueprint" to store Blueprint JSON that would always install fresh plugins versions.
I find the naming confusing. I would expect "Save as a Template" to save a blueprint because blueprints are technically templates for sites.
Maybe we could use export of backup instead of "Save as a Template".
adamziel
commented
2 months ago I find the naming confusing. I would expect "Save as a Template" to save a blueprint because blueprints are technically templates for sites.
Oh sorry @bgrgicak, all I meant is this user experience:
What's a zip snapshot and what's a Blueprint will emerge from technical limitations.
jarekmorawski
commented
2 months ago the linear nature of GitHub issues got me confused – do you have feedback on everything you posted so far, or did we miss anything?
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.
bgrgicak
commented
2 months ago We started a discussion about implementing the new design. https://github.com/WordPress/wordpress-playground/discussions/1652
adamziel
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago ❤️ I think it is thorough and well-considered overall.
brandonpayton
commented
2 months ago I left one comment about possibly keeping temporary sites in browser storage for a short time.
bgrgicak
commented
2 months ago We have a new issue for tracking project development.
I'm closing this one because the design is completed.
Thank you @jarekmorawski!
adamziel
commented
2 months ago 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
commented
2 months ago Ah, https://github.com/WordPress/wordpress-playground/issues/1655 is playing that higher level role. Alright, let's close this one.
Now that Playground supports multiple offline sites, we need a UI redesign to actually enable using it. The redesign will also unlock:
Done is
@jarekmorawski is exploring it.