talldan
commented
2 years ago If this ticket is invalid, please identify a better place for this initiative.
Often you'll see what we call 'Tracking Issues' for this kind of thing. Some examples: https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is%3Aissue+label%3A%22%5BType%5D+Tracking+Issue%22
Usually they contain fairly prominent checklists of tasks. It might be worth considering something like that, but granted if you're not a regular contributor this can be a lot to maintain.
annezazu
The Challenge
Create a site with FSE on desktop. Now open FSE for the site on a mobile device. The UX can be described as painful.
Why would anyone do that? Let's turn that around. Why would anyone Not value the ability to continue working on content when they are away from their desk? WordPress bloggers have never had challenges with creating or editing content with TinyMCE - the simple screens of WPv5 and prior easily worked in any mobile browser. But we can't do that as well now with Gutenberg. Site developers have had to use desktop tools for classic template editing, but now that we can edit templates in the UI, the allure of doing so is irresistable when we're AFK. (Anyone else here get inspiration to make site tweaks when outside or in bed?)
Suggestion for Improvement
This ticket is intended to provide a single place to identify primary pain points with the FSE experience on mobile devices, with links to/from other tickets that address specific challenges. This ticket might be considered for closing when we can realistically say "FSE on a mobile device is comparable to desktop, we're running out of things that need obvious improvement".
34641 seems to be a similar approach to this, but to me that ticket is describing the technical approach for addressing the overall problem (a necessary step!) and not describing the UX challenges in a way that is meaningful to the average WordPress website developer who is trying to use FSE for daily efforts. That ticket focuses on "responsive blocks", which is an area worthy of effort, but here I'm talking about the overall FSE UX over mobile, and the responsiveness of blocks is only one part of that.
I'm trying to take the pressure off of individuals to create and justify dedicated tickets so that we can start with a less rigorous pool of commonly recognized pain points that can then be used as a base for inquiry by others who are more inclined to create and work on such tickets.
Is this even valid?
This ticket might be invalid if there is a general understanding that FSE is not supposed to have a desktop-like experience on mobile. I have not seen that explicitly stated anywhere. From what I've seen, FSE over mobile is not addressed at all by Make/#marketing. I try to use FSE on mobile because I am not directed not to do so by any documentation, announcement, or on-screen warning. I expect FSE to "work" in mobile because I don't see anything in announcements like "we know this feature is not functional/optimal in mobile yet". If we are told explicity "of course, silly, we don't expect people to be using FSE on a phone", then I will no longer try to do so. But if we want people to use WordPress FSE on a phone as fluidly as on desktop (with obvious screen size considerations) then I think we need to be more explicit about how the mobile UX differs from desktop.
Bigger picture
The paradox here is that the modern world has a "mobile first" mantra for websites. So far Gutenberg is a "desktop first" platform. That makes complete sense given how we all work, but the next step would seem to be "mobile second". An important bigger picture here is that there is still a very poor mobile UX for a multitude of sites, despite the "mobile first" mantra. I suspect that if effort is put into dealing with these concepts in the underlying WordPress/Gutenberg/FSE tooling, that we might see better mobile sites resulting from developers who use these tools - and that's good for everyone.
Proposal
After some confirmation that this is a worthy exercise and that this is the right place to do this, let's itemize UX pain points here. Other tickets can be created to address specific technical issues that create the painful conditions surfaced here.
What you can do:
Examples of usability issues reported here that might be itemized in some other ticket for improvement:
If this ticket is invalid, please identify a better place for this initiative. Appropriately enough, the Make/Slack #fse-outreach-experiment suggestion is to pursue this challenge here ... so please don't point back there. :) Ref1 Ref2 Maybe a better place for this is a website with a form, where FSE users can document their difficulties. Make another proposal.
Thanks for your patience in enduring this long-winded proposal. :)