Practical guide to building apps

Editor's Notes

• #2: \n
• #3: What do we mean when we are talking about Apps? We could mean just about anything in today’s app centric world. Apps can address any platform. Solving problems in government with open source allows for this sharing and collaboration at any level. Our expertise is at the web level and building reusable efficient solution in Drupal and distributions targeted for industry, but we were doing these things in Java and C/C++ long before today. \n
• #4: This is probably the single greatest example of apps, the iPhone. There are now over 350k apps for the iOS platform. Apple made finding, installing, managing and using apps easy for even the most technically inept.\n
• #5: Apps for Android\n
• #6: App Exchange for salesforce.com\n
• #7: Apps for Facebook\n
• #8: Even to Apps.gov. Vivek Kyundra’s federal government IT strategy focused on Cloud Computing, Apps and Open Source.\n
• #9: So when talking about apps in government, we are talking about tools that are quick and easy to locate, develop, procure or use. Quick and easy is such a key point to Apps essence.\n\nThe apps ecosystem makes it not only easy to use, but also easy to contribute.\n
• #10: Government is the perfect environment for this open source sharing and collaboration on solutions, and all of us can relate as tax payers. Taxpayer money building solutions once and seeing the benefits of it again and again. Open Source and Government could be the same things. This sharing and collaboration can happen across city, county, state boundaries, across federal agencies, and in the grander scale to some degree it *could* happen across national boundaries too.\n\nThe basic idea here is developing these tools, these apps, that solve specific problems and open those tools up to a wider audience for others to use.\n\n\n
• #11: There are quite a few ways that this collaboration in Open Government Apps can happen. Any place that fosters a community and allows collaboration.\n\nApps.gov make it easy to procure these utilities/utilities.\n\nAny agency/entity that produces something to share, can publish it on a site like github or the like. The DoD has a portal called forge.mil. Government employees can contribute to open source projects that are already in existence like Drupal or Node. Really any open source project of any kind.\n\nAs such we are building support for Apps in OpenPublic to allow a mechanism for discovering and distributing reusable functionality across federal and state govern2ment.\n
• #12: Drupal offers many ways to share the work of one developer with others. The module system which facilitates this is foundational to Drupal’s structure. But modules are more like providing another developer a phillips head screwdriver when all they have is a flathead. These are building blocks. There are tons of examples of government contributions to open source in Drupal. We worked on a few as part of Whitehouse.gov contributing back an Akamai integration and a mechanism for embedding content in a 508 compliant way. There are other integration with services like GovDelivery. Many of the current examples of open source in government are on the building block level.\n\nFeatures go a little further in providing a complete solution to a specific problem, more like giving someone a paint by numbers kit. They still may need to obtain some of the specific colors they want but they have a much more complete guide. Features allow a developer to provide many of the end user components for a set of functionality. A content type, various pages for listing and editing, etc.\n\nApps take the concept even further to provide a finished component out of the box. The idea is that it is similar to installing an application on your phone or computer. Apps are attempting to address but the app builder, the end user, the webmaster and the site administrator. Making it easy to install, evaluate, use and extend. From developer centric to adminstrator centric\n
• #13: An app is a module, feature, or theme that delivers a piece of functionality fully and clearly, upon installation. The goal of the “Apps” module is to reduce the number of steps required of users from installation to usability for functionality for their Drupal sites. \n\nWe think Features make the best modules, but you *could* do any of this with a simply a standard module, but Features and Apps aim to provide the framework from which you interact.\n\nThe goal is to provide the facilities to easily install, evaluate, use and extend. We feel that the real killer aspect here is that when combined with a distribution, a core framework you know to be in place, you can develop really target rich Apps. \n
• #14: One example we will talk about today, is an app we use to put projects on a map. These projects can be just about anything, Construction/Civil engineering projects. Relief efforts, just about anything and providing a place to list and describe these “projects” and have those feed a beautiful map using a tool like MapBox. Another example is an Ideation app. DevSeed built it for the Department of Education OpenAtrium site initially, but Phase2 has taken this tool and and also included it in our OpenPublic distribution as an app to hopefully reach and even larger audience. These apps provide a platform for this kind of efficiency.\n
• #15: App Console, this provides a mechaism for searching for installed apps and learning more details about them.\n
• #16: This is an App detailed page. Here an app producer can tel you a bit about their app, give you some screen shots.\n
• #17: After install you are taken to a configuration screen (if one exists). This allows and app producer us to combine all of the configuration in one easy to use place.\n
• #18: Nav placement\n
• #19: Main landing page and demo content\n
• #20: Project detail view\n
• #21: Edit screens for Project Details, Location, etc.\n
• #22: Locations as Taxonomy with Latitude/Longitude\n
• #23: \n
• #24: Project detail page, similar to the Project Mapper page. A place to see ratings and comments, etc.\n
• #25: Again, here is a default placement of the Ideation feature in the main navigation.\n
• #26: When clicking on the ideation menu item, it takes us to the overview of submitted ideas. The ability to drill in deeper and filter by category, etc.\n
• #27: Clicking “Submit an Idea” takes us to the Idea creation screen\n
• #28: The detail page for an Idea has a palce to rate each idea (here on a scale of 1 to 5) and to have a threaded discussion on each idea.\n
• #29: There is a search filter for ideas\n
• #30: and even a block displaying recent comments. The thing is though, you dont need to configure all of the App to get these things to appear, they know where to go out of the box. It is built and tailored for OpenPublic and that is a very powerful combination of a purpose built tool installing into a purpose built platform.\n
• #31: Anyone with a problem to solve, now creating apps does require technical know how. But within legal boundaries agencies can contract for the creation of apps for any of the platforms that are out there.\n
• #32: What your app can do depends on the platform you are creating an app for. iPhone and mobile apps can do different things than Salesforce apps which are more int he web paradigm. OpenPublic apps are considerably more unique. \n\nI think that apps work best when they solve a specific problem completely providing ease of use for structure, configuration and display.\n\nIron out the kinks, solve it completely\n
• #33: If you want to opensource an collaboration on the code, you have to make it available for folks to use. Pick a license that is legally acceptable and not too restrictive. Pick somewhere to share, like Github, Forge.mil, or an extension/app of an exiting project.\n\nThen get about building a community of folks around it.\n
• #34: To to get back into real examples lets talk about something we do know details about, building for OpenPublic is a best case scenario to get started.\n
• #35: Duh\n
• #36: First off, building a Feature is the easiest way to build an app for openpublic. Just search for ”drupal features” for lots of good info on building features. Then create some data to manage, this can eitherb e via content types or through a service integration. Next come the site structures around your data the blocks and page layouts, placement of information the experience around the data. Then provide mechanisms for configuration and interoperability compliance.\n\n
• #37: Menu paths should start with the namespace\n\nVisibility of blocks and location in restricted region set\n\nCan’t rely on a non kit compliant module\n\nTalk about compliance as a set of guidelines instead of hard and fast rules\n
• #38: Talk about the parts of a module, obviously the functionality is first but then there are the parts that make the functionality work well as an app: manifest, the configuration form and demo content\n
• #39: Talk about the problem with configuration for an app being scattered in D6, how D7 is a little better with links to the configuration forms and how the configuration form for apps is intended to pull all the configuration necessary for the piece of functionality together. Allows configuration of multiple app components in a single location, this i basically your on-ramp for an administrator using your app. Point out relevant things, provide rich configuration where possible\n\n
• #40: Talk about the importance of having demo content, a picture’s worth a thousand words, and ways that it can be provided\n
• #41: You can implement your app and simply upload the code to Drupal.org if you’d like. It will certainly have the most exposure there and can be downloaded directly there. If you wanted a more seamless administration experiece you could submit your application to be included in the official OpenPublic App Server, or we are working on mechanisms to allow people to host your own App server. I have a grand vision of a GSA managed openpublic app server.\n\n
• #42: \n
• #43: \n