I encourage people to check out 18F's Github repos...there's a lot of useful tools and libraries, for starters. And then there's full projects to learn from, such as APIs and front-facing static sites.
I don't know if they use any other kind of project manager besides Github Issues, but their projects have among the most active Issues activity...it seems that the USDS/18F team uses them as project discussion rooms that also happen to be public...as they should be for government, public facing work. And they accept pull requests from the public...here's one I made to make their style guides more readable on mobile/non-traditional-browsers:
They talked about it amongst themselves (in public) and then merged it in. I know that's part for course for most industry teams...but not for the federal government. Think about all the regulations and CYA-guideliens (cover-your-ass) that have built-up over the years that would've made accepting code, or any input, from a total outsider, to be...not a priority. A few years ago I remember finding a very obvious, easily fixable XSS vulnerability across all of the Department of Homeland Security sites...not only was it hard to find a point of contact, but I was pretty much ignored until I sent emails to US-CERT, and then also threatened to have a tech journalist write about it.
With the USDS projects, it's a completely different paradigm to work via systems like Github. At the very least, you can more easily take credit for suggestions/fixes you made.
>A few years ago I remember finding a very obvious, easily fixable XSS vulnerability across all of the Department of Homeland Security sites...
I think if I were in this situation today, I just wouldn't say anything. Being ignored would be one of the good outcomes; I'd be terrified of getting chucked into court for being a "HACKER AGAINST HOMELAND SECURITY."
The CFA is so broad that basically doing anything to a server that the server operator didn't anticipate is a violation. And since it was written to protect major companies' infrastructure in the 80s and 90s, the penalties are incredibly harsh.
In order to find the vulnerbility you almost certainly have to try it out. Even for an XSS, you'd have to make a JS alert box popup for yourself. And then you've technically broken the law, since you hacked the website.
I really used to love Bourbon and Neat, but they're unnecessary today. The vendor prefix mixins are mostly obviated by modern tools like Autoprefixer, and Neat itself can be mostly reduced to a Sass mixin.
I second this recommendation, even for those not using Ruby! The Sass compiler is written in Ruby but that doesn't mean you have to know Ruby to use Sass.
If you can do without the latest of the latest in Sass I highly recommend using a libsass implementation. So much faster than the Ruby version!
OT: I also like that they've used a BEM-like approach, although I personally prefer a double underscore as separator between elements.
Libsass is night & day vs Ruby Sass. No problems using libsass with Bourbon, Bourbon thankfully stays away from the bleeding-edge features (many of which can be emulated with clever functions).
In a previous project, we saw Sass compiles go from ~15s to about 400ms by moving to libsass. Completely changes the development cycle (with HMR or livereload) as you see changes immediately.
I've been using node-sass (libsass wrapper) recently, which hasn't been too bad compared to less (which is native to node/js). Seems to be working fine with bootstrap-sass, and surprisingly fast, compared to less, so I imaging the ruby sass implementation would be similarly slow by comparison.
Just an FYI for anyone who sees this, you don't need to know or utilize Ruby at all in your workflow to make use of SASS/Bourbon (not sure about Neat, but I'm guessing it's like Bourbon?). You just need to have it installed and be able to install a few gems (gem install gemname) and you're pretty much good to go. Or there are a few GUI options out there that make it even easier.
I couldn't write a damn thing in Ruby and I utilize it every day via SASS/Compass
Not gonna lie, I confused this site for one of those sites you see on parked domains. I can see a resemblance with respect to the color scheme, but I think the entire design aesthetic is completely different.
I had the same impression (on an iPhone). I'm not really sure what contributed to my unconscious snap judgement, but I think it has to do with the layout of the search box and list of links, along with the lack of images (other than a little icon in the corner) and the four copies of the domain name (in all caps) on the page.
Arguably unifying of back-ends are more important than the visual design for consistency and ease of use though.
The introduction to the article shows several different styles of registration or login button used across different US govt departments, but the key point here is that they're all separate user identities requiring separate logins. Making visually identical login flows that actually require different credentials to log into separate services actually makes things worse for periodic users of multiple government sites. What's needed as an even higher priority than changing the buttons is a uniform OpenGovernmentID everywhere it makes sense to do so
Priority number two for ease of use in government websites would probably be fixing link rot, since government websites have a horrible tendency to deep link to other departments just before that department's site gets reorganised or renames (and departments whose sites were replaced by the gov.uk platform unfortunately are no exception)
That article is bullshit. You can't judge gov.uk by its homepage, because that's almost never where you land.
Now that we have gov.uk, whenever I google something about doing my tax, or registering to vote at a new address, or any other arduous governmental admin shit, I usually end up on a beautifully simple and focused gov.uk page, and I'm in and out in 2 minutes. That's what a government website is about.
Look at how brief and clear the writing is. Look at how straightforward its URL is. Have a look at some more pages, look how consistent the design language is. This is exactly what a government website should be like.
This is the official US gov site for applying for a visa. Given there are so many dodgy immigration agents operating with .com addresses it makes no sense as to why the official site is not just 'visa.gov'.
Can anyone think of any reasons that any and all interaction with the US Government via the web shouldn't take place via a .gov website? If something like healthcare takes place on a .gov site, visas definitely should.
It's really easy to imagine a lowly staffer with an unrealistic deadline or contractor deciding to register a .com to use for a demo and thinking they'll go through simply learning who the official contact is, getting the agency CIO / agency head to sign off, dealing with internal politics[1], etc. later and then never actually getting around to that part. At some point the argument probably became “Now we've advertised it too much to change”.
1. At large organizations both public and private I've seen this kind of fragmentation happen because person A wanted a project to exist and person B, who controlled DNS, thought it should be included in their application (horrible vendorware, the first big Cold Fusion project they personally managed which will be upgraded over their dead body, etc.).
That's a great initiative. Being from a country that changes the URLs of a bunch of ministries (and breaks half of them) each time a new government takes charge, I envy it!
Now, for improved consistency, adopt the metric system.
I saw a presentation from the Gov.UK folk about keeping URLs working, when they migrated from the 2000s-era site.
They tried to keep everything going somewhere useful, and had examples of URLs printed on mouse mats, mugs, notebooks etc -- as well as the obvious official forms which might remain valid for decades.
Good ol' Kingdom of Spain. Governments tend to rearrange ministries (fusing them, eliminating some and embedding their competences in another, or simply renaming them) and the URL changes accordingly, but most of the times links break, the styles of a former deleted ministry are different from the new host, etc.
The Medium article says to visit the site for the standards.[1]
That yields:
MAX.gov Application Unavailable
If you are seeing this message and it is not Sunday 2AM-8AM ET then
please contact MAX Support by clicking here.
If you’re trying to access MAX Community, please use our snapshot
site: MAX Snapshot Community Site
"MAX.gov" appears to be some kind of in-house cloud service for the Federal government.
It's not fully in house. The idea is to centralize management of services (both in-house and external) for budgeting reasons, since MAX is part of GSA which is part of the OMB (Office of Management and Budget).
GSA, the General Services Administration, is the purchasing, construction, and building operations unit of the US Government. They're a huge operation, with a $20 billion budget and operations all over the US. The Office of Management and Budget is a White House staff unit with about 500 employees, most in an office building next to the White House.
What a great step in the right direction. Every time I navigate through another government website in search of information, it is a different experience. I'm all for consistency and can't wait until this is well adopted in all the .gov's I find myself visiting.
I really like this, but as someone who recently went through the federal loans process I know that the interface isn't the only thing holding back our government's web presence. Can we adopt a standard work flow? Something that behaves as expected when you submit forms?
When looking at a random website I expect to know roughly what I'm looking at within 20 seconds - max. Ideally 5 if not text heavy.
>shared set of tools [...] government websites
That is exactly what I wanted to know. Pity thats hidden on page 3 and I had to read credits & something about some Joanne's problems first.
The narrative story flow is fine...but you've got to give something solid up front. e.g. Do the startup cliche and say how you're revolutionising the world in a short sentence. Then launch into the speech about Joanne's problems...
I really like the look of this and think it is a great initiative. Especially as I am the only human on earth who don't love Material Design more than my own mother.
I think that material design works well for applications in particular... a lot of the time too much is shoveled into applications without a concern for information overload, material design enforces this to some extent.
That said, even looking a step back towards, for example twitter bootstrap, it's about keeping things clean and orderly. One of the examples I appreciated was the password prompt, too often what is allowed in a password isn't clear, and to be honest, I'm almost in favor of allowing pretty much anything, I wish people would use "passphrase" instead of "password" and encourage multi-word phrases, even a full sentence. "Fear is the mind k1ll3r." for example.
This post doesn't address the most important thing: when can we actually expect all of the government's websites to start using these common patterns?
Creating a library/set of guidelines that you expect other developers to use is great and all, but not impactful in and of itself. Right now it looks like the library's authors are more focused on making their library useful than used, which is a thousand times more important.
Nice! I did notice some of the component definitions look like very close paraphrases to Semantic UI's component descriptions though, but I'll take that as a good thing.
Hopefully this guide will be updated as time goes on to stay relevant as technology changes. Otherwise in a few years from now, everything will look outdated again.
Looking outdated isn't the worst thing in a world. I think National Forest signs look like hotel signs from the 1950s, and that's probably not a coincidence.
What's more interesting is if this will lead to better maintainability. Since this includes code as well as guidelines, hopefully it will reduce the variation between various agencies' websites. That in turn should make future upgrades more uniform and therefore less costly.
That standard is incredible, I had a good flick through it just in awe of the level of specification that goes into signage, I love that type of stuff, it's a hidden world.
I attended a presentation by one of the people working on the project last week and they put a lot of thought into both how to make this a usable guide for now and how to keep it growing into the future. The USDS has attracted some really great people lately, and it shows!
Well if all gov't websites transition to this - at least they'll all look outdated but still in sync with each other. Not to mention responsive, and still good looking.
Doesn't this make it incredibly easy for phishing websites to be created? I suppose such websites would exist anyway, but this would certainly diminish a user's ability to differentiate between a legitimate .gov or another page with malicious intent at a glance.
Not any easier than it already is. There are tools like Social-Engineer Toolkit (SET) that make it dead simple to launch all sorts of phishing attacks.
You might be thinking about different "design". In this particular case USDS tries to "design" (as in engineering or architecture) efficient, cross-organizational set of guidelines to keep look consistent across all government websites. This should lead to same standard of UX and AX, which should lower amount of confusion of customers and lower costs building new projects.
You can think about it as of Twitter Bootstrap for government websites.
It depends on what you're trying to achieve. US Government sites aren't about creating an artistic experience. It's more important that digital services are delivered consistently and give citizens a good UX. As an experience, the design hinges on creating trust, accessibility, and being able to carry what you've learned about the interface to different sites. These things won't degrade easily with time. For instance, the significance of the color blue won't change rapidly (barring a large scale invasion by blue extraterrestrials).
As a designer, my job isn't to "design a website," it is to design patterns of UI/UX and a framework to build new features and interactions for a particular application. Basically, a designer's first job is to design the lego blocks. Then she can build stuff with it.
The application in this case is the U.S. Government. The purpose of this design is to provide the lego blocks and framework for developers and designers to build an interaction layer for the federal government.
No, it's fullfilled. The design of the average table, pencil, glass, fork, spoon, text-based book etc. is fairly standard (save for few ornamental details).
That's not because its purpose is lost for design conformity, but because those are peak designs that work best for what they need to do.
The only purpose design for government sites has is to be able to give information quickly and in a legible and accessible way. No artistic ambitions here. That can be standardized very well.
> average table, pencil, glass, fork, spoon, text-based book etc. is fairly standard (save for few ornamental details).
Except that's the point of the OP's comment. These items actually do not have any explicitly declared standard like this design standard published by the government. Design became standardized through people landing on a good design, not through a government mandate.
I don't think that that's his point -- I see this as orthogonal to whether there is a standard or not.
The reason those don't have a standard is merely because they are so simple they don't need a full document to describe them.
And I don't see a clash between a "goverment mandate" and "design", since in this case the government mandate is exactly a design, that is, the work and output of a set of designers working for the government.
It's not like some random bureucrat that knows nothing about the web created the standard.
"It doesn't do anything useful and it only loads Saturdays at 3am, but it sure has some syntactically awesome stylesheets!" ...Anyway, it sounds good on paper.
The design level is the wrong level to solve the fishing problem. Any site can be immitated, and 100 differently-looking sites can be immitated with almost the same ease as 100 same-looking ones...
For one, you don't even have to create anything -- you just download the original assets, and merely inject some JS or change a form destination in your version.
So mirrorring (wget -mkp http://foo.bar) designs is not that more difficult...
OK, now that it's back up, let's take a look at the examples. There's a "register to vote" page, but that's trivial. Here's a more difficult one - a mockup of a Veterans Administration form.[1] This is clearly for use by a Government employee, not the public.
(The first question one asks is, if an appeal is "certified", why does it also have to be "activated" by a human before anything happens? But that's the organization's problem, not web design.)
It's a high-contrast layout, to support the visually impaired. Although it does have both white on black and black on white buttons, visually it seems OK.
The form has a pull-down for "Confirm type action". This isn't a "Confirm" button, it's a selection option, for selecting the type of bureaucratic action. There are several documents mentioned, "Form 8", "Form 9", etc. These are in bold sans-serif blue text. The "NOD" document is apparently missing, so you couldn't view it, but the text for it is the same as for the documents you can view. At the end of each line is the word "Change", in the same font and color. It's not clear if "Form 8" is clickable, leading to a view of the form. "Change" is presumably clickable, and ought to lead to a popup. It's not clear whether changes commit immediately, or when the final buttons at the bottom ("Reassign" or "Activate Appeal") are clicked.
The "POA" heading is misaligned. You can tell they used table-less design - things don't line up right.
This form is useful only if the user has paper materials on hand against which they are checking. Functionally, this form is exactly equivalent to something on a green-screen IBM 3270 terminal from 30 years ago, which may be what it is emulating.
This is their example of good Government web design.
> The "POA" heading is misaligned. You can tell they used table-less design - things don't line up right.
Um, that's not the case. Those look like table tags, as they should be (it's a table). The only problem is that that column header is left-aligned, not right-aligned like the rows are.
Most of your complaints are bullshit, frankly, and the rest are about interaction design/UX, not visual design, which is all that this project claimed to be. The visual design and layout look fine, with the exception of that misaligned column heading (the horror!).
Re-reading this a couple hours later, I agree. I responded to needless negativity with more needless negativity. Guess my IRC habits have been leaking into my other hobbies. I'd edit it, but it's been too long since it was posted.
The misaligned comment head is over a blank space, and to the left of a column that doesn't have a head. So the "clean" web design results in a column head that's not associated with a column.
Interaction design is what it's all about. This page would work equally well with the browser's default fonts and colors.
I don't know if they use any other kind of project manager besides Github Issues, but their projects have among the most active Issues activity...it seems that the USDS/18F team uses them as project discussion rooms that also happen to be public...as they should be for government, public facing work. And they accept pull requests from the public...here's one I made to make their style guides more readable on mobile/non-traditional-browsers:
https://github.com/18F/content-guide/pull/43
They talked about it amongst themselves (in public) and then merged it in. I know that's part for course for most industry teams...but not for the federal government. Think about all the regulations and CYA-guideliens (cover-your-ass) that have built-up over the years that would've made accepting code, or any input, from a total outsider, to be...not a priority. A few years ago I remember finding a very obvious, easily fixable XSS vulnerability across all of the Department of Homeland Security sites...not only was it hard to find a point of contact, but I was pretty much ignored until I sent emails to US-CERT, and then also threatened to have a tech journalist write about it.
With the USDS projects, it's a completely different paradigm to work via systems like Github. At the very least, you can more easily take credit for suggestions/fixes you made.