Skip to main content
Posted in

2018

Private sector innovations in information technologies are transforming virtually every industry, and the rate of change seems to be accelerating. A decade ago, Facebook was a website used almost exclusively by college students to keep in touch with each other; today it’s one of the world’s largest media distributors with the capability of swaying elections simply by tweaking its algorithms; and in ten years it’ll likely be directing a self-driving car to drop you off at your friend’s house.

Read the Article at the Source: For Government, It’s DSO or Die | Gotham Gazette

The mindblowing rate of innovation taking place in the private sector is a stark contrast to the glacial pace of innovation in government bureaucracies. Indeed, to many people in the private and public sectors, government agencies appear, at best, frozen in time, and at worst, actually deteriorating before our very eyes. New York City’s beloved subway system is a case in point.

It doesn’t have to be this way. Government agencies can leverage new tools, techniques and technologies to improve their effectiveness and even delight their users, but doing so requires more than simply signing a fat contract with a vendor of high-tech wares. It requires government adopting the values of the “open source way”: open exchange, participation, rapid prototyping, meritocracy, and community building.

Doing so will change government agencies in significant ways: new roles, new skills, new trainings, new people, and new organizational structures.

It’s easy to see why wholesale reform of government agencies isn’t happening: people don’t want to lose their jobs. But piecemeal reform is taking place within government, and patterns are emerging that show how small teams within government that deliver “digital services” to other government units and agencies – things like websites, mapping systems, workflow management solutions and other high-tech products and services – are driving change.

The major factor that distinguishes these newly emergent “digital services organizations” (DSOs) from other technology groups within government is that their main job isn’t procuring software from large software companies, but instead to leverage open source software, peer to peer collaboration methodologies, and agile development approaches to build their own products.

The origins of the “digital service” concept can be traced back to 2010 when the government of the United Kingdom began a website redesign project that turned into something much more: a rethinking of the very nature of government. Mike Bracken, co-founder of the U.K.’s Government Digital Services (GDS), articulated “government as a platform” in his 2014 PDF talk. GDS has gone on to become a vocal advocate of the open source way in government and is responsible for saving the UK Government over £1 billion a year since its inception in 2013.

The United States federal government got serious about starting a GDS-style entity in 2013 when the Obama administration realized that its hallmark legislative achievement, the Affordable Care Act, could be jeopardized by its inability to successfully launch the HealthCare.gov website by the time the legislation came into effect.

Once it became clear that the project was massively mismanaged, the administration assembled a crack team of technologists from inside and outside government to get the website up and stable. To achieve this goal, the team used many open source and agile development methodologies popular in startup culture. Ultimately they got the site launched, and many of the people involved went on to create and lead high-tech units in the government such as the U.S. Digital Service in the White House, and “18F” within the General Services Administration.

18F “collaborates with other agencies to fix technical problems, build products, and improve how government serves the public through technology.” Its process relies on open source and startup-centric principles of “human centered design, agile methods and open technology.”

This approach is very different than the “monolithic procurement” approach that usually happens within government where “large, complex, multi-year contracts” are drawn up between government agencies and large corporations. “According to the Standish Report from 2003-2012, 94 percent of government software projects over $10 million are either over budget, over time, or just don’t work,” via the 18F website.

Instead of monolithic procurement, 18F and other DSO advocate for in-house open source development and modular procurement, which is “a strategy that breaks up large, complex procurements into multiple, tightly-scoped projects to implement technology systems in successive, interoperable increments.” By pairing this with open source software development and meticulous documentation, 18F can share the innovations they develop for one agency with others, reducing costs for everyone involved and allowing anyone in the world to use and contribute code to their projects.

This approach has been highly successful. In less than four years, 18F has grown to nearly 200 staff and completed hundreds of projects for over 25 federal agencies that range from building public websites (like FEC.gov) to backend infrastructure (like Cloud.gov) and a myriad of products that help other government workers build fastermore accessible, and more secure technology products. They’ve been successful to the point where for-profit software industry groups lodged an official complaint that 18F was hurting their businesses because they were saving the federal government too much money.

The significance of 18F’s accomplishments, along with the clarity of their message about how to reform government, has gone almost entirely unnoticed by nearly everyone, except for a small but very online group of people who self-identify as “civic technologists.” This community consists mostly of people who work as technologists for private enterprise by day, and try to use their technical skills to more broadly help people by night. Rarely do these people actually work within government, and if they do, it’s rarer still for them to have the freedom and support within government to perform the type of work that 18F does.

While there are a number of federal entities that have adopted the DSO model such as Defense Digital Service, which applies 18F-style approaches across the Department of Defense, at the municipal level there are very few: San Francisco has a small digital services team, and the teams managing websites in Boston and Philadelphia have some DSO characteristics, but New York City Department of City Planning’s Planning Labs follows the 18F model most closely.

Planning Labs is a nine-month-old, three-person unit within DCP that isn’t shy about borrowing from 18F’s playbook. Its site is built with 18F code, its published principles are nearly identical, and its members’ outspoken support for open source as the path forward for government is just as loud.

In its short existence, its already launched a half-dozen products, each of which uses open source approaches to deliver a standardized product. Looking through its portfolio of products – from its zoning toolfacilities directory, tax lot viewer, and statistical mapping tool – it becomes clear that Labs isn’t simply building products, but instead organizing the city’s information in an open, standardized, and future-friendly way that will benefit New Yorkers for generations. It’s not hard to imagine these various systems being weaved together along with other open source solutions such as David Moore’s City Council tracking system Councilmatic to create a comprehensive city information system like SimCity, but real, and in real-time.

For Chris Whong, Planning Lab’s founder, NYC Planning Labs “is responding to the need to create more functional and accessible tools for planners, practitioners, and the general public to use and analyze data. With a smaller team, human-centered design, agile processes, and open source software, we are delivering tech products better, faster, and cheaper in-house.”

Whether one thinks government is good or bad, or somewhere in between, almost everyone agrees that it should work effectively, operate transparently, and if it’s going to provide services to the public, they should be of decent quality and at a reasonable costs. The capacity for government to deliver services, and the public’s desire to pay taxes to fund government agencies to provide them, is heavily dependent on the effectiveness of government agencies and the civil servants that work within them.

In an age of rapid private sector innovation, those agencies and civil servants will need to be able to leverage technology effectively if they want to keep up with their private sector counterparts. If they don’t, the public will want to privatize these services. It’s that simple.

The “do or die” nature of this moment can’t be overstressed enough. If DSOs like 18F and Planning Labs aren’t given the resources and flexibility they need, their members will become dejected and find happier homes in a private sector that values their talents.

Anyone who is passionate about good government, anyone who thinks the public sector is important and worth preserving, should be studying and supporting DSOs and the principles that they follow. If they aren’t the future of government, it’s possible nothing is. Such is the sentiment of Matt Brackin, the co-founder of the U.K.’s GSA, who recently tweeted: “I hoped the internet era would revitalise our state. It’s just exposed its bankruptcy.”

***
Devin Balkind is a technologists and nonprofit executive who works on civic technology projects in New York City through Sarapis Foundation and on humanitarian projects around the world through Sahana Software Foundation. He was a candidate for New York City Public Advocate in 2017. On Twitter @DevinBalkind.

Read the Article at the Source: For Government, It’s DSO or Die | Gotham Gazette

Today, we’re happy to announce the first open position on the new hiring page for the Technology Transformation Services (TTS). JoinTTS will be the new home for all TTS job postings, including open 18F jobs.

Read the Article at the Source: The Technology Transformation Services launches new job site

Besides 18F, TTS is also home to an acquisitions team, the TTS Front Office, an operations group, the Presidential Innovation Fellows program, and the Office of Products and Platforms, which operates all kinds of helpful services like USA.gov and FedRAMP. The new JoinTTS page has more details about all these offices, timelines for what to expect when applying to TTS, and information about the interview and security clearance process.

The TTS Talent Team is preparing additional open positions, but today we’re looking for four product managers to work at 18F.

As a Product Manager at 18F, you’ll lead cross-functional teams to deliver user-centered products using agile methodologies and modern software development practices while building capacity for product innovation in government. When you build products with a partner agency, you’ll coach them on modern product development practices so they’re set up for success in the long term.

If that sounds like you, head over to JoinTTS to learn more and apply. We’re accepting applications only until Monday, February 26 at 11:59 p.m. ET, so hurry! Make sure you don’t miss an open job post by following 18F on Twitter and subscribing to our newsletter.

Read the Article at the Source: The Technology Transformation Services launches new job site

The Plain Language Action and Information Network (PLAIN) is one of the longest-standing champions for great content and user experience in government. Since the 90s, this incredible community has shepherded the adoption of plain language in federal regulations and communications with the public. Last year, we were honored to partner with them to update and redesign plainlanguage.gov.

The new plainlanguage.gov home page.

Read the Article at the Source: A new home for the federal plain language community

As a volunteer-run organization, their old site was trapped in a legacy system that was hard for them to access and maintain. After an initial pitch, we were able to secure an incremental investment from the Technology Transformation Services’ 10x program, which supports experiments and early-stage investigations. We set out to explore how DigitalGov and TTS can support government-wide communities of practice. A small team from 18F worked closely with DigitalGov and PLAIN to redesign plainlanguage.gov, making it more modern and usable. We used existing tools including Federalist and the U.S. Web Design System to help complete the project in less than six months and make it easier to maintain over the long run.

Recently, we talked with Katherine Spivey, co-chair of PLAIN and coordinator of the plain language program at GSA, and Miriam Vincent, PLAIN’s web manager and an attorney at the Office of the Federal Register, about the redesign of plainlanguage.gov and how volunteers can get involved.

Interview

Before we talk about the new plainlanguage.gov, can you tell us a little bit about PLAIN, and what you do on a daily basis?

Katherine Spivey: We communicate the importance of plain language, how it can work, and how we do things. On a day-to-day basis, we respond to emails that are sometimes outside of what we do, and other times, folks are looking for resources or requesting training. We also maintain the plain language community and are working on getting more volunteers.

Miriam Vincent: We serve as a resource, and our volunteers are a resource, just as the website is. Our mission is to provide resources to agencies so they can use and understand plain language, so that’s what we try to do. We want to give agencies and individuals within agencies the information they need to change minds and make things clearer.

What’s it like to be a four-person volunteer team running a government-wide resource?

Katherine: Overwhelming! [Laughs.] What is surprising to me is the number of states, cities, and counties that come to us and say, “Can we join — can you come and teach us?” And the answer is no, but it’s interesting that that’s one of the needs. If there were seven of us, we might be able to do something there.

How can people get more involved if they’re interested in volunteering?

Katherine: What I would recommend is first joining the community. There are a number of open volunteer positions, and it’s true that you’d have to be a fed. We’re especially looking for community managers — people who make it a conscious activity to feed discussion questions to the list, post things from other lists, or ask for guidance.

Miriam: The other thing that we’d like to say is that it’s not just volunteers for something that we’re already doing. If somebody has an idea and wants to volunteer to start a new program or project, we’re more than happy to entertain suggestions for things we haven’t thought of or had the ability to do. Get involved with the list, and then send us an email and let us know who you are and what you’d like to do as a volunteer.

For folks who are less familiar, can you talk about a time that plain language has changed how an agency works or thinks about its work?

Katherine: I’m thinking about a recent thing where our internal IT department [at the General Services Administration] said, “We’re sending out these emails but they are confusing people.” [I asked:] Can you send this to people that it actually affects? Sometimes, just getting that kind of feedback is useful.

Miriam and I went up to the Office of Minority Health, and said: “You’re communicating with an audience that is very busy and they don’t have time to wade through all of this stuff. What do you need folks to know?” It had never occurred to them to think about what they need to communicate. You really need to clarify who’s your audience and what they need to know.

One of the most valuable things we do is maintain that senior officials list. If someone from the VA says, “I think plain language training would be helpful for my team,” we tell them to talk to the plain language contact at their agency and folks are often surprised that they’re even there. Some of what we do is connecting. People say, “Oh, I didn’t know my agency was already doing this.” In a small sense, that’s a success story for us.

What would be different if more people in government used plain language?

Katherine: I generally ask people: who wants more emails or phone calls? People look at me like I am crazy, but if you write emails more clearly, you will get fewer phone calls. We can’t say you will save money, or the plain language department will send you a check. But we can say it will it will make your life easier, and it will make your users’ lives easier. People will trust you more. You’ll have more time to do other things.

Miriam: If you say or present something in such a way that you don’t have another 5 or 10 emails coming back asking what it means, that’s huge. We have studies that prove that you can save agencies time and money — and then have time to do other important work that was previously spent answering emails and phone calls.

Katherine: Or answering the same question, which really bugs people.

Miriam: Being able to avoid that repetition would be a huge success.

For me, a success would be that agencies, and the individuals that work within agencies, understand that customer service from an agency perspective is not about making people happy — it’s about making sure that people understand that they have all of the information they need and can understand and use it.

With the mindset in this country on customer service, which is different than some other countries (it’s a culture), where the customer is always right and you have to go the extra mile, that mindset has filtered its way into the federal government to some extent.

The pushback I get from agencies is that if we tell people “no” in plain language, they are just going to get upset. For me, success would be that it’s a given that if you tell someone no they are going to get upset, but if you tell them no in such a way that they understand it then everyone can focus on the reason why the answer was no. Once you understand that it’s a no, then you can move forward and look at next steps. If you don’t understand it’s a no, then you can’t move forward.

Plain language is crucial for customer service. But it’s not that customer service means you have to say yes or disguise the fact that you’re saying no. Good customer service from the federal government, at least from my perspective, is: it doesn’t matter what the answer is, we need to make sure that we are communicating the answer clearly, so people know what the next step is instead of focusing on the answer. We’re focused on making sure that the answer is clear and then dealing with the substance of the issue.

In terms of the redesign, what were some of the biggest issues you were facing going into the process?

Miriam: The biggest issue was being able to maintain the website so that it stayed relevant. Because we are not a physical thing, and we don’t have an infrastructure or budget, we have to rely on other agencies.

When the Federal Aviation Administration (FAA) agreed to host the site, they took over paying for the domain name, database resources, server access, a lot of things, and they also had someone who was working there at a high level that was instrumental at forcing some support through, which was wonderful. Flash ahead 10-to-12 years later, and we don’t have anyone at the FAA that is a champion of the website, and no one at PLAIN is actually employed at FAA, and it effectively meant we were locked out of the site. So we weren’t able to get in and do any maintenance whatsoever. We couldn’t fix typos, or change anything that was out of date.

Did you learn anything along the way that surprised you?

Katherine: They were all pleasant surprises. You made this so easy for us. You really did a ton of work to make that happen. I think that I had forgotten how much stuff we have on the website, and I’d also forgotten what we were going to do with those before-and-after examples because people really like those.

Miriam: I wasn’t surprised at the amount of content, because I hand-coded the whole thing back in 2004. I’m aware of the amount of content that we had, and how buried it was. But trying to figure out prioritizing what to fix first, and to make sure it was all on the site when it went live was a bit more challenging.

As Katherine said, there are some things on the site that I use all the time, and other things people use all the time that I don’t look at. It’s easy to say, “That’s historical stuff, and we can’t get rid of it.” But if we get rid of it, it’s gone. And people actually use that. We’ll get questions from folks teaching a class, and they want to refer to the website. I’m thrilled that it’s useful. I’m happy that what we have is there. I think that the biggest takeaway is that we’re probably going to keep adding to the site and tweaking some of the content, but we’re probably not going to be removing a lot of things from the site because it continues to be useful to at least a subset of people. As long as it’s useful, it needs to stay up, even if we aren’t using it.

Katherine: That’s another useful reminder—that we’re not necessarily the audience.

Was there anything that you thought would be a problem that turned out to be not so bad?

Miriam: The fact that you did all of the conversion [to Markdown and HTML], was a huge gift to us and a great surprise. Until this website and this iteration of plainlanguage.gov, all of the coding and design, everything, was done by plain language volunteers. And I’ve basically been working on the website since 2000. So the fact that I didn’t actually have to do it — I just said, “Here, I’ll download it for you,” and you just did it — that was wonderful.

Katherine: That was fantastic. I haven’t dealt with domain names, and the fact that it happened pretty magically was super cool. It just happened! Hot diggity!

I know some people coming to Federalist are working groups without a budget. So whatever we can do to say how easy it was — I don’t want to lead people down the wrong path, but we certainly want to say what a great job you did since we are hearing nothing but compliments.

The site is full of fantastic resources, guidelines, and examples. Is there anything specific that you’re hoping people find and share with their colleagues?

Katherine: I would say mostly the guidelines and the before-and-after examples. And also the humor, because plain language is not a hugely funny topic.

Miriam: The quotations, and we haven’t updated them, so we don’t have a lot of recent quotes about plain language, but we do have a number of historical quotes. It’s interesting to look and see how much communicating clearly has been a part of our history. Relationships fall apart all of the time because people aren’t communicating with each other. It’s hard and even if you’re good at it, it’s hard! It’ll get easier, but it’s still going to be a fair amount of work, because communication is work.

Thank you so much for talking with us today! It was an honor to work with you on this project. Is there anything else you want to share with readers?

Miriam: There is so much on the site, and there has been so much. I’m familiar with the volume, but I’m not that familiar with the individual details of every page. If we’re missing something or you can’t find something that used to be on the site, please let us know.

We’re very grateful for how the website has come together, the look and feel, and all of the work you did to make it what it is.

Read the Article at the Source: A new home for the federal plain language community

 

When our apps need a web map, we turn to MapboxGL, a cutting-edge open source mapping library that allows us to build fast, beautiful maps. Not too long after we started tinkering with MapboxGL, we were faced with the need to let the user draw polygons. Enter mapbox-gl-draw, an add-on to MapboxGL that gives you some simple draw controls, renders shapes on the screen as the user draws a point, line, or polygon, and gives you some nice event hooks.

Read the Article at the Source: Building a custom draw mode for mapbox-gl-draw

You can see mapbox-gl-draw in action in ZoLa’s measurement tool:

In this case, we’re still using the out-of-the-box functionality of the draw tools but have added a custom control to choose between line and polygon mode, and a UI for displaying the measurement (and switching units!).

We recently encountered a need to have the user select geometries on a web map by radius from a center point. Mapbox-gl-draw does not include a circle-drawing mode.

One approach would be to have the user select a center point, and then enter a radius using a text input, but it would be better if the user could see the circle they are defining as they define it, just like they can with the polygon and line tools.

What’s a radius, really? Well, it’s a line, and mapbox-gl-draw already has a line tool. So, what we need to do is modify the line tool with the following rules:

The user’s first click is the center pointAs the user moves the pointer, render both the line between the center point and the pointer, and the circle that they are defining.The user’s second click always ends the drawing.When drawing is complete, the resulting GeoJSON is a Point feature for the center point, with a radius property.

Here’s what it looks like in our app:

Using the custom radius mode to select census tracts

How we built it

After some snooping, we discovered that mapbox-gl-draw allows you to define custom drawing modes, and has a nice markdown file all about it. We didn’t want to start from scratch, so we decided to hijack the Line mode.

const draw = new MapboxDraw({ displayControlsDefault: false, styles: drawStyles, modes: Object.assign({ draw_radius: RadiusMode, }, MapboxDraw.modes),});

We instantiate mapbox-gl-draw using a modes property in the options. RadiusMode is our new custom mode which is really just the built-in line mode that’s been modified to meet our needs.

To create RadiusMode, we started with importing the existing line tool.

const RadiusMode = MapboxDraw.modes.draw_line_string;

Then we define new functions for some of the line tool’s event listeners, in order to achieve the rules described above.

Rule #1 works out of the box: the first click will set the first vertex of the line.

For rule #2, we get half of the functionality for free because the line tool already draws the line between the first vertex and the pointer. To draw the circle, we actually end up drawing a circle-like polygon.

RadiusMode.toDisplayFeatures() is called with each move of the mouse, and fires display() for each GeoJSON feature that should be displayed in real time. The existing line tool displays the vertices and the line, so we added one more to display the circle-like polygon.

const circleFeature = createGeoJSONCircle(center, radiusInKm, state.line.id);display(circleFeature);

Creating the circle-like polygon was simple using an algorithm we found in this Stack Overflow post. Given a center point and radius in kilometers, it creates a 64-point polygon that resembles a circle.

function createGeoJSONCircle(center, radiusInKm, parentId, points = 64) { const coords = { latitude: center[1], longitude: center[0], };const km = radiusInKm;const ret = []; const distanceX = km / (111.320 * Math.cos((coords.latitude * Math.PI) / 180)); const distanceY = km / 110.574;let theta; let x; let y; for (let i = 0; i < points; i += 1) { theta = (i / points) * (2 * Math.PI); x = distanceX * Math.cos(theta); y = distanceY * Math.sin(theta);ret.push([coords.longitude + x, coords.latitude + y]); } ret.push(ret[0]);return { type: ‘Feature’, geometry: { type: ‘Polygon’, coordinates: [ret], }, properties: { parent: parentId, }, };}

We had originally attempted to use a MapboxGL circle marker, but by using a circle-like polygon the feature still remains accurate even if the map is pitched!

For the best user experience when drawing a radius, we also added a label layer to the map showing the in-progress radius in both standard and metric formats. We borrowed the same logic for switching from meters to kilometers, and feet to miles as was used in ZoLa’s drawing tool.

The last step was to hijack RadiusMode.clickAnywhere() to force drawing to stop after the second click (rule #3 above). clickAnywhere(), as the name suggests, is called when the user clicks anywhere after drawing begins.

RadiusMode.clickAnywhere = function(state, e) { // this ends the drawing after the user creates a second point, triggering this.onStop if (state.currentVertexPosition === 1) { state.line.addCoordinate(0, e.lngLat.lng, e.lngLat.lat); return this.changeMode(‘simple_select’, { featureIds: [state.line.id] }); }…// default click handling remains the same, adding the vertex to the state.}

There’s a bit more to it, but those are the highlights. In our app, we use the GeoJSON Point feature created by the drawing tools to do an ST_Dwithin() query in PostGIS, selecting polygons that are within the specified distance of the center point.

You can inspect the full RadiusMode module here, and see it in action once our app launches (yes, we’ll update this with a link!). We hope this will be a useful starting point for anyone thinking of extending a mapbox-gl-draw mode or writing their own.

Happy hacking!

Building a custom draw mode for mapbox-gl-draw was originally published in nycplanninglabs on Medium, where people are continuing the conversation by highlighting and responding to this story.

 

Sarapis Launches DSO News

Digital Service Organizations, or DSOs, are units, organizations and teams within government institutions that use open source and agile methodologies to drive change by serving other organizations and agencies within government.

We consider them the “tip of the spear” when it comes to government reform, so we’ve put together this humble website to serve the people making DSO’s function.

We hope you enjoy it!

STILL NOT SURE WHAT TO DO?

We are glad that you preferred to contact us. Please fill our short form and one of our friendly team members will contact you back.

Form is not available. Please visit our contact page.
X
CONTACT US