Call for Bids - Redesign of ICANN.org

Answers to Questions Vendors Have Asked

Thanks for your interest in redesigning ICANN.org. We’re excited at the prospect of having a dramatically improved site. If you would like to bid on the project but have not received our RFP, you’ll find it below, followed by our detailed requirements:

icann-org-redesign-rfp-final.doc

icann-redesign-detailed-reqs-final.xls

All responses are due no later than January 17, 2011.

Questions Asked After the RFP Deadline

1. I see that the date when proposals were due has passed. How many proposals did ICANN receive, and who bid on the project?
2. What should the responding vendors anticipate from the evaluation process?

Note to Vendors: We originally targeted Friday, February 4, to announce our short list of 3 firms being considered to help us redesign ICANN.ORG. Due to the amount of proposals received, we need more time. We now intend to announce our top three candidates one week later, on Friday, February 11, 2011. Watch this page for further updates.

Announcement: As of 10 February, ICANN's proposal evaluation committee has narrowed the vendor selection to four finalists. In alphabetical order, they are:

Andalucia Web Solutions
Forum One
Four Kitchens
Revere Group

ICANN again thanks all the responding vendors for their proposals.

Asked Questions (whether Frequently or Not)

We have approached 28 vendors with our Call for Bids. As of this writing, 11 have responded with follow-up questions and thus far, 8 have said they plan to respond in full. In order to keep a level playing field, whenever any of the vendors asks clarifying questions, we also post them here so that all bidders have access to the same information.

1. From which physical ICANN office will this project be run?
2. Where is the site hosted?
3. Is ICANN encouraging bids solely from firms near ICANN's Marina del Rey office, or from any qualified firm, regardless of location?
4. What is your budget for this project?
5. What is the timeline for the project?
6. What are the main drivers for the project?
7. Will ICANN accept a proposal that includes two firms working in partnership?
8. Do you have a CMS preference for the re-designed site?
9. Will a consultancy’s work with ICANN be limited to interacting with a project committee, or will the consultant be involved in public-facing discussions with other members of ICANN's community, including constituents from other countries?
10. Does ICANN plan to make public the proposals it receives in response to this RFP?
11. Are you letting the vendors know who is bidding on the project?
12. What degree of maintenance is required to support the legacy file management system? ... What makes the file management system "unique"?
13. Will you need SSO [single sign-on] between [ICANN.org] and Confluence?
14. Can you clarify Confluence's role in the content workflow?
15. Can you clarify the "file container" (8.2.1) and "link container" (8.3.1) aspects of file management (section 8 of the spreadsheet)? We're not sure what's meant by "replacing BODY content with a file attachment."
16. Can you clarify ability to "patch the site upon evaluation of new security releases of upgrades" via a mobile devices? ... "included" in 15.1 of the spreadsheet.
17. Item 16.1 seems to include mobile support "develop[ing] custom features upon redesign" - please clarify.
18. What domains are in scope for the RFP?
19. What do we do with the other pieces of software that the site interacts with?
20. Will there be any integration between ICANN.org and ICANN's newsletter publishing platform?
21. What powers the Dashboard, and how should that data be brought into the refreshed site?
22. What kind of hand-off or processing should be done with ICANN's job listings page, which comes from a third party?
23. Will the community at large provide input/feedback on aesthetic design and/or information architecture? If yes, at what key junctures? Do you have a review process/ timeframe in mind?
24. Will ICANN provide all graphic assets (i.e. images of the businessman in Nepal or the church lady in New Zealand) or will vendor be responsible for originating and/or acquiring graphic assets on ICANN's behalf? Will any other graphics assets, other than photos, be provided or required, such as video or audio? If yes, please clarify.
25. Will ICANN provide all editorial content (existing, instructional text, new content that may emerge during IA, etc.)? Please clarify vendor's role in editorial, if any.
26. Will mobile platforms access the site using browser or custom "apps"?
27. What is the Acronym Helper app referred to in the requirements?
28. Please clarify requirements around the Vocabularies/Taxonomies
29. What is the existing system?
30. What are the requirements for content migration?
31. URLs with 2 character internationalization: What about the localization (es-ES, es-mx, etc)?
32. In the Requirements doc, line 1.4, ICANN asks for a "mark up," i.e. Mark up the design in adherence to best practices for accessibility, browser compatibility, search engine optimization and web compliance standards. Is this a written doc or an actual mark up on top of a design comp?
33. Requirements 2.1.1 - Is there a specific purpose for having customizable columns?
34. Requirements 2.1.1 - Can we designate these column switches by section?
35. Requirements 2.5.2.4 - Content Aggregations refers to customized content listings?
36. Requirements 2.5.2.5 - Does the administrator need to be able to do this with or without technical (i.e. css styling) knowledge?
37. Requirements 2.6 - Can the metadata be auto-generated instead of ported for content that is not database driven?
38. Requirements 6.1 - Can you explain this line item more clearly?
39. Requirements 6.3 - Is there a specific type of content for these imports that will need to be enabled?
40. Requirements 6.3 - Will this information simply need to be displayed and not edited inside of the CMS?
41. Requirements 6.3 - Will there be multiple types of content to import regularly?
42. Requirements 12.4 - What kind of customization were you thinking of giving the end user?
43. Do you envisage admin selecting certain individual pages from the Wiki which have interesting content and displaying them within a sub section of the ICANN .org website?
44. Do you envisage displaying large sections of the content from the Wiki in the ICANN website, noting that some sections, such as the public comment forums, extend to tens of thousands of pages?
45. One of the key requirements of project is to offer a role based navigation to users. How does system differentiate between types of users? We have not seen any authentication interface on icann.org? Do you foresee to offer different sections for different archetypes?
46. We are unsure (though it has been answered in RFP and Q&A Page) on the domain names which are in scope. We have figured out following domain names:
47. We are assuming that the admin interface (exposed to admin users) would be only available in English language. Please confirm.
48. A bridge has to be created in between the new system and Confluence WIKI. Does the integration between the new system (what content to be shown on the main site) and Confluence has to be fully automated (Synchronization daemon runs which keeps synching the content between the two systems)? Or should it be a manual activity (Admin staff exports the content in an XML format and imports it in the system)?
49. In summary of requirements it is mentioned that content administrator should be empowered to aggregate the content. Does this mean that administrator should be able to group the content (may be by tag, type, Author …)?
50. It is being assumed that ICANN.org will continue with the same set of third party providers like Brightcove, Flickr…. Please confirm?
51. How do you envision Site Tracking to be done? Would you be open to Google Analytics?
52. Would the users or content (in addition to confluence) be shared between sites?
53. Site exposes pages like http://icann.org/en/registries/rsep/ and http://www.icann.org/en/registries/rsep/submitted_app.html. Do you intend to keep them as plain static pages? Or you intend to create interface (create seed entities to accept things like Registry, ) for generation of such pages?
54. In the RFP it is mentioned that we need to have multistep/multipage submission. Is this required for all content creation form? Please clarify.
55. RFP talks about the requirement per which generation and transmission of granular and customizable external feeds in XML is required. Can you please elaborate on this? How will this be used?
56. From the outlines in the documents it seems that ICANN is interested in developing mobile versions of website (and not the native version). Please confirm.
57. We are assuming that all the currently available languages are to be supported in mobile site, too. Please confirm.
58. Do we need to expose all the features on the mobile version of site too? Or we need to just expose a limited set of features? Please elaborate.

From which physical ICANN office will this project be run?

Anchor
From which physical ICANN office will this project be run? From which physical ICANN office will this project be run?

The project will be run out of ICANN’s headquarters, in Marina del Rey, California.

Where is the site hosted?

Anchor
Where is the site hosted? Where is the site hosted?

ICANN.org is hosted primarily from clustered servers on the West Coast of the United States, with some redundant servers on the East Coast. The selected vendor will receive more detailed information after signing a Non-Disclosure Agreement.

Is ICANN encouraging bids solely from firms near ICANN's Marina del Rey office, or from any qualified firm, regardless of location?

Anchor
Is ICANN encouraging bids solely from firms near ICANN's Marina del Rey office, or from any qualified firm, regardless of location? Is ICANN encouraging bids solely from firms near ICANN's Marina del Rey office, or from any qualified firm, regardless of location?

ICANN’s mission is truly global, and we are used to working on teams that are widely dispersed geographically. We encourage responses from any company anywhere that has the technical qualifications and the ability to conduct this project in English.

What is your budget for this project?

Anchor
What is your budget for this project? What is your budget for this project?

We fully anticipate that this is a six-figure project (that is, over $100,000 USD). Beyond that, we’re not specifying a budget to vendors, as we want to see the spread of price ranges proposed. As the RFP indicates, we are not eager to enter into a permanent, maintenance-based relationship with any vendor. The goal would be to leave ICANN as self-sufficient as possible after the redesign.

What is the timeline for the project?

Anchor
What is the timeline for the project? What is the timeline for the project?

We plan to select a vendor by 18 Feb. 2011, and hope to have that vendor contracted by 4 March 2011. From there, we don't know the timeline yet because it will be set by the vendor's proposal. In our estimation this is easily a six-month project. Our target is to go live in 2011.

What are the main drivers for the project?

Anchor
What are the main drivers for the project? What are the main drivers for the project?

There are three critical drivers for the project.

One is that our existing site does not work for visitors. People cannot find what they’re looking for and cannot complete tasks they set out to do, roughly half the time. Unacceptable.

Secondly, the site’s aesthetic does not rise to the level of a pre-eminent, international, non-profit organization. The artistic sensibilities need to be more human and reflective of ICANN’s important work.

The third main driver is the need to eventually open up most content on ICANN.org to direct maintenance by staff, through our existing wiki installation. We seek to build a seamless bridge between ICANN.org sections and content grown in staff-maintained wiki spaces. We plan for the amount of staff-maintained “wiki-ized” pages on the site to grow significantly over the next two years.

Will ICANN accept a proposal that includes two firms working in partnership?

Anchor
Will ICANN accept a proposal that includes two firms working in partnership? Will ICANN accept a proposal that includes two firms working in partnership?

Yes. The site redesign is complicated, cuts across several web-related disciplines, and must work well all over the globe, in several languages. If you can offer a better, more globally appealing result by combining your skills with those of a like-minded company, we will give your proposal consideration equal to proposals offered by single companies.

Do you have a CMS preference for the re-designed site?

Anchor
Do you have a CMS preference for the re-designed site? Do you have a CMS preference for the re-designed site?

In two words: not really. ICANN.org is currently a static site. Many of the other sites it interacts with are in Drupal, but senior management is open to any sensible CMS proposal. We deliberately solicited proposals from houses with expertise in a variety of CMS tools. Pick the tool you think is best, and make your case.

Will a consultancy’s work with ICANN be limited to interacting with a project committee, or will the consultant be involved in public-facing discussions with other members of ICANN's community, including constituents from other countries?

Anchor

Will a consultancy’s work with ICANN be limited to interacting with a project committee, or will the consultant be involved in public-facing discussions with other members of ICANN's community, including constituents from other countries? Will a consultancy’s work with ICANN be limited to interacting with a project committee, or will the consultant be involved in public-facing discussions with other members of ICANN's community, including constituents from other countries?

For the bulk of the work, the consultancy will be working with ICANN staff, primarily (but not exclusively) US. At certain key junctures as we show the proposed site to our volunteer community and receive community input, and at the end, when the site is nearly ready to go live, we welcome participation from the vendor. In these sessions, you will interact with a wide variety of nationalities and cultures.

Does ICANN plan to make public the proposals it receives in response to this RFP?

Anchor
Does ICANN plan to make public the proposals it receives in response to this RFP? Does ICANN plan to make public the proposals it receives in response to this RFP?

As a not-for-profit organization run for the public benefit, ICANN uses open, transparent and accountable business practices. However, we realize that publishing vendor proposals in full may reveal a vendor’s trade secrets or otherwise hamper a vendor’s ability to compete for future customers. To balance the needs of transparency and privacy, we plan to post a public list of all vendors who respond to our RFP, and their aggregate score at the end of our evaluation process. We do not expect to post vendor proposals in full.

Are you letting the vendors know who is bidding on the project?

Anchor
Are you letting the vendors know who is bidding on the project? Are you letting the vendors know who is bidding on the project?

We are keeping the names of participating vendors confidential until after we have received proposals on 17 January, 2011. We want to see you make your best case for solving the problems on our site, and we feel we'll get your input in a purer form if it is focused on our issues rather than angled to cut out specific rivals. As stated above, once the proposals are in, we'll publish a list showing who responded to our RFP.

Anchor
12 12

What degree of maintenance is required to support the legacy file management system? ... What makes the file management system "unique"?

- "File" here means file in the sense of content that is contained in PDF, DOC, PPT, TXT, XLS and other non-HTML formats.

- Other files that comprise theme and code components, images, audio, and video are not covered by this reference.

- All legacy file URLs must be carried over and still resolve, even if post-launch URL conventions deviate. This is vital in the case of key documents, such as files containing legal content.

- Files must carry both localization and internationalization references in their URLs, as seen by the two "ar" references in: http://www.icann.org/ar/topics/new-gtlds/draft-new-gtld-drp-redline-12nov10-ar.pdf- Files containing multilingual content must be "correlate-able" with English originals via a translation interface.

- Links to files will often need to be intermixed with links to HTML pages, as seen in: http://www.icann.org/en/committees/security/ssac-documents.htm

Will you need SSO [single sign-on] between [ICANN.org] and Confluence?

There is no use case for non-administrator users to log in on the ICANN.org side, as we have envisioned it. However if using SSO is part of a proposal for bridging ICANN.org with content maintained by staff on the wiki side, we are open to hearing it.

Can you clarify Confluence's role in the content workflow?

Initially, a small amount of content would be maintained by staff in spaces within a public-facing Confluence wiki installation. We would minimally like to link to these spaces in a sensible way, as wiki pages tend to proliferate and lack an overarching structure. Better yet would be to pull the content straight into dedicated sections on ICANN.org that carry an intentional structure and uniform aesthetic. To be clear, importation is preferred to linking. For example, a staff member would maintain the "Registry Services Evaluation Process" section on the wiki side. In addition to displaying the content in Confluence we would like to pull it in (presumably via XML) for display within ICANN.org itself. The amount of public-facing content maintained on the wiki side would grow over time. This additional material will also need to be bridged with ICANN.org in the same manner just described. We do not plan to launch the redesigned ICANN.org with all of its content maintained in the wiki, as sufficient time is unavailable to migrate all content to the wiki and transform existing staff workflows. It will take the organization time to transition.

Can you clarify the "file container" (8.2.1) and "link container" (8.3.1) aspects of file management (section 8 of the spreadsheet)? We're not sure what's meant by "replacing BODY content with a file attachment."

Files and links must be treated as first class objects by means of containers designed specially for them. The container must accommodate the same properties associated with HTML pages -- date, tags from a taxonomy, language, title, alias, etc. Files and links thus would be equivalent in most respects to full HTML pages with the exception that -- by their nature -- they contain no <BODY> content. The file container would be used to handle files such as PDF, XLS, etc. and often intermix links to them in aggregations with links to full HTML pages. The link container would be used to reference and handle URLs of assets hosted on domains outside ICANN's control. For example, we might occasionally need to use a link container to reference a file or page contained on IETF.org, such as http://www.ietf.org/rfc/rfc5378.txt. Using a link container would allow us to tag that file, date it, and assign a language setting for our own purposes in displaying it via ICANN.org. The page at http://ccnso.icann.org/announcements is an example of a listing that contains URLs leading to full HTML pages, file containers holding PDFs, and link containers that lead to external pages.

Can you clarify ability to "patch the site upon evaluation of new security releases of upgrades" via a mobile devices? ... "included" in 15.1 of the spreadsheet.

This reference was inadvertent -- there is no intention of patching the site via a mobile device. Rather any patches and security upgrades must cover both the desktop/laptop display and the mobile display, where applicable.

Item 16.1 seems to include mobile support "develop[ing] custom features upon redesign" - please clarify.

To clarify, at the conclusion of the project ICANN staff or an external contractor must be able to develop custom features for the redesigned site in both its desktop/laptop and mobile expressions. Again, it is not intended that this development actually be carried out via a mobile device. Rather it is meant as development for the mobile site itself.

Anchor
18 18

What domains are in scope for the RFP?

- ICANN.org

- As stated in the requirements XLS: “Possibly incorporate content and functionality from root-dnssec.org, internic.net, nomcom.icann.org and dns.icann.org into redesigned icann.org.” These four sites still remain subject to final determination by the ICANN.org redesign working group. If integrated into ICANN.org, much of the content would be merely HTML pages and PDFs. None of the pages on these domains have sophisticated functionality beyond sometimes containing traditional forms that submit information to external applications.

- Domain TBD: public-facing Confluence wiki for staff content maintenance, as covered in RFP

- Staff may be migrating content from blog.icann.org to the a new blog space on the public-facing Confluence wiki, but that is out-of-scope for the vendor.

What do we do with the other pieces of software that the site interacts with?

Nothing unless specifically designated in the stated requirements. With regard to interaction with external systems – other than Confluence wiki as discussed in the RFP separately -- ICANN.org pages generally only need to be able to accommodate embedded code such as form fields, a Brightcove video embed, a Twitter feed embed, a Flickr embed, etc. This code is typically javascript, object, param, and rarely iframe.

Will there be any integration between ICANN.org and ICANN's newsletter publishing platform?

The newsletter distribution mechanism is not in scope. The newsletter signup pages themselves merely contain form code that sends subscriber information out to a cloud service, from where our news mailings are then distributed through a separate interface. Newsletter publishing is otherwise not part of the ICANN.org infrastructure.

What powers the Dashboard, and how should that data be brought into the refreshed site?

The dashboard is not in scope. Dashboard pages are either standalone and connected by links to ICANN.org, or embedded within ICANN.org pages. The dashboard application is already maintained separately. ICANN.org pages merely need to be able to accommodate the object embed code that calls in these dashboards, which are Flash.

What kind of hand-off or processing should be done with ICANN's job listings page, which comes from a third party?

The jobs page is not in scope. We will simply retain the link to the third-party service through whom we already recruit and process job applicants.

Will the community at large provide input/feedback on aesthetic design and/or information architecture? If yes, at what key junctures? Do you have a review process/ timeframe in mind?

The timeline and process of involving community input is not fully defined yet because some of it will depend on the selected vendor's proposal. Many of our users are not sophisticated in understanding web interfaces, so we could experience difficulty getting meaningful input on IA before there is a design skin on top of it. We currently expect that after the selected vendor and ICANN Staff agree on a probable IA, we would ask a limited, qualified set of community members for guidance, as a basic sanity check. We will definitely go to the community before making a final decision on the Aesthetic design. Those are the only two checkpoints where we know we must include our audience. Towards the end of the project, when we are weeks from taking it live, we will mount a small education and awareness campaign to the community so that they'll understand and feel positive about the change before the switch-over. During that phase our emphasis is more on demo’ing what is coming, rather than collecting input that would result in dramatic changes to the design. However, we'd love for the selected vendor to join ICANN staff in presenting to the community. Depending upon when this part of the project occurs, it might involve travel or it might simply be presented remotely, 'webinar'-style.

Will ICANN provide all graphic assets (i.e. images of the businessman in Nepal or the church lady in New Zealand) or will vendor be responsible for originating and/or acquiring graphic assets on ICANN's behalf? Will any other graphics assets, other than photos, be provided or required, such as video or audio? If yes, please clarify.

We would like the vendor to provide graphic assets where possible. ICANN
currently does not have in-house graphic artists. There will be video and
audio on the site, used the same way they are now. (Examples – not all from
ICANN.ORG, but typical of how we use such files: http://icann.org/video/; video file on http://blog.icann.org/ ; audio files on http://icann.org/en/learning/podcasts.htm andhttp://gnso.icann.org/calendar/.)

Will ICANN provide all editorial content (existing, instructional text, new content that may emerge during IA, etc.)? Please clarify vendor's role in editorial, if any.

ICANN will provide all editorial content. We expect that the new design
will generate need for lots of new text bits to help explain new features or indicate navigation. Vendor's role would be adminstrative only: to identify all new content the design requires and, as we create new pieces, assist us in tracking what exists and what still needs to be created.

Will mobile platforms access the site using browser or custom "apps"?

We currently envision mobile platforms as using browsers.

What is the Acronym Helper app referred to in the requirements?

"Acronym Helper" is a nimble utility that helps our community remember what all our acronyms stand for. It will soon be appearing on GNSO.ICANN.ORG, which is also being refreshed. For now, you can see Acronym Helper at http://www.andalucia.com/icann/.

Please clarify requirements around the Vocabularies/Taxonomies

Please see items 2.4.1, 2.4.2, 2.5, 2.5.1. Free-tagging is out of scope on the CMS (non-wiki) side. Also note 3.4.1: "Provide back-end mechanism for administrator to correlate translations of taxonomy terms."

What is the existing system?

http://www.icann.org is comprised primarily of thousands of static HTML files and static PDFs, along with a smaller selection of other document formats (XLS, PPT, TXT, DOC, etc.). There are standard and print stylesheets. There is otherwise no unifying database or content management system beneath the site. The site does link to other icann.org subdomains that contain database-generated material, i.e. http://forum.icann.org. However, those subdomains are out of scope unless specifically referenced in the RFP, as below.

The fate of the smaller, related sites identified in the RFP – root-dnssec.org, internic.net, nomcom.icann.org, and dns.icann.org – is still pending determination. If incorporated into http://www.icann.org, we envision migrating the text content of these sites – but continuing to link to or embed existing functional elements such as dashboards, maps, video, Twitter feeds, etc. Forms could be recreated within the new system. However the back-end databases to which forms transmit data would remain separate and intact, such as they exist now.

What are the requirements for content migration?

That for HTML pages, all content and its accompanying markup contained within the DIVs confocus, confocusnoline, and confocusfull be copied into the redesigned site's database; and that legacy tags be restyled as part of the new design or removed if deemed irrelevant based upon the new aesthetic. Removal of extraneous tags can be done post-migration.

That for files (PDF, XLS, PPT, TXT, DOC, etc.), all are copied into the new site with the content and metadata contained within them remaining intact.

URLs with 2 character internationalization: What about the localization (es-ES, es-mx, etc)?

The XX-XX patterns contained in your question are out of scope. ICANN.org follows the simplified localization pattern /ar/, /es/, /fr/, /zh/, /ru/, etc. We do not distinguish more granularly than those designations.

In the Requirements doc, line 1.4, ICANN asks for a "mark up," i.e. Mark up the design in adherence to best practices for accessibility, browser compatibility, search engine optimization and web compliance standards. Is this a written doc or an actual mark up on top of a design comp?

Here "mark up" means to generate the actual HTML and CSS (we avoid the term "code" unless it denotes actual code such as PHP, javascript, etc.) required to bring the redesigned site to life. Modern content management systems typically use a template and theme system to accomplish this. The markup must be output by the system in such a way that it yields the functioning website as specified.

Requirements 2.1.1 - Is there a specific purpose for having customizable columns?

• Some pages might need all three columns – left, main content area, right: http://www.icann.org/en/topics/idn/
• Some pages might only the left column and main content area: http://www.icann.org/en/topics/idn/idn-announcements-archive.htm
• Some pages might need to be full width (main content area only, across entire page): http://www.icann.org/en/maps/idntld.htm

Requirements 2.1.1 - Can we designate these column switches by section?

Not by section alone; column designations need to be assignable down to the page level. The examples above show different column configurations for three IDN pages that could all be part of the same IDN section.

Requirements 2.5.2.4 - Content Aggregations refers to customized content listings?

Yes, for example, these are customized content listings:

• http://www.icann.org/en/committees/security/ssac-documents.htm (SSAC Documents - documents specifically relating to SSAC; moreover there are HTML pages intermixed with PDF files.)
• http://www.icann.org/ru/announcements/ (ICANN announcements specifically in Russian)
• http://www.icann.org/en/topics/idn/fast-track/announcements-en.htm (ICANN announcements specifically relating to IDNs and the ccTLD Fast-Track process)

And here are examples of customized content listings assigned to various columns:

• http://www.icann.org/ (Announcements and Blog postings in right-column)
• http://www.icann.org/en/announcements/ (Announcements in main content area)
• http://www.icann.org/en/topics/new-gtlds/news-en.htm (latest New gTLD Announcements in main content area, just above the page fold)
• (there is no current example of a customized content listing in the left-column, but it needs to be feasible)

Requirements 2.5.2.5 - Does the administrator need to be able to do this with or without technical (i.e. css styling) knowledge?

The Administrator will need to possess advanced CSS knowledge, as the members of the web team already do.

Requirements 2.6 - Can the metadata be auto-generated instead of ported for content that is not database driven?

Yes, noting that this question would largely pertain to HTML pages. Note also that files (PDF, XLS, PPT, TXT, DOC, etc.) need to be copied into the new site with the metadata within them (author, creation date, etc.) remaining intact. Lastly, related to this item, note that automated application of taxonomy terms to content is out of scope.

Requirements 6.1 - Can you explain this line item more clearly?

We manage Drupal, Confluence, and WordPress installations for sites other than http://www.icann.org. Examples: http://cartagena39.icann.org/ and http://ccnso.icann.org (both of these sites are among several sites that share the same Drupal installation, modules, content types, and database), https://community.icann.org/ (Confluence), http://www.root-dnssec.org/ (WordPress)

All of these installations are capable of exporting XML, so that is one (and currently the most likely) avenue of indirectly bringing their content into ICANN.org, where it could be further styled to match the surrounding aesthetic. Another (albeit remote) possibility would be to build ICANN.org on top of one of these existing installations for direct content sharing. However that would, by default, exclude the other installations from direct content sharing.

A use case to consider is this: It would be nice to present part of the Remote Schedule from an international meeting site like http://cartagena39.icann.org within the http://www.icann.org site itself. For example, the five upcoming rows from the schedule at http://cartagena39.icann.org/remote-schedule could be presented at the top of the http://www.icann.org homepage to prominently show remote participants what sessions were coming up next.

Requirements 6.3 - Is there a specific type of content for these imports that will need to be enabled?

This item pertains to content presented in HTML. For example, a feed of XBRL coming from the Finance system would be rendered on an HTML page as a table presenting columnar data.

Requirements 6.3 - Will this information simply need to be displayed and not edited inside of the CMS?

The information will need to be displayed on the http://www.icann.org side, though not edited there. The content would be generated and edited elsewhere, outside http://www.icann.org.

Requirements 6.3 - Will there be multiple types of content to import regularly?

There could be as many as the variability of the XML feeds generated by the originating sites.

Requirements 12.4 - What kind of customization were you thinking of giving the end user?

This item remains subject to further discussion and finalization by ICANN’s in-house redesign group. It is currently a might-have, rather than a must-have.

Do you envisage admin selecting certain individual pages from the Wiki which have interesting content and displaying them within a sub section of the ICANN .org website.

Yes, we need this granularity.

Do you envisage displaying large sections of the content from the Wiki in the ICANN website, noting that some sections, such as the public comment forums, extend to tens of thousands of pages?

Yes, we need this scalability.

One of the key requirements of project is to offer a role based navigation to users. How does system differentiate between types of users? We have not seen any authentication interface on icann.org? Do you foresee to offer different sections for different archetypes?

Role-based navigation should not be based upon any sort of authentication such as a log-in that re-mixes the site based on the user’s identity. We had not envisioned a switching mechanism such as a drop-down menu that alternates navigation options based upon a role selection.

The starting thought for this requirement is that the design would position features and navigation options accordingly so each archetype can find them intuitively. The Learner, for example, should simply find what she needs without consciously self-identifying, “I am a Learner.”

To the question of “do we offer different sections for different archetypes,” the RFP listed the features that each archetype most uses. To the extent that different sections might make sense in presenting these features, that’s something a vendor could propose.

We are unsure (though it has been answered in RFP and Q&A Page) on the domain names which are in scope. We have figured out following domain names:

http://icann.org – in scope
http://www.root-dnssec.org – might have, still pending determination
http://www.internic.net – might have, still pending determination
http://nomcom.icann.org – might have, still pending determination
http://dns.icann.org – might have, still pending determination

Any other domains or icann.org subdomains are out of scope.

We are assuming that the admin interface (exposed to admin users) would be only available in English language. Please confirm.

The admin interface must minimally be available in English. It could also be presented in other languages. Note that certain requirements such as 3.4.1 (Provide back-end mechanism for administrator to correlate translations of taxonomy terms.|Provide back-end mechanism for administrator to correlate translations of taxonomy terms.) would require the management of non-English languages and their scripts within an English admin interface. Note also that a significant amount of non-English content would need to be managed within an English admin interface.

A bridge has to be created in between the new system and Confluence WIKI. Does the integration between the new system (what content to be shown on the main site) and Confluence has to be fully automated (Synchronization daemon runs which keeps synching the content between the two systems)? Or should it be a manual activity (Admin staff exports the content in an XML format and imports it in the system)?

The integration needs to be automated to the extent that once the content of a wiki page or section is designated for export into the CMS side, updates to that content on the wiki side need to be reflected in near-real time on the CMS side. To the extent a synchronization daemon achieves that, it would be appropriate for inclusion in a vendor proposal.

The role of admin staff will be to set up and populate pages and sections on the wiki side, and then designate which wiki content should be exported into the CMS side. The CMS side needs to be able to automatically receive and parse the XML containing the content in near-real time, then present the content within the surrounding look and feel of the redesigned website.

In summary of requirements it is mentioned that content administrator should be empowered to aggregate the content. Does this mean that administrator should be able to group the content (may be by tag, type, Author …)?

Yes, by tag, type, language, date range, etc. For example, note the various aggregations of “Announcements” by date range and language seen via http://www.icann.org/en/announcements/index-2010.htm

It is being assumed that ICANN.org will continue with the same set of third party providers like Brightcove, Flickr…. Please confirm?

Yes.

How do you envision Site Tracking to be done? Would you be open to Google Analytics?

Site tracking is out of scope for the RFP. We already gather and analyze logs using Splunk.

Would the users or content (in addition to confluence) be shared between sites?

Only content would be shared. And content Sharing would be one-way, from wiki to CMS. Sharing of users or single sign-on is out of scope.

Site exposes pages like http://icann.org/en/registries/rsep/ and http://www.icann.org/en/registries/rsep/submitted_app.html. Do you intend to keep them as plain static pages? Or you intend to create interface (create seed entities to accept things like Registry, ) for generation of such pages?

Under ICANN’s usage of the term “static,” these pages would be dynamic, because their content would reside in a database and be retrieved for presentation dynamically within the site theme each time a user visits the page. Likewise, changes to the content by an admin would be automatically and dynamically presented to the user.

When maintained on the wiki side, these pages would still be manually populated. In this particular case, there would not be discrete database entries for each row item seen in the tables on these pages. The tables would be marked up manually in wiki markup or using a rich-text table builder.

Confluence wiki is, however, capable of automatically aggregating content from a database into dynamic listings that we might want to export via XML into the CMS side. See for example: https://community.icann.org/display/tap/2004 – We might want to export the list seen on this page into the CMS side for presentation on http://www.icann.org

On the CMS side, pages like this will not always be manually populated. Note that pages like http://www.icann.org/ru/announcements/ would be generated from a set of database records. In this case: Every page or file tagged as “Announcement,” across the date range 1998-2010, and whose language is set to Russian is presented in the aggregation.

Note also requirement 13.1.2, which states “Provide ability for administrator to add new content containers …” These new content containers could require creating new seed entities or referencing existing seed entities.

In the RFP it is mentioned that we need to have multistep/multipage submission. Is this required for all content creation form? Please clarify.

This is not required for all content creation forms but we still require the capability. Many will be single-page forms. Only some will me multistep/multipage.

RFP talks about the requirement per which generation and transmission of granular and customizable external feeds in XML is required. Can you please elaborate on this? How will this be used?

We will need feeds like these, which are fairly simple RSS: http://www.icann.org/en/rss/

We will also need sophisticated full XML export feeds, such as http://cartagena39.icann.org/cartagena39/schedule.xml

These feeds will be exported for public consumption and for whatever uses the public wishes to employ them.

From the outlines in the documents it seems that ICANN is interested in developing mobile versions of website (and not the native version). Please confirm.

The question is unclear. Perhaps it will lend clarity to state: We want both desktop / laptop and mobile displays for the website. We will maintain the same content but want it presented differently for each of the two types of displays.

We are assuming that all the currently available languages are to be supported in mobile site, too. Please confirm.|#57]

Yes.

Do we need to expose all the features on the mobile version of site too? Or we need to just expose a limited set of features? Please elaborate.

The features that need to be exposed on the mobile expression of the site are listed in the XLS that accompanied the RFP, under the column heading “Mobile Device Display.”

Answers to Questions Asked After the RFP Deadline

I see that the date when proposals were due has passed. How many proposals did ICANN receive, and who bid on the project?

Unknown to ICANN, our RFP was posted on RFPdb.com. We had hoped to receive 10 proposals, and received 25. In alphabetical order, the responding vendors were: 3Si2, Achieve, Advanced System Software, Andalucia Web Solutions in joint venture with ForLinux, C3i3, Cactus Soft, Chapter Three, Civic Actions, CNP Integrations, Database Publishers in joint venture with Cabengo, Dogs of Design, Forum One, Four Kitchens, Fragment Labs, Glen Echo Group, imagistic, Infobeans, ProPeople, Pyxl, Revere Group, Stigasoft, Vibrant Creative, WiiKno, Zemoga, and Zivtech.

This response makes the bid truly international, since the companies in the list originate in North America, South America, Scandinavia, Europe, Eastern Europe, and the Middle East. We’re pleased and honored by the response.

What should the responding vendors anticipate from the evaluation process?

As you can see, our evaluation committee certainly has its work cut out for it! We have several internal steps to go through now. We will evaluate the proposals applying all the criteria mentioned in the RFP, plus common sense criteria such as the evident quality of the vendor’s RFP and past work. First we’ll reach a “short list” of the top 3 candidate firms. We are targeting Feb. 4 as the date when we announce that short list. It will be posted here immediately after the three candidate firms have been notified.

We will then interact with the three firms, as we’ll have follow-up questions and may seek added details in order to ensure we fully understand their proposals and what it would be like to work with each organization. Where feasible, we may seek face-to-face meetings with them between February 7 and 11. We also plan to check references and background. We are working toward the goal of making a final vendor selection by Feb.18.

At that point, our legal department would seek to contract with the chosen firm. We expect to have a developer engaged by March 4 (a Friday), and would start work immediately thereafter. Be sure to watch this page for further announcements.