Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Public Sans – A strong, neutral typeface for text or display

public-sans.digital.gov

Post reply on HN
Print view View original

231–240 of 245 posts

Re: Public Sans – A strong, neutral typeface for text or display

#231

Post by carapace »

Ephiiz wrote: post #206
carapace wrote: post #185

Earlier quoted context omitted.

First, as a person who makes web sites and apps, I believe it's unprofessional to fail to account for users who can't or won't run JS. JS abuse is rampant. I choose not to let sites run JS by default because I don't trust most sites not to have some sort of compromise or malware. Second, it's fine with me if some site wants to forgo my patronage, or provide "a deprecated experience", but not the government. I certain…

While I agree with you that most if not all sites should offer some sort of no JavaScript fallback, the development resources required to offer such a thing is just generally unpractical when it's such a small minority of users. Government or not, they still have to choose between spending their limited departmental resources on an extremely small minority, or the greater userbase as a whole.

> the development resources required to offer such a thing is just generally unpractical

Yeah, iSnow made the same point, but it doesn't scan. "Boss, I can make it work w/o JS but it will cost more..." Huh? Doesn't that sound just like what an unprofessional developer would say?

The fact that so many popular JS frameworks don't do the right thing is part of the JS abuse in my opinion (same goes for accessibility.) Lazy developers wrote half-assed frameworks and other lazy developers chose to use them and then people start to believe that adding JS somehow makes it hard or expensive to do without JS when really they are just doing it wrong in the first place.

> when it's such a small minority of users.

The population of the US is just under 330M, so if, say, 0.5% can't or won't run JS to interact with taxpayer-funded government services that's about 1.5M people. Those folks (of whom I am one) should not be disenfranchised, so to speak, because the gov hired unprofessional developers. The government shouldn't do that, and they certainly shouldn't try to tell me that I'm some out-of-date digital neanderthal for caring enough about web insecurity to disable JS, eh? Lousy devs (as demonstrated by the fact that they can't provide a non-JS web experience/fallbacks at an affordable rate) are precisely the ones the JS code of whom I have no wish to run, and I certainly don't want my tax dollars going to pay them to screw me out of access to the service also paid for by my tax dollars.

> choose between spending their limited departmental resources on an extremely small minority, or the greater userbase as a whole.

Or they could use tech that works for everybody automatically for the same cost, eh?

Re: Public Sans – A strong, neutral typeface for text or display

#232

Post by wolfgang42 »

yellowapple wrote: post #76
Wowfunhappy wrote: post #64

Earlier quoted context omitted.

I imagine just the government's code contributions would be public domain, and public domain code should be GPL compatible.

Public domain code ain't GPL-compatible though unless it's explicitly released under a "license" that functions as a public domain grant (e.g. CC0, 0-clause BSD, WTFPL, etc., though WTFPL has some legal wording issues IIRC), the reason for this being that not all jurisdictions recognize the concept of "public domain" and thus require explicit license terms.

Wouldn't the PD "license" in this case be US law [1], which specifically prohibits copyright protection for works produced by the government?

[1] 17 USC 105: https://www.law.cornell.edu/uscode/text/17/105

Re: Public Sans – A strong, neutral typeface for text or display

#233

Post by donjo »

frogpelt wrote: post #88
eddietejeda wrote: post #41

Earlier quoted context omitted.

Yup. I run Federalist at 18F and absolutely love the work, the challenge and colleagues. We do everything in the open, so feel free to follow our work here: https://github.com/18F/federalist We also implement the USWDS, which you can follow here: https://github.com/18F/federalist-uswds-jekyll Let me know if you have any questions!

Do you (18f) have any success with redesigning internal government sites, those that require smart cards to access? Some of those are the worst.

^ what Yoz said (Hi Yoz!). Also within the last 6 months login.gov added support for PIV/CAC cards so while that product only handles the sign on experience, there is some hope for internal sites improving across the board. The tools exist at least.

Re: Public Sans – A strong, neutral typeface for text or display

#234

Post by janc_ »

yellowapple wrote: post #76
Wowfunhappy wrote: post #64

Earlier quoted context omitted.

I imagine just the government's code contributions would be public domain, and public domain code should be GPL compatible.

Public domain code ain't GPL-compatible though unless it's explicitly released under a "license" that functions as a public domain grant (e.g. CC0, 0-clause BSD, WTFPL, etc., though WTFPL has some legal wording issues IIRC), the reason for this being that not all jurisdictions recognize the concept of "public domain" and thus require explicit license terms.

I don't know any jurisdictions that don't recognize the concept of “public domain”, but there are some that define “public domain” differently than it is defined in the US.

In the US “public domain” means “without copyright”, while in some other countries it means “without authors rights” (authors rights are a superset of copyright). The problem here is that some authors rights (both in the US & in those countries) are “inalienable”, meaning they can't be given or taken away (although there might be exceptions listed in the law).

Re: Public Sans – A strong, neutral typeface for text or display

#235

Post by velcrovan »

jancsika wrote: post #87

Before I submit a bug report-- is there a good reason that the zero isn't dotted in this font? For example, executive order numbers have both "O" and "0" appearing in them. But I'm sure there are stronger examples in various gov't depts. where those characters can occur in sequence and create errors. Not to mention any code snippets that already appear in government web sites. I suppose the extra ink could be a conce…

“is there a good reason that the zero isn't dotted in this font?”

Because it isn’t a coding/monospaced font?

Most text/display typefaces don’t have dotted or slashed zeros.

The expectation is that if you have ID numbers etc where you’d need them, you would use a different typeface.

The US Web Design System 2.0 (of which Public Sans is a part) specifies Roboto Mono (which does have a slashed zero) for such purposes. See https://v2.designsystem.digital.gov/components/typography/

Re: Public Sans – A strong, neutral typeface for text or display

#236

Post by andrei_says_ »

eddietejeda wrote: post #41
2bitencryption wrote: post #3

This is so interesting. These modern sites clash really hard with my mental visual of "Government technology." And it led me to this, which is maybe even more interesting: https://federalist.18f.gov/

Yup. I run Federalist at 18F and absolutely love the work, the challenge and colleagues. We do everything in the open, so feel free to follow our work here: https://github.com/18F/federalist We also implement the USWDS, which you can follow here: https://github.com/18F/federalist-uswds-jekyll Let me know if you have any questions!

GitHub for content management? How do you approach training?

Asking because I think this approach rocks but have a hard time selling it internally.

Re: Public Sans – A strong, neutral typeface for text or display

#237

Post by carapace »

Someone1234 wrote: post #186
carapace wrote: post #185

Earlier quoted context omitted.

First, as a person who makes web sites and apps, I believe it's unprofessional to fail to account for users who can't or won't run JS. JS abuse is rampant. I choose not to let sites run JS by default because I don't trust most sites not to have some sort of compromise or malware. Second, it's fine with me if some site wants to forgo my patronage, or provide "a deprecated experience", but not the government. I certain…

> I certainly do expect my federal, state and local government to follow best practices and provide working websites that I can use without running JS. Best practices is a moving target. What made sense in 1999 doesn't make sense in 2019. The web simply requires JS, CSS, and HTML today. If you disable any one you aren't compatible. There's no actual argument for why websites should spend significantly to support a ti…

> Best practices is a moving target. What made sense in 1999 doesn't make sense in 2019.

Sure, but it still makes sense to use JS sparingly. Running untrusted remote code in your browser is a huge nest of attack vectors. I don't think that, in 2019, running JS from the open internet willy-nilly can be described as "best practices", despite the prevalence of it. We're not there yet. If three hundred million people jump off a bridge I'm still not going to do it too.

> The web simply requires JS, CSS, and HTML today. If you disable any one you aren't compatible.

That's, like, your opinion, man.

You're trying to insist that your concept of the Internet is the concept of the Internet. It's a self-fulfilling prophecy. But it's not quite true yet, eh?

> There's no actual argument for why websites should spend significantly to support [non-JS users]

Right, they shouldn't spend more because the tech they use should provide for non-JS users out-of-the box without additional overhead. If devs have chosen NOT to use tech like that then they are at fault, not the user, eh?

> for ideological reasons.

What about for security reasons?

> It is unfair to our other >99% of users who we'd have more time for.

But the reason you have to "spend significantly" to do the right thing is that you chose to use and deploy crappy JS frameworks, not that some people refuse to run your crappy frameworks. This is classic "blame the user".

Now, this is your prerogative if you're doing your own site/app, but the government doesn't get to exclude some people from service just because they don't run JS. Speaking as a techno-elitist, that's techno-elitist BS.

> If you really insist on a JavaScript free world you are of course welcome to visit a government office in person, pick up, and mail back a paper form.

AH-whaaaa? Rather than fallback to plain HTML+CSS you're content to let the user fallback to hard copies and physically transporting their meat-puppet? To save costs? On web development? Where's the sense in that?

> The website is merely a convenience we offer to you.

Well, no. It's an INconvenience you offer me. If you're offering convenience to most people but deliberately excluding some that seems to me to go against the egalitarian spirit of our American government, no? "Unfair"?

> Otherwise you'll need an IE 10 or newer browser, on an Operating System that supports TLS 1.1 (Windows Vista or newer), JavaScript, CSS, and HTML.

I run Dillo. A government website that doesn't look decent and work right when accessed with the Dillo browser is just broken and sad in 2019.

Re: Public Sans – A strong, neutral typeface for text or display

#238

Post by jimktrains2 »

iSnow wrote: post #202
carapace wrote: post #185

Earlier quoted context omitted.

First, as a person who makes web sites and apps, I believe it's unprofessional to fail to account for users who can't or won't run JS. JS abuse is rampant. I choose not to let sites run JS by default because I don't trust most sites not to have some sort of compromise or malware. Second, it's fine with me if some site wants to forgo my patronage, or provide "a deprecated experience", but not the government. I certain…

>First, as a person who makes web sites and apps, I believe it's unprofessional to fail to account for users who can't or won't run JS. JS abuse is rampant. If you do web for a living, you should also know that fallbacks and graceful degradation and server-side rendering all come with a cost. Both monetarily and in terms of complexity.

I would bet that the vast majority of government websites are nothing more than simple forms or informational pages.

Yes, I'll Grant you that if you've designed an interactive, multipage form then it is costly to rebuild it to degrade. However, I'd argue that the form was probably unnecessary technically complex and that starting with having a degraded option in the first place isn't additionally costly (and better protects the agency from ada lawsuits).

In the very rare cases that we're talking about a true webapp (i.e. Google docs, or I'll even Grant you GIS (mapping)visualizations, even if it's possible to degrade those), then yes, decisions need to be made on what minimal technical requirements are required. E.g. a government agency offering an application that only works in chrome would be a non starter.

Re: Public Sans – A strong, neutral typeface for text or display

#239

Post by Spivak »

wongarsu wrote: post #166
dannyw wrote: post #164

Earlier quoted context omitted.

Can someone release their work in the public domain, and also license it under the Apache License?

Sure. In any country without a concept of releasing something into public domain the fact that you did so would be irrelevant and the Apache License would apply, in any country where you successfully released it into public domain that already gives all the rights granted by the Apache License. The restrictions of the Apache License obviously wouldn't apply in those countries. Though if you try such legal tricks you…

> The restrictions of the Apache License obviously wouldn't apply in those countries.

How does this work? Can you 'dual license' with public domain?

Re: Public Sans – A strong, neutral typeface for text or display

#240

Post by webmaven »

Someone1234 wrote: post #133
nulbyte wrote: post #97

Earlier quoted context omitted.

I wholeheartedly disagree. This is a public-facing government website. It ought to degrade gracefully in order to reach the broadest possible audience. Or, write a decent site to start with, and you wouldn't have to worry about degrading. The entire page is nothing but a shell for a web app written in JavaScript that doesn't need to be a web app written entirely in JavaScript.

> It ought to degrade gracefully in order to reach the broadest possible audience. You mean under 1% of users that intentionally broke their browser? Seems unreasonable to dedicate resources to that, that could be better spent on 99% of our users. Why should the 1% get special treatment? And what other parts of their browser can they disable that we need to support, perhaps no CSS? Maybe IE5? Maybe they only render X…

There is still one important scenario that benefits from supporting a fallback to "classic" HTML for web sites (and apps): Bandwidth constrained environments. GMail's plain HTML version is an existing example (a link to it shows up if the JS version takes too long to load).

Anyway, for public facing sites and apps, you may already be doing most of the necessary work for SEO purposes. Letting humans access the version that you're showing to search engine spiders shouldn't be a huge burden.

Post reply on HN