The easiest way to help out OpenPublic is to spread the word! Tweet, re-tweet, Facebook, present at local meet-ups and mention OpenPublic in private conversations. By letting the world know about OpenPublic, you will help both the distributions, as well as Drupal and the open-source movement in general, since OpenPublic are pure open-source, pure Drupal and an example of what Drupal and open-source can achieve.
Please feel free to comment on OpenPublic documentation pages with suggestions, additions, examples or if you have more information published elsewhere that we can incorporate in this central place.
If you are interested in contributing your translation services to OpenPublic, please contact us at firstname.lastname@example.org and we will speak with you further about where you can contribute.
Our OpenPublic issue queue on drupal.org help centralize issues, ideas, and support and starts good community conversation. Getting involved is a great way to contribute to OpenPublic. You will be able to ask questions, interact with core developers, share your experiences, and help others.
If you are a developer and are using OpenPublic, please contribute back! Patches, enhancements, modules and features, bug reports - everything is welcome, appreciated and helps improve the product.
OpenPublic open a new level of opportunity for designers interested in Drupal. Being more specifically defined distributions, compared to generic vanilla Drupal, it is easier to create unique themes for OpenPublic. We have also created a robust base theme for both distributions to further assist in theme development. Please refer to the OpenPublic Theming Guide for more details.
The idea behind Apps is to use the existing building blocks of Drupal to create a more discoverable and usable set of functionality for a Drupal distribution. So, our goal is that building an App for a distribution is a simple and straightforward process. We've laid out the following steps to help accomplish the goal of planning, creating, and submitting your app to OpenPublic or OpenPublish. For more information about Apps generally, please see Apps Documentation. And if you're interested in learning about the Open App Standard please visit our groups at http://groups.drupal.org/open-app-standard
The process of building an app for a distribution can be summarized in four steps, each with a set of activities. They are:
1. Define the problem
2. Define the audience
3. Define the solution
4. Contact the team that manages the distribution to discuss inclusion
1. Identify contributed modules to use
2. Identify components you need to build
3. Identify what can be contributed back
4. Build the app's main module.
1. Prepare the app for its distribution
2. Build the configuration page
3. Build default content
4. Test your app
1. Put it somewhere!
-- Drupal.org or some other location
-- Create a project on d.o for it and add all of your content
-- Tag on d.o for distributions/ apps, etc. (?)
2. Submit the app
Let's get started.
Steps to Building an App
I. PLAN for your app
1. Define the Problem: What is the Problem we're trying to solve?
The first thing to understand is the exact, specific problem you're trying to solve.
At Phase2, 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.
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?
Example of a Problem to Solve: create a calendar to tell people what the agency is doing and when
2. Define the Audience: Who is this app for? (who is going to INSTALL the app?)
Before we say what an App is it's helpful to know who it's for: An App is for the end user, typically a non-technical user of a Drupal site such as the site administrator. These are the users we are thinking about when we discuss Apps:
An App is an installable package which solves a concrete task specific use-case. The complexity of its installation should be hidden as much as possible keeping the process uniform and simple. The goal of the App concept is to make extending the functionality of a Drupal site with discrete functions in a polished, "user friendly" way its main goal.
An App is a piece of packaged functionality. Upon installation, an App delivers a polished solution for a specific need.
The goal of the "Apps" module is to reduce the number of steps required of users from discovery to usability for functionality for their Drupal sites. By creating a specific protocol for installing and configuring apps, we'll streamline the end-user experience, making Drupal functionality more "pluggable" and inherently easier to use.
Technically, an App is a collection of new or existing Drupal functionality, including Modules, Features, and Themes along with some simple additional code that publishes the existence of the App to the rest of the App infrastructure.
What distinguishes an App from a Module or Feature is that the App includes all of the additional polish, end-user UI, configuration UI, sample content, and documentation that are needed to fully meet a specific need. Whereas Modules and Features are more developer-centric and provide building blocks for larger functionality, Apps are larger blocks of completed functionality.
Unlike a Distribution or Product, one App only solves one specific problem. A collection of Apps might be seen as a full Product, just as a collection of Modules and Features might be seen as a Distribution.
What is the purpose of an app?
The primary purpose of an app is to simplify and make consistent the discovery, installation, setup and use of a specific piece of functionality on a Drupal site.
Examples include a Mailchimp app, which synchronises site users with a MailChimp list, a Project Mapper app that provides geolocation around specific projects for an organization, and then displays them on a map, or an ImageSlideshow app, which displays your images in a slideshow.
The App Philosophy: Why do apps exist?
There are a couple of things about Apps that are important to understand. First, that apps exist to solve specific problems for specific users. And second, that apps are generally built for the benefit of Drupal consumers, as opposed to modules which are generally built for the benefit of developers or site builders. To explain further:
Apps exist to solve specific problems for specific users.
Account Settings The Account Settings section describes how to change settings to control information about yourself and also your use and experience of a Drupal site.
Content Types and Creating Content Content types define various default settings for nodes of that type, such as whether the node is published automatically and whether comments are permitted. This section also includes instructions on how to create content.
Nodequeues A nodequeue allows a content administrator to put nodes in an arbitrarily ordered list.
Menus The Menus section describes how to administer primary and secondary menus.
Taxonomy The Taxonomy module assists in classifying your web content and establishing your site's information architecture.
Views The Views documentation describes how to present your content to your site users in the way you choose.
Theming A theme is a collection of files that determines the look and feel of the site
RSS Feed This section provides instructions on how to create RSS feeds for your content