Gutenberg respects the editor support as declared by a CPT and won't load if that is not supported.

If this means that Gutenberg doesn't load at all and the Classic editor is used instead, then that sets us on a path towards a fractured WP admin that is split between Gutenberg and Classic environments. This would be bad for WordPress in many ways.

• New users would have to learn the major and subtle ways in which the two types of interfaces differ. Action as simple as publishing a post or changing to text view work differently in Gutenberg and Classic editors.

• Existing developers would be forced to maintain functionality of their themes and plugins in both environments. We're not talking about a transition period; we're talking indefinitely. Plugins that are meant to extend any post type would be most affected. If those developers do end up converting their meta boxes to blocks, then they'll still have to maintain the old meta boxes in case anyone uses their plugin in a non-Gutenberg post type.

• New plugin developers entering WordPress development would have to learn how to build plugins two different ways. Assuming they embrace Gutenberg blocks, their plugin functionality may not even be available in post types using the Classic editor.

As much as I believe we must get meta boxes working, simply turning off Gutenberg is not the best solution over the long term.

If this means that Gutenberg doesn't load at all and the Classic editor is used instead, then that sets us on a path towards a fractured WP admin that is split between Gutenberg and Classic environments.

In the cases where a CPT doesn't want to enable the editor at all, that seems like the best path forward. It is simply a different admin view, optimized for a different experience. (The "orders" view from Woo, for instance.) It wouldn't help anyone to try to render those within the Gutenberg context.

It is similar to the advent of the Customizer—it was a new interface paradigm that did some of the same things in a different context. We'll always need a "management" interface and an "editing" interface. That is partially how we move forwards, by clarifying the different purposes of interfaces.

But because of Gutenberg's scope creep, it's not simply about enabling or disabling the type of editor. Since Gutenberg now determines the entire editing interface, there are a whole list of side effects associated with the editor type that I listed above.

We'll always need a "management" interface and an "editing" interface.

Those are exactly the roles that the editor and meta boxes fulfill today. They are not isolated experiences. They work together.

then perhaps the scope creep should be addressed, and Gutenberg should be constrained to the area populated by wp_editor(). It would certainly solve many compatibility issues.

Scope Creep

Addressing the scope creep is my preference and something many of us have been calling for over the past several months. Doing so would allow us to improve the editor without splitting the admin experience.

Enabling Gutenberg Per Post Type

Regarding the ability to disable Gutenberg per post type, I want to stress that avoiding the problem is not the same as arriving at a solution. Toggling off Gutenberg per post type may avoid the meta box incompatibility for some plugins, but it damages the WordPress landscape over the long term.

If you can't see why, imagine being a new plugin developer entering the industry two years from now, after Gutenberg has been merged.

• As a developer, do you write your plugin UI as a block or as a meta box? If you want to support all post types, you'll have to write it as both.
• When a user is searching for plugins, are they aware that the functionality you promise on your plugin page only works in Gutenberg-enabled post types? Will they be disappointed when they find out they can't use it alongside the Classic editor?
• When that same user contacts you for support, do you know if they are asking about how your plugin works in the Classic editor or the Gutenberg editor. Does that customer even know the difference?
• When you want to add functionality months after launch, are you willing to multiply your development time to build that functionality into both the PHP meta box and the JS block?

Those are just a few of the questions that confuse the landscape when we move forward with two editors and no path towards singularity in the UI.

show_in_rest

The fact that posts can't use Gutenberg when show_in_rest is not set is just another example of unrelated functionality affecting the editing experience. There's no reason why my preference for public post visibility in the REST API should affect what interface I use when editing. I understand the technical reasons but the logic isn't there, and I suspect many developers aren't even aware this is a limitation at this point.

How Gutenberg ever got outside the scope of wp_editor() parameters still baffles me. If the Gutenberg "editor" would be restrained to wp_editor() then the "enabling as an option" per post type becomes a reality and much more manageable and expandable in the future. I still have not seen a rational explanation on why Gutenberg scope creep can't be scaled back and just be contained within wp_editor().

It doesn't make sense for Gutenberg to be enabled for Custom Post Types that don't use the editor and that aren't directly displayed on the frontend.

I've seen various websites where CPTs are used not just for genuine post types, but as a method of creating admin interfaces for various settings and elements.

For example, an author site I've worked on has CPTs for "Books" and "Shop links". Having Gutenberg as the editor for the Books listings pages absolutely makes sense. But "Shop links" have no posts or pages of their own, but are used to supply the logic for links to online bookstores on each "Book" page. The Books page template displays Shop Links to product pages that match the region (e.g. UK, US) and format (e.g. ebook, print), inserting the ISBN stored in a post meta field into each online store's URL structure - see screenshots.

CPTs may not be the best way of managing this kind of data and settings, but there are lots of websites that have bolted together various functions using editor-less CPTs and custom meta fields - I could provide other examples of this kind of usage. It would be confusing and counterproductive to force the Gutenberg editor onto CPTs that don't use the editor at all.

It doesn't make sense for Gutenberg to be enabled for Custom Post Types that don't use the editor and that aren't directly displayed on the frontend.

No it doesn't make sense, but as long as Gutenberg is a full-screen replacement, then the decision to include or exclude Gutenberg has larger ramifications that go beyond whether you want an editor in your post type or not.

For example, imagine you're a plugin developer and you want your "Shop link settings" meta box to be available in one post type that uses Gutenberg and a second post type that does not. When you're distributing a plugin to thousands of users who expect it to work with any post type, you don't have the luxury of choosing. That's when the questions mentioned in https://github.com/WordPress/gutenberg/issues/3330#issuecomment-341867663 come into play.

It's worth repeating that meta boxes isolated within their own post type are the least affected by Gutenberg, so we have to consider how it affects plugin functionality that serves across post types.

Yes, I can see that plugins having to support both Gutenberg and non-Gutenberg interfaces would be a major ongoing issue

I guess the question then becomes is how Gutenberg should handle CPTs that don't support the editor - how does Gutenberg function in contexts where it doesn't make sense to build a page from blocks, where it is just meta driven?

...how Gutenberg should handle CPTs that don't support the editor - how does Gutenberg function in contexts where it doesn't make sense to build a page from blocks, where it is just meta driven?

If Gutenberg was to scale back and only replace the editor like in the Yoast concept I mentioned in https://github.com/WordPress/gutenberg/issues/3304#issuecomment-341474018, then enabling or disabling Gutenberg becomes pretty straightforward.

• If editor is enabled, then the block editor is present and meta boxes can appear above or below it depending on the hooks that are used.
• If editor is disabled, then the block editor is absent and the meta boxes slide up to become the primary interface for the post type.

That's essentially how it works today, and by maintaining that behavior, it would allow plugins to gradually transition meta boxes to blocks in cases where that makes sense. It would also avoid a lot of the confusing questions listed above that are associated with a split admin experience.

I find "scope creep" to be a weird term to use, given the kickoff post, and the blessing the project has received. It feels disparaging to the work that's already been done, in public, since January 11th where we started discussing and researching how to improve the editing experience as a whole. Nothing creeped up on us, this was always the plan, and it's why there's no set term for the focus.

Be that as it may, I'd like to talk a little bit about the design perspective, and why I feel that designing the editor focus around just replacing the content area would have been a ridiculously compromising experience, just for the sake of maintaining complete backwards compatibility with every plugin built to extend the editor in the past decade. The status quo is the easy way out, but not always the right way.

Adding blocks to the existing editor without rethinking the flow would have added complexity where there was already complexity.

Given the mandate — to rethink post authoring to involve blocks to replace shortcodes, custom HTML, widgets and more — I would be squandering my responsibility as a designer by not looking at the entire writing, editing and publishing flow holistically.

I'm not convinced that WordPress will be relevant in five years, unless the project as a whole takes bold steps to meet the future. A JavaScript core has been advertized at State of the Word keynotes for years. Keeping that in mind, and the opportunity we have to radically simplify rich post content authoring, looking at the whole editing experience instead of a tiny window is not only an opportunity, but it would arguably be negligent to design otherwise, despite the challenges it brings with it.

It is impossible to design a good editor without looking at the whole screen. This is inconvenient, it makes the project difficult, and given the legacy of WordPress, it makes it still harder. It hasn't been easy, and we have a ways to go still, notably around how Gutenberg can be extended natively. But taking a half-step, building Gutenberg to replace only the content textarea, would be a major disservice to WordPress and a bad design to boot.

Loading one component of Gutenberg, just the editor canvas, into the current editing screen is possible. It will be a heavily compromised experience and a Frankenstein of a UI, but it can be one avenue to explore for ensuring a good migration path from 4.9 to 5.0. But it should be made clear that this is neither the stock experience, nor the optimal one.

I guess the question then becomes is how Gutenberg should handle CPTs that don't support the editor - how does Gutenberg function in contexts where it doesn't make sense to build a page from blocks, where it is just meta driven?

@CalebWoodbridge this is already how it works. See: https://github.com/WordPress/gutenberg/blob/master/lib/register.php#L290

I would second that using the term 'scope creep' is not correct. It's a term that certainly doesn't apply to a project that is meant to do what Gutenberg is.

Forgive me for taking a side point on this, but I think it's worth saying. Just like respect is given to developers when they say something technical, think about the designers in the same light. The designers working on this project have a lot of experience and skill, I deeply respect the work and it's a pleasure to be the design lead of a project with such amazing designers.

I feel honoured to have the opportunity to work with the designers that are on Gutenberg. It's a daily pleasure and something we don't always get in WordPress. Most of the time as a designer in core you are a lone person, it's been incredible to get to work together.

The experience is key when we look at the design approach. @jasmussen in the original vision along with @matias set the foundation of a complete experience. As the second design lead, it's been something I value and want to preserve.

One of the big issues with WordPress in the past from a design perspective has been a spiral of small iterations on top of small iterations. Whilst it works for the first few, over time it adds up to an experience held together with patches of improvements. There's a lot of WordPress that suffers from this. Editor is one, media is another and there are a whole lot more able to be pointed to.

Gutenberg has given us space to remove the patches, to look at what we have and build up again. It's given us as a result the start of a strong visual language to move into Customization and beyond. To actually have a visual language that moves WordPress forward into the next 10 years. Yes, we have to think that far ahead.

I want to take a point to also warn against Frankendesigns. Every single designer in the world has at some point had someone suggest they 'just put x here or y there'. This is not allowing the designer to design. As a project we are on a downward spiral if we do not let designers design. This is the kind of process that to be blunt, kills the fire in designers. Let's keep the fire going.

This is a personal note, that goes beyond Gutenberg. I am passionate we create a space where designers can thrive and grow - we haven't always as a project. Let's show with Gutenberg that we do that. Passion is great, but respect the design vision just like we do in WordPress the technical vision. Let's listen to designers as much as we listen to those talking about the latest JS framework.

To the point about being bold raised by @jasmussen, good design is bold. It always has been. It also requires space to explore and think, Gutenberg has been incredible for that. We have (we still have) a space where we can explore ideas that before we felt were too much as a project to tackle. There has been freedom to iterate, experiment and try. This has produced some incredible design, let's not forget that.

I want to be clear, I am not saying Gutenberg is 'done' or perfect as a design. We need to iterate and we need to test. What we do not need is to go backwards, take away from the strong design language established. We do not need to Frankendesign. What we need is to test, get feedback and allow designers to iterate.

One of the big issues with WordPress in the past from a design perspective has been a spiral of small iterations on top of small iterations. Whilst it works for the first few, over time it adds up to an experience held together with patches of improvements.

Trying to reconcile statements like this with public statements like this http://matiasventura.com/post/gutenberg-or-the-ship-of-theseus/ makes it very hard for users to feel like they are receiving honest communication about the work being done. WordPress is used by millions of people in millions of ways, and it has been made abundantly clear that, with regard to technical aspects like metabox support or the post storage format, an incremental approach is required, with as little breakage as possible. This decision has complicated several parts of the implementation, and has forced decisions that are sub-optimal but better supported in many ways.

It is not reasonable to hold the development to one standard and the design to another. Sometimes the 'bold design' needs to be scaled back for reasonable production. This is well known in automotive manufacture, and is why it is easy to compare Gutenberg to a concept car.

Sure, you want a wholistic design that uses javascript for the entirety of the admin, but that can't be the v5 release without breaking the experience for millions of users. Instead, if you scale back to focus on the editor, rather than the edit page, you can provide a much better experience (that can accomplish many of your secondary goals with judicious use of css), without breakage.

Then, by providing a well documented Fields API, you can convert plugins and themes to the Gutenberg blocks mentality over the next year, by making it easier and more logical to produce the same interface. Very swiftly, metaboxes become the old way of doing things, and all high value plugins will switch to blocks... once again, this has to happen organically. Forcing peoples hands by deprecating features or creating a split interface where plugin authors have to code for both gutenberg and metaboxes is untenable.

It's good that you mention overhauling media as an area that needs rework... that is an area that suffered due to runaway, inflexible overhaul. It was the first section of WordPress to fully embrace a JS framework, and it was largely a huge step backwards for developers. The lack of customization in the Media Library is not a sign that it is perfect, but rather that it lacks thoughtful design that takes future and current use-cases into account. I have tried modifying the media interface many times, only to find that someone, at some point decided that major components should be hard-coded into the backbone templates. I literally ran into one of these cases yesterday! (as you can see in the seventh paragraph here: https://gschoppe.com/wordpress/disable-attachment-pages/)

Scaling Gutenberg back to the editor, rather than the edit page would give you a path forward that doesn't break everything. Once Gutenberg is well established as the basis of custom post interfaces, then the JavaScript-only vision can move to take over the rest of the edit page. This sort of iteration is absolutely crucial in large software packages, unless (as matt has claimed unacceptable) you offer LTS releases, and make each major version a complete breaking change.

There are two pits that you run the risk of falling into, and you've identified one. Yes, without moving towards a unified interface using modern technologies, WordPress will likely die in the next half decade. But also, if WordPress fails to provide adequate support for its massive community of developers and professional users during this transition, it will die much sooner.

Take a beat, scale back, and deliver something that opens the toolbox up to users, without breaking the existing workflow. Then you can scale forward, version by version. You have a beautiful concept car, but what we need is a production car that works for all the edge cases of real-world driving. But by providing the concept, you can take that idea and apply it to a more limited scope, and by a year in, those principles will be ubiquitous

@gschoppe, thank you for taking time to reply.

First, some clarity. I do not agree that my comment counters the post by Matias. I stand with the post he made fully, it's my vision too and we are as the leads of this project united in the way we see the direction. Your personal opinion is yours, so let's move on from that point.

It is not reasonable to hold the development to one standard and the design to another.

I agree and my comment does not aim that design gets heard more or has different srtandards, it is about hearing all voices, applying same standard to all.

It's good that you mention overhauling media as an area that needs rework... that is an area that suffered due to runaway, inflexible overhaul.

I would love to see a media focusing from ground up with designers and developers, that hasn't been the case.

But also, if WordPress fails to provide adequate support for its massive community of developers and professional users during this transition, it will die much sooner.

It's interesting you say this as nobody is taking away any functionality. No design suggestion by Gutenberg has done that. One way or the other, all existing functionality can get done, even if that's using the classic editor plugin.

I can't think of anything more Frankendesign than relying on iframes to piece together a UI. While I understand meta boxes are throwing a major wrench into the design process, part of design is dealing with limitations. Moving forward as if those limitations don't exist or putting off the transition plan until the end will add further concern to an already worried and skeptical community.

If the long-term plan for Gutenberg was plugin territory, then I would say experiment away without limits. But if it's not destined to be a plugin that people have to opt into rather than opt out of, then it has to deal realistically with core and all the baggage it brings with it.

my comment does not aim that design gets heard more

Every single designer in the world has at some point had someone suggest they 'just put x here or y there'. This is not allowing the designer to design. As a project we are on a downward spiral if we do not let designers design. This is the kind of process that to be blunt, kills the fire in designers. Let's keep the fire going.

In every business in the world, designs are adjusted to the constraints of the implementation. If backwards compatibility for metaboxes is a constraint, the design needs to accept that and work within constraints.

To be blunt, is complete support for metaboxes, without loss of accessibility, a design constraint or not? I would like a clear answer, as would thousands of others.

No design suggestion by Gutenberg has done that. One way or the other, all existing functionality can get done, even if that's using the classic editor plugin.

Currently, Gutenberg puts all metafields in an iframe. That breaks functionality at a very deep level. We are in the age of Accessibility, and taking the primary expected method of creating custom user experiences and jailing it in an iframe fundamentally removes all accessibility from those tools. It also triples the number of requests required to load the editor, and gives users terrible ui, jailing full-screen modal experiences to a tiny area.

Currently, this thread discusses whether Gutenberg should be opt in or opt out for custom post types. If opt-in, previously consistent UI decisions made by developers who want to support all post types will be fractured between the Gutenberg experience, and the classic experience, requiring twice the dev work to provide a reasonable user experience for both, and ensuring no consistence of user experience.

Currently, the wp_editor() function (which is the current best-practices way to implement a full-featured copy of the editing experience on non-edit pages) doesn't provide a Gutenberg interface, meaning that I can't create custom edit experiences on non-post pages... what is my path forward there, aside from giving users a split UX?

While the plugin to remove Gutenberg may solve some problems, you can't ship it as a solution for plugin developers. They don't have the freedom to say "if you want a consistent and accessible user interface across post types, you need to disable the new editor".

Feature removal is NOT backwards compatibility for the standard workflow. Feature removal is the last resort for the 1% of users who can't be accommodated as first-class experiences. In this case, none of the examples i've given are 1% issues.

To add a bit of oil into the flames: Just last week, I ran into a massive issue with using iFrames, ie. they may play nice on Desktop systems, but in 90% of the cases tested, they fail massively on Mobile / Responsive. After digging through numerous of message board threads, articles on the net and questions on Stack Overflow, I decided to totally abandon the iframe approach, because responsiveness gets so horrible complicated with em .. ugh. Some conversion tasks were rather easy done, like "use a redirect to the actual subdomain where the project resides" instead of relying on an iframe to put up a nice decoration aka only showing the supposed main domain, but others were much more wretching.

Nonetheless, compared with the massive amount of work I'd have to do to get RWD properly, and most of all, reliable AND maintainable, to work with iframes, the turn-about was much less effort and thus the better way out.

To sum it up, although iframes look at first glance like an easy way out, they are a VERY BAD design choice, not just because of (lots of) accessibility issues.

Just my .02 cents,
cu, w0lf.

Thank you @mtias for showing this issue.
Bellow I'm posting my thoughts on how Gutenberg can open doors for the WordPress plugin developers.

Customizable CSS class for any existing block

Needed: CSS class for each block wrapper and full access to customize it. It will be great if Gutenberg requires CSS class on the very top element even from third-party developers.

Purpose: This way we can add custom classes to the blocks for advanced styling. We can also use classes to add animations or other advanced block properties.

Example usage: We create a website for a big client with a strictly defined design language. Side editor should be able to create blocks with a predefined number of styles created by our designer, especially for this client.

Customizable data attributes for any existing block

Needed: Possibility to add customize data attributes for any block wrapper.

Purpose: Cleaner and more flexible alternative to custom CSS classes described above. With data attributes, we can style any element on the page. Besides styling, custom data attributes can be used to store additional metadata for JS.

Example usage:

• responsive blocks: mark a block to be shown on mobile/desktop only
• conditional blocks: mark a block to be shown/hidden with JS <div data-condition="if-adblock"..., <div data-condition="if-from-facebook"...
• block animation: mark a block to be animated <div data-animation="on-load animation-style-3"...
• block design: <div data-skin="dark"...

Customizable block settings/styling controls

Needed: Option to add custom controls and a possibility to change existing controls in the block.

Purpose: To extend any current and future block with new advanced settings or clean from unwanted/unneeded settings.

Example usage:

• I don't want my clients to design "their own" button styles (mostly they have a very bad taste) but to stick with predesigned corporate styles. To make it done I need to be able to hide text and background color options for a button and add one more additional Style dropdown control.

See also: #2474

Option to filter any block output right before rendering it (PHP).

This will allow developers to have a final chance to customize the block rendering. Can be used in many scenarios, here are some examples:
- Restricted content: hide block for non-members

• Conditional rendering: hide block based on some advanced condition
• Filter/Clean block code: I hate the idea of having inline styles added by Gutenberg. Using this filter I will be able to clean the code before rendering.
• Content translation: translate block to another language

Access to the Gutenberg state and UI events.

We can extend Gutenberg with advanced functionality if we have access to the events happening on the page and the state of the editor.

Need access to events like (subscription to state changes?):

• block selected (+ block meta)
• block added
• block deleted
• block setting changed
• block moved
• revision created
• settings panel open/close
• preview clicked

Access to the state from the outside.

It will open a door for advanced Gutenberg plugins without a need to ask you for new API.

Possibility to add new blocks on the page programmatically.

Example usage:

I can add a library of the block designs with the custom sidebar in Gutenberg. Users will click on the block design they like and JS from my plugin will add the block programmatically on the page with preset settings.

See also: #2473

A possibility to reuse the default blocks in the custom blocks (as part of the bigger block).

See #2995

@lumberman That pro arguments and efforts will all fail if the documentation is going to be as spare as it has been in the case of the Theme Customizer (esp. when there nowhere was prominently mentioned the fact that it's been missing a major part from the start, ie. the Changeset API / feature).

cu, w0lf.

@ginsterbusch Gutenberg is well documented when it comes to the already-codeded components and controls.

@mtias regarding the pre-publish checkup, how do you feel about making that a screen takeover too? It would offer some more room to the various elements to give more feedback, and has the potential to turn into a multi-step sort of wizard maybe. This might also help remove the double publish button confusion, as you're actually switching context instead of just opening a dropdown.

@hedgefield As part of the mockups, I also explored a "larger than a dropdown" version. Let's call this the "popover" version. I didn't show it because it's mostly an experiment/concept. But worth sharing, as it's an idea we can test depending on how the dropdown w. toggle-off version works:

@lumberman thanks for your thoughts and ideas!

Customizable CSS class for any existing block

We give blocks a default class of wp-block-{name}. There's some ongoing work to make this easier to extend as well apart from user configurable custom classes. How do you envision this working from the developer perspective?

Customizable block settings/styling controls

Definitely. This is the main purpose of adding "inspector items to existing blocks". Some of this is already possible. You could also completely replace a block with your own version in some cases. Disabling specific features of a block might have to be something we do in add_theme_support.

Option to filter any block output right before rendering it (PHP)

This should be possible already for the most part.

@mtias re: Custom Post Types:

It also won't load is show_in_rest is not set.

In testing I've also found that it won't load if a Custom Post Type uses a custom REST controller class. In Pressbooks, we register a custom controller for our CPTs in our own namespace (/wp-json/pressbooks/v2/<posttype>) and this is not currently compatible with Gutenberg. See #3462.

Here are some mockups for how pinning extensions to the toolbar could work. This is inspired by Chrome and Firefox.

1. You open it from the ellipsis, where all editor extensions register themselves

1. This immediately opens a sidebar, because this is a "editor sidebar extension":

1. All sidebar extensions have a "Star" icon in their heading.

1. Click it to pin the icon to the toolbar:

1. Even if you close the sidebar, the extension icon still sits there for quick access:

Repeat these steps in reverse to unpin it.

@jasmussen Wouldn't it make more sense to have a pin icon rather than a star for pinning/unpinning a sidebar extension if the terminology being used is pin and unpin?

Wouldn't it make more sense to have a pin icon rather than a star for pinning/unpinning a sidebar extension if the terminology being used is pin and unpin?

I actually tried several variants of a pin icon for the very same reason. But none of them visually read very well. The star on the other hand seems to be becoming a pattern for "favorite" or "bookmark". Though you make a good point about the verbiage. Could "bookmark to toolbar" work as a label?

I actually tried several variants of a pin icon for the very same reason. But none of them visually read very well. The star on the other hand seems to be becoming a pattern for "favorite" or "bookmark". Though you make a good point about the verbiage. Could "bookmark to toolbar" work as a label?

I think that the "pin" verbiage is the correct one. Typically you would pin an element to a UI for utility reasons. Which isn't necessarily the same thing as favoriting or bookmarking something. There are certainly nuances.

"Star" icon in their heading

Both Chrome and Firefox use text labels ( Pin Tab and Unpin Tab ) that are clear to everyone. If using an icon, I'd suggest to think also to an "unpin" icon.

Accessibility note: the "pinned icon" in the toolbar suffers from the same issue of the sidebar "cog" icon. When using a keyboard:

• activate the icon (they're buttons, so press Enter or Spacebar)
• the sidebar opens
• now users have to press Tab a lots of times to get to the sidebar

Ideally, controls that open expandable panels should be placed in the source immediately before the panel. Alternatively, focus should be managed programmatically. See also #469 (posted on April 20th).

I do wonder if a pin means anything to most users, I am really not convinced it does. Star means favourite to a lot of people or 'mark' so that feels more logical.

Just use text 🙂

I do wonder if a pin means anything to most users, I am really not convinced it does. Star means favourite to a lot of people or 'mark' so that feels more logical.

Keep in Dock is used in macOS for a similar feature.

Noting that I've updated this ticket with more recent "Screen Takeover" mockups. They are now modal, where previosuly they were a separate screen. A separate screen can be revisited in the future, if need be.

Oops, sorry, didn't mean to close this one. Reopened and filed as not done again :)

Closing this as everything has an implementation by now. Improvements should come in individual tasks. Thanks all!