I wanted to suggest adding a feature that our clients constantly ask for, and it's the ability hide a slice from a page, just like with layers in Photoshop, Figma etc.
For example, our current client wants to hide a section without deleting it, so that the slice data persists. The only optimal solution right now is to copy the slice and paste it in another draft page. The other would be to include an additional boolean field on each slice, but it's suboptimal DX-wise and it would still appear in the API response.
I have a hefty bulk of feature ideas for Prismic and this one sits among the top requests I would have – and I collect them, because I care about Prismic and love using it and seeing it grow!
Thank you for reaching out with this, we love hearing from our users
I want to pass this on to the team as a feature request, but before I do that I'd like a little bit more information on your use case here. What's the key to this need, is it for when you have too many slices to edit a document comfortably, is it to compare different set-ups for any given page, something else? The more details you can give me on how this would serve your work flow, the better we can address it, be it in this proposed iteration or in another one in line with something we're already planning for the product.
I believe the key is convenience and flexibility. In this particular use case, our client wants to have some slices already prepared and filled with data for future use. These slices include:
Banner – some important information that they want and have planned to reveal at a later time. As for banners, I had another client who wanted to have a set of seasonal banners at the top of the page that they can easily toggle between and just edit tiny details like dates in the text and URLs. With previously predefined banner slices, but hidden from users, the process of hiding, showing and reusing seasonal banner would be much easier.
Featured Blog Articles – after the launch, the client doesn't want to display this section immediately, but rather after some time, and when the time comes, he wants to easily toggle this section on, preferably with one click instead of adding a slice and filling in the data.
There's also a dev use case where I'd like to test a slice on a page with different data variations, and instead of having multiple slices on my page, I could show only the one that I'm currently working on.
Also, in my use case, page hero contains a gradient that spans across the next section, so I need to see how it combines with the next slice. I guess this one can be solved by just changing slice order, but I still feel like I'd want to have my page to not be visually cluttered.
I'm aware some of these issues can be solved with Releases, but I think it's not as flexible in every case, such as this one, as the proposed solution in this case. I can't schedule two releases for one page edits, one with new banner and another with new section, because the second one will overwrite the first one. I still believe releases are a great tool and I just think visibility switching would be another flexible tool in the arsenal that can solve similar issues and some new issues that clients may rise. Comparing different set-ups, as you've mentioned, could be one of these use cases, although we know that can be approached in a different way, e.g. creating a page copy with a different set-up.
In summary, I think this feature would unlock new flexible and convenient ways to go about your content that previously had to be "hacked" or dealed with in inconvenient ways. It would serve as an alternative solution to some issues that clients might prefer, but it wouldn't end here and instead offer novel use cases, making it worthwhile considering.
Thank you for all the details, this is really helpful!
What I get from this is that we really could improve releases I agree especially with your point about scheduling two releases for one page, it makes it hard to plan ahead in the future (I'm thinking especially for things like Holiday sales for example). However, it does bring up some issues of having separate branches of the same page "cancelling" content previously published, so it's a tricky one.
I'm not sure if having visibility toggles directly in the document would be the best workflow, as a simple toggle for on/off visibility could create a catastrophe of misclicks and complicate an otherwise straight-forward page, but I totally see your vision. That said, I'm going to leave that kind of decision-making up to the Product team!
I've passed on your feature request in this iteration: https://prismic.atlassian.net/browse/BT-270. I think it's more focused on what we can improve on in the existing product, but makes a note of your use cases that an update on releases wouldn't necessarily cover. I can't make any promises these features/ideas will be prioritised or implemented in one way or another, but they will look into it, so thank you for taking the time to raise this
There's also a dev use case where I'd like to test a slice on a page with different data variations, and instead of having multiple slices on my page, I could show only the one that I'm currently working on.
Is there a reason why the Slice Simulator and/or Live Preview isn't cutting it for you here, or not doing enough?
I definitely think visibility toggles could potentially lead to a messy document, but probably from mismanagement, just like a Media Library can become a hell to navigate without proper tags and file names. As for the misclicks, I think that simply moving the toggle to the options dropdown, where copy, paste etc. are located, would solve that issue, but that's just one of the options that can be considered
And as for the dev case, most of the time it's not a big deal as Slice Simulator and Live Preview are enough. The use cases where they usually are not enough would be the before mentioned gradient spanning, so basically some kinds of interactions with other slices. Slice Simulator is also not enough when content relationships are to be tested, and Live Previews are sometimes not enough with detailed content, as the previews are quite small, which is why I've supported this idea of bringing an ability to the end user to enlarge them if needed.
Thanks for taking your time, I appreciate you looking into my idea! Even if all this achieves is improving existing features like releases, I'm happy that I had my part in contributing to the great product!
Live Preview is relatively new, so there's room for improvement on that as well for sure. For Slice Simulator and content relationships, we also have it logged to work on making that available too if possible, so these are existing feature requests, which is good news. Lots to look forward to
Thanks again, and if you have more good ideas like these, do feel free to keep sharing them, we love to hear it!
