Another example for the need of a warning color as background is T108762.

In T123860#2059687, @Pginer-WMF wrote:

I had no time to look into this in detail yet, but some quick comments based on the video:

• I think that the highlight is less prominent than the active state, and I don't think it too distracting, but the use of blue may bee communicating that the item is "active" instead of "about/ready to be active". Some examples (a bit exaggerated to communicate the idea behind them, not expecting these problems to happen a lot in practice):
  • I click into an input field and the mouse is not working properly. I keep typing thinking the input is already active.
  • I'm filling a form, as I fill the first field I moved the cursor away over what happened to be the second field. I end up typing on the wrong field.

It's been available on WikiFont for quite some time now. 4th column from the right, 4th row down.

I've also been using the same yellow from the old palette. It currently fails contrast test, but I still want to look into guidelines for non-text.

@Pginer-WMF I got a document started to start listing some needs around style guide. While I might not be able to get to this request right away, I want to make sure that they're captured.

@Volker_E, would you be able to help @Praveenraj?

Also, that's a good reminder...

In T125317#1988573, @violetto wrote:

In the recent T109915 task, we came up with 3 black/gray for text colors that is colorblind-friendly. They were #000, #222, and #949494 (for disabled text, placeholder text).

Does this have implications for the current default text color of content #252525 ? (on most but not all wikis, IIRC) If so, is there a task or discussion for that?
(I'd forgotten about that, as I use global.css to override #content to black, hence the #333 I use has more contrast for me, than it would for others... :/ )

We can explore an option to this effect that does not depend on the color of a button to show its presence.

The latest SVGs are usually at Dropbox.

ping @Esanders @Volker_E

@MSyed, we saw that you guys were exploring different kinds of input text fields for the search interface. Can you update us on this task on the progress so we can capture possible new input fields?

There you go!

Looks much better!

I'll get something prepared on sketch and pholio.

I put together some needs for our Phabricator board. I wrote some suggestions on how we can organize them after looking around the links you sent us. Let me know what you think.

I'm curious how much effort will it be to just replace the entire box and replace with a dropdown like that:

In T109915#1994576, @Esanders wrote:

On the other hand Echo seems to (ab?)using constructive green for positive feedback ('thanks' messages etc.)

That's really good to know @Esanders. Would you be able to share some of the bug tasks you mentioned?

In the recent T109915 task, we came up with 3 black/gray for text colors that is colorblind-friendly. They were #000, #222, and #949494 (for disabled text, placeholder text).

@violetto, once the basics are covered, I would like to invite you act as the great creative designer you are, and to think of a functional and visually attractive design for this page. Newsletters are great, some people put a lot of effort on them. All publishers want as many subscribers as possible. Think of it, newsletters can be an entry point for readers not even considering editing today, if they discover that... Wikipedia has a newsletter about Archeology of the Pleistocene!!!

I'm curious to hear what you all think about letting the browser take care of the focus states. From my point of view, I want to make this focus state design invisible. What that means is:

on Dropbox as well Design > + Assets > Icons > 4 Current > uniE042 - clip.svg

Ya, can.

In T124571#1968414, @Prtksxna wrote:

@violetto, do you also happen to have the same icon for the Apex theme?

A different icon?

It's a better practice to not only use color to differentiate because color blindness users. What do you think about using an icon like this?

I hope that wasn't too overwhelming! What are you guys' thoughts on this, feel free to poke. :):)

We have a pretty similar one here, but there are space and line thickness issues that I need to resolve. Give me until Friday to get this resolved, or is this pretty urgent?

Yup we got one, it's not in the final folder. But I'll get that fixed soon.

As a prototype. I didn't think it was sustainable either, that's why the switch to svg.

I switched icons to use svg sprite as opposed to a .js file that fetches svg from fontastic.me and have been getting this issue

Create a Newsletter

I finally saw it in action, thanks @bmansurov.

Since Jan 1, we entered a new quarter (Q3) and this task was our goal for the last quarter (Q2). We still have our eyes on these unchecked tasks and they are continuously being worked on and awaiting finalization.

@Pginer-WMF your desc here is accurate. It's worth mentioning again that OOjs UI icons used to have its own set of icons that differ from Wikifont icons. Although OOjs UI has adopted Wikifont icons, there are still remaining pieces of OOjs UI icons that VE uses but not available on Wikifont.

We won't have green buttons anymore--T110555. I think that addresses a lot of concerns here.

We use #555 for regular button text… Maybe we should change that to something darker.

Got it. It will be good to frame the use cases around date and time input widget to make sure we're making some informed decisions, otherwise it'll be hard to decide what should stay and what shouldn't based on your implementations. I don't mind doing this.

Want to point out also that we plan to underline interactable links as much as possible at least on interaction (see screenshot below from M101)

Wondering who should weigh in on this to move this forward?

Added my response at T89271, let's talk there.

Disabled elements are basically non-interactable UI elements. Our intention of decreasing contrast on hover might feel like a bug because the button reacts to the cursor, but it's going out of focus/becoming lighter. But on the other hand, if it does not look disabled, we will frustrate users with this non-responding UI element. Like someone mentioned in task T121960, Bootstrap also has been using the not-allowed cursor. Perhaps it's worth doing some research to see how have that been received?

I thought it could have been because the panel is no longer full width. But your version has focus states yea?

@Victorbarbu the screenshot looks good. I visited the link that Baha shared again to check out the changes. The subject line's bottom margin is large, and the focus state is missing. I remember we used to have focus states, we did right?

Sounds good @Volker_E

Being furthest away from #000 gray was one perspective. I also compared it with the backgrounds we'll be using in the palette because UI components can be found in many different layers of an interface aside from #FFF. The examples are shown here and listed here:

Lighter is better for users who aren't vision deficient. We are only WCAG AA compliant with large text with #888, and with #949494 we won't be compliant with any standards. But at the same time, use case must be sparse with disabled large text. I'm pretty unaffected by this suggestion because the difference is small:

Awesome!