There are two tasks needed for a client, one of which entails SilverStripe 2.4.5, one that entails Constant Contact integration, both for the same website:
1. The client would like to add at least 2 (with the possibility of adding more) graphic ads to their homepage which will rotate every 4-5 seconds (fade in/fade out effect). Each graphic ad will also have a link associated with it in which the link will open in a new tab. Client will be able to add the graphic ads and links in the SilverStripe backend. This will only apply for the homepage.
2. Client would like to add a Constant Contact email sign up form on the site. Must integrate with their Constant Contact lists. We will add an icon to the header of each page and when the user clicks on the icon they will either be taken to separate page to add email address or they will receive a pop up window to add email address.
1. We are looking for fixed price proposals. The design document is very detailed and should you be selected as a finalist, should provide you all the information you need to accurately quote this.
2. We assume that all bug fixing by you and identified by testers will be included within the project price.
3. We ask that all developers on our fixed price proposals expect reasonable time for revisions and changes – generally three rounds of revisions – two by us, and one by the client. Any changes that represent significant new functionality that were not explicitly defined at project outset will be quoted as a new project, but any changes requests that are made because functionality was not implemented as requested in the original specs will not be considered billable. Additionally, we ask that you quote assuming some subjective changes to the project as well where requirements are subject to interpretation.
4. There is no perfect way to present requirements, as well know, so we expect that developers will question anything that they are not sure about, that would create code that is not scalable or well built, and that they will use common sense in development so that code is modular and based on good OOP principles.
5. The developer is expected to be clear about any code they are reusing from any previous projects, especially in a way that would compete with this project. If you have prior code you have used that you will contribute to the project to reduce cost, please document what that is. If you have used any code in prior projects, please be clear about that. Although we are open to receiving a project based on prior work, it is our intent to obtain all source code with the project as well as the right to use, modify and extend that source code as we see fit.
6. Certain functionality in the project that is defined in the design document is unique. Therefore, we expect that you will program that functionality on a “work for hire” basis – i.e., you will not reuse that code or reshow that functionality without our prior permission. This does not apply to configurators in general but to the particular functionality that we have planned for this one.