We met with an Oakland librarian this morning to talk about editing for the web. She highlighted a few features of common content management systems that tech people take for granted and library staff don’t use or understand.

Oakland DFD Kickoff, June 12

Last week, team Digital Front Door held our inaugural kickoff meeting at City Hall. It was our first opportunity to meet the steering committee for the project, and we brought barely enough donuts for the 24 staff who showed up from across city departments. We had representatives from human resources, the library, the mayor’s office, the police department, parks, public works, and others. The IT department brought seven people to the meeting and participated strongly. It was a great first exchange of real needs and concerns around the project to re-work Oakland’s website redesign process. We’re grateful to Karen Boyd and Mai-Ling Garcia at the City Administrator’s Office for running the project from Oakland’s side.

We’ve been able to convene this steering group thanks to the passage of City Resolution 13-0506 (Staff Report), “A Professional Services Agreement To Code For America For Phase I And An Option To Extend The Agreement For Phase II Of The ‘Digital Front Door’ Project Which Would Modernize Oakland’s Digital Presence And Service Delivery.” The first phase of the project focuses on research and rapid prototyping. A large focus of the kickoff was to meet the leaders who will introduce us to the staff and residents we’ll need to interview. Our goal is a representative cross-section, with all of the staff responsible for web pages, and as many as 400 residents from around the city.

At CfA, we’re used to frequent check-ins on project status. We’re doing daily check-ins each morning with our partners in the City Administrator’s office, and expecting once every few weeks with the larger project steering committee. Some of the feedback we heard yesterday made us realize that staff thought they might only be consulted once: members of the IT department asked for meetings like yesterday’s once or twice per year, in the context of saying how valuable the meeting was. A very different time-scale from what we’re accustomed to. We know how busy all the city staff are, but we hope to find lightweight ways to keep the whole steering group in close touch.

Another theme that emerged was the need for continuity with existing efforts. Staff who worked on the previous redesign are justifiably proud of what a big step forward it was. We need to bring their hard-won institutional knowledge into the process we’re embarking on, while still inviting them to work in new ways. In short, it would be a mistake for us treat this as a burn-it-down, ground-up redesign. When we use a phrase like “redesign the redesign,” what we really mean is to perform the work in many incremental steps instead of one giant one, in hopes that the result will serve the city’s needs for longer.

A few other consistent ideas came up. The need for staff support for technical training and content editing; safeguards like a staging environment so staff can test changes before publishing. A strong desire to address citizen needs. The clustering of users into staff, resident, media, and (unexpectedly) city IT vendors. The simple idea of excellent site search. Responsive design and usable navigation. An experience that looks like Oakland.

These ideas begin to rough in a sketch of the goals and principles that will guide this project. We will refine them as we talk with more city staff and residents in the coming months.

A few weeks ago, we had the honor of presenting our project to Oakland City Council along with Karen Boyd of the City Administrator’s Office. Council had excellent questions about the sustainability of work developed during the Digital Front Door project and also about whether the end site will be more than pretty and truly usable by residents. In the end, the resolution passed with six in favor and one abstaining.

Why the city staff experience matters

It’s definitely possible to achieve great things with limited tools, given time and passion. Plenty of major leaguers started out with milk carton baseball gloves, and plenty of beautiful buildings were constructed when hand tools were all that existed. But is it possible to build a great website using a system that heavily restricts what you can do, for an audience you don’t have direct contact with, and as an extra job requirement not described when you were hired? It’s might be technically possible, but it’s nowhere close to reasonable to expect.

For most city employees, the website is a burden of one kind or another. For administrative staff, it’s one more channel to publish information on; for IT staff, it’s a boringly non-technical system with demanding non-technical users. Departments that are already managing counters, inbound phone lines, brochures, and paper forms see it as a painful and unfamiliar addition. On top of these realities, (never mind the budget environment of the last decade) it’s extremely unusual for municipal staff responsible for web pages to have access to useful analytics or qualitative feedback on the impact of their work. And the enterprise-grade web publishing tools provided to them fall far short of the types of experiences the modern commercial web has shown has shown to be possible: they are seldom humane, flexible, or simple. You could say that this shouldn’t matter for employees paid to do a job, but all of these factors join together to create a situation where it requires heroic measures to do the job decently, let alone at a high level of creativity and responsiveness. Very few people who don’t wear capes can sustain a heroic level of energy every single day, especially without any feedback.

Fundamentally, a modern website is a channel for local governments to do business with and for their citizens. Using its capabilities effectively requires continual watching, experimenting, and minor innovations. The nature of the web makes it uniquely suited to quick changes, frequent upgrades, and experiments in service delivery. Staff who find their web tools easy and rewarding to use will be able to take advantage of these possibilities; those who find their tools unresponsive and confusing can’t be blamed for focusing their efforts elsewhere. In some ways, so far so good - except that citizens are moving to the desktop and mobile web in ever-increasing numbers. If we can’t provide staff with web tools good enough that they prefer to use them, a misalignment between citizen habits and city practices will deepen. If we can do that, however (providing truly good tools) we can expect municipal websites to evolve as really useful primary interfaces for participation and governance in the 21st century.

Working Differently With Vendors

A website built by city employees who start with a clear picture of what they and their users need, and who take care of the non-specialist tasks themselves, collaborating with vendors who support them with extra skills and hands, will be much more sustainable than one handed off to a vendor as a single contract. This approach is similar to how most people would treat a home remodel project: the owners might not be experts in construction, but they would be confident in stating their needs, and comfortable with where decisions must be outsourced (walls need to meet building codes, for example). Further, there are certain basic assumptions about a house and how it serves its inhabitants and its neighborhood that support this comfort level. This extends to the components of a house - aside from experimental architecture projects, everyone knows what the main entrance to a house is supposed to do, so people without deep skills in construction still feel qualified to evaluate whether a front door is working properly.

But when city staff without deep expertise in web development are asked to source help for a website redesign, they behave differently. Some this has to do with the undefined role of a municipal website in citizen-government interaction. But some of it is due to a lack of confidence in staff’s ability to play the homeowner role. This is too bad, because the people who interact with and publish information for citizens online do have the requisite knowledge to manage a better, more sustainable redesign. We believe that reframing the vendor engagement process to work like a home remodel will help a lot.

For starters, being able to articulate not just the goal of a redesign but how each component of the website will contribute, allows for evaluating vendors in a different way. This doesn’t need to be at a deep technical level - the house analogy still works. I may not know the technical terms for how to reinforce a wall near a garage door opening, but I know I want my house earthquake safe and built to code. That’s enough to start a conversation with a skilled contractor. I may need to educate myself about different kinds of kitchen floors, but I know my kitchen activities and what my family’s budget looks like. I can level up, get advice if needed, and make a decision with confidence. Most homeowners wouldn’t automatically choose the same vendor for both earthquake reinforcements and flooring, and we don’t think cities should be quick to consider a vendor offering both visual design and CMS integration as an advantage.

Constructing a more nuanced list of what the website needs to do is a critical first step to engaging with vendors differently. A short list of needs for a hypothetical city website redesign might look like this:

  • the navigation & search should make it easy to find where you can do a task (this should be a priority over finding departments)

  • the language should be readable to native speakers of 3 languages at a 5th grade level

  • the visual design should convey a sense of place (what IS the sense of place of the city?)

  • all designs need to work well on any size screen, with priority given to small screens used by mobile-only internet users.

  • the information design should present chunks in an order that is logical *to users*

  • the homepage should prioritize showing things that are perpetually requested

  • transactions need to work similarly across the site; a design for those needs to prioritize easy flow for low literacy citizens

  • the site must be easy for non-technical city staff to edit with minimal training

  • IT should need to do only traditional IT tasks like hosting, security, etc. - it should not require a request to IT to change a page design.

Several of these tasks (determining core navigation elements, structuring information on a web page, identifying the most requested things to show on the homepage) are best done by those closest to the work, i.e. internal staff - even if they are not web experts. Several of the others can be clustered into different capabilities so that the city can then create smaller, more focused engagements with firms offering very deep expertise. Creating a responsive design that conveys a sense of place (grouping two of the above goals) would match the skill sets of many modern design firms. Many of those firms could deliver the design as front-end code in the language of the city’s choice. Providing a publishing system that works in multiple languages, requires minimal training and minimal IT support would suit a very different vendor, but those vendors also exist. In either case, it is likely to be less expensive and better for the outcome to hire two specialists and work closely with them, than to engage a large vendor that offers both services but is only expert in one (or neither).

Doing things this way means committing substantial staff time during the vendor engagement process and also beyond - a high level of communication and interaction needs to continue throughout the project, with the buyer taking as much responsibility as the vendor in ensuring that what’s delivered is appropriate. Close collaboration minimizes surprises and lost time, but more importantly it ensures that the internal team will be familiar with what they are getting and will be in a position to sustain a living website once the vendor engagements end. And that should be the real goal of any redesign.

Where are city governments in a user’s journey?

One of the first discussion points we tend to go over when we’re talking with cities about their web presences is the lack of clarity they have about how services are being used and consumed by the people in their community.  

Many have analytics packages recording usage, search terms, journeys and such, but they’re locked away in the reporting tools that these systems provide that are often difficult to read, understand and access. Alternatively, they are provided periodic reports in the form of graphs and charts, often many months after the interactions being returned occurred. There’s little opportunity for those that produce and manage civic content and services to get immediate feedback on how they’re doing.

It’s difficult to show the benefit of treating digital services as part of a person’s job if they can’t easily see the effect their work has on the world, nor the place their services lives in the larger journey a citizen has while navigating city hall.

For this reason, we’re researching the effect it may have to pull analytic information directly into the place that city officials are producing their content.

We’ve been knocking up an MVP CMS, we’ve affectionately been calling Bizarro, to try out how these interactions might look and be presented, and then do some initial user testing to see if this is an idea that has legs.

There’s a lot of discussion around the web about increasing engagement from citizens with city hall, but it’s a two-way street and we need to work on ways to inspire city hall’s employees to get more involved with the modern, approachable ways that citizens want to interact with them and give them greater transparency.  As my former colleagues would say, we want city employees to have internal tools for their digital services that are so good that they prefer to use them.

We want to provide those inside city hall with the following abilities, to help them make better decisions about their content and services:

Increase awareness of how their individual piece of content, or service, affects citizens

  • Qualitative data from feedback, contact forms etc.

Provide a feedback loop to show how recent changes, improvements or removals have affected citizens

  • How long did people spend on the content, which parts did they focus on

Discover where their content fits in with the larger city hall journey

  • Where do users go next and where did they funnel in from

  • How did they find the content (internal search, Google, direct etc.)

  • Is there contact in direct conflict with other information or services, or does it support other pieces

We’d also want to have the same information presented back out to end users who want to know more about how their city is performing - in a similar approach to RecordTrac - perhaps this should simply be the same system in a read-only mode.

For fun, we’re also starting a look at giving cities information radiators - high visibility live statistics about their website and services.  GDS’s Edd Sowden made an excellent live dashboard, showing the current usage of their website that is shown prominently throughout their office - we’re forking his work to create something similar that we can give to cities to immediately get the analytics they already have out in the open in high foot-traffic areas.

Content Management Is Overdue For A Rethink

When we talk to cities, it’s common to hear how unhappy they are with their content management options. Web publishing technology is permanently frozen in 1997, and for many “CMS” is a trigger word. And yet, there are innovative new approaches to content management bubbling up around the web. How might we connect the left-for-dead world of institutional content technology with hackers’ and designers’ newfound interest in publishing?

State Of The CMS

Content management systems were once a highly-active area of open source software development, with now-ubiquitous products like Drupal and Wordpress emerging in the late 1990s and early 2000s. Today, a decade’s worth of detritus has built up around commercial CMS products. We’ve seen demonstrations of IT-supplied content management systems that make the pain and cost of simple edits unbearable for communications employees. No one likes their CMS, so no one wants to use it. The website and by extension the visiting public suffers as a result.

New Developments

In the past few years, we’ve seen an explosion in new content-writing tools, all of them focused on ease of use and simplicity.

  • Markdown syntax has matured from simple blog and code comments to a complete system for generating written words on the web. The UK Government Digital Service has developed Govspeak, an adaptation of Markdown for simple government publishing.
  • Jekyll leads a small pack of static-site generators, and enables the simple and free Github Pages hosting model. Tools like Prose.io have made it easier to edit Jekyll sites hosted on Github in modern browsers. Code for America’s own Jekit tool has made the previewing of complex Jekyll sites fast and easy, and Development Seed have argued that static sites are a viable alternative to bad old content management systems. Other products have stepped in to focus simple publishing: Metalsmith.io makes text pipelines simple for programmers, while Pancake.io makes it easy to publish directly from Dropbox.
  • On the high end, the Medium publishing platform has paid special attention to its writing tools, evoking high praise from Slate journalist Matthew Yglesias, who was “blown away by the quality of the product as a writing tool.” The Guardian Newspaper has produced their own digital text editor called Scribe, and GOV.UK is run from a home-built tool called Publisher. With content UI, bad usability means higher cost of use. Important things don’t get written.

What We’re Doing

Reading between the lines, we believe there is space for new technical work in content publishing. The CMS is due for a re-think to knock it off balance and back into a place of new work. We’re developing a sketch of what this might look like, based on our successful use of Jekyll, Github, and similar tools for the Code for America website. With a static site generator like Jekyll, we can avoid the complexity of a database and replace it with simple files, more flexible deployment methods, and support for a wider variety of easy-to-understand server environments. With a revision control system like Git, we gain the power of infinite undo and a linkable history of an entire site. With a code-sharing service like Github, we can expose content in progress to a community of participants and accept input from the general public via the magic of Pull Requests.

All these ideas can work together to create a system that’s a shared space for writers, participants, and the public.

What is the Digital Front Door?

“City government websites are usually about the City, but they should be the City, doing the people’s business online.”
—Cyd Harrell

Stroll up to a resident of any city in the US and ask them how to get to city hall, and odds are good they’ll point you in the right direction. Most citizens can tell you not just where their city hall is but also why they would go there: to take care of those parts of life that are regulatory, communal, and otherwise associated with being a city resident.

The same can’t be said for city websites. There’s no equivalent to this shared understanding about city hall in the digital space. It’s 2014—a city can’t not have a website. What the website is for, exactly, is usually a lot less clear.

Some cities use their websites to promote the latest news from inside the administration, some have information about where citizens can go and who to talk to in order to accomplish city-related tasks, and some even let citizens perform basic city services online, like paying parking tickets. But there’s no consistency, which means no clear sense of purpose in the minds of citizens. If city hall is the front door to the city, welcoming you to everything the city has to offer, the online version—the digital front door—is boarded up, off its hinges, covered in flyers, and even occasionally missing completely.

This inconsistency has kept city sites from evolving alongside the rest of the Web. You can’t move forward when you don’t know which direction to go. As a result, city websites often lag significantly behind commercial online sites. This disparity comes with a price. When a citizen can easily buy an item on Amazon.com yet struggles to find a city official or pay a utility bill online, it furthers their belief that government can’t deliver.

This can’t be fixed with a simple website redesign. Many cities actually redesign their websites with some frequency, but don’t address the root cause of the disparity. This is why so many of them need to get redesigned just a few years later. What appears on the site is the end result of a mixture of internal expectations, processes, and decision-making. These are what need to change.

To start, cities need to treat digital service delivery as a core component of how the city operates, and their websites as the primary channel for interacting with constituents. Many commercial services can now be done more efficiently and pleasantly online. Citizens expect no less from city services, yet many cities treat their sites as if they were simply marketing brochures. Cities need to commit consistent resources to building and maintaining their digital presence and should make the maintenance of digital services a major part of the daily workflow of all city employees, not just the IT or technology team.

We recognize that this prospect is daunting, and represents a major shift for many cities in how they deliver services. We want to help. We’re proposing to develop a new “Digital Front Door” for US cities: an open-source suite of code, documentation, and practices that cities can use to modernize their online presence. Inspired by the success of the UK’s Government Digital Service in centralizing a wide range of information and services at GOV.UK, the Digital Front Door will allow any city in the US to create a default single entry point for residents.

We’ll work with a select set of cities in the US to see them through these changes, with the intent to make the tools and processes developed freely available to any city. Our approach will be one of mentorship, oversight, co-development, and mutual learning, working to develop the people, the skills, and the services necessary to support and extend their sites. Our hope is that we’ll be able to document how a modern technical engagement for cities should work, in the process creating a template that any city can use to do the same.

Our scope will not be limited to only technical work, but will take on a wide range of challenges critical to re-architecting the role of the website within city government. This includes developing better approaches to technology contracting and procurement; instilling a commitment to agile development methodologies and user experience design principles; finding ways to improve citizen engagement before, during, and after the site launch; and expanding the technological literacy of all city employees so that they support and benefit from the site redesign.

Through programs like the CfA Peer Network and the citizen-led Brigades that have sprung up in recent years, we’ve seen that individuals inside and outside city hall have a huge interest in being a part of this shift. We want to build a system that can channel this effort, harnessing the desire of city employees and invested citizens to make their site, and their city, as good as it can be.

Goals for the Digital Front Door Project

We put together a list of nine principles for cities that want to launch a Digital Front Door. Every city that launches one agrees to:


1. Embrace digital services as central to governing

  • Government services should be “digital by default,” available to us on the mainstream platforms and technologies we already use.  
  • Services should be useful, accessible, and add value to our lives.

  • Government should do more than broadcast out. Tools should make room for interaction, feedback, and citizen participation.

2. Design with empathy, establish trust

  • Government service design should reflect a respect for our time, dignity, and abilities.

  • When the act of renewing a driver’s license, filing a request, or getting a business license is pleasant, citizens begin to trust and appreciate government.

  • Services should be compelling enough that citizens prefer to use them.

3. Serve everyone

  • Government services should be designed to reach as many citizens as possible regardless of income, location, language, or access to technology.

  • Government employees should get out of the building, test assumptions with real citizens, and tweak service design to improve it on a regular basis.

4. Encourage citizen participation

  • Governments and citizens should share in decision-making and service design.

  • Services should be built to anticipate participation from employees and citizens in the design and development process.

5. Be transparent and accountable

  • Let citizens and staff see and support what’s going on in government, whether it’s purchasing data, viewing open source code, or accessing open data portals.

  • Governments should be clear on the goals of a service and identify areas that can be measured, displayed, and improved on by employees and the public.

6. Build for flexibility, welcome change

  • Online services are an ongoing investment that require attention and modification over time.

  • Government services should be launched as evolving pilot projects rather than one-time massive monoliths.

  • Cities should invest in ongoing research, maintenance, and development and should have the internal support to push regular technology upgrades.

7. Create better processes and policies

  • The best government technologies should be easy-to-use and useful in a city employee’s regular work routine.

  • Government technology should reduce overall workload and increase the efficiency of city employees.

  • City policies should support the creation and deployment of better online services.

8. Unlock the capabilities of government employees

  • Governments should expect city employees to tweak and improve on city services.

  • Innovation, technology maintenance, and service design should be a responsibility of all employees, rather than the realm of one group or department.

9. Get value for tax dollars

  • Whether through short-term trials or pilot programs, no system or vendor solution should be deployed en masse without evidence of success.

  • When investing in technology, cities should consider their internal skills and ability to maintain and upgrade that technology in the future.

  • Governments should reduce barriers to the contracting process and encourage greater competition amongst vendors in order to increase options and drive down the cost of technology.

the data that isn’t available

As we work on foundational research for the DFD project, we’re trying to conserve staff effort and rely on publicly available/accepted information where possible. One thing we expected we’d be able to find easily was statistics on smartphone adoption and other internet access questions by city, or even by area within cities. But as far as we can tell, this data hasn’t been collected by anyone at the local level; the excellent Pew Internet and American Life Project collects it nationally three times a year, but with too small a sample size to make local inferences. Scarborough Research tracks it for certain markets, but not for the specific ones we are looking for. Local organizations have not collected it in the last 5 years, at least as far as we can find out.

So, we’ll be faced with either estimating the state of adoption from national numbers, or doing some kind of very rough estimation based on minimal observation on the ground. There are some indicators, like this new report from the Knight Foundation, that the nature of the digital divide has changed recently; we’ll take what we can find, but for now we have to acknowledge that we’ll be making some key decisions with less information than we would like.