[6.x] Let's Talk UX

[andjsch]

Bug description

I hate to bring this up on the all new shiny interface, and while it is shiny at first glance, I believe it comes with some huge downsides when it comes to usability. I don't know how others feel about it, but it's early and I hope we can find a solution. Let's break it up. I'll mark some of my conclusions/suggestions bold.

While these are some severe issues I see with the new design, please don't take them too harsh, but also don't take them too lightly. Currently we are still in an alpha state where things could improve a lot. I also know how hard it is to redesign a thing completely, yet alone how many hours it must have taken the whole team to pull this huge Vue 3 transition that took place in the background even off.

Primary button color

It's black! 😬

This is in my opinion a really bad choice, because it makes the UI hard to scan as it is mostly white and gray.

The primary actions are immediately visible, no searching required.

While this is still fine in light mode, some color would definitely make it way more easy. Bring back the blue! Why you might ask? Because the black primary color totally breaks in dark mode.

One could make some guesses that the light-gray is now a primary button. But is the selected-site-pill named "Statamic 6" one as well? The real primary button has some shadows and a light gradient applied, the pill is flat. Barely a difference. Some color would fix this here as well.

GH for reference.

Bring back a color for primary actions. Blue, green, pink - all great!

Destructive actions should always be red.

Color

This is a great example of the current hover situation for many items. It's all gray and white and you can barely tell a difference. Context: you are looking at a table with 2 items, the second one is hovered. It's barely visible and I am sure it will be even worse on a consumer grade monitor. Sitting here on a calibrated one just to have that mentioned. Make hover states darker.

Same issue with the menu items: A hovered element shouldn't be only distinct by it's background color. Give the text a different color - any color that makes it stand out more. The active state is fine I think - the text gets bold.

v5 did a great job here btw

Here another example on a replicator field. Right one is hovered.

Main navigation

While the old navigation was probably a bit too big text-size-wise for more nav entries, the current one is way too small for an item you interact the most with. This get's even worse when there are sub-items. We are at 14px (sm) on a level-1 nav item. Make them 16px again or let's meet in the middle at 15 ;D

Icons

Could sometimes be a notch bigger than the actual text (that's just a taste thing of mine) and have some more color or more contrast. Again, it's all so gray 😢

Inputs

Buttons should be darker.

What if inputs had a different background than white? Or the container they are in had a different background than white? White is a really shiny color that makes an element pop out if it's surrounding is a different color - make use of that! Use less white backgrounds. In the image above, I gave the container a color of zinc-50 and it works great in my opinion, huge improvement. What doesn't work is the slimmer border around the container, but who needs that one anyway?

For real?

This shouldn't be needed in the first place. Currently it gives inputs a darker border color. My suggestion is to not keep adding stuff to this mode to improve things. Improve them properly and get rid of that option.

How to reproduce

Spin up v6

Logs

Environment

v6

Installation

Fresh statamic/statamic site via CLI

Additional details

No response

[avocadesign]

I noticed a couple of other things straight away about the UX/UI that bother me. While I like the overall design choices there's some perplexing things that slow down the user and or make it more confusing. I agree with the colour points above. I know it's alpha so some of this might well be on the to do list already.

In addition I noticed

The removal of the quick link back to the collection list above the title of the entry you are editing.

I use this link all the time and immediately missed it when navigating a new install of v6 - I know you can click on the left hand menu and the collection in the dropdown but that's a lot more cursor movement and it felt slow and since it breaks muscle memory it also felt broken.

Secondly I find the new interface for managing field options very visually confusing. I think this is a significant usability step backwards. I totally understand the desire to shorten the page but the overal effect is that I don't know where to look. There's two columns then one then four then back to one etc. The old interface was very scannable and you could quickly scroll and find what you need. I don't know if it's the combination of all the different rows and widths and small borders but I just "bounce off" this interface and don't know where to look. It's hard to at a glance get a feel for where fields start and stop.

It also doesn't shorten it enough to make less scrolling for advanced options to justify it my opinion

There's a different approach taken in the Site options and I much much prefer this:

There's also still the issue where if you have a large bard field in a replicator and you scroll down you lose the text options off the top of the screen. this makes it very hard to add links or styling options that don't have keyboard shortcuts to the bard text. This last one is an existing issue with v5 also.

In live preview there's a lot of borders and lines that add to the confusion. I'd love if the small grey border and the rounding was removed for this view, it's not necessary and looks like visual bug against the drag bar on the preview window.

Finally on wide screens (27") i get the desire to make the editing interface not locked to a specific size but this feels way too much and will dramatically change the line length in text for clients (the current limit on the editing window roughly matches max line length that anything would reasonably be on a page)

What I do like (to balance the ship)

I love the new replicator set UI. That's really nice and keeps things "connected" with the dotted line

I also love the dark admin bar and the bread crumbs that's a winner

Hope that's helpful

[avocadesign]

The new placement of the item actions is also less intuitive. I accidentally ticked an entry in the list and then couldn't work out why I was getting a warning about leaving the page. Then I glanced at the bottom of the screen. The lack of colour in the buttons mentioned by @andjsch really makes that even worse. I doubt many clients would think to look down the bottom of the list for actions though as the filtering UI is at the top of a list and the system puts controls at the top of a view for the most part.

[avocadesign]

Finally from me - sorry for the many posts.

the placement of the column control in list views "inside" the view chrome (i.e. below the line that delineates the view tabs)

Makes it seem like the columns are a per view option not an overall option for the list view. I'd LOVE it if they were a per view option but the UX of that is confusing for new users.

[Oleafeon]

3 issues with 2fa

on dark mode there should be a white border arround the qr now scanners wont trigger it because of the background color

the copy button doesnt work

recorvery codes arent in dark mode

[duncanmcclean]

@Oleafeon This issue is more about general UX issues. Can you create an issue for the 2FA-related bugs?

[Oleafeon]

@Oleafeon This issue is more about general UX issues. Can you create an issue for the 2FA-related bugs?

@duncanmcclean
offcourse #12074

[afonic]

I agree with @avocadesign on the field options design. It's visually very confusing and the cognitive load is very high. It's a downgrade from the old design. Certainly changing the number of columns doesn't help (2 - 3 - 4 - 1 columns) and also putting everything on a "card" with its own toggle is not good UI because based on the content the controls are in different positions.

Also the Collection settings page suffers a bit from the same issues.

Also, maybe some display options that are common for most fields can be hidden? For instance the whole Sortable / Preview area with 4 toggles could be on a collapsed "Control panel display" section as I doubt many people change these.

[JonKaric]

I feel like there is something inherently wrong with the visual colour hierarchy. There are many layers stacked on top of one another, making it hard to parse the page visually.

Sidebar dark > Main area white > Section dark, > Section content white

I think an aim should be to reduce the number of layers and distinguish areas and sections differently, reducing cognitive load whilst helping guide peoples eyes and attention to the information they need.

I spent some time experimenting with what this could look like. In the examples below, a maximum of 3 layers is used. This makes a lot more hierarchical sense and creates a stacking effect that gives you a sense of where you are on the page.

1. Sidebar in the background
2. Content container in the middleground
3. Content sections, etc, are in the foreground

All I really did here was:

1. Increase the darkness of the sidebar background slightly
2. Increased darkness of the main content background
3. Removed the 'card' thingie background, borders and shadows.

Of course, they're just examples and mockups, but I feel like it's a great improvement, especially in some areas of the control panel like the field picker.

Before	After

Before	After

Before	After

Before	After

[jackmcdade]

Thanks for taking the time to be so detailed (if a little brutal so quickly). I recorded my feedback on all of your feedback here: https://screen.studio/share/J0UsaU5f

Also, I converted this to a Discussion because that's exactly what it is. ❤️

[godismyjudge95]

That theming stuff is nuts. We have a few clients that will go wild with that.

I like the smaller nav, but I also see the critique of it being difficult to click. Maybe a compromise would be to make the click target larger than the text?

I do like the "folder" look, but I also appreciate any work towards reducing the nested boxes look - which adding section titles like you noted also resolves some of that.

I love the breadcrumbs at the top, that is one of my favorite features.

I like the more compact options for the replicator field. Maybe there is an alternate layout that combines all those toggles into checkboxes and then hover a tooltip icon about what each of them does? I don't know, I see both sides on that one.

I love the max width; we changed it on every site on v5.

Overall, I appreciate everyone's work on improving the UI. I think it's miles better, but as with any art it's never finished you just have to call it when you think it is.

[JonKaric]

Preface: I love almost everything about the new design, and I don't nessessarily agree with above posts and comments even if I posted here. I think the feedback has constructive and I wouldn't take it to heart. I know as a designer it's always anxiety-inducing to hand over a design for feedback, and I have to try hard not to take feedback to heart. It's something you made, put effort into trying to make it the best you can. I have to remind myself that ultimately, design is always the first thing people see. So it's only natural for that to be the initial focal point and people's first thoughts.

That said, it's okay if you don't like it - it was just an example. For me at least, content and cards within the grey card containers don't feel grounded or connected to it, as if they're trying to burst out. That was the key focus of my feedback. For example, in the field options, it kinda feels like the background is fighting for my attention instead of the next option box. Creating a sort of moiré effect.

Adding more padding around the box, and inbetween the items really helps reduce that effect for me. Helping my eyes glide from box to box, and helping me quicker distinguish the next section I want to go to. Curious to see what you and others think about that.

[afonic]

I agree with most of the points Jack made, for example:

• having "black" as the primary color is definitely fine.
• adding WCAG is thoughtful for people that need that. Using is as default is simply not possible if you want a decent design.
• removing the "Back" button and adding the breadcrumbs is a huge improvement.
• adding "more contrast" is not really needed imho, the low contrast points are headings and stuff that blend into the background. Your brain doesn't even process them after a while.
• and of course, you can never please everyone!

I still feel the field options screen might benefit from a redesign.

Generally, love it. I used it for a couple of hours and going back to v5 wasn't easy.

[jackmcdade]

Just keeping you all in the loop, these are the changes made so far based on the feedback in this discussion:

• Added vars to control the app shell (body and main content) colors so you can increase/modify the contrast between the the inputs and sections. This doesn't have a gui or config yet, but will. [6.x] Configurable app shell colors #12134
• Increased nav hover contrast: [6.x] Add nav hover contrast #12132
• Fixed missing destructive button color: [6.x] Fix destructive buttons #12086
• Changed primary button color (though this will likely go back to black once we roll out the theming config): [6.x] Change the primary button color from black to the defined primary color #12077
• Relaxed the blueprint field configs to only be 1 or 2 per row: [6.x] Relax field configs so they max out at 50% width #12122
• Don't show the copy button when on http (the clipboard api is only available on https): [6.x] Input only shows copy button if supported #12100
• Fixed Recovery Codes on Dark Mode: [6.x] Fix 2fa recovery codes dark mode #12133

These will be in the next alpha release.

[avocadesign]

@jackmcdade Thanks for the feedback in the video, that mostly makes sense. However, for me the columns are never linked to the "view". If I change columns for any collection entry list, all the saved views have the same columns. This is true of v5 and v6 unless i'm doing something wrong - here's a 20s loom showing what I mean.
https://www.loom.com/share/d5de68aa0c9d4dd39a11470f75a2f3e0

[robdekort]

Something else UX: I would reconsider the shadow on input elements as this makes them look like buttons. They could be crisper and clearer.

[robdekort]

A few more things for now:

1. The sidebar collapse button is very undiscoverable right now, using a pattern like this also wouldn't pass WCAG.
2. The hovers on replicators are very distracting, stuff shouldn't move. It becomes hard to use when you have quite some items in them. An interaction like this also wouldn't pass WCAG. Plus it seems you currently can't reorder them with a keyboard.
3. You can still tab through the buttons/inputs in collapsed replicator sets.
4. There's no proper aria rules being set like aria-expanded.
5. The header to collapse a replicator set is not a button but a div. Also it has no aria-label set.

I've only took a quick peek at a11y for this part of the replicator. But based on these findings I really would be very careful with claiming the CP passes WCAG conformity.

[robdekort]

In the asset manager the buttons have no labels anymore. These icons are hard to decipher and having to hover all them for a tooltip isn't a great user experience.

v6:

v5:

[jackmcdade]

More updates from today's Alpha 2 release:

• We've added some subtle gray to the main content area – just enough to make the sections and inputs pop a bit.
• Made a number of other small contrast/legibility tweaks (text colors, icon colors, etc) based on overall feedback: [6.x] Match the text color of Bard fields with markdown fields #12177
• Made a number of the global elements in the Control Panel themeable so you can fine-tune your way to the contrast levels and CTA color you prefer: [6.x] CP Theme Config #12170
• Asset icons have labels again: [6.x] Bring back asset editor button labels #12171

[robdekort]

My two cents on customization. I think it's a better strategy to push great defaults instead. A lot of users won't use customization for themselves or their customers. This means users get a sub-par experience (without having the ability to change it). When keeping the theming options, I would at least change the defaults to:

• Not use black as a primary color.
• Have green toggles. Actually I don't think theming those is a good idea for those at all, just design them right. What happens when someone configures red as their primary color for example?

[robdekort]

Thanks for all the feedback 😊

Always around to be a PITA, you know me ;-)

[daun]

+1 for choosing a default theme color for primary actions for the final v6 release. Currently spending a lot of time in the Shopify admin which also uses black as primary color, and it ends up being a bit drab after a while. I think toggles are fine in the primary color, too, unless it ends up being red of course 🙃

[daun]

That said, the theming works surprisingly well, considering how much of a crapshoot it usually is in other backends. I'm almost hesitant to tell our team about the theming options... Pretty sure we'll be customizing colors for every new project going forward 🌈

[andjsch]

I agree too! A default primary differing from black would be amazing. I think having a great first time experience really matters. Which means for me:

• Have a primary color other than black (preferrably blue)
• Switches not in black (perferrably green, that's what we've been used to for years now - the primary would probably be okay too)
• An accent color other than black (blue again? the default is blue in pretty much all OSes and in the web)

I cannot emphasize enough on how important it is to have these things not set to black by default. It's been one of the main reason why I started this discussion/issue initially. Especially for first time users that just give statamic a first try - these theming options are hidden away. One doesn't stumble upon these easily. If statamic really insists on having a "neutral" state from where you can start theming, why not offer a few themes (maybe two to three) that users are choosing when first logging in?

To be fair, I'd list the current default as last, as it's really bland and not particularly user-friendly in my oponion.

1. default theme
2. rad theme (pink/green primarys?)
3. bland - your perfect start to make the CP your very own
4. • additionally the customization page Jack has talked about in his most recent theming update? (to be found in Discord)

[jackmcdade]

I can't emphasize how much I like black as the default. But I hear you. Also, green toggle are the default now. And we plan to make these themes much more discoverable — they will not remain hidden away in a config file, I assure you.

[daun]

Minor observation (or question) about button UI. Currently, there seem to be two types of secondary/contextual action buttons. A flat one and a slightly more threedimensional one. Do these represent different types of actions? Or is the flat one just not brought over yet? I would assume the latter, but I might just be dense :)

[jackmcdade]

They are two of the variants available on the ui/Button component. I think we've been a tad inconsistent in when we use that filled variant. Will need to give it some thought and see what logic we should apply when choosing which.

[JonKaric]

Really nice work on the latest alpha releases team :)

Is the theming being used as a solution to the contrast heirarchy thing (#12093 (comment))? I can't seem to get mine configured in a way that makes that go away, although it does ease it a little.

I only mentioned because it seems the dashboard widgets seem to come without the gray border, and full white header, and think they look amazing!

[jackmcdade]

It's a solution to it yes — though we definitely want to find the right balance between what we're aiming for as an overall aesthetic (something that fits neatly into the Laravel ecosystem of products — Forge, Cloud, etc) as well as modern UI expectations (shadcn, tailwind ui, etc) but with our own twist.

Try these settings and see how it looks to ya:

'body-bg' => Color::Zinc[200],
'content-bg' => Color::Zinc[100],
'content-border' => Color::Zinc[300],

I think we might need to add a var for the Sections/Panels to increase the contrast there too as it starts to get a little muddy the darker you make the content-bg.

[JonKaric]

Nothing overly works without changing the panel colour / design -

Perhaps an opaque panel would fit perfectly with the aims you've described? To me, this is an great compromise between form and function without actually changing the panel design. It would just fit the colour of whatever you have set for the content background

This is the CSS I've used.

background: #ffffff70;
border: 1px solid #00000012;
padding: 12px; 

Only really works when you set your background to something other than #FFF white. If you did have a white background, you could instead have a black opaque panel instead - but would face the same issue as in that comment. But defo an avenue to explore.

[godismyjudge95]

It's a solution to it yes — though we definitely want to find the right balance between what we're aiming for as an overall aesthetic (something that fits neatly into the Laravel ecosystem of products — Forge, Cloud, etc) as well as modern UI expectations (shadcn, tailwind ui, etc) but with our own twist.

I appreciate the nods to the overall design language of Laravel's apps. It makes Statamic feel much closer to a first party CMS for Laravel and by extension makes Statamic feel more legitimate when showing it to clients.

[daun]

There's a larger UX topic I'd love to touch on — error states and error notifications. It isn't related to v6 specifically since nothing major changed here, but I'd love to help improve these while things are in flux. This is all according to feedback we've been getting from our users.

Error toasts

The main thing we've been hearing from users of v5 is that very often they don't notice that a form submission has failed and close the window, losing data. The reason seems to be that the error toast message is in the lower left corner with only the icon colored red to distinguish it from a success state. On larger screens, the error toast is usually no longer in the field of view. Many of our users have reported closing the window, thinking there were no errors. Sure, they probably also clicked away the unsaved-changes alert out of inertia, but I think this could benefit a lot from a more obvious error toast.

This has happened to myself and almost every customer so far at some point or another.

A CMS that does this well in my opinion is Twill. Probably a bit over the top, but definitely never overlooked by editors.

Compare to the current toast. Might be enough to have the whole thing red and centered in the bottom to make it pop.

Error states in tabs

In case users don't notice the error toast, they might notice the red validation error. Unfortunately, if the error occurred on an invisible tab, the tab name is merely rendered in red. One colorblind user has reported this looking almost identical to the default disabled tab state.

Two suggestions I could think of:

1. Open the first tab with an error and scroll the invalid field into view.
2. Make the error tab more prominent: bold, underlined, or maybe a red pill that says "2 errors". That pill might actually be best.

Error states in fields

I think there's no harm in adding a red border around an error field, and also making the field label red. It might seem a bit much at first, but it helps prevent edge cases where, for example, there is no input border (replicator), the name would still be red, or when there is no name (hide_display), the border would still be red.

Again, Twill is kind of doing this, and I think it's preferable to just a red validation message below the field. It's not pretty, but should be easy to come up with something that matches the current look and feel :)

Compare to current validation error:

[godismyjudge95]

1. Open the first tab with an error and scroll the invalid field into view.
2. Make the error tab more prominent: bold, underlined, or maybe a red pill that says "2 errors". That pill might actually be best.

I believe there was work done on this already. It may be a bug that it is not switching the tab and scrolling to the incorrect field.

[daun]

@godismyjudge95 I see! It currently doesn't switch tabs or scroll on alpha.4, fwiw.

[daun]

Another thought: the error toast disappears after 3 seconds or so. Might make sense to show it until the user edits the form.

[robdekort]

I also noticed long (laravel) errors overflow in the toast. Perhaps some line clamp/ellipsis on them would help as well.

[o1y]

This is more of a UI-related comment, but I hope it’s fine to post here. I find it a bit difficult to tell whether a field is set as localizable or not. You really have to look closely, and with many fields the grey tones tend to blur together .. :)

v6

v5

[afonic]

As a general comment, in most places I would use one step darker gray, for instance zinc-700 -> zinc-800.

Sometimes us designers and developers forget that ordinary users don't use the monitors we use. I was trying to hype a client today with a demo I have online and while the general reaction was "WOW", he really couldn't read the menu that well in this 1080p Asus $100 monitor.

[helloDanuk]

I'm not sure exactly what has already been written for the Blueprint Editor. I noticed the following:

Options that have a similar effect take on a completely different significance when they are displayed in half a column or in a whole column. And the grey border further emphasises the clear separation.

On the 'Validation'-tab, they are arranged a little closer together (in the same line and without a grey border). This makes it easier for me to read.

[helloDanuk]

It has something to do with the organisation and prioritisation, It's about where my eyes are directed. I can understand your thoughts.

For example, the select field: The 'Show Actions' toggle button appears to be a more important setting (the border around the 'Show Actions' field and the full width emphasis this) than the ‘Options’ with key/value, which is crowded in its placement and, in most cases, is of greater importance to customers using the CMS. That's why I would also expect it to be given it's weight in the Blueprint Editor.

In v5, it was simpler (everything is ordered from top to bottom, one below the other), so many of these questions didn't even arise. Now, with the attempt to improve a few downsides of the top to bottom approach, new challenges have been added.

Either way, I'll be able to get used to it and it's not that important for my clients. They won't see the blueprint editor.

[robdekort]

I'm guessing the choice to expand those last row 50% items is to prevent a big slab of grey caused because by this card design. This design choice seems to lead to quite some issues as addressed in this topic already. I totally understand this sucks and it's late in the process however.

[JonKaric]

I understand it's late in the process, but I hope the team have something cooking for it. There's a very strong community signal that the card design / heirarchy is causing people issues. It seems like it's the most common feedback on here and discord.

[helloDanuk]

I don't have problems with the card design per se. If titles are set, it's a nice UX to edit an entry. I think it will help me to create better editing experience for my clients. But comparing to the blueprint editor, different fields are more grouped together, not every toggle or field has a grey border (e.g. the Sites-page)

[helloDanuk]

After working with the Blueprint Editor while optimising the German translations, I have to admit that the two-column layout with the borders isn't that bad when I actually use it. I am fine with it.

But it's a fine line when things start to fall apart logically and visually. Like the issue #12338 with the prepend/append fields shows.

If new fields are added in the future, visual logic should be carefully taken into account.

If you leave it as it is, the layout will differ from the Condition and Validation tabs. I haven't yet figured out why it's different there or whether it simply hasn't been adjusted yet.

And making the bard sets more prominent in some way would certainly still be an improvement.

[helloDanuk]

Just a minor thing: The CSS utility text-balance looks less elegant when applied to sublines. It might be better to omit it?

text-balance is an important typographical skill, but often requires a keen manual sense of rhythm and understanding of the content. Unfortunately, automatic CSS is not very good at this.

I didn't open an issue.

[daun]

I also think text-wrap: pretty might be the better alternative in non-headings. It does prevent widows making sure the last two words stick together, but doesn't try to rebalance the whole paragraph.