Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Centralize/Facilitate Reporting of UX Challenges with FSE over Mobile #44682

Open
TonyGravagno opened this issue Oct 4, 2022 · 2 comments
Open
Labels
General Interface Parts of the UI which don't fall neatly under other labels. Needs Design Feedback Needs general design feedback. [Type] Discussion For issues that are high-level and not yet ready to implement.

Comments

@TonyGravagno
Copy link
Contributor

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:

  • Just open any aspect of FSE on a phone or tablet and try to use it.
  • Create and edit templates and parts.
  • Add blocks to a post and configure them.
  • Add more structure with nested/container blocks.
  • Note the challenges here along with device type, screen size, browser, and related versions.
  • Is the experience any better if you switch from mobile view to desktop view on the mobile device?

Examples of usability issues reported here that might be itemized in some other ticket for improvement:

  • Moving blocks
  • Visibility of settings, menus, and controls
  • Popups or other helpful mechanisms that improve desktop experience but which do not work on mobile
  • Issues with operations on multiple blocks
  • Issues between List View and the main editor window

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. :)

@talldan
Copy link
Contributor

talldan commented Oct 5, 2022

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.

@talldan talldan added General Interface Parts of the UI which don't fall neatly under other labels. Needs Design Feedback Needs general design feedback. labels Oct 5, 2022
@annezazu
Copy link
Contributor

annezazu commented Oct 5, 2022

Thanks for opening this and taking the time to share the feedback. That intrinsic web design is definitely covering the technical aspects but I can see where an overall tracking issue would be helpful. It might make sense to turn that #34641 into that or to have a companion one for it. Until that happens, this can be a placeholder of sorts for dialogue and consideration :)

@jordesign jordesign added the [Type] Discussion For issues that are high-level and not yet ready to implement. label Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
General Interface Parts of the UI which don't fall neatly under other labels. Needs Design Feedback Needs general design feedback. [Type] Discussion For issues that are high-level and not yet ready to implement.
Projects
None yet
Development

No branches or pull requests

4 participants