Cyfanswm maint neu gwmpas y tendr
The work includes the provision of both an English and a Welsh language version of the service.
Publication of consultation materials via website
● A stand-alone website, separate from a Commission’s regular corporate site
● Must display both narrative text (existing electoral arrangements, draft proposals, final recommendations and in some reviews, revised draft proposals) and visual scalable interactive mapping to accompany those, i.e: background mapping (preferably using OS vector map API), togglable overlay display of ‘layers’ for existing boundaries and names for principal council areas, existing electoral wards, communities and community wards, plus proposed, revised and recommended electoral wards, communities and community wards (including numeric data). Text and maps will also be available as downloadable files, with boundaries available as downloadable ‘shape files’.
● Visual representation of consultation responses previously received, by use of ‘hot spot’ indicators on the map for each response received (located using postcode provided) - hovering over hot spot displays first few lines of text of response, clicking on it takes you to full response. Categorise responses by consultation stage, and allow filtering of hot spot display by stage.
● Published version of consultation responses should not contain any personal data (name, detailed physical address, or email address), unless respondent has specifically opted in to publication of their name (see below).
Public search and Submission of consultation responses via website
● Site must have a ‘How to’ guide available detailing how to use the site, and particularly how to submit a response (text, screenshots, and potentially animated video guide).
● From the front page, public user must be able to access their area map and info about it by entering their postcode, or by selection of their local authority (drop-down lists).
● Public user must also be able to browse and filter consultation responses previously received using metadata tags applied when the response was received (see below). Should also be able to browse using visual ‘hotspot markers’ on the map (see above).
● Site should allow for user printing what they can see on-screen.
● Website must allow for public submission of consultation responses during defined date ranges of the review period (switching on and off of consultation function by pre-programmed dates).
● During a consultation period, whilst looking at the proposals map on the website, a respondent must be able to simultaneously type in their views, which will then be electronically submitted to the back-end database.
● When selecting that they wish to submit a response, the user entry fields must initially request that they confirm the area to which their comments will relate. Prompt to user to click or specify area their response relates to.
● If the response relates to a specific area, the user must be able to denote the area by clicking on the map, which the system must then be able to use to ‘tag’ the response with markers denoting the ward, existing and proposed, to which the response relates. Default to centre of map area looking at currently, but over-writeable manually by user.
● Tagging must indicate a) existing electoral ward, b)communities c) community wards,
● If the response relates to multiple areas, user will need to indicate this and manually select the region and council area(s) their response relates to (from a drop-down list - selection of multiple areas within a local authority area will need to be possible).
● User must be required to provide the following information in addition to a free text field for the substantive response (with a character/word limit of about 500 words): Name; Full address and (separately) postcode; email address (required only if they want unique response code emailed to them).
● In addition to their own name, user must be given the option to provide the name of an organisation on behalf of which the response is being submitted (if they are authorised to do so). Tag also by organisation type. This organisation name will be published.
● Service must also allow a consultation respondent to attach files for upload, which system must attach to the main response.
● Respondent name - Explanatory text must clearly specify a) that the name will not be subsequently published unless the user expressly opts in (and provide a check box option for them to do so), and b) that user may provide the name of an organisation they are responding on behalf of, rather than their own name.
● Address and postcode - explanatory text must specify that only the latter part of the address - i.e. village/town/area name and above will be published.
● Public user must have the opportunity to provide feedback on the website experience via completion of a satisfaction survey, response to which must be available to Commissions for analysis with a view to continuous improvement of the service.
Back-end database functionality
● All consultation responses must be stored in a back-end database to which designated Commission users must have access.
● These user accounts will require different access levels (e.g. staff will require edit access, whilst Commissioners will require read-only).
● Must be able to export data to Microsoft Dynamics
● Responses submitted through the portal itself must automatically be stored into the database, with meta-tagging applied according to the local area to which the response relates (see above).
● Electronic responses received outside of the portal (e.g. emails, scanned copies of hard copy responses, pdfs of hearing transcripts) must be able to be manually entered directly into the back-end database by Commission staff.
● System must store petitions as single entry (tagged specifically as a petition) under name of petition organiser, but ‘count’ for number of responses as the number of signatories to the petition.
● Identical individual responses (i.e. letter-writing campaign) must be capable of being linked in the system as a single initial ‘parent’ example, and subsequent individual ‘children’.
● Entry of a response into the database, whether automatically or manually, must allocate the response a unique consultation response number, and automatically trigger an acknowledgement email (and on screen message for portal submission) to be sent to the respondent’s email address, with details of date and time entered into the system, and quoting the unique response number.
● Responses in database must be able to be published back out to the public-facing front end of the portal at defined times in the constituencies review, to facilitate future consultation. NB: published responses must not display respondent’s name (unless respondent specifically opted in), early part of physical address, or email address (see above).
● System must allow a staff user to view, edit, and download full details of any individual response received, browsing and filtering by any of the tags applied, and running of basic statistical reports.
● System must allow linking with public hearing videos (available on another site) and recording of basic details of these responses manually within the database. NB: each public hearing submission is a separate response (i.e. not one response for whole hearing!)
● At end of contract, all database content must be extracted and submitted to the relevant Commission in searchable CSV format, with any files uploaded alongside responses remaining clearly associated with the relevant unique response number.
● Consultation portal must have the ability to link-up with our advertising strategy to enable monitoring of the channels that people are using to access the site.
|