Powerful new features for businesses on GitHub.com | Hacker News Reader

Powerful new features for businesses on GitHub.com

github.com

106 pointsmoby55 comments

Tangentially related, but on our slack this morning everyone is griping about the updated blue text color on repo pages at Github. It's pretty ugly.

Ha, glad I'm not the only one who thinks so.

Thanks for that comment, I'd been clearing browser caches and trying to debug my overridden styles, I'd assumed something was horribly broken.

This is for colourblind people.

Still doesn't make it look good. If thats an issue they could always have an optional setting to enable colorblind mode.

I think we should give it a few months to see if the fact that it doesn't look good is inherent to the color or just because we've become accustomed to it looking one way for so long. I can't count the number of interface redesigns I've seen in services I used that I hated at first and now I look back at the old design and can't fathom how I ever thought it was better.

And if colorblind people aren't inconvenienced (and don't have to navigate to a menu to de-inconvenience themself) then that's enough of a reason for me.

Fair enough.

Side note: I'm surprised there isn't a specific header browsers could send for something like colorblindness. That would allow sites to react to that header and serve up a different stylesheet.

Isn't that what the accept header is for? Telling the server what content types you're willing to accept, including relevant parameters. Something like:

    Accept: text/css; color-blind=trichromatic

Of course no server would recognize this today, since afaik the CSS media type doesn't define any parameters other than perhaps `charset`, but the mechanism is there at least. Also any self respecting web server would just ignore the parameter so it shouldn't break anything, just cost a few more bytes of bandwidth I guess. No need to invent a new header I don't think.

Why not have colorblind mode be the default? Much more courteous to make the nitpickers change their mode than casual browsers who just want to be able to use the site.

It should be an opt-in thing then. How many of us are not colorblined?

This is for sure a requirement for us governmental customers as they require certain accessibility requirements from used products.

Serious question: How does making something WAY MORE GREEN make things more visible for people who CAN'T SEE GREEN?

That's not how colorblindness works. Green things aren't invisible to colorblind people. They just can't discriminate some colors from others as well. I would guess that this color is more different from the body text in some color channel that's extra useful for contrast for colorblind people.

In the same way that turning up the volume helps people who are hard of hearing to hear. Colorblindness is a spectrum, not a switch; many people who suffer from it simply have reduced sensitivity to a color. I'm mildly colorblind myself; I can see green, but I can't see it as well as you can.

Upvoted because this is a legitimate question.

I'm slightly grey-green colorblind, and if you make text standard CSS green (#008000) I sometimes have trouble telling that it's actually green and not dark grey. If you make it just a little more green (say #00A000) it's much easier for me to see.

I believe the color of the green buttons also changed.

yeah, and they have a more visible border now as well. The purple colour of the "Merged" icon also looks different to me.

Not only that but why would you change the clean top bar? The dark one that is live for weeks now is worse than the old one.

That and the eye-seering blue draw too much attention for what they are. Content is de-emphasized. Whole page is slightly harder to read. I don't understand these changes at all.

I love it! Everything is suddenly so readable. And no, I am not colorblind.

I too thought I was going crazy when I noticed it this morning... Funny, but that shade (or one very much like it) is forever etched into my brain as "porn blue" thanks to a k10k issue back in the day when the internet was still referred to as the information super highway and nobody knew what we were doing. Here's an excerpt from the first "lesson":

    You must never use this colour.
    You can like it as much as you want.
    You can buy a dress in this colour for your girlfriend.
    Your mum might have it as the colour of her eyes.
    Feel free to paint your house like it.
    But never use it on a website. Never.
    This colour is the porn colour. 
    You must never copy the porncolours.

Source thanks to Internet Archive: http://web.archive.org/web/20050404141942/http://www.k10k.ne...

Still cracks me up.

EDIT: for those who have no idea what k10k was, here's the story: http://www.cubancouncil.com/work/project/kaliber-10000

2005 wasn't that long ago. I thought the press stopped using the term "information super highway" in the 90s. But in case thanks for share that, it was an amusing read.

I think that particular issue is older though, I'd guess 1999 or 2000. If I recall correctly people were still going on about the information super highway around that time, along with very literal illustrations of "surfing the web." 2005 is just when the snapshot is from I think.

Oh man I forgot about K10k. Was an amazing site.

What is the porn color? I don't understand the reference. What makes it "the porn color"?

Aren't links blue (#0000ff) by default?

From the above Internet Archive link, looks like the color is #0033FF.

I believe that's the reference right there. Porn sites, along with most other sites, were usually not quite as spiffy as they are these days. Aside from some creative hot spots that really overdid it with the GIFs (geocities 4 life!) most sites were typically just browser defaults with perhaps some changes to background colors, maybe add a nifty tiled background image and such. Web design (not to mention development) was quite different back in the late nineties, early naughts, than what it's like now – the default blue link color was everywhere.

This whole issue is effectively a sarcastic response to that lack of design, and referring to the default blue as "the porn color" I read to mean "don't be cheap and stick with the defaults; don't be a porn site."

The joke doesn't age very well, but it was really funny back then.

It's "blueprint blue" - a reference to the cheap printing process used to make the posters for pornographic films, and also the reason they got the nickname "blue movies."

Today I learned – thanks!

AKA "Blueprint blue," source of the term "blue movie" and "working blue."

Maybe this is all a build up to April 1st.

I actually like the blue text, contrast.

I agree the blue is really hard on the eyes.

Here are the diffs for the two CSS files I found between yesterday and today in case anyone cares.

github.css: https://www.diffchecker.com/STyCXVyk framework.css: https://www.diffchecker.com/x1uMGh3h

The merge request buttons/general purple color also pops quite a bit more today.

I don't share the disgruntled feeling toward the color.

The new color is #0366D6, while the old color is #7FA5CF. The new blue color is far more saturated and is much less light, but is actually still a pretty big step down from ultra-hard blue #0000FF. IMO, it's much more readable than the previous blue and stands out nicely.

Exactly. The 0366D6 against the hover background of f6f8fa provides a 5:1 contrast versus the old 2:1 contrast.

http://webaim.org/resources/contrastchecker/

SSO is important for enterprise.. but github presents a challenge where devs usually have pre-existing personal accounts which are added to company github accounts, rather than the company account being used.

That's what people used to do before because there were no good options to provision separate work accounts for people. With the new for business model I'm guessing we'll see people being issued work accounts and keeping their personal GitHub accounts completely separate, which might be a good thing.

Developers have the same identity no matter who they work for.

It makes sense to separate access ("this person has access to Example Corp's repos only as long as they work for Example Corp") from identity ("this person owns this account").

Introducing single-sign-on as one way to simplify login, and potentially as a second-factor for gaining access to repositories run by the business, makes sense. Making developers create entirely separate accounts doesn't.

But it's not just about having access to example corp. If I log in to GitHub from my work laptop then my company technically has access to my personal GitHub account and the repos of any other organization I happen to belong to. It goes the other way around to. If an attacker hacks my personal laptop and I'm logged into GitHub then they have access to all of my companies repositories.

There are perfectly valid reasons for segregating accounts so that there is complete separation between them.

That's why I'm saying it may make sense to separate identity from access.

You company only managed your membership in the GitHub organization. It doesn't have access your personal account or the details within it.

It does if I am logged in on a company laptop and they control access to that laptop. (This is hypothetical in this case, I happen to know that the particular company I work at does not have any backdoors on my laptop).

It is the first scenario not the second. The person is gaining access to the GitHub organization via SAML SSO. They are bringing their own identity and do not lose access.

Personal accounts will work fine under the Business plan. You'll just need to hit your organization's IdP for access.

Well, won't that require a different identity? My personal email account is funny-nickname@gmail but my work email is my-real-name@work. Github used to allow/encourage multiple identities but then changed it because it was super confusing and hard to manage. Maybe they've fixed that now. :/

They fixed some awkward "custom routing" screens a while ago. I've been using my single account with different companies for years now. I just make sure my git `config.email` is set right, set GitHub to route notifications for work repos to my work email, and it's done.

I've also been the admin on those Business accounts. It's easy.

I would really just love to be able to group my repositories. Either logically in folders, or in another structure that cleans everything up. Tags help, but it is not enough.

I am happy that they continue to add features like this, but I feel like some of the more common wishlist items are not being addressed.

I never really thought about it but grouping by tags would be a good thing. Once you get over 10-15 repos it gets much harder to find stuff.

Yes - and there's also the fact that you have to get everyone on the same page with tags. It isn't as simple as just moving something where it belongs.

the new "topics" feature is basically just tags as far as i can tell.

you can use the "user:" search operator + the name of the topic to filter your repos and then just bookmark the searches that youll be using often. its better than nothing for now

The blue text color blinded me for like a minute

It's a little frustrating to see that Github is holding SAML hostage with a more expensive business plan. SAML integrations should be par for the course with any SaaS solution.

It's because it's one of the few things an enterprise can't cheap out on. They have to have it.

Reply on news.ycombinator.com