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/
I must applaud your legislators for their foresight when they wrote the federal copyright charter. All works by. U.S. federal employees are in public domain, forming one of the planet's largest bodies of free online resources. The cultural impact of this collection is considerable also globally.
In my country, all tax-funded government works are copyrighted. It's an ongoing battle to make each department release their works under a free license, and massive bodies of government-owned digitized cultural works sadly remain accessible only to those who pay for them.
> Doesn't apply to works by contractors paid by the government though.
Depends on the terms and conditions of the contract. Keep trying to get people to ensure they secure rights for the government by default but it's a constant struggle to get people to sweat the details :p
We should always demand more from our governments. But we should also celebrate them for doing good. The politicians and government workers are people too, and while different people have different motivations I know that I am not alone in valuing praise from others highly.
If all someone hears is complaints, I think they are probably more likely to burn out. I don’t have any source to back this claim, but it’s how I think it is.
I have very high standards, but expecting public information to be public wouldn’t even be meeting those. It would be meeting one of my most basic standards.
To reject and fight FOIA requests takes _effort_, more so than simply complying with them. So no, I will not applaud shit. Our government needs to get past “basically good” before I praise them for frosting like this.
But feel free to embrace your feel good powwow approach. It’s done us so well so far.
Hello, are your web analytics also publicly available ?
Th EU has http://ec.europa.eu/ipg/services/analytics/ but I recently discovered that I cannot access any data as a citizen. Legally, I'm convinced this data should be public domain.
If this is meant for web sites, I have a question and I ask this on HN a lot. Why does the government need to provide ANY fonts? I have a real problem with websites pushing their own fonts on users. I don't think it's their place. Users should select their preferred font in their own browser. Why would a US government site feel the need to use particular fonts?
If this is for publishing in .pdf format I can understand. If it's for web, I just don't get it.
Because ~no users curate their fonts, and making your site look better for the ~all users who don't curate their own fonts is the better more pragmatic choice by such a large margin that it isn't really worth much thought.
Does this negatively affect your experience? Can't you override fonts if you want to?
Edit: note, I'm not the person the question was directed at, and have no connection to the federalist project at all.
Every time I've visited a site where I thought, oh that's a terrible font, it's been basically one of these reasons:
* Improper selection of default font for constrained display eg tabular
* Or the more popular "Let's create a font because we can. It's branding."
There are of course other considerations involved like the increasing diversity of rendering devices, but that doesn't make the fact that any web site font issue is nearly always the fault of the web site operator.
I can't recall any instance of "oh, that website with a great custom font is so appealing I'm going regularly and voraciously consume its content". The opposite of that is true though.
I know there have been a couple of occurrences where I dropped into the web dev tools to see which font a site was using because they used beautifully, fitting fonts.
Properly selected, fonts contribute to the user experience so seamlessly that most users don't even realize that the font used is something out of the ordinary.
This is similar in effect to users liking a site more when it is faster, but attributing the improvement to any number of other things that haven't actually changed.
This is an interesting perspective, and one that could only exist in the past few decades.
For millennia, of course, the written word would appear in the particular style of an individual scribe, and might take on an entirely different look when copied by another. Gutenberg’s movable type introduced the concept of a text appearing exactly the same across multiple copies, something that has persisted for centuries through lead type, phototypesetting, and into PDFs. Only with the advent of information technology in the 20th century did the idea arise of text appearing in formats other than those chosen by its publisher, advanced by technologies such as TeX and HTML.
In the latter’s case, however, the original idea of a platonically structured document to be interpreted per the user’s preferences has long since been superseded by a return to the concept of the publisher defining the presentation. Client CSS never caught on, while server CSS took over.
I would argue that a font is a part of an organization's brand. I think publishers like Airbnb and google have built around Cereal and roboto respectively.
Some of us do, and that's probably the best lifehack I've found so far.
Enforcing the same font and size across all pages is ergonomic and does lower the cognitive overhead of recalibrating your sight-reading for every new page you visit. Just my two cents...
Although we are part of the government, we operate as a business unit that must pay for itself to exist. To do this, we have to charge other agencies for our services. My group is "cost-recoverable," meaning, that we are longer losing money and can reinvest back into the product. You will notice our Github activity picked up recently and even more significant changes are coming soon. So, I'd say we are in the best shape we've ever been.
I was at 18F for almost 4 years. In that time, many of the projects I worked on were internally-facing. The US Government runs thousands of internally-facing websites and web applications. Many of them are entirely internal to single agencies, others are for inter-agency collaboration. Many of them require PIV or CAC cards for auth. And yes, many of them - whether card-authenticated or not - are utterly horrific.
This is a big part of why the USWDS project was created. 18F is tiny, and there's no way it could address even 1% of .gov by itself. Fortunately, there are many people all across government who want to improve UX on sites and apps. USWDS is a good starter kit that significantly reduces the cost of such projects for everyone, not just 18F.
^ 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.
I’ve found Boston’s city websites [1] to have a nice user experience and fantastic branding that ties in not just all the city’s web properties, but also some official postal mail flyers from the city, printed placards and signage at City Hall, and more.
I haven’t noticed this strong of a branding in other cities I’ve lived, but would love to see examples of others.
Boston even maintains its code on github! [2] Their digital department also has a roadmap of what their initiatives are, and it’s communicated in what I think is such an easily digestible manner [3]
The USDS (US Digital Service) was born in the fire of the healthcare.gov fiasco, and several industry veterans from Google stepped in to fix the infrastructure issues they saw within the US Government. Currently, @Matt_Cutts is leading the org. I can only think that your comment brings a smile to his face.
IIRC the USDS is also in part based on GDS[1] who did (and continue to do) a really good job at dragging parts of the government kicking and screaming into the future.
Does anyone know what it's like working for the USDS? Curious what it's like to work for the Government but under the leadership of presumably a bunch of ex-Googlers.
I really wanted to work for the USDS for a while. I'd still like to, but the invasiveness of an SF-86 which is required for some reason even if you don't need a security clearance, drug testing (I'd pass, but I'm not okay with requiring one anyways), and the fact that I'd have to move to D.C. make the sacrifice a big thing to weigh against the public good you'd be able to do. It's a tough call.
USDS's requirement to be in DC is a tough ask, but necessary given the work they do. At 18F, we travel to DC a couple of times a year, but we are mostly remote. There are significant hubs in SF, NYC, DC, and CHI, but the remote culture is the most successful I've seen.
I'm fine with the SF-86 once every 10 years. It's moving to DC Metro that's the deal-breaker.
And even if I were okay with both things, I'd rather fill out the SF-86 to get a real clearance, and work for one of the military-industrial-congressional complex "Beltway Baron" companies for higher pay, more job openings, and no 4-year term limit.
There are also a couple contractors that came out of the healthcare.gov rescue (notably: Nava [1] and Ad Hoc [2]) trying to do the same kind of work. I recently left a long career at Google to work for Ad Hoc, and we get to work alongside the great folks at USDS trying to make things better.
Hit me up if you're interested in getting into this space!
I always enjoy reading the job posting in the monthly whoishiring thread. I also like that Matt is active in the comments answering questions. For example, April: https://news.ycombinator.com/item?id=19545383
The Forest Service worked with 18F on this Open Forest project to enable people to buy Christmas tree permits online, which uses United States Web Design System components: https://openforest.fs.usda.gov/christmas-trees/forests
https://openforest.fs.usda.gov/christmas-trees/forests has a pretty heavy dependency on Javascript (read: there's no fallback to anything non-javascript, so I get a white page). It feels like that goes against some of the things that 18F is about.
Pages don't need a fallback to non-Javascript in 2019. Accessibility technologies now fully support a JS enabled web, with accessibility standards following suit.
That leaves only those who have voluntarily disabled JavaScript (<1% of users), but fortunately those users are typically aware of how to resolve the issue of their own creation.
I've worked on public facing government websites (not 18F). We simply don't support this edge case, and our legal department supports our legal right to do so (in particular in relation to ADA requirements).
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 XHTML? Etc.
> Pages don't need a fallback to non-Javascript in 2019.
Strongly disagree. Having your page completely break instead of degrading gracefully puts up a barrier to those who cannot run JavaScript (for example, users with older, weaker computers).
People on "older, weaker computers" are likely running a browser we also don't support (<IE10) on an Operating System we don't support, and they'll likely see a TLS error before even hitting the load balancer (we don't support SSL or TLS 1.0).
It is unlikely that there exists a subset of users with a modern enough computer to even hit our web servers that is under-powered to the point of not handling JavaScript. Our analytics definitely don't show this.
Thank you for the response. I wasn't trying to suggest that it was a requirement, simply that it seemed odd that there would be no fallback whatsoever. I guess I'm behind the times.
> Pages don't need a fallback to non-Javascript in 2019. Accessibility technologies now fully support a JS enabled web, with accessibility standards following suit.
I think we should broaden the definition of accessibility to make websites aren't unneccesarily annoying or invasive for normal users either ;-)
(And yes, making web applications is part of my job.)
> Pages don't need a fallback to non-Javascript in 2019. Accessibility technologies now fully support a JS enabled web, with accessibility standards following suit.
This is wrong, of course, because it requires that people buy expensive hardware to use the latest accessibility technology, which is not generally available. It's like demanding that people buy electric-powered wheelchairs instead of making your building accessible to normal wheelchairs.
> We simply don't support this edge case, and our legal department supports our legal right to do so (in particular in relation to ADA requirements).
And I'm sure that ignoring poor people enables you to sleep very well at night.
If you disable a tool which you know is used to build many websites nowadays then you really should expect a deprecated experience. You're in the minority and honestly I don't know why you should expect web developers to cater for you.
At this point, there is no reason to support <IE11 style JS, but JavaScript-less browsers are still A Thing and always will be. Search engines, Opera Mini, various accessibility thing, people with extremely low bandwidth, and weirdos who choose to disable JS are all factors.
Yes, if you're making a webapp, there's no good way to do it without JS and you can just be upfront about that. Also, people who can't use ES6+ are going to zero over time, so it's fine to just write ES6. But you should also have a no-JS fallback version of an information page (anything that's not a webapp) because that's an important usecase that won't drop to zero over time.
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!