(Editor’s note: this post is on behalf of the Open Government Partnership)
In response to vendor questions on the Open Government website RFP, OGP is posting responses below to aid vendors in the development of their proposals.
Regarding “core site content will be translated into key languages (English, French, Spanish, Portuguese) ahead of time.”: is this partial or full page translation – i.e. should this include translation of navigation, categories, blocks and other page elements, in addition to the actual content? Can you give a sense of how many landing pages or sections comprise the core that will be translated into all languages?
We would like to translate system nav/tabs and would provide those translations ahead of time, at minimum we would want core site content translated. We would expect this to include 3-5 landing pages.
Regarding “built in cross-posting to social media and quick import/ export functions”: what social networks are you interested in cross-posting to? Does import/export refer to specific content pages (and if so in what format?), or to providing/consuming feeds such as RSS?
RSS Feeds and AddThis. Rather than automatic facebook and twitter updates, we imagine having the web editor craft tailored messages and updates to post here.
Are you looking for ideas into possible social media and engagement strategies in the proposal, or should we focus on capabilities?
Focus on capabilities.
Whilst the data visualization strategy is something that would be developed as part of the process, is there a sense of what data points/metrics may be included? Is this likely to include temporal and/or spatial drill-downs?
Not yet, but it may include visualizing country commitments in terms of themes and location, visualizing the network directory in terms of civil society and private sector practitioners and their project activities, or visualizing the new data produced/provided by OGP participating governments based on commitment implementation. Overall, we want this strategy to be opportunity-driven rather than pre-set, and focused primarily on the goals we want to achieve rather than the technology, so data visualization should not drive platform decisions. It is not an immediate term priority, but one that we will address later on once we have identified the key stories that we want to tell.
Hosting Recommendations: Any idea of expected user base, and user traffic around the key September date?
Probably around 15,000 unique users for site launch (peak load), and less on an average/daily basis. Site traffic will be “spiky” given that countries will periodically join/announce new commitments and issue reports that will drive more significant traffic.
Localization/Internationalization: Are functional requirements expected to vary across any of the localized implementations (e.g. varying social media services integration)?
No.
Mobile Development: No localization/internationalization requirements were explicitly mentioned around this piece, is it safe to assume the same localization/internationalization requirements for the rest of the site will apply?
Yes. We don’t want the mobile development to distract from other initial priorities, and it is not a deliverable for v1, but we want whatever is built to allow an easy transition to a mobile site if/when we decide to do it
User Data: Any end user data to be gathered was not explicitly mentioned. Will a CRM component be required for managing user data, activities, email blasts, etc.?
We would like to collect email addresses, so an easy secure export for CRM will be required.
Systems Integrations: Any known or considered systems integrations not mentioned in the RFP beyond the potential of the data visualization piece?
None that we can think of.
Do you have a prefered CMS solution?
No, although in general we like Drupal.
In what ways do you see social media working with the site? Do you see having Social Media sign in, sharing, etc. or do you see having your own social media integrated into the site? Both?
Would ideally like a low tech/non-custom solution at the moment. AddThis for posting site content and basic functionality for pre-populating Twitter hashtag.
When a country/user registers what do you want the approval process to look like?
We haven’t thought about a user registration process yet, open to ideas. The main area relevant to this question right now is the network directory, where we will call on various actors working in the open government field (especially civil society, but also the private sector) to list what work they are doing and where. There does not need to be an approval process for this as we imagine it right now.
What do you feel the workflow roles/privileges should be? i.e. Who would you like to have content creation, editing, deletion, publishing privileges?
Small team of 2-4 people internal to the OGP team. There might be 1-2 admins and 1-2 content editors/creators.
What do you see the content creation/review/approval process should look like?
We are in the midst of discussing a site curation role/process for OGP, but in general, this will be a very thin process largely in the hands of a web editor, so not sure that we need the site to dictate how/when content is approved for publication right now. For V1 launch, core site content will be created by primarily OGP (and/or the vendor as appropriate), with a senior OGP advisor reviewing/approving in consultation with a small sub-committee of the OGP board.
For the blog, do you envision multiple blogs linked from a blog overview page or will there be one blog with tags where the bloggers create content?
Multiple blogs feeding into/linked from main blog overview page, that also includes a special space/signifier for original OGP blog postings.
Translation – do you want the CMS to translate documents or have different landing pages based on language preference?
We do not want auto-translation, and we do not want to have different landing pages based on language preferences.
Which content should be shared vs. custom for the OGP vs. governments?
Use of off-the-shelf theming, modules, open-source code or other preexisting components is encouraged where they meet requirements. Use of vendor-specific proprietary technologies is not allowed (an in-house CMS, for example)—portability to new vendors is a required criteria. OGP will own or open-source all code created for the project.
Which of the following ways should the sites be set up:
- Content types are created, restricting access to updating content. So that if a government page gets changed, and a super admin from the OGP can go into each site and manually update it?
- OGP content gets automatically updated on OGP and government sites, with those sites not being able to edit those pages?
Right now, we do not envision the OGP site pulling automatically from government websites or data-streams. OGP web editor will be controlling all content appearing on the site.
What would they like the replication process for a new government to look like, if this is required?
This is not required.
What are the hosting requirements?
Commercial-grade hosting with 99% up time or better guaranteed.
You mention in v2 you would like to highlight successes and reference video, images, etc but in v1 you say no flash or javascript. Do you see video being hosted on a separate platform (YouTube)?
Most likely youtube/third party solutions.
Consideration of SEO – should the individual country pages have custom SEO for separate indexing?
No.
Should OGP and governments have separate social networking links that they can manage?
No. This is not going to be a government controlled or “co-hosted” site. This site will be run by OGP, which is a multi-stakeholder initiative (govts and civil society co-managing).
What OS/browsers should be considered for testing purposes?
IE 6.x and higher; Firefox 3.x and higher; Safari (most current version), and Chrome (most current version).
Will image assets need to be purchased?
We prefer to use Creative Commons imagery.
Do they have any compliance requirements to follow (for example Section 508 in the USA)?
No compliance requirements to follow (this is not a governmental site/procurement process). But we do want to make the site as accessible as possible using existing technology/solutions.
Do they require a software analysis as well – or just our single recommendation for their requested CMS?
A single recommendation for CMS.
Do they need any third-party integration for newsletters, a CRM or other customer data?
Not at the moment and not likely going forward.
Do you wish for full compatibility with the site features and the mobile site?
For v1, we would like to focus on web-based site development and leave mobile to a later stage. We do not want to focus on this or build a mobile-specific site right now.
What range do you have in mind for the budget? This will help us determine the solution presented to you; if you have no budget in mind can you provide a maximum you do not want to exceed?
Proposals will be evaluated on a best value for money basis. It would be helpful if you could breakdown the budget in such a way as to allow us to analyze how it could be reduced/increased based on how sophisticated or ambitious we want to get in key areas.
Will users need training for the CMS and analytics?
Yes, this should be included in a proposal, along with documentation of site tools and upkeep (including in particular all functions that are customized.
How many vendors did you invite to participate? How many vendors have expressed interest in submitting responses?
This is an open process. We made sure that about 10 top vendors in the open government field were aware of the RFP, but it is open to all. So far we have received about 10 intentions to submit proposals.
You require “open source,” is there a specific reason you are requiring an open source?
Yes, this is the ethos of the initiative, and we also do not want to get locked into any individual vendor’s solution.
What’s the reasoning behind no flash, javascript, etc.?
Do you anticipate most of the website visitors to have JavaScript turned off? Or are you looking for a solution that initially has this functionality but will degrade gracefully on older browsers and mobile platforms?
Thanks Chuck. We want to avoid any unnecessary bandwidth constraints on our users, many of whom will be accessing the site on slow/dial-up connections. If this can be done so that it gracefully fails for slow connections, we are happy to look at it.