WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 5 months ago

#43163 new feature request

Did you know? CSS notification needs a Dismiss button to close

Reported by: pracko Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.9
Component: Editor Keywords: has-patch has-screenshots
Focuses: administration Cc:

Description

The CSS notification bar at the top of the Edit Themes editor needs a Dismiss button so that it can be closed.

The notification bar I'm referring to says:

Did you know?

There’s no need to change your CSS here — you can edit and live preview CSS changes in the built-in CSS editor.

Attachments (2)

43163.diff (508 bytes) - added by audrasjb 5 months ago.
Add is-dismissible class to "Did you know?" notice
62ca30cd95993aa19d7d15674309ab8c.gif (336.7 KB) - added by audrasjb 5 months ago.
Dismissible notice

Download all attachments as: .zip

Change History (7)

@audrasjb
5 months ago

Add is-dismissible class to "Did you know?" notice

#1 @audrasjb
5 months ago

  • Keywords has-patch added

Hi @pracko

Thanks for your issue. I fixed it by adding is-dismissible class to this notice.

Cheers, Jb

@audrasjb
5 months ago

Dismissible notice

#2 @pracko
5 months ago

Thanks JB, very helpful!

#3 follow-up: @Clorith
5 months ago

  • Version changed from 4.9.2 to 4.9

I am actually in favor of the messages at the top of the editor pages being non-dismissible. We want to encourage users to stick with the tools they're given that will prevent them from accidentally losing the changes they've made.

See #42100 for discussions on the various warnings shown, and r42013 which makes a specific mention of it being intentionally persistent.

I am up for hearing arguments for it needing to be dismissible though.

#4 in reply to: ↑ 3 @pracko
5 months ago

Replying to Clorith:

I am actually in favor of the messages at the top of the editor pages being non-dismissible. We want to encourage users to stick with the tools they're given that will prevent them from accidentally losing the changes they've made.

I am up for hearing arguments for it needing to be dismissible though.

OK, here's one: the warning takes up too much space. As an experienced designer who knows what he's doing, I don't need a bulky reminder constantly nagging me to use the narrow and virtually unusable CSS editor in the customizer. I want to be able to remove nags when I don't find them useful or applicable to my situation. The warning is helpful, but not necessary to be persistent; therefore it should be dismissable.

#5 @afercia
5 months ago

  • Keywords has-screenshots added

Although @pracko makes a point when says experienced users don't need a persistent reminder and argues that editing in the 253 pixels wide (!) editor in the Customizer is any better than using the classic theme editor (well actually this depends on the use cases), going through #42100 and looking a bit at WordPress history, there are other cases of persistent notices or other persistent "hints". I'd rather point out that there's no consistency though:

https://cldup.com/PjW6Q2vxnC.png

Design consistency

I'm not sure why the Editor screen uses the new notice, while the Widgets and Menus screens use the "Manage with Live Preview" button (which I always found not so nice looking, to be fair). Historically, the persistent notices have been used for pages that were going to be dismissed, or their usage discouraged, like the Custom Header and Custom Background pages. For pages still in use, the choice has been the less invasive "Manage" button.

I'm pretty sure there were good argumentation when these buttons and notices were introduced but now it's probably time to try to introduce some consistency and improve things. Consistency is key. I'd lean towards the notices just because the buttons bother me, and I'd prefer to have the main heading on its own reserved space, without any additional element close to it. But that's just my personal preference.

Language consistency

What is the proper name to use for the Customizer? As a user, I have no idea what a built-in CSS editor is. And I have no idea clicking on a link that says built-in CSS editor actually brings me to the Customizer. Links purpose/destination should always be clear, even when the link is read out of context. The link text should include the word "Customizer" or "Live Preview" or whatever the hte Customizer should be named.

I seem to recall there was a long discussion when the "Manage" buttons were introduced, focused on avoiding to use the word "Customizer". I guess that's the reason why the buttons use "Live Preview" with title case: to indicate the name of a WordPress feature. However, the old Custom Header/Background pages use "Customizer". I'd agree this is a minor case since these pages are hidden by default. By the way, the word "Customizer" is now used in a very prominent place: the 4.9 About page:

Major Customizer Improvements, Code Error Checking, and More! Welcome to an improved Customizer workflow ... Customizer Workflow Improved Customizer JS API Improvements We’ve made numerous improvements to the Customizer JS API ...

I'm not a native English speaker and I do know "Customizer" is very difficult to translate. In the Italian translation, it's always translated with "Personalizza", which is the verb imperative mood "Customize" and I can tell you that's far from ideal. On the other hand, any Italian people I talk with, they call it with the English word "Customizer" because that just makes more sense. In my country, we're not opposed to using non-italian terms, when that makes sense. However, this may not apply to other countries and cultures. A more generic term like "Live Preview" might be a better option. Regardless of the final choice, there should be some consistency in the interface. Right now, WordPress is using both "Live Preview" and "Customizer", which is confusing for users.

Minor: does "live preview" needs a hyphen when used as a verb? There's no consistency here either: There’s no need to change your CSS here — you can edit and live preview CSS changes in the built-in CSS editor. You can now manage and live-preview Custom Header in the Customizer.

I do realize the considerations about naming are a bit out of the scope of this ticket, glad to create a new one if there's consensus.

/cc @melchoyce @helen

Note: See TracTickets for help on using tickets.