This request for proposals (RFP) for a new DLF website. There are two documents: the use case scenarios and the request for proposals.
The documents are available in a variety of formats. The PDF version should be considered the most reliable. The native format is Apple Pages, which has been zipped together so that both parts of the report are in one file.
Request for Proposals as PDF | | Use Cases as PDF | | Pages versions of both documents in one ZIP
Overview
A mindmap diagram used as a handout at the DLF Spring Forum BOF. It provides a bit of an overview of the DLF website envisioned by the RFP and Use Cases below.
Guidelines for Proposals
Intent to file a proposal (a note with a contact name, email and phone number) shall be sent to Barrie Howard at the following address: bhoward@diglib.org, on or before Thursday, 26 June 2008.
There will be a conference call option made available on Monday, 30 June 2008 to allow for clarification and responses to any questions raised. Questions sent to Barrie Howard via email will be answered, with responses posted to this web page, so that all respondents have the same information.
Final proposals are due to Barrie Howard, bhoward@diglib.org (or, if via snailmail, Barrie Howard, Digital Library Federation, 1755 Massachusetts Ave, NW, Suite 500, Washington, DC 20036) by Thursday, 17 July 2008. Proposals must comply with the requirements presented in this document.
The proposal shall include:
- description of the organization/company and its staff (including names/URLs of previous projects completed)
- plan for the project and method of work, including any variance from the proposed timeline
- response to the requirements, including detailed notes of concerns with individual requirements
- proposed price: a) for software development and launch into production, b) for monthly technical support, c) for monthly hosting
- description of technology to be used
- description of software from third parties to be used
- hardware and software requirements of the server where the software will be installed
- hardware and software requirements for the client using the software
- characteristics of the hosting service offered or recommended
- any additional resources the respondent offers to the project (work study student time, for instance, or usability testing)
The selection shall be communicated to all persons who sent a proposal, no later than Thursday, 31 July 2008.
Vendor Questions
Questions
Budget
DLF has earmarked some funds, but we are not a huge enterprise (we don't intend to spend $50,000 for example). We are price-sensitive. We are counting on vendors to let us know what the cost will be.
Open Source
We do consider using open-source solutions core to our development. We need to walk the walk with regard to open source and be able to share code with members.
Working Across the World
No problem to work with organizations across the world.
File Formats
For the most part PDF, PPT, and DOC. But we see many other file formats. We can't predict all the formats that may be important over time, and require that the system be able to allow any format.
DLF can envision hosting three types of files from its website:
- static - change little over time and maintain currency (HTM organizational bylaws)
- transient - short lifecycles eventually being taken down, archived, or repurposed (DOC project proposal)
- curated - lasting value with content embedded in format requiring migration over time (PPT Forum presentation)
0.4.1. What is the mix of HTML and other file content?
The current site has roughly 11,000 ".htm" or ".html" files.
0.4.2. What are peak traffic numbers? Is there a "digg effect" during DLF Forum periods?
While the traffic does clearly increase during the run-up to and fall-off from the DLF Forums, we don't yet have peak loads in terms of hits/minute or max connects. We will try to provide some numbers here when we dig them up. However, the DLF site is not a very high traffic site. In the scheme of things it is a moderate traffic site that most single server solutions should easily be able to cope with. If the "digg effect" buries us some day, we'll celebrate our success!
1.1.1. Could we spec Firefox 3 or IE8?
Sure, but realize that Firefox 2, Safari 3, and IE7 would still be our baseline; everything on the site should work from these browsers. If the site also works with FF3, IE8, Opera, Flock, and so on, that is great and we will be very happy, but it is not required.
1.1.2. Does editing of the "skin" need to be through templates in the CMS?
Editing through templates would be acceptable. But it would also be OK to require direct editing of CSS and HTML files through a back-end SSH transaction or the like.
1.3.1. How much optimization are you looking for to become the top hit on search engines like Google?
We are not going out of the way to be the top hit here. We just want to be able to use reasonable search optimizations like sitemaps to improve the way crawlers comprehend our site, not necessarily to position ourselves all that much more highly in the results.
1.4. Which browsers are targeted for editing?
The same set as in 1.1.1.
''1.7.1. Any examples of what "paragraph level" comments means? Does this apply to uploaded documents or just to CMS-based content?
This only applies to content out of the CMS. A nice example of this in use would be John Wilkin's blog.
1.8. Do you literally mean a wiki engine must be used for this content?
No, any other engine that can provide services similar to a wiki would be fine. Key are multiple users editing a whole page, a history of changes, the ability to roll back, etc. But you don't have to use a wiki engine to accomplish this if you have another solution to propose.
''1.8. How sophisticated does the solution have to be with regard to multiple simultaneous edits of a single page?"
The groups editing these pages will be fairly small and widely dispersed. Multiple simultaneous edits will be uncommon. A simple warning that such a thing has occurred with an opportunity for the user getting the warning to manually resolve the resulting conflicts would be sufficient. We are not requiring automatic resolution of simultaneous edits. A simple locking mechanism to prevent simultaneous edits would also be sufficient.
5.1. Does the system have to be able to route input from forms into a database?
No, while helpful such functionality is not required. A simple ability to route form input to email should do the trick for us. We are also no longer producing a newsletter, so we don't need to track subscribers and the like. We probably could use a function that mirrors group members into associated mailing lists, but event that is not essential.
5.5. Do you want the site to conform to A, AA, or AAA?
We are also just developing our understanding of the W3 accessibility guidelines, so we really can't answer this question very well. We find some of the guidelines may rule out some open source solutions that we would rather not rule out at this stage, so we are not seeking complete conformance. We'd like to just say that we are looking for solutions that conform as well as they can to these guidelines, we are about the guidelines, but consider this a "desirable" at this stage.
5.5.2 Does this mean you want an alternate "print view?"
Not quite. We want users to have the ability to switch to an alternate skin that still includes all the navigation elements (sometimes often left off of "print view" skins) but simplify the design so that screen readers and users with visual challenges can read the output. Usually this means an alternate view with a simpler design in larger fonts with high-contrast colors. More can be found at the W3 accessibility site about this notion.
Deliverables: What does delivering a migration of legacy content involve?
This could be as simple as keeping legacy content online at the old URLs while creating the new site in a parallel namespace. The key content we would like to see moved to the new CMS would be the DLF Forum content: meeting schedules, presentations, and the like. It will be very helpful if your solution includes a strategy for moving this material to the new system.
Deliverables: I notice you are experimenting with CrowdVine, do you need this integrated and moved to the new CMS?
No. Things like our use of CrowdVine are experiments and we don't expect you to merge that content into our new site. Only content from http://www.diglib.org need be included in any migration.
Deliverables: How much input will there be from other parties, like the membership?
We do want to include the membership and groups like our executive committee in the review process. We expect to share the beta site with them and ask for feedback, perhaps to a bit of usability testing. However, the main week to week contact during development will be with a relatively small group (Barrie (manager), Eric (consultant), and perhaps Peter (director)).
Deliverables: How strict is the timeline?
We would like to have at least a beta site for our Fall Forum meeting. We understand that our timeline might be ambitious and welcome any changes you would propose. Just be clear about any variations from the timeline we lay out and explain why you think they are advisable. We will weigh this when we review proposals.
Proposals: Do you want specifics about the hardware requirements, server sizing and such?
Yes.
Proposals: Do you want proposals for 24/7 tech support?
We don't think 24/7 support should be required, remember, we are looking for the simplest possible solutions; solutions that our own tech-able staff can support as much as possible. That said, feel free to propose whatever support you are willing to provide. You might want to offer a 24/7 alternative a price A and a 48 hour alternative at price B, for example. Letting us know what you can do won't hurt.
Proposals: Are you looking for the vendor to provide network security monitoring?
No. We don't expect vendors to maintain intrusion monitoring and the like. In fact, our network security needs are probably less aggressive than some you see out there. While some of our data will be sensitive to the working groups creating it, we don't anticipate any of it will be sensitive in legal privacy terms. We expect to maintain our own security monitoring at this level.
Use Case C: What are you trying to convey with this use case?
Basically, this one shows that users from outside the organization, its membership, or its working groups can still find information about its initiatives on worldwide search engines. The site must be open to this sort of indexing and allow working groups to mark certain key information "public" so that this can be the case.
Comments
Anyone reading these documents is welcome to leave comments below. Thanks! ...Eric
Charles Blair / 24 April 2008 / 13:53
With respect to the first use case, the first thing member needs to do is find the link to the Forum. This is one of the most time-consuming things to do in the current site, unless you've been there a few times and know where to look (way up at the top in teeny tiny font). This is the first thing I would address.
T.J. Cook, HiDef Web Solutions / 02 July 2008 / 12:51
Hello Eric and Charles,
In reviewing the use cases and RFP again today in preparation for preparing our proposal for the project, I'm curious if you could provide examples of this action taken by members: "Working groups of DLF often go to outside sites for basic workgroup services and even to share their output."
There was once a university I attended that first constructed buildings on campus without sidewalks, then "piloted" them for students for a month or two, letting the students' travel patterns between buildings determine where to put the sidewalks. I'm thinking that where the membership is going right now to achieve the collaboration they want can really shed some light on what functionality we want in groups specifically and for the rest of the site.
So any light on what tools or kinds of tools members are going to outside the site right now?
Thank you, T.J.
efc / 07 July 2008 / 11:40
Hi TJ, sorry for the holiday delay in responding!
Barrie will have more to say on this, but I know that some working groups have used PmWiki at the University of Minnesota, BaseCamp, and a Confluence wiki in the past. It's a bit all over the map. Satisfaction was never terribly high with any of these solutions, partly because it never integrated very well with what other groups were doing. These spaces also all felt "outside" the DLF umbrella, and as a result a bit like a sidelight rather than the main event.
That's my take, anyway.
Barrie / 08 July 2008 / 08:02
Hi TJ, et al,
Eric is spot on.
- Barrie
Kim Ryan / 08 July 2008 / 08:20
DLF Team Our team has reviewed the DLF RFP in-depth. As our team leaders develop a strategic game plan for DLF we are concerned about keeping our recommendations under the $50,000 mark. It was mentioned on the 30th conference call that DLF is price sensitive and as an organization we understand.
One major impact on pricing is entering all the content you currently have. Is the DLF team willing to enter all your content on the site through a CMS solution?
Lastly, can we bid on the hosting component only? Thank you. Kim
T.J. Cook / 10 July 2008 / 11:18
Hi Kim,
I believe the desire to see content migrated from the old site was not a requirement. If I'm right (and Eric, correct me if I'm wrong), budget is a primary concern but they want to get everything they can for the price they can afford. The most cost-effective solution for the old content would be a link to the old site as-is. However, if a company bids on this project and shows a cost-effective way to get that content integrated into the new system, or at least a method for doing so as you allude to in your post, that'll help that company rise above the others.
Did I get that right, Eric?
Barrie / 14 July 2008 / 07:27
Hi Kim, TJ, et al,
TJ has reiterated our point about how to handle the old site content nicely. DLF assumes its staff will take a lead in migrating much of the content. However, there are tens of thousands of files. So as TJ mentions, a bid with a cost-effective integration solution will get noticed.
- Barrie
/wiki/dlf/rfp