We require web application development for an online petition system. The system will be hosted by us and integrated into several client websites. The aim is for clients can add an electronic petition system to their existing website with minimum integration effort.
We have no preference as to the language or framework used for the system. The key requirement is that it is easy to integrate into a wide range of client websites.
We would expect the backend database to be MySQL although we are open to alternative suggestions.
## Deliverables
# Introduction
We require web application development for an online petition system. The system will be hosted by us and integrated into several client websites. The aim is for clients can add an electronic petition system to their existing website with minimum integration effort.
For clarity we will use the following terms in this document:
**Site** - Our online petition system http://subdomain.online-petitions.co.uk. This site will not normally be accessed directly by the public; it will be integrated into client websites. All processing and database will be hosted here.
**Client** - Owner of the website that includes our petition system. They will also administer the petitions on their website. Their website is [[login to view URL]][1]
They will setup a DNS alias [[login to view URL]][2] for the petition section of their website, this will redirect to [login to view URL]
**Petitioner** - Member of the public who creates or signs the online petition.
**Administrator** - Our administrator who can manage client profiles. Define the color scheme, fonts and logo so that the system matches the client website.
# System Overview
A new Client will request a petition system for their website. Our Administrator will create a new client profile on the website. This will create an alias [http://example. [login to view URL]][3]
Where "example" is the client name. The client will then create a DNS alias for their domain and integrate some code into their website to link to the petition landing page for the domain.
We have no preference as to the language or framework used for the system. The key requirement is that it is easy to integrate into a wide range of client websites.
We would expect the backend database to be MySQL although we are open to alternative suggestions.
# Backend System Functions (For our administrator)
* Specify client email address for receiving email alerts.
* Specify client email name for confirmation emails. For example when we send the automated email to a new signatory the From email address would be <clientname@[login to view URL]> and the email name would be "Client Name"
<!-- -->
* Edit style CSS so that petition system matches look and feel of client website.
* New petition signatory receives email with a link to confirm signing.
* The template for each aleart email should be editable on a per-client basis.
* Specify threshold for number of signatures when email alert is sent.
<!-- -->
* Email Alerts:
* Client receives email when new petition pending approval
* Petitioner receives email when petition is approved or rejected.
* Client receives email when signature threshold passed.
# Petitioner Functions
View Open Petitions
View Closed Petitions
View Rejected Petitions
Filter and sort the petition view by:
? Signatures
? Closing Date
? Most Recent Petition
? Most Popular Petition (most signatories)
* Create a new Petition
<!-- -->
* Receive email when pending approval
* Receive email if approved
* Receive email if rejected
* Sign an open Petition
(Requires input of name, email, address. Only the signatory name is publicly displayed)
# Client Functions
Client should have same features as petitioner, plus the following functions:
* Log on to system.
* Approve Petition.
* Reject Petition.
* Edit Petition
* Edit signatory (eg to remove profane names)
# System Enhancements
The developer may bid to include the following enhancements at this stage, or they can be included at a later date.
* RSS Feed of Petitions
* Facebook Integration
* Email alerts signatory with news of petition
* Include list of standard reasons for rejection to be selected by client administrator.
* Include list of client departments that petition should be directed towards (eg Housing, Highways etc) - Configurable on a per-client basis.
# Reference
Existing electronic petition websites with similar functions to what we are looking for.
<[login to view URL]>
<[login to view URL]>
<[login to view URL]>
<[login to view URL]> (New petitions closed but old ones available for reference)
* * *This broadcast message was sent to all bidders on Monday Oct 11, 2010 2:36:39 PM:
Could all bidders please comment on the suitability of ajax for this application; if suitable please showcase work you have done in ajax. Could you also please suggest you approach to integrating this system into client websites. For example by using form and cgi "post" or perhaps using iframes. If you have not already done so can you please also provide a time estimate for this project. Thanks !
* * *This broadcast message was sent to all bidders on Tuesday Oct 12, 2010 12:29:10 PM:
Dear All,
We have some additional requirements from a client which I have listed below. If you would like to adjust your bid to take these into account please do so.
Additional requirements:
1. Petitioner should specify closing date when creating petition. Client has the option to edit this date in the administration area.
2. Petitioner has the ability to upload supporting documents or photographs when creating or editing the petition. Client can also add/remove documents from the petition.
3. Facility for the client administrator to send email from the administration area to the petitioner (petition creator)
4. Facility for the petitioner to edit the petition before it is approved. I think this may be done by automatically email the petitioner an "edit link" and random password. This may be easier than having full accounts for the petitioner. Although I'm open to suggestions on this. Points 3 & 4 will provide a neat work-flow, so petitioner can create a petition, the client administrator can give feedback and the petitioner can change the petition before it is approved.
5. Search box when looking at petitions. This can be "title only" or "full text" the search functions can be used by members of the public or client administrators.
6. Enhancements to email alerts to include: Petitioner and Client receives email when closing date passes. Client only receives email when signature threshold passes. There should be several thresholds configurable per client. For example alert when petitions receives 100, 200, 300, 400 signatures - 5 Thresholds should be enough for each client.
7. Basic reporting function for client administrators. Client should be able to download a document showing summary of all petitions and number of signatures, closing dates etc. This could be csv file. It would be desirable for client to be able to download each petition in doc/pdf format showing petition text and signatories in columns to fit A4 paper.
8. Client administration option to manually add a paper petition. This would be the same as creating a new petition, but the client administrator would have the option to add signatories in bulk (text entry field) without email verification.
Thank you for your replies regarding Ajax. The consensus is that it is not necessary as we are not doing asynchronous data transfer. Please provide details on the frameworks and languages you intend to use, for example JScript, ASP.Net and and suggestions requirements for CMS etc.
We are looking for the project be delivered in 30days of bid acceptance. We also require a mock up of the client and administration features to show the client within 10 days of bid acceptance. Please let me know if this is possible.
Finally my preference is for a coder who can give this their full time attention, rather than working on it part time after work. Please highlight this if you are able to do so.
Thanks again for your time.
Regards
Ed Sturdy