Our end product was predominantly made with accessibility in mind. This is why it was crucial that we tested regularly with end-users while also consulting professionals in the field of accessible technology. We also ensured we were following the accessibility standard WCAG 2.2.

We had weekly meetings with industry professionals (GDI Hub, SoundScape, Esri UK) who had been developing with accessibility in mind for years. We also got help from a blind user at the beginning of the project to help us establish requirements, and also had 2 testing sessions (predominantly UI-focused), first with non-visually impaired and then also with 8 visually impaired users. The visually impaired users found the design clear and intuitive, and especially found the focus mode and the dark theme very useful. The general feedback was very good, as the users found the high costumizability incredibly useful, while at the same time not finding the design too cluttered due to our "hide sidebar" feature. Even when asked to be very critical, the testers gave our design an average score of 8.2 / 10. We also got great feedback on this front from our partners who specifically complemented the clean and familiar design, and user-friendly features such as marker clustering.

With this in mind, we give our User Interface a score of great.

We successfully implemented all functionality according to our MoSCoW requirements. Our widget has touch-screen and voice-activated functionality, while also having a variety of customizable accessibility-friendly end-user tested features that allow easy use (high-contrast dark theme, yellow theme, focus mode, dyslexia-friendly font, marker clustering, what3words support). The integration with what3words also allows the users of the widget to quickly talk about their location in case of an emergency. We also have a community-run feature where users report additional accessibility information, enriching our datasets.

Furthermore, the geolocation API automatically finds the user's location, while the integration with GoogleMaps's API allows for street view and navigation.

With this great variety of functions, we give ourselves the score of great.

Throughout the development cycle, our team followed strict testing conventions for the backend, ensuring the database and the API were properly tested with Unit tests. We also noticed no performance issues with larger amounts of data.
As the most important part of our product is a frontend component, most of the testing was done by manual user testing. This was conducted weekly by the team and clients, and also three times by the end-users. All the bugs we discovered in these sessions were addressed.

With this in mind, we are confident in our system's stability and give ourselves a score of very good.

The system is very efficient and works perfectly also on less capable devices. We took care too call the GoogleMaps, Azure Speech and what3words APIs only when necessary to avoid any latency problems. We also ensured that only data within 10 miles of the user is displayed on the widget, ensuring fast load times. However, when deploying on Azure, we had to settle for a cheaper plan to save cost, which could be a problem if in the future the traffic to our API becomes too large.

We give ourselves the score of very good.

Our widget can be easily integrated into any webpage as a React component and adapts to fill the designated area on websites that support React. Our database migration functionality also allows for backward compatibility of the system. However, note that the widget is more suited for devices with the landscape view rather than portrait view.
We recognize this as quite a significant shortcoming, as it allows users to plan their journey at home on laptops, but only allows users with tablets to actually use the widgets on the go. Furthermore, when testing with different browsers, we realized that even though the widget works perfectly on the most popular browsers (Chrome, Safari), however, the text to speech does not work on Firefox. Even though this is not our fault, but the Azure Speech SDK - which is the UCL preferred web service, it is still a shame.

Neither mobile support nor packaging the final product as an npm package were in our Must-haves or Should-haves. However, as the project developed, we realized that in order to have a very usable product, we would have to package it up. Unfortunately, due to numerous type errors when trying to package the widget, we were unsuccessful. Because this was our priority, we also did not manage to implement mobile support. Because of this, we give ourselves only the score of adequate.

We took great care to make the backend as scalable and maintainable as possible. That is why we implemented database migrations which would allow storage of even more accessibility-related features for each datapoint in simple way. We also developed a sophisticated API framework that allows us to easily issue new API keys of different access level. This ensures maintainability of the system when both the number of users and features grows. The backend adheres to good coding practices and is well documented.

However, there is room for improvement, especially in the widget code. Even though adding new data layer functionality is relatively simple, the code should have been documented better and more effectively split up into individual files for clarity.

We give ourselves the score of good.

The project was well-managed with regular updates and clear communication between team members. We conducted weekly half-hour meetings with our partners every week before our lab sessions. This allowed us to get constant feedback throughout the project, while also forcing us to have something new to demo and show every week. The convenient time of the meeting before our sessions also allowed us to split the workload for the next week after getting feedback. We had a developer groupchat where internal deadlines were set and specifics were discussed. We also used GitHub's issue tracking functionality for major changes.

While we did manage the project well, the whole process could have been improved by also opening GitHub issues for smaller additions for better clarity. We also did not enforce internal deadlines harshly enough, which meant that workflow was significantly more congested close to deadlines.

That is why we give ourselves the score of good.