In the newer design, the space name has a red callout so it should be pretty hard to miss. Here's an example on the detail view:

I think this is a change we should probably pursue, and start with a color treatment as in T6787#88172. There are several technical challenges:

The clearly-desirable integrations now work. I want to wait for use cases for the others; they likely aren't technically hard, but are potentially bad/confusing/ambiguous.

I'm going to close this since we seem to have made it to a state that no one hates too much. There are some followups in T8420 and T7870, and we'll adjust the UI a bit more and bring hiding to Diffusion in the future.

Development Log

The "strongest policy" thing landed a few days ago and can be seen on T8514, for example (policy hint says "Space Test Users" even though the object policy is weaker, and clicking it explains why, although on the redesign the dialog formatting is a little messy). I think this is a pretty reasonable approach that adds clarity without being less powerful, but let me know how it feels. There's also a stronger color for the space name in headers now in the redesign. That's still in flux, but feels pretty good to me.

A broad guide for this stuff is available here now:

no thanks

I don't think applications can ever show as feed actors today, although I'm not 100% sure about that.

For application actors, like Herald, we don't have a profile icon when they create feed stories:

This might not be fully correct, but it should get you a little further:

After D13363, you can now select "Use High Contrast Colors" in Settings → Display Preferences → Accessibility. It currently looks like this:

I didn't really implement anchor integration properly because I wasn't sure that hiding was going to stick, but I think hiding is pretty good.

Alright. I think that probably falls under T8614 more than being a core design constraint. We can do resource post-processors + more variables with relative ease for users with substantially different visual constraints, at some point in the future, but given that huge swaths of the internet are problematic for your particular constraint I don't think we should design around it for the majority of the userbase, for whom black text on a white background is easy to read.

I use a stacked diff workflow without detaching heads. Can you walk me through your workflow in a little more detail?

Do you have difficulty reading Wikipedia, NYTimes, etc? Other major web properties which primarily present large blocks of text in black on white backgrounds?

@CodeMouse92, I'm really confused about your feedback. Almost all of the text was on pure white in the old design, too. Here's a screenshot of the old design: all the text is black on white:

"Making the effects ... more reversible" is the same as "deleting, disabling or hiding workboards"; they are not separate tasks.

Can you show me the output of this command, when run from the server Phabricator is installed on?

@joshuaspence, pretty sure that's the right fix but yell if it looks suspicious?

Hitting this locally too, and using --clean may have been inadvisable since it nuked all the docs.

I merged/updated and now new 100x100 profile pictures look like background-size isn't being applied correctly:

(Similar trace with --clean.)

After using this for a while, I also find the UI very "bright", or I'd specifically say "unsaturated", or "washed-out" or "muted". Nothing is hard to read and the text contrast is great, the overall feeling of the UI for me is that all of the backgrounds and borders have the minimum level of saturation and contrast to be clear.

I think this is fixed now, but let me know if it's still acting up.

It worked!

@paladox, please read the description carefully. The images are helping support the main point of the section, which is that Phabricator changes very quickly. Having old images which are very different from the modern UI helps reinforce this point.

I think this is now fixed (in the sense of "not broken anymore", not in the sense of "working as nicely as it possibly could"). Let me know if that's not the case.

See also T8597. Two specific areas for improvement:

Two fixes here:

To echo @chad's comments, we really want to drive accessibility changes by understanding problems and then solving them, just like we drive all other product changes.

yeah that does not make sense and would cause nothing to work I'm pretty sure

This parameter is not required, although the hint should probably say "optional order".

I have a repro for this if you don't.

Can you do this to get a stack trace?