Planning Your App: Phase2's Process for Getting Started

Posted Jun 16, 2011 // 2 comments

These days, it’s hard for us to walk across a conference lobby or leave a meeting without someone saying "I have a great idea for an App for OpenPublic." A lot of people are thinking about ideas for Apps or translating an existing Feature into an App. For those of you thinking about creating an App, we want to lay out the internal process we use at Phase2 as a suggested starting point for your own App.

Technically, creating an App for OpenPublic actually follows a very similar process to creating modules for Drupal. The difference is that apps are Features-based and Kit Compliant and often bundle together configuration forms, demo content, and other functionality to ensure that they’re simple to implement with a single click. All this means that the functionality of an App has to be very specific–Apps are best used to solve single, well-defined problems, not to provide frameworks for development or wide-ranging functionality to the distribution.

When you’re trying to create a concise solution to a specific problem, some planning is required. Our planning process has four parts, which we recommend for anyone creating an App:

• Identify the specific audience
• Identify a specific problem
• Identify a concise solution
• Identify a plan of attack

1. Identify the specific audience

To begin, we think about the exact problem we’re trying to solve and who we’re trying to solve it for. Does it solve a problem for administrators or staff? Is it for a non-profit, local, state, or federal organization? Not every app is for every OpenPublic user–if it was, it would be a better fit for OpenPublic’s core installation. So, the first thing to do is to understand the person who will be using it. This includes both the people who will be implementing the app technically and those who will be using it on a day-to-day basis. If it will be used to regularly add content to a site, who will be the person using it? What is their level of knowledge of Drupal, of CMS, and of your app’s specific area of knowledge?

2. Identify a specific problem

Many of our ideas for Apps come from active projects, and the process of "solving a specific problem" is built into our solutions analysis here at Phase2. However, as we look toward more community-generated Apps, it will be important for all of us to engage in more community-generated solutions to the business problems emerging within the group.

Now that we’re launching the community site at community.openpublicapp.com, we’ll all be able to use its features like a documentation wiki and Ideation to help inspire and review ideas.

At this point, it can be useful to look at existing apps and to engage the community to see how the idea fits into the larger picture, and if the App really meets a need in the community.

One way to do this is to take a page from traditional product design, and take a look at existing sites to see how the problem is being solved now:

• How is the data being published?
• What workarounds are people using?
• What third parties are engaged in this solution?
• What’s missing from the current solutions?
• Which steps could be reduced or removed to make the process easier?

These questions can help build a clear understanding of the problem you’re solving. At this point at Phase2, if our team can express the core use case for the App in a one-minute "elevator pitch" tailored for our target audience, we know that we’re on to something.

3. Identify a concise solution

Once we’ve settled on what we’re building and written the requirements we need, we start considering the solution. We start by looking at what we already have and asking ourselves: Is there an existing module that could be used for this App? Have we built this solution for a site before?

Then we look at the solution’s main question: "what is the simplest and most concise way to solve this problem for this audience?" Often, there is more than one way to solve a problem, so understanding what the potential solution set is, and which solution solves the question best is key.

This is the point in the process when we find that it’s helpful to return to the core elevator pitch and user we identified before. In considering the solution, we don’t just consider the app’s main module or function. We instead use a short checklist that considers the whole app’s "experience" for our user:

• Does our solution address the exact problem we identified?
• Does our solution solve any other problems that need to be stripped out or broken up into two or more apps?
• Can our solution be executed technically?

Our goal is to identify the enhancements that will make our App useable and easy to explore. If the solution we see in front of us is as concise and specific as the audience and the problem we’ve identified, we’re on our way to a great app.

4. Create a plan of attack

So, the audience is there. The problem is clear. The solution in fully formed in your mind. Ready to go build? Hang on.

Before you start building, we’d like to ask you to turn back to the community first. Before you build anything, make sure that this solution, for this audience, doesn’t yet exist. If it does, and you have ways to make it better, consider contacting the App’s maintainer to add your enhancements. Remember, part of the reason behind OpenPublic’s Apps structure is to reduce inefficiencies and encourage collaboration in the public sector.

At Phase2, that often means engaging one of our excellent partners. For the Project Mapper app, Development Seed’s outstanding MapBox functionality provided the specific solution necessary for those looking for a way to geolocate information about their organization’s projects. We’d never have considered building our own mapping app–Development Seed already had a much more elegant solution, and all it took was a little collaboration.

There are a lot of ways to create your solution. Start with a few bits of research to see if you can cut down your development time:

• Are there existing community-contributed modules that I could use to build this app?
• Are there other firms or teams considering a similar solution with whom I should collaborate?
• Is there anyone else I need to help effectively build this technical solution?
• Are there third party service providers who I might engage here?

From here, you can build a plan of attack that includes collaboration, partnership, and development.

There is more to come for the OpenPublic community and App Store, but we’re seeing so many good ideas already that we wanted to share our process for going from idea to App. We think OpenGovernment and Public Sector Transparency is a really exciting space for developers and designers to think about, and we can’t wait to see the solutions people are working on.