Given all of the latest changes, my team and I are wondering if there is any talk internally for Prismic regarding the requirement of fields?
Besides slugs it has been Prismic's stance to opt-out of requiring fields to be filled out in order for editors to save the document. While I can understand some of the reasoning behind this choice, it seems that the choice should be left in the hands of admins who need to uphold some standard for our documents. Whether that is for SEO purposes, writing standards, etc.
Does the Prismic team have any intentions of revisiting their stance now or in the near future or does the article above still maintain Prismic's views moving forward?
Thank you and hope to hear from you all!
Edit:
The reasoning behind this question comes from Prismic's warnings when using the "PrismicNextImage" component and adding an alt and/or fallbackAlt prop.
There is a warning given whenever a user does not add alt text however we cannot edit alt to be anything other than an empty string. This seems like it would be much simpler by either allowing devs to add alt/fallback alt that is not an empty string or requiring it from the cms user.
Regardless, this seems to put our developers in a catch 22. We can neither require the user to put in alt text nor implement an alternative solution to make sure there is an alt text. Thus going against Prismic's stance and reasoning for not having required fields.
This is not a helpful response, so allow me to preemptively apologize for that fact. I surmise this is a popular request, but one that probably doesn't have a simple solution (or it would have been implemented already). This could be one of those annoying things that we deal with because there's so much else we like about their service. I will be interested to hear what they have to say, just like you.
It's quite relevant to your question about SEO. Saying that though I will bring this to the team to see if we have any further updates on this concept.
While I can appreciate the incoming feature for SEO metadata, there are still other factors that will affect SEO and accessibility. Would more use cases and/or a written reasoning help?
I'm of no mind that this is a easy or simple request to make as I'm sure the codebase is structurally built on this premise. While it may not be a flip of the switch, we are convinced this would be an essential feature users can opt into.
At the very least, would we be able to get the why behind this decision? Even if it's stating Prismic's original stance is the reason why.
I agree with much of this.
As stated above in my response to Phil, I don't believe that this is a simple solution. If this has been Prismic's stance for over seven years now, I am sure much of their codebase is predicated on it. I don't work for a CMS company, nor do I run one, so I'm sure there is much more to take into account than I can know. Hopefully we are just a data point of many to show that maybe there is a middle ground.
Simultaneously, if the reasoning is that Prismic does not want a bad UX then it begs the question of who does Prismic consider the user. Based on the article frequently cited, that's the content editor yet I'd argue that there are more factors to consider. Explicitly quoting Prismic "we are not ready to sacrifice the entirety of the editor experience simply to make a developer's work easier".
Frankly we hope everyone's work can be easier however our goal is not easier, Our goal is a better product for our users and that means, at times, upholding a standard so the users of our site have a wonderful experience. Whether that's dealing with SEO, accessibility, or some other factors. To expound, if Prismic believes the dichotomy is between content editors and developers than that may be a belief that is more of a hinderance than previously perceived.
All in all, Prismic is a product we enjoy and is evolving in ways better than we can imagine. This is just a point of friction that we hope we can better be heard and if nothing changes, at least better understand the reasoning behind it. At this time, it seems that the lack of required fields has become more of an impediment to UX than it has been given credit for.
