Wagtail 3.x-4.x editor experience feedback

[gasman]

Since the 3.0 and 4.0 releases we've had lots of valuable feedback about the redesigned editor. Since this often isn't something that can be captured well in Github issues (there's no well-defined "broken" vs "working" binary; changes have to be considered collectively and weighed up against each other; and our design team isn't routinely following the issue queue), that feedback has become spread across various forums, Slack support, and informal conversations - and so I'm starting a thread to collect it in one place and allow us to identify common themes that might get buried otherwise.

If you have any feedback of your own to contribute, or you've seen other people's feedback that hasn't been represented here, please feel free to add to this thread.

[gasman]

Hard to distinguish fields / hierarchy in struct blocks

See also #9293

From Slack #support https://wagtailcms.slack.com/archives/C014L7KJH3N/p1664463966052759:

Darrel O'Pry
4:06 PM
Where is the best place to provide feedback on Admin UI wrt StreamField. I'm getting some feedback from our editors I'd like to share. 2 hot button issues have been raised internally

1. Block titles changing when collapsed, it's replaced with the first field name and the block type is hidden
2. Hard to distinguish fields in struct blocks, the new borders help with individual blocks, but struct blocks are still causing issue. The dominant suggestions that has surfaced internally is that the field labels and block title are the same size, and should probably be scaled to imply a hierarch through typography...

zerolab
1 month ago
Hey
@Darrel O'Pry
thank you for this.
#ui would be a good place, but I've shared this with the team too

LB
1 month ago
See also this chat and my response.
https://wagtailcms.slack.com/archives/C81FGJR2S/p1664471053047009?thread_ts=1664471053.047009&cid=C81FGJR2S

Thibaud
27 days ago
If the issues are very specific like this I’d suggest creating an issue in our bug tracker, after checking there isn’t one already: https://github.com/wagtail/wagtail/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
Make sure to add ample screenshots because it’s crucial for our understanding of what is reported

Thibaud
27 days ago
For 1), we’ve discussed it briefly and had an interest in reverting this but I don’t think this is captured anywhere.
For 2), I’m not sure I follow – as far as I can tell, the block title is bigger and uses a heavier weight than the field labels. The hierarchy is also implied through nesting, and the presence of an icon next to block titles

Darrel O'Pry
27 days ago
I'll open some issues with screen caps today.

LB
27 days ago
See also. https://wagtailcms.slack.com/archives/C81FGJR2S/p1664907731044219?thread_ts=1664907731.044219&cid=C81FGJR2S

LB
25 days ago
See also.
https://wagtailcms.slack.com/archives/C81FGJR2S/p1665074809767969

[gasman]

Visual differences between blocks and group of inputs

Thread 1

From Slack #support https://wagtailcms.slack.com/archives/C81FGJR2S/p1664471053047009?thread_ts=1664471053.047009&cid=C81FGJR2S:

Moreplavec
Sep 29th at 6:04 PM
I upgraded Wagtail 2.x to 4.x and customer was used to much better visual differences between blocks and group of inputs. Is it possible to switch style to old one or is there some theme select to get better visual orientation?

LB
1 month ago
You could probably add custom styles in the interim but I recommend you raise an issue with the exact feedback and ideas if possible.
The old styles are not easy to apply to the new html structure.
The new designs are the culmination of the last 8 months of a redesign and major improvements to the editor interface. Many of the designs did go through large revisions, UX reviews and feedback.
#7739
Nonetheless - any new feedback would be appreciated.

Eric Sherman
1 month ago
Sounds similar to some concerns
@Darrel O'Pry
mentioned

LB
1 month ago
Yeah. See https://wagtailcms.slack.com/archives/C014L7KJH3N/p1664463966052759?thread_ts=1664463966.052759&cid=C014L7KJH3N

Thread 2

From Slack #support https://wagtailcms.slack.com/archives/C81FGJR2S/p1664907731044219?thread_ts=1664907731.044219&cid=C81FGJR2S\:

Moreplavec
7:22 PM
Is there some Wagtail admin theme with more visible blocks and separators? New admin is nice, but some of my customers prefer the old one mainly because of more readable blocks and edges.

LB
27 days ago
Can you please add your thoughts to this existing thread.
https://wagtailcms.slack.com/archives/C014L7KJH3N/p1664463966052759?thread_ts=1664463966.052759&cid=C014L7KJH3N
There isn't another Wagtail theme - you could add your own css if you need though.

LB
27 days ago
See also this comment and the response there.
https://wagtailcms.slack.com/archives/C81FGJR2S/p1664471053047009?thread_ts=1664471053.047009&cid=C81FGJR2S

[gasman]

#9281 - Rich text toolbar is hidden by default making some edits difficult

Prior to Wagtail v4, the rich text toolbar was always visible which made it easy to access the full range of options when editing. Now that the toolbar is hidden by default, it's very difficult. I understand the desire to save screen real estate but it's now nearly impossible for normal editors to discover how to make the same edits they could prior to v4.

[allcaps]

This is addressed via #9905 👏

[gasman]

Accessibility concerns when using Dragon dictation software

From Slack #accessibility https://wagtailcms.slack.com/archives/CB7L6L5S6/p1666358097109509:

Albert Freeman
Hello. I've got some accessibility concerns about Wagtail 4 after testing it on the demo site. I use Dragon dictation software and there are several things about the redesigned UI that don't work well, if at all, for me. I wasn't sure whether to explain full details in this channel, in #accessibility or by using Stack Overflow. In summary, the main problem is that a lot of clickable items are now hidden unless they have the focus. This is fine for mouse or keyboard users, but for users of voice control software like me, this creates lots of barriers and makes using Wagtail much harder. I can give more details of the problems I've experienced if I know the best channel for this.
Posted in support | Oct 21st | View message

Albert Freeman
10 days ago
More about the specific problems I've had while testing version 4:
A lot of clickable links and buttons are now hidden unless they have the focus. A mouse user can hover over elements, or a keyboard user can tab through them, so the elements get the focus and their icons and titles are shown. But this doesn't work with voice control software. I always activate links or buttons either by saying "click [name of link/button]" or "click link" or "click button". If there is more than one matching option, I choose from numbered options displayed next to each matching item on the screen. In Wagtail 3.x this works fine as all options are visible. But all the elements being hidden in Wagtail 4 makes it very difficult to use.
This also applies to the newly hidden toolbar in the rich text editor. I can no longer format text by voice control, but I could this in 3.x. I now need to select text to reveal the toolbar, and then when I have revealed the new toolbar, I can't activate any of its options using Dragon. Previously I could just say a command to activate any item from the static toolbar.
There are other problems as well. The new collapsible feature for sections of the page doesn't work for me. If I say "click collapse", every section of the page collapses. I can't see a way to collapse an individual section while using Dragon. The same applies to expanding after collapsing.

SaptakS
6 days ago
Thanks for pointing these issues out. I think we might need to create a Github issue to test the new design more thoroughly with voice control softwares. I would draw the attention of
@Thibaud

@scotchester

scotchester
6 days ago
Yes, thank you Albert. We very much appreciate the feedback. I agree that a new issue to track voice control improvements would be good. This is an area of assistive technology that I am not very familiar with, compared to screen readers in particular.

SaptakS
6 days ago
I have seen demos of folks using it rather than testing by myself. Most of the times, if it works in screen reader, it usually works with a voice control. But since there are a lot of interfaces in wagtail 4.x which become visible only after user interactions, I can see how this might cause some problem.

SaptakS
6 days ago
One solution might be to keep important information in the accessibility tree and only visually hide? Since we anyways allow to tab through them, might be okay? But I am not fully sure if that solves the voice control issues. Will definitely need more testing from our side as well as voice control users like
@Albert Freeman

LB
6 days ago
Yeah I think we can probably revisit the CSS we use for this kind of behaviour - I would assume opacity:0 is used (not display none) and that would ensure the element is still in the accessibility tree. But I have not looked at the code.
Nonetheless, an issue describing the problem would be super helpful.

Albert Freeman
5 days ago
Thanks everyone. I'm glad my feedback is useful. I'd be happy to test things with Dragon if you need any more voice control user feedback.
Up until now I have generally found Wagtail to be more accessible to me than some other CMS platforms I've used. There are a few other things that I find difficult to do in version 3 and version 4, but up to this point using version 3 I have been able to easily do most things using Dragon.
Dragon often seems to cause the the rich text editor to crash in version 3, and clicking certain buttons or links without obvious labels can be difficult. One example is the upwards chevron to the right of the "save draft" button. I haven't found a way to activate this using either Dragon or with a keyboard, and this problem exists in version 3 and also the demo site for version 4.

Thibaud
4 days ago
@Albert Freeman
honestly getting people like you involved and providing us with feedback is a dream come true for us! We’ve been working on Wagtail’s accessibility consistently for about 3-4 years now, and over all this time we’ve heard from one screen reader user, one user of magnification software, and now you.
We’ve been hoping to get big accessibility experts involved over the years, as well as get funding to test with real users, but this stuff is really hard.
For speech recognition in general and Dragon in particular – do you have good resources to share to educate ourselves? Of all types of assistive technologies personally this is the one I think I know the least about and feel the least able to test with (edited)

Thibaud
4 days ago
Our accessibility team is meeting today in 2 hours (UTC15:30), if you wanted to show us how you use Wagtail, or even just say hi, we’d love to have you there. Here is the Zoom link: https://torchbox.zoom.us/j/81670370421?pwd=bjNmYnFtOC9RK01jdlpENWJHR1Vpdz09
Can also arrange another meeting software if something else works better for you than Zoom

Albert Freeman
4 days ago
Thanks for inviting me
@Thibaud
. I could join your call today (Zoom is fine for me) but it would have to just be a brief hello today as I only have 5 or 10 minutes at that time before I go out. But I'd definitely be happy to join a meeting another day do talk to you for longer about how I use Wagtail.
I can't think of any resource at the moment that might help you, I'll but let you know if I think of something.

[Scotchester]

New issue opened on this topic: #9666

[gasman]

#9498 - None collapsing breadcrumbs in wagtail 4.x

The current wagtail 4.x interface is collapsing breadcrumbs on desktop. This is annoying and unwanted for users.

[gasman]

#9499 - Show a + next to the ... in top menu to add a new page directly and not first have to click the ...

User interface is hard for users not using wagtail everyday. There task is to add a new page and this is hidden under de ... menu next to the breadcrumbs.

[gasman]

#9318 - Page title visual cue that it is a field

I notice that users are skipping the first field Title, "page title" in wagtail 4.0. They are not aware of that this is a form field. So there is slight learning curve. However they keep missing it even when knowing this need to fill it in.

Maybe it would be good to have a better visual que or auto focus on this field so they can't mis it when creating a page or changing a page?

[thibaudcolas]

Just to note this has now been addressed by always showing the border when the field is empty.

[gasman]

#9546 - A few thoughts about the new minimap

Hi devs,

thank you very much for your work and the many new improvements. I have currently looked at the new MiniMap and think it is excellent. However, I would like to share a few thoughts with you on a few points.

• In principle, I would like the MiniMap to be animated so that there is a smoother transition from display to disappearance. The sudden appearance and disappearance makes me a little uneasy. However, I am not a designer and generally Wagtail is sparing with animations.

• If you move the mouse over the scrollbar, the MiniMap disappears again. This is quite fast, because the area for opening the MiniMap is relatively small. (It is also a "mini" map).

• If you want to disable the comment function, you (I) quickly get into the MiniMap area and it overlays the disable button. Maybe it is also because I use a touchpad.

• In Chrome, sometimes an extra scrollbar appears.

• Sometimes an "Open" arrow appears and sometimes it does not. (Chrome and Firefox)

• For streamfields, a snippet of the content is displayed. I find this extremely useful for getting around better. Unfortunately, the content is rarely updated (when saving?) and is thus no longer up to date during editing. So I was sometimes confused where I am and where I have to go.

• I would like it if there was a way to display the MiniMap permanently.

• It would be nice if a click in the MiniMap would expand a collapsed field.

These are all not problems or something that needs to be changed and the advantages of the MiniMap clearly outweigh them. I especially love the display when saving where something still needs to be filled in. But maybe someone finds that here still adjustments would be useful.

[th3hamm0r]

New UI for scheduled publishing

Actually, this is not just a problem with the new UI in 4.1, it probably exists since scheduled publishing is possible.
In general, the nice feature of scheduled publishing is often a bit hard to understand. With every new customer or wagtail installation, we basically have to explain that again: "when you set the schedule dates, you have to publish the page, but don't worry, publishing the page does not actually publish it, it just schedules it".
I'm afraid the new UI won't change that, it just adds a new step, actually 4 more clicks and a page reload (publish page vs. open panel, edit schedule, save schedule, publish page).

The new UI is trying to clarify this, which is good, but after @loicteixeira's suggestion (see slack comments below) I really think, that the simple (technically maybe not that simple) change of the publish-button's label depending on the go-live/expiry dates could actually make the result very clear to the user.
With that, we may even revert back to the previous date fields in the content area.

From Slack #translators https://wagtailcms.slack.com/archives/CTKN6UXKN/p1666852489207999

loicteixeira
27 Oct at 08:34
I'm a bit puzzled by this source string :thinking_face:

This publishing schedule will only take effect after you have published

Apparently it's in the side panel where you set when a page should go live, but what does "after you have published" refers to? The page? Like you set the go live date & time, then you have to publish the page?

loicteixeira
5 days ago
Ah.. This is the header of the schedule popup, and clicking "save schedule" will actually save a draft for the whole page. Saving the whole page makes sense from a technical POV, but the wording of this a rather confusing. Maybe it's meant to teach that closing the popup is not enough, you have to "save schedule", but then why talk about "publish"-ing.
image.png

mattwestcott
👉 5 days ago
It's telling you that you have to publish the page for the scheduling to happen - just clicking "save schedule" or saving as draft won't do it

loicteixeira
5 days ago
I see, doing so I can see the page is now locked until the scheduling happens.
That being said, it should probably say something like "after you publish the page" instead of "after you have published" because it's not entirely clear what the next action is.
Furthermore, the page "publish" button should probably say something like "publish at defined scheduled time" or "approve current version for scheduling" because publish sounds quite immediate.

mattwestcott
👉 5 days ago
Probably something to open as an issue on Github then... might be a bit late for 4.1 though.

th3hamm0r
4 days ago
+1 GH ticket for improvements
I also stumbled over this text during translation. I totally understand, that the new approach is trying to clarify the scheduling, but a the end it still saves the current page form, so any changes will be saved too (or not, if validation errors exist), not only the schedule. So maybe the schedule form should move back into the content, or better to the sidebar, where the new schedule-block is placed
@loicteixeira
really like the suggestion of changing the button labels based on the schedule! ideally, also in js, when dates are selected by the user

[th3hamm0r]

A few more thoughts:

• Revert back to the visible PublishingPanel in the settings tab (so it is again possible to create and schedule a page with a single click), but maybe reuse/add some help text.
• Keep the new go-live/expiry information of the status panel
• Depending on the state of the page (draft vs. live) and the content of the go_live_at/expire_at fields, replace the publish button's label in the frontend with JS:
  • draft + go_live_at > now: "Schedule publication"
  • live + go_live_at > now: "Schedule publication of changes"
  • ... there are probably other combinations, which have to be handled

[vorlif]

Left aligned image overview page

I would like it if the image overview page was left-aligned (right-aligned for some regions) even with few images. Otherwise, the page looks a bit restless and it's hard to find the selection box because it's far away and has low contrast.

Once multiple images are uploaded, all images are left-aligned and it looks nice.

[Scotchester]

I believe this was addressed in #9695.

[vorlif]

Yes, it looks like it's customized. I'm glad to see that. 😊

[vorlif]

Footer buttons partly too small

I am not a designer and have limited taste, but find that the footer buttons are too small in some places.

I find it takes some getting used to that in many places the footer uses the big buttons and in some places these small buttons. The small buttons fit well in the tables, but look out of place in the footer.

I'm afraid I can't put it into words any better, but maybe someone sees it similarly and can better describe my feeling of "dislike".

[thibaudcolas]

👍 I can confirm this is something we’re intending to revisit, for the exact reasons you mentioned, but just haven’t gotten around to doing. Here is the specific issue for reference: #9030.

[vorlif]

Missing validation hint for the new publishing schedule UI

If you set invalid values for the schedule (Go live after expiry), you get the error message The page could not be saved due to validation errors , but nowhere does a hint appear where or what error is present. This sounds stupid and should happen rather rarely. But it happened to me, and I searched for a while before I found the problem. Only after opening the publishing schedule dialog an error message is displayed.

Stupid example, but imagine if more changes had been made:

Peek.2022-11-01.17-54.webm

[laymonage]

See also #9767

[lb-]

Potentially related issue has come up where there is a bit of confusion about the inconsistent position of the 'add comment' (bubble) button relative to different fields.

#9543

The positioning has probably been this way for a while but now that there are less borders and other differences it is probably a bit more noticeable.

[gasman]

Labelling of chooser buttons

#9200 (comment)

We've previously gone back and forth on this, from "Choose another X" / "Edit this X" to "Change" / "Edit" (which proved to be too similar, and identical in some translations) and back again, but there's an additional subtlety where the chooser is part of an InlinePanel where "Choose another X" might mean "Add another item alongside the existing one".

This is probably compounded by the lack of dividing lines between adjacent blocks/fields in the new design - the real Add button isn't clearly associated with the items being added.

[Scotchester]

Help text positioned at bottom of StreamFields

In the 4.0 editor redesign (I believe), help text generally moved to the bottom of the field (except for StructBlocks, ListBlocks, and StreamBlocks, which insert their help text via JS at the top). Previously it was to the right of the field (at the top).

This makes the help text for a StreamField, where any number of blocks can be added, very hard to locate when blocks have been added and it is all the way at the bottom of the entire StreamField.

First thought for a solution

Update wagtail/admin/templates/wagtailadmin/shared/field.html to check whether the field is a StreamField or not (I think that field|fieldtype == block_field would work for this), and if it is, output the help text above the input, instead of below.

[thibaudcolas]

FYI we’ve created #9784 to track this separately.

[thibaudcolas]

👋 here is a (draft) preview of the new help text placement in the upcoming release: https://static-wagtail-v5-0.netlify.app/admin/pages/84/edit/

[timonweb]

I've upgraded a couple of my clients from 2.x/3.x to 4.x, and while the overall feedback was very positive, below are the most common complaints:

1. "The Draftail toolbar isn't sticky anymore." Fortunately, it's possible to stick it manually since 4.2, but some clients want it to be sticky at the top permanently for all users from the start.
2. "There's too much white space which causes excessive scrolling." Indeed, on long forms, it's hard to grasp all the fields without excessive scrolling.
3. "Why are labels and fields not horizontally aligned anymore?" Some users miss how fields used to be aligned in inline panels, and they say there's too much whitespace there.

[thibaudcolas]

@timonweb 👋 thank you for the feedback! We’ve considered this recently and made changes accordingly.

For 1., could you share more about the reasoning there? From our perspective we’ve not seen a good enough reason to have it "present by default", but definitely interested in more feedback on this.

---

For 2., scrolling is something we spent a lot of time considering in our designs. We’re much more reliant on white space for the visual hierarchy of the page than in past releases, the reason being that we can then have the content of the page be more prominent when scrolling. A more compact alternative would mean the actual content being harder to spot.

We’ve also introduced the "minimap" menu off to the right in v4.1 to help with this.

In the upcoming v5.0 we’re also revisiting field-to-field, section-to-section vertical spacing to be a bit tighter. For comparison, here is a static snapshot of Wagtail with:

• v4.2 vertical spacing: https://static-wagtail-v4-2.netlify.app/admin/pages/84/edit/
• v5.0 vertical spacing (draft): https://static-wagtail-v5-0.netlify.app/admin/pages/84/edit/

Are there specific scenarios where white space or scrolling could be further reduced?

---

For 3., there are two reasons why we moved away from the "horizontally aligned label and field" pattern:

• It doesn’t work well at all for people using magnification software. UI elements are much harder to find if they don’t follow a strict top-to-bottom flow, which hurts form completion in particular. This is a well documented issue.
• We wanted more space to the right of the forms to introduce side panels.

[thibaudcolas]

For anyone interested in this – our designer @benenright has recently published a blog post on Wagtail’s recent design direction, How and why the Wagtail page editor is evolving.

Keep the feedback coming, we’re still keeping tabs on everything raised in this discussion (and elsewhere as much as possible) to inform incremental changes in every release.