The best way to think about this is that it is a new 'base' for the next few years with Phabricator. Based on what products are coming soon (Spaces, Harbormaster, Calendar) and what will come down the road, it was becoming clear to me that shoehorning stuff in endlessly would end up being quite a mess. Time to refresh. It was intentional to break everything down to a minimal site and from that move forward. I just want the "tools" themselves to seem invisible, and out of the way. All that should matter is your content and that it's clearly accessible.

Another way to think about it is our previous redesign (T3772) which was met with many a pitchfork. The UI will continue to evolve, whimsey and delight will be back. I promise. There are just hundreds of pieces, and they can't all be done at once. Timeline alone I'd like to spend at least a week on.

So before I test "centered content" (like Phriction) everywhere, are people significantly opposed?

I wouldn't say i'm "significantly opposed" to width-limited/centered content, but I don't like the notion. I want to be able to set the width of the content to whatever I want, and the browser window lets me do that on the fly.
Philosophically, deciding that I only get 800 pixels or whatever makes your (The designer's) life easier, at the expense of limiting the user's choices, and that something I dislike.

The only reason to move to fixed width is that it's easier to read (lots of UX studies on the matter). It doesn't change anything for me, as everything is already responsively designed anyways

It means you don't need to make it look good at 1000px, 1200px, 700px...

Would it be possible to support both fixed and fluid layouts? Or is that
going to be a pain to support for all the different apps?

@chad, SIGNIFICANTLY opposed only to the massive use of pure white. See my large above comment.

@CodeMouse92 this would reduce white, not increase.

@chad, Comparing the new UI to the old one, I see quite the opposite. I'm just asking for the white to be toned down to a subtle off-white so as to make it usable to users like myself. I am having a VERY hard time on here right now.

@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:

What, specifically, are you having trouble with?

I think he is more concerned with the added whitespace of the boxes, and lowered contrast between boxes and background. That the more individual boxes popped off the page, the easier they were to consume.

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

@epriestley, @chad
EDIT: Yes, Chad, exactly.

You have to understand, with dyslexia, the black-on-white is already hard...always was. Mine is minor, so I cope, albeit with some difficulty at times. However, having darker framing was very helpful, as it gave a line for my eyes to follow, to help me track. (With dyslexia, one often cannot track w/ black-on-white and white-on-black, meaning move from word-to-word, line-to-line, consistently).

I totally understand the new color scheme, but with nothing to help track as I read, the screen is a jumble that takes more time for me to navigate and read on. It is hard on my eyes because of that. By dropping the darker framing, one would need to compensate by making the pure-white to an off-white to enable better tracking.

@epriestley Yes, I do have difficulty. I prefer interfaces that don't use that color scheme. Even with textbooks, I have to use a colored plastic sheet to deal with the glaring white and black, otherwise I can't process what I read. For example, my code editor...

Without that color scheme, I have a harder time reading, typing, and processing what it is I'm reading. Granted, I went for a much GREENER color than I would expect others to use in UI design, but you get the idea. Pure white = aih.

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.

That is, we're better off with alternatives that cater well to each visual constraint than trying to find a compromise between the two that will only work OK for either.

@epriestley I understand prioritization. However, if that's the case, is there a way that I can NOT get the UI update on my end? I spend a lot of time on my Phabricator server, since I'm the lead developer, and my eyes are already tired from being here.

(By the way, dyslexia actually affects 1 in 5 people, just FYI when you're prioritizing.)

D13361 is one potential solution, T8614 is another. Redesign is still weeks away at best. July was always the target.

@chad The dark header solution would be very helpful. Given that features generally take months to roll out (just due to the nature of software, it's the same at my place), you can understand why I'm concerned about the promise of T8614 post-redesign.

I would +1 :

• a more contrasted UI (bordure) aand find @epriestley solutions good
• a try with fixed centred width or more margin (lets say contents over 8/12 of the screen)

Else, after the first shock, im quite impressed with this UI !

I don't like the different colours here:

Although maybe this hasn't changed.

One is a link, and gets the consistent color of darkbluetext, the other is not. This isn't new to the redesign (though I think it did not previously render consistently). I don't expect Timeline to be redesigned in this branch, it's too big a project.

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

This doesn't apply to everything yet, and the actual color set it uses is just me making up a couple of values to make sure it works.

Generally, we'd like to address feedback motivated by very unusual vision constraints by providing an alternate accessible UI, not by trying to find a single design which works for users with radically different vision constraints (e.g., black-on-white highly readable vs black-on-white highly unreadable). Finding some compromise which is acceptable for both groups but can't use the contrast and colors that users in the different groups find most readable is worse for everyone. (This also means that we're happy to use magenta-on-green in the "High Contrast" accessibility profile, if that's more readable for you.)

The default UI should still work well for users with low or limited vision, but we can better serve users who benefit from more significant affordances by building targeted profiles for their particular vision constraints.

You can also define a custom accessibility profile yourself now, although we probably won't document or recommend this until the technology is a little more mature.

That's an awesome feature, @epriestley. I'm don't even need it myself, but I really love how Phabricator tries to be a tool for anyone to use, without getting in their way. We're about to move our entire company off of Github and onto Phabricator and it's things like this that reassure me we've made the right choice :-).

I have one major problem for me & team with redesign: font choice. It seems that choosen font misses all of polish diacritic characters. Let me try here before sending screenshots:

A-Ą-a-ą
E-Ę-e-ę
O-Ó-o-ó
S-Ś-s-ś
L-Ł-l-ł
Z-Ż-Ź-z-ż-ź
C-Ć-c-ć
N-Ń-n-ń

yep, looks bad here too.

OS: Gentoo linux, Gnome 3.16. Firefox 38.0.5

BTW: High contrast setting is almost perfect for me, yet I do not have any confirmed issues with sight or reading. :) thanks @epriestley!

It'll be fixed before final, I have the full font, just not as a woff.

Ahhhhhh, after D13363 I can track more easily again. Thanks @chad and @epriestley!

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

I can just add a class like this-actor-has-no-image and we can remove the border, but we could also try to do something fancier with app icons -- let me know what your ideal behavior is and I can give you whatever pieces you need for it?

I fixed this in timeline. Does herald show as an actor in feed? I don't feel timeline needs the image for herald, but feed actor images could be nice. I'd probably generate them by application needs (herald, harbor master, diffusion)

Herald obviously should be an outline of Exploud.

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

The background on the "Needs Revision" state in Differential looks odd to me. I feel that this would actually look better without a background color.

After using the new UI daily for a little bit now, I'd have to agree with many of the comments here on brightness, low-contrast, etc. It seems less of an accessibility issue (which would be more about readability/legibility - the text contrast is fine) and more of a usability issue (more about scanability of UI elements and identifying UI elements quickly in peripheral vision, differentiating comment-blocks quickly while scrolling, etc.)

@epriestley:
I think the UI does an excellent job of feeling very airy and staying out of the way, but those goals feel like better fits to me for highly content-driven UIs like a blog.

This comment stood out to me. I guess a content-driven UI typically involves focused reading (needs text-legibility) and slow-scrolling where as a highly-functional app UI involves a lot of navigation, interaction and scanning (needs ability to very quickly differentiate UI elements).

That said, I don't feel I've experienced any tangible/measurable reduction of productivity using the UI - just a vague "fluffy" inclination that it's a little harder on the eyes and slower finding things on screen. Possibly a figment of my imagination.

@chad: I'm not sure if this has been mentioned before but it seems title tags (<h1>, <h2>, ...) render differently in the preview. Compare these screenshots from Phriction:

Preview:

Result:

Additionally, the font family of the preview seems to differ from the rendered result.

It looks like the icons in some (maybe all font-awesomey) dropdowns are vertically misaligned.

Current:

Redesign:

It also looks like buttons are missing a padding-top.

In Phonder the "comment link" is out of the screen:

Ponder is a Prototype Application.

The Spaces select has not yet been designed, and looks equally bad in either master or redesign. It will be resolved with T8449 somewhat sooner-ish.

I'm not sure what you mean by not aligned vertically though, maybe it's a specific browser issue, what are you using @ftdysa? This is my layout in Chrome:

@chad i know it is a prototype but as it matter css design it could affect other part that are not prototype no ? Shall i not report in this thread a visual bug i see in prototype app ?

We’re not able to take bug reports on Prototype applications. You should assume that these issues will be resolved before they leave prototype phase, as most older prototypes like Ponder use old UI elements and will naturally resolve when modernized.

https://secure.phabricator.com/book/phabricator/article/prototypes/

Chrome Version 43.0.2357.130 (64-bit) (Linux). I've tried clearing cache and it didn't resolve it.

In T8549#123918, @ftdysa wrote:

Chrome Version 43.0.2357.130 (64-bit) (Linux). I've tried clearing cache and it didn't resolve it.

Specifically which Linux, if I have to load a VM from scratch to test, might as well be the exact one.

@tycho.tatitscheff if your install does heavily use a prototype that regressed in the redesign, it will be attended to shortly after we land to master. We're just not seeking these issues out.

fred@natnet:~$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=15.04
DISTRIB_CODENAME=vivid
DISTRIB_DESCRIPTION="Ubuntu 15.04"

Edit: Looks the same in Firefox 38.0 as well.
Edit2: And I wanted to be more clear. The "working" screenshot is from the same browser, but my hosted phabricator install that is at or close to head.

The broken image is secure.phabricator.com.

Oki thank for answer @chad

Other catched issue :

In T8549#121394, @20after4 wrote:

When I scale the text size up a bit, I get a weird left margin of blank space next to the page content:

This happens in both Firefox and Chrome on ubuntu. It takes two steps of ctrl-plus in Firefox, but it takes 3 (150%) in Chrome.

Adding clear: left; to the #phabricator-standard-page-body element fixes it. Apparently something in the header (which is float:left) is slightly extending outside of the bounds of the header and pushing the page body over.

Edit: Sorry, didn't notice that @staticshock already posted the same issue. Hopefully this is still helpful as I am pretty sure that I have isolated the cause/solution. It wasn't at all obvious at first.

I noticed this too on vanilla Firefox 38.0.5 on Windows 8.1, thanks for the temp fix @20after4.

We definitely don't test Phabricator out to 150% size. Are people using this on a day to day basis? Is this a regression?

We also include natively a larger font in Display > Accessibility.

I was seeing my specific problem by tweaking viewport width, not by zooming, and that problem is already fixed on this install.

The negative space on the left side at 150% does seem awkward; I'm still seeing that. I'm using phabricator at 100%, but I've used it at 110% in the past to reduce the eye strain of reading small fonts (especially code.)

In my experience, using browser shortcuts to find the font size sweet-spot for any given site is significantly less effort than explicitly configuring Accessibility settings. (App-specific configuration is generally a rabbit-hole of trying to figure out what's tweakable, where it's hidden, how to "unlock" special modes in which other things become tweakable, learning all the non-standard jargon the app may use to represent familiar concepts, etc.)

The fact that I've had to manually set my Display Settings > Monospace Font to 10pt Consolas, Monaco, monospace is an excellent example of this. Especially because about 6-12 months ago we upgraded phabricator and an ancestor of that line just stopped working until I tweaked it in some manner. I know plenty of C programmers who don't know enough CSS to, uh, rub two sticks together. They don't want to lose a day falling down such rabbit holes.

The negative space on the left side at 150% does seem awkward; I'm still seeing that. I'm using phabricator at 100%, but I've used it at 110% in the past to reduce the eye strain of reading small fonts (especially code.)

There is already a diff out for this, similar to the suggestion provided. It hasn't landed yet.

In my experience, using browser shortcuts to find the font size sweet-spot for any given site is significantly less effort than explicitly configuring Accessibility settings. (App-specific configuration is generally a rabbit-hole of trying to figure out what's tweakable, where it's hidden, how to "unlock" special modes in which other things become tweakable, learning all the non-standard jargon the app may use to represent familiar concepts, etc.)

Understood, but we're still not likely to take bug reports on browser zoom, we just don't have the manpower. Prefer solving accessibility issues with real tools when possible, as it's much easier to control across all mediums/browsers/oses. In implementing the accessibility features, browser zoom should naturally work better as we've been resolving layout bugs around absolute positioning, etc.

The fact that I've had to manually set my Display Settings > Monospace Font to 10pt Consolas, Monaco, monospace is an excellent example of this. Especially because about 6-12 months ago we upgraded phabricator and an ancestor of that line just stopped working until I tweaked it in some manner. I know plenty of C programmers who don't know enough CSS to, uh, rub two sticks together. They don't want to lose a day falling down such rabbit holes.

I don't know offhand what change you might be referring to. The only recent change I can think of is when we removed the admin/system level setting. So if you had it defined there globally, you would have had to have added it to your local user account instead.

In T8549#124258, @chad wrote:

We definitely don't test Phabricator out to 150% size. Are people using this on a day to day basis? Is this a regression?

We also include natively a larger font in Display > Accessibility.

Although on Chrome it seems like it needs to get to 150% to appear, on Firefox I'm seeing this at 110%, the first zoom step.

In T8549#124445, @fanis wrote:

In T8549#124258, @chad wrote:

We definitely don't test Phabricator out to 150% size. Are people using this on a day to day basis? Is this a regression?

We also include natively a larger font in Display > Accessibility.

Although on Chrome it seems like it needs to get to 150% to appear, on Firefox I'm seeing this at 110%, the first zoom step.

The issue has already been resolved at HEAD of the redesign branch (note this instance is near HEAD). Are you still having an issue locally?

@chad I hadn't upgraded, partly due to this. I'll do that soon and get back to you. Appreciate the quick responses.

This is now merged to master.

With full lato font and all that, this looks great on my install.. so:

In T8549#124716, @epriestley wrote:

This is now merged to master.

This looks WONDERFUL!!! My colleagues will feel very happy tomorrow when they see the new interface.

On Firefox 39.0 on OSX (Yosemite) the Actions button on Phriction page looks like the icon is mis-aligned:

It just hit my server. Excellent final result, @chad and @epriestley! Very clean. Thanks again for taking my suggestions seriously - I have my server running on dark high contrast, and it is much easier to read than the early draft. Bravo!

In T8549#122040, @avivey wrote:

I wouldn't say i'm "significantly opposed" to width-limited/centered content, but I don't like the notion. I want to be able to set the width of the content to whatever I want, and the browser window lets me do that on the fly.
Philosophically, deciding that I only get 800 pixels or whatever makes your (The designer's) life easier, at the expense of limiting the user's choices, and that something I dislike.

+1

Fixed width is annoying because it limits our ability to adjust presentation of content - one-size does not fit all use-cases or all users. Arguing that it is required for better readability doesn't really make sense to me. If I need shorter text width, I can adjust my browser window to the dimensions that feel comfortable for me. Phabricator is a part of my/our developers development environment - and in my experience, every developer has their own idiosyncrasies and preferences. Limits on user choice (sometimes justified) are the most frequent complaints we receive on our Phabricator install.

I'd rather see dynamic widths extended to Phriction as well (think I've commented on it too).

While I agree that making the browser window narrower is a good work around for things like Phriction and Maniphest, it does get annoying when using Diffusion/Differential/Audit, to review code diffs. In those cases, you kind of need the horizontal space to be able to read the code easily. That means I would have to constantly resize my browser window when switching apps/context in Phabricator.

Github solves this by applying both fixed and fluid with in different situations: issues/comments are fixed for readability, while commits/diffs are fluid to make optimal use of screen real estate.

Would this be an option for Phabricator, too? To look at the fixed/fluid layout on a per-app basis, instead of for the entire suite?

In T8549#124461, @fanis wrote:

@chad I hadn't upgraded, partly due to this. I'll do that soon and get back to you. Appreciate the quick responses.

Upgraded, looking good. Great work @chad et al.