Responding to Citizens with OpenPublic
As Luke Wroblewski puts it, Mobile is Exploding. As smartphone sales surpass PCs and more and more people are doing their casual surfing from the couch or the line in the grocery store, everyone is talking about how to meet mobile user’s needs. Moreover, an increasing number of users are using smartphones or tablets as their only personal computer. We think that for the public sector, especially for any organization that wants to provide equal access to everyone, this means that you need a strategy for reaching these devices.
One way to do this is to build your websites in such a way that they’re appropriate for a small screen. Accommodating the smaller screens of these post-PC devices is helps ensure equal access, without having to necessarily go all the way to a native app or mobile theme.
This technique was christened responsive design by designer Ethan Marcotte. Responsive design begins with a flexible grid and, with some special CSS, allows your site to snap to target resolutions for desktops, tablets, phones, and even very large resolution displays. (If you’re unfamiliar with the concept, you should check out media queries for some inspiration.)
Because the OpenPublic Team thinks that the mission of making content as accessible as possible is core to our users in the Public Sector, we’ve decided to make OpenPublic responsive and to provide it in a way that makes responsive-sub-theming easier. To do this, we teamed up with DevelopmentGeeks, creator of the Omega base theme, to revamp the OpenPublic theme options with responsive design in mind.
If you’re unfamiliar with Omega, lead designer and developer, Jake Strawn, introduces it this way:
Responsive design serves content to multiple devices without managing duplicated, often complicated code bases. Drupal is an ever-evolving platform that allows us the flexibility to present content in any manner we choose, and to that end, more products like OpenPublic are turning their focus to adopting responsive theming in order to greatly serve niche vertical markets with the technologies of tomorrow, today.
We’re excited to be working with the Omega in OpenPublic, and grateful to Jake for his help on the project. If you are interested in getting involved with the OpenPublic project, then join the community and start by sending us your feedback on Omega theme for OpenPublic.
Using Omega, we’ve re-themed the original base theme design in OpenPublic Beta 4, but we’ve also created a new Omega sub-theme, Spartan. This no-frills, quick-to-customize sub theme is a response to community requests to help OpenPublic implementers get up and going faster by creating a simpler theme that is easy to customize. With new documentation on building OpenPublic sub-themes using Omega, you should be on the road to responsive design in no time.
Consider it this way: do you know which screen you would most likely be using to find disaster relief information, should natural disaster strike your town? You might be accessing it on your mobile phone, but you might be at a desktop computer at a local community center or shelter. Citizens often don’t know exactly when they’re going to need vital information like this, nor do they know which device they’ll be using. Making essential information available to citizens on multiple devices is not only convenient — it furthers the impact of the public sector organization itself.
For more information on on this release of OpenPublic, review our release notes and get started theming with OpenOmega and Spartan here.
Comments
Great job with Omega!
I've been working with Omega for the past few weeks and I was excited to see Phase2 jump on the bandwagon. (plus, I don't have to relearn a new theming paradigm!)
I do have a theming suggestion. Your two sprite files, (sprite.png & sprite-sm.png) definitely help to increase performance, but they are a pain in the ass when a themer needs to change a button color or gradient.
Could you guys PLEASE include the Photoshop or Fireworks files that were used to generate the sprites, so that us themers will have an easier time making changes?
Or better yet, just switch to CSS3 (and add the CSS3PIE module) so that some of these sprites can be eliminated.
Files for Sprites
Strange as it may seem, we typically work with PNGs for our sprites. When we need to, we quickly slice up the PNG into layers and rearrange, and then save it back to the repository as a PNG. This works well in our workflow, but I can definitely see the utility of sharing an easier to work with sprite.
Post new comment