The a16z podcast takes Capitol Hill to chat with Representatives Jared Polis (D-Colorado) and David Schweikert (R-Arizona) about possible applications for blockchain technologies, way beyond cryptocurrencies. The 20-minute episode will leave you with plenty of cocktail party worthy soundbites about everything from information privacy to more effective foreign aid.
We love the concept of dogfooding at DOBT. Even though we’re not a government agency, we’re always on the lookout for new opportunities to use Screendoor for ourselves. So, when our Customer Success team mentioned that they were looking at different tools to conduct a Net Promoter Score (NPS) survey with our users, we immediately thought, “Hey, we can build that with Screendoor!”
We’re pretty excited about how easy Screendoor makes this process, so we’ve decided to share our strategy (and our own Screendoor-NPS repository) with all of you. Feel free to try it out and let us know what you think.
In this episode of Rewiring Government, DOBT’s CTO Adam Becker steps in as guest host and talks to Aidan Feldman, an Innovation Specialist and developer at 18F, which is part of the United States General Services Administration’s Technology Transformation Service. They discuss cloud.gov, some interesting “bureaucracy hacks,” and the remaining barriers to real technological change within the federal government. If you’re interested in learning more about the work 18F is doing, check out Aidan’s talk about IT compliance, 18F’s guide to launching software, and cloud.gov.
Use the player above to listen, or subscribe on iTunes and Google Play! You can also add our RSS feed to your favorite podcast app. If you like this episode, rate and review us on iTunes, and tell your friends.
A transcript of the interview is below, edited for content and flow.
Last month, we rethought the way that respondents to our customers’ hosted forms authenticate themselves. Previously, we required respondents to create an account, which adds unnecessary friction. We redesigned the system to deliver all of the benefits of account creation with none of the downsides, taking cues from the “passwordless authentication” movement.
We wanted to give you a look into the problems we identified with our old system, the design process we used to iterate upon user flows, and how we migrated to the new system with minimal impact to our users.
In our work with government and enterprise IT, we’ve seen how user support can go terribly wrong. Enterprise software is often so complicated and unintuitive that it requires a hefty binder bearing the words “User Manual.”
After experimenting with a few options, from in-app tooltips to comprehensive phone support, we decided that an online knowledge base would be our best way forward. None of the existing out-of-the-box solutions fit our needs exactly, so we built our own from scratch. Here’s how we did it.
Last week, we experienced a small period of downtime due to a network issue in our underlying data center. While small incidents like this one can happen to anyone, we realized that we needed a way to keep our customers informed about the status of our services. I’m happy to announce that now, you can see current and historical uptime data for our apps at status.dobt.co, as well as subscribe to be notified of future outages and planned maintenance.
This past weekend, DOBT participated in Code Across 2014, a nationwide hackathon where community members and local governments come together to develop tools and applications that improve their communities. We’ve attended events like this before, but this weekend was special because we had just launched OpenRFPs, our community-based initiative to democratize RFP data across the country.
Tomorrow at CodeAcross we’ll be launching our first community-based project, OpenRFPs. The goal is to liberate the data inside of every state RFP listing website in the country. We hope you’ll find your own state’s RFP site, and contribute a parser.
When Clay and I first started working together, we quickly realized that we are both total nerds when it comes to team productivity. In just a few weeks, we had built the first version of MorningCheckin, a lightweight app that lets each team member “check in” every morning and let others know what they “got done” the previous day and what they intend to “get done” today. Our team started using MorningCheckin fastidiously, but after a few months the habit just wasn’t sticking. When we arrived at our office in the morning, the first thing we wanted to do was open a new browser tab, wait for MorningCheckin to load, and craft a new checkin using its special syntax.
One thing that’s been frustrating about developing apps for the government web is that some of the great front-end frameworks we use don’t take accessibility into account. A week ago I announced our plan to add some modest accessibility improvements to Bootstrap, and asked some friends from Code for America and the White House’s Presidential Innovation Fellows program to help contribute.
I’m proud to announce that as of today, our changes have been merged into the main Bootstrap repo. Our work isn’t completely done, (in round 2, we’ll start testing Bootstrap with an actual screen reader,) but we’ve already achieved significant progress in making Bootstrap more friendly to users of assistive technology.
Recently I’ve been working on making Screendoor “508 compliant”. Section 508 is a federal law stating that all IT systems must be accessible to users with disabilities – kind of like WCAG, except mandated by the federal government. In it’s most simplified form, it’s basically a checklist of accessibility best-practices that all federal websites need to follow.
Unfortunately, everyone’s favorite Twitter Bootstrap is rife with accessibility issues. Things like using the <i> tag for icon classes, using anchor tags to toggle menus… and some trickier ones, like encouraging users to use non-semantic header nesting. (Is the biggest header on your site an <h1>? no? bzzzzzzz)
That’s why this weekend we’re hosting an informal gathering in Oakland (and virtually) to work on making Bootstrap follow accessibility best-practices. Where we need your help is filing issues – before Sunday, we would love to have a fairly comprehensive list of where Bootstrap fails 508 and WCAG guidelines. I’ve started building the list, and would love any and all help filling it out:
One big problem we have in getting government to use new technology is the Terms of Service problem. See, unlike you and me, government employees can’t just “click through” a legally binding contract without reading it. Instead, if you want to buy something, you’ve got to have your counsel read through the Terms, and often, negotiate with the service providing the terms.
That’s why for a lot of small businesses, it’s good to have some kind of standardized terms. Eventually, we want to get to the point where Counsel says “oh, I’ve seen these terms before. It’s fine.”
So now we’ve got something we can work with – a template, a place to start. Let’s work together to craft a terms document that works for everybody, so we can focus on what we do best – making great software.