Support with front-end software development

Tender description

Summary of the work Proven, innovative and leading-edge front-end development services are sought to help expedite the development of an in-house data collection/workflow prototype into a fully-responsive, production-ready SPA. Expected Contract Length 3 months Latest start date Thursday 3 August 2017 Budget Range In the region of £100,000. Why the Work is Being Done This work directly relates to the West Midlands Fire and Rescue Authority's "Third Platform" programme - several inter-related projects with the common aim of modernising key services. Specifically, this work relates to our "Mobile First" stream - and will contribute to the Authority's vision of 90% of all front-line data collection being undertaken on mobile devices by May 2018. Ultimately, this work will enable us to benefit from modern technology to improve the processes associated with our core purpose of making the West Midlands safer, stronger and healthier. Problem to Be Solved Today's modern Fire Service has an increasing need to collect timely, relevant and often critical data from its front-line teams... yet the time operational personnel spend with a PC is time spent away from the communities they serve. We require talented and experienced front-end developers to develop a robust web-app which will allow our employees to interact with an existing REST API. This fully-responsive SPA will offer Auth0-based authentication, dynamic form-rendering, search page and to-do list. We have already have a POC - we require assistance to build a production-ready MVP that we can easily extend through new components. Who Are the Users This work is to produce a common front-end to a universal data-collection and workflow SaaS. As such, it will be used by almost all of our employees. Some examples: As an operational firefighter I need to submit data as efficiently as possible, so that I can concentrate on front-line service delivery. As a Hydrant Technician I need to be able to quickly access the state of nearby hydrants so I can make more effective use of my time. As a Fire Safety officer I need to complete my assessments and enact any necessary prosecution workflows in a timely manner. Early Market Engagement We sought early validation of our timescale-estimates from a supplier that undertook a code review of the server-side (Node.js) component of the project. Based on the feedback received, it is considered that 3 months for 3 front-end developers to develop the required MVP SPA is a realistic expectation. Work Already Done For this third iteration of our data-collection platform, we recently completed some 3+ years' worth of research and prototyping. Using JSON Schema to dynamically render form content is the predominant focus of this work. The prototype SPA currently uses Schemaform.io and AngularJS V1.6. We now believe React to be a more appropriate framework for our needs (we may consider Angular V2+, Vue.js or equivalent). Therefore we're looking to incorporate something akin (perhaps extending) React-jsonschema-form. We have recently been accepted on the Auth0 Open Source Programme and will continue using the Auth0 authentication SDK (also proven in our prototype). Existing Team West Midlands Fire Service has its own internal development team of 10 developers (predominantly Java/Spring/JSP/RDBMS skills). The successful supplier will work with team's Software Architect, Development Team Leader and Principal Developers. A critical factor of this work is, that on its completion, the in-house team have will be left with the necessary assets and understanding to evolve and continue the web-app independently. Current Phase Alpha Skills & Experience • Demonstrate deep and expert-level knowledge/experience with a modern front-end framework especially React (or Angular V2+, Vue or equivalent) to solve a complex UX problem • Demonstrate experience incorporating the Auth0 SDK • Be able to deliver modern, performant, user-centred and innovative data collection UX - via a SPA • Demonstrate excellent use of build-chain technologies to minimise development overheads - package managers, CSS pre-compilers, linters, minification tools etc. • Be able to produce consistently high-quality, modular code for non-trivial problems, to agreed timescales • Be able to leave the codebase in such a way that our in-house team can easily continue and evolve it after this work is complete • Demonstrate design principals that will maximise codebase reuse and minimise friction when porting to native mobile apps (Android, iOS and Windows) • Must demonstrate expertise in designing modular, easily extended, component-orientated front-ends • Demonstrate deep experience implementing fully-responsive UI capabilities Nice to Haves • Demonstrate active Open Source contributions / activity (e.g. Github contributions, blogs etc.) • Experience of offline-first technologies such as PouchDB or equivalent • Have published apps to iTunes, Google Play etc. • To have worked with other Public Sector (especially Local Government or emergency service) organisations • Experience designing UX for challenging "in the field" environments • Demonstrate experience with building apps for Windows devices • Experience with dynamic form libraries (preferably JSON Schema-based) such as SchemaForm.io, react-schema-form or equivalent • Experience building cross platform desktop apps with JavaScript, HTML etc. via open source technology such as Electron.js or equivalent • Demonstrable experience with the Mapbox SDK Work Location We are based at: West Midlands Fire Service Headquarters 99 Vauxhall Road Birmingham B7 4HW Working Arrangments Given the nature of this project (and our team's established working practices) an MVP + Agile + TDD approach is considered the most appropriate way to deliver this work. Monthly face-to-face meetings and continual releases are favoured - along with an initial on-site presence of at least 10 days. We use Github (public and private repos) for our source control and Travis-CI.org for testing. Security Clearance West Midlands Fire and Rescue Authority complies with Her Majesty’s Government Security Policy Framework. Compliance with Baseline Personnel Security Standard should be undertaken as a minimum. Suppliers will need to agree to terms as defined by the Authority related to the Data Protection Act 1998 and management of information. Additional T&Cs At all stages of development West Midlands Fire and Rescue Authority will retain all Intellectual Property Rights to code and other assets produced as part of this work. West Midlands Fire and Rescue Authority reserve the right to offer code and assets produced as part of this work under an open source arrangement - most likely by adding an MIT license and publishing a public repository via the WMFS Github organisation. No. of Suppliers to Evaluate 3 Proposal Criteria • Length and depth of experience with React (or comparable front-end framework such as Angular 2+, Vue) and related technologies • Experience and success with similar projects • Size of team and ability to deliver to budget / timescales • Estimated timeframe for work • Value for money • Ability to deliver quality, extensible software that embraces industry best practices Cultural Fit Criteria • Work as a team with our organisation and other suppliers • Be transparent and collaborative when making decisions • Have a no-blame culture and encourage people to learn from their mistakes • Take responsibility for their work • Share knowledge and experience with other team members • Challenge the status quo • Be comfortable standing up for their discipline • Have a strong Open Source ethos Payment Approach Capped time and materials Evaluation Weighting Technical competence 50% Cultural fit 5% Price 45% Questions from Suppliers 1. There is a link to a Q&A session for this requirement but the date is Fri 23rd February. Is that a typo for Fri 23rd June? Please could you confirm the arrangements for the Q&A session. Apologies everyone... that was a hard-to-explain typo. To confirm, it is tomorrow (23rd *JUNE* 2017 @10:30am). All other details are correct:Join by Skype: https://meet.lync.com/wmfs-net/tim.needham/SYZJ1LJ4 or join by telephone: 02034436311... Conference ID: 82512767. Apologies again for any confusion caused. 2. Can you clarify if you only want the app to collect data? How do you want to present the data? Is that in-scope? Withstanding basic authentication, to-list, task-creation and search-result views... the focus of this work is to develop a robust front-end mechanism to download form definitions (JSON) and dynamically render those through definitions via a set of extensible UI components. In the first instance these components will be predominantly data-collection orientated (please see the demos at http://schemaform.io/ to get a feel for a list). However in time (and out of scope of this work) we'll be wanting to add new components... e.g. a d3js.org chart component or similar. As such the app is initially focused on data-collection, but with potential to grow. 3. Is the desktop requirement relating just to the future or for this phase of delivery? In short: a future phase. For this requirement we "only" require the development of a Single Page Application (usable via any modern HTML5-capable browser). That said, it is part of our road-map (out-of-scope of this initial delivery) to offer the same functionality (perhaps with the addition of features such as push-notifications and off-line storage) via mobile apps and maybe a Windows application. As such, we're keen to maximise the reuse *potential* of the codebase/assets produced for this work. We'd like for suppliers to indicate how they might preemptively prepare for such future incarnations. 4. Have you done any work on User Research, e.g, types of users; different needs; user journeys etc? No - not explicitly documented/available for this work. As an in-house development team of some 20 years we have developed a very close relationship with colleagues/users throughout our organisation and the wider Fire Service - this app represents a third-generation iteration for us. Some initial uses of this software (e.g. data collection for our Fire Safety teams) do have user-focused requirements available. That said, we're hopeful the fresh perspective Digital Marketplace suppliers bring will help us avoid complacency. 5. Can we access the information from the POC and discovery? The results of the POC is not available in a publishable form. Briefly (100 word limit here): The core components were Auth0-AngularJS-SDK, Angular 1.6, Schemaform.io, Bower.js, Bootstrap 3. We then added to-do list, task-initiation and search views. All back-end information is served from a REST API using FlobotJS (http://www.flobotjs.io). All API requests require a valid JWT token (Auth0) to access. The POC success encouraged us to continue. Angular V1 seems too slow and incurs a heavy payload/complexity. React or Vue.js seems to address these issues... decision to use/extend an off-the-shelf JSON-form renderer (react-jsonschema-form?) vs. going hand-crafted is to be explored. 6. How do you intend/wish to run the project and working with your team - will this be an agile/scrum project? Our team has adopted Agile and run 10-day sprints, starting every-other Thursday. Suppliers should provide a usable app at the end of each iteration. We envisage suppliers regularly committing to a private Github repo. We will have developers here dedicated to this project. We have used Trello.com and Skype on similar supplier-led projects, which has worked well. We believe the initial sprint will require 10 days on-site at our HQ in Birmingham. We seek suppliers that can work under their own initiative - while also delivering a product that entirely meets our expectations. As such MVP/agile seems the best fit. 7. Q&A session: How big do you envisage the team that you require? Pre-engagement research suggests 3 or so front-end developers for 3 months. But we have had great experiences working with smaller SMEs. 8. Q&A session: Is there an indication of what group of users are likely to use the MVP first? Our Fire Safety teams are likely to be early adopters of the MVP. They will use it to access their prioritised workloads and complete the results of their inspections. All the prioritisation calculations and similar will be undertaken in the out-of-scope back-end work. 9. Q&A session: Is there a continued role for the partner who develops the MVP past the initial 3 month project? We'll need the deliverables of this project to be understood and handed to the team in such a way that it can be maintained/extended independently. We envisage there will be several further Digital Marketplace procurements after this initial work - which will be run as separate requirements on Digital Marketplace and require incumbent suppliers to re-tender. 10. Q&A session: What is the range of devices that need to be supported? Business or personal? Eventually we'd like to support as many devices as possible with mobile/native apps... both managed and personal. However, for the purposes of this work, and in-keeping with MVP thinking: at this point we only require the development of a Single Page Application running within a modern HTML5 Browser. WMFS uses Chrome internally. 11. Q&A session: What is the size of your workforce? West Midlands Fire Service employs just under 2,000 people. 12. Q&A session: How are you considering releasing the app to the workforce? This is an early piece of work to establish an MVP, from which to build-out from. As such we're keen to concentrate on core/generic/low-level functionality and finesse in later iterations - roll-out plans and similar will be the focus of subsequent phases of the project. 13. Q&A session: Do we need to provide hosting? For test environments? No. For production we are looking to serve this on containerised cloud-based infrastructure, which is out-of-scope for this MVP development work. We have commissioned a report by an external supplier to advise on infrastructure considerations (including test/development pipelines), but no work has yet been carried-out implanting those suggestions. We have tentatively looked at using the GOV.UK PaaS platform, but have made no decisions as-of-yet. 14. Q&A session: What data security provision needs to be made? This SPA will only be handling data considered "Official", as defined here:https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/251480/Government-Security-Classifications-April-2014.pdf.Internally, WMFS has sub-divided Official into three levels, with handling requirements placed on each… but from a national perspective the data is all considered “Official”. 15. Q&A session: Would suppliers have access to front-line workforce? For this foundation-laying MVP work, not so much. That said, Fire Safety is strong candidate for initial uptake of this SPA, and we will involve them throughout the process. The back-end is designed to easily adapt workflow/data capture around teams. 16. Q&A session: Do you have any user stories for the MVP? No, given the technology investigations involved, we went the prototyping route and would share that exploratory work with a supplier. 17. Q&A session: Has a decision been made about the framework that should be used? No, but at the moment, React is our strong preference - but alternatives (AngularJS V2+, Vue.js etc.) will be considered. 18. Q&A session: Are there any accessibility considerations? As this is a generic SPA that potentially everyone in the organisation will use (in a wide variety of contexts… in-the-field and at a desk) we will require as much accessibility potential to be built-in as we can. It was suggested similar projects target a "AA" rating, and this seems a good goal to aim for. This said, we can always finesse the components to make them as accessible as possible over subsequent iterations - the intent of this work is to get something robust running, with the ability to be easily (continually?) enhanced in future. 19. Q&A session: Will you have a product owner of the MVP? Given the generic/low-level/technical focus of the MVP the Product Owner will be our Software Architect. 20. Q&A session: How mature are you with Agile? We're 6 months into our agile journey, we run 10 day sprints, have a retrospective/planning day every other Thursday. We use points, have daily stand-ups, we calculate our velocity, the new projects embrace TDD and we work with an industry mentor to help us through. So quite early on, but sticking with it and seeing benefits. 21. Q&A session: Do you have much automation? The back-end piece has many tests with good coverage, and we use public Travis-CI to automated testing direct from Github. Part of the requirements of this work is to help automate the front-end tests and for suppliers to add their experience to our build pipelines. We have used Selenium in our prototype and are keen to build on browser automation. 22. Can you please let us know approximate number of dynamic forms to be built along with complexity of each form based on your understanding? Over the time spent developing our current and previous incarnations of this platform, we've built-up a library of some 140 dynamic forms. It's very rare for one individual to be granted exposure to everything - a typical firefighter role attracts around 30 forms for example. As for complexity, the majority of forms are constructed from a core set of components such as text, number, date/time, radio-groups, check-boxes, drop-downs etc. We'll need robust component/group/form validation and conditional dynamic visibility of components groups. Withstanding discussion around MVP scope: we also support map widgets, API-search components and image maps. Inspiration: http://schemaform.io and https://github.com/mozilla-services/react-jsonschema-form. 23. We are assuming that "via mobile apps and maybe a Windows application" means Windows Mobile App, please confirm? Not exclusively, no. Along with Android and Apple devices, we would like the option to target Windows Mobile apps in *future*. However we have also experimented with Electron ( https://electron.atom.io/ ) for creating desktop apps (e.g. Windows executables) from a shared web-orientated codebase. As per an earlier question, the production of mobile/desktop apps is out-of-scope for this initial work... but how suppliers intend to leverage the same codebase/assets to ease development of apps (mobile/desktop) in future *is* of interest to us at this time. 24. Is experience using a similar SDK to Auth0 (but not Auth0 itself) acceptable? We're seeking suppliers that are comfortable using the Auth0 SDK and are able to incorporate the associated libraries into this SPA as effectively as possible. As such, in this particular area, we will favour suppliers who have proven experience with the Auth0 SDK and API in production environments. That said, we will consider suppliers who have used the Auth0 SDK to some lesser extent (perhaps as part of some Proof-of-Concept work or internal R&D/evaluation). Suppliers will need to show they are capable of maximising our Auth0 opportunity. In-lieu of Auth0... production experience of other comparable authentication services would be beneficial.