EVALUATION

MoSCoW List Achievement



IndexDescriptionPriorityContributorsState
1Simple random sample size calculatorMUSTAadi, Matyas✔
2Systematic random sample size calculatorMUSTAadi, Matyas✔
3Allow users to input the information of their surveyMUSTNick, Matyas✔
4Decision tree to guide user to decide sampling methodMUSTMatyas✔
5Ability to go back to previous stages of decision treeMUSTMatyas✔
6Open API for future workMUSTMatyas✔
7Tooltip to explain users the terminologies and planning processMUSTQiren, Nick✔
8Time-location sampling calulcatorSHOULDAadi, Nick, Matyas✔
9Cluster sampling calulcatorSHOULDAadi, Matyas✔
10PDF export functionalitySHOULDNick✔
11Resources page with educational contentSHOULDNick, Matyas✔
12Support multiple languages (Spanish, French, Arabic).COULDMatyas✔

Key functionalities (Must haves and Should haves) are 100% completed



Individual Contribution

Work PackagesNickQirenMatyasAadi
Project Partners liaison25%15%50%10%
Requirements formulation25%25%25%25%
Research20%30%20%30%
Testing40%10%10%40%
Report Website10%50%30%10%
UI Design35%20%35%10%
Frontend development25%10%65%0%
Backend development and Deployment0%0%40%60%
Video Scripting and Editing10%10%30%50%
Overall Contribution23%19%34%24%
Main RoleFront End Developer and TesterResearcher, Portfolio DeveleoperResearcher, Front and Back End DeveloperBack End Developer




Critical Evaluation

Before getting into the details of the evaluation, we believe it is important to recognise and evaluate not only the tool we delivered but also the learning curve our team has gone through in the last 6 months. None of us in the team has done any web, React, frontend or fullstack development before the project had commenced. Yet, in contrast to our preferences, we were assigned to a project where the final deliverable was a web application. We did not shy away from the challenge and we are proud of ourselves as a team for all the things we learnt and created!

User Experience

As pointed out multiple times under Requirements and HCI, one of our main goals was to develop a user friendly interface that is easy to use but can also accommodate the complexity of sampling. The final UI is indeed simple, anyone can use, but still has a level of complexity with the decision tree and different types of sampling size calculators. Additionally, we developed a custom tooltip to help users look up long/difficult definitions and we are providing user friendly alerts whenever user-input does not match predefined conditions. We can also proudly say that all this was achieved using vanilla Javascript and Typescript. Firstly, we designed the UI in Figma ourselves based on material we learnt from the HCI part of the COMP0016 module, but also based on personal research and experimentation. Second, we developed a UI almost identical to our Figma designs from scratch, without the use of any UI frameworks. Overall, the UI is accessible, modern, responsive but most importantly it fits the needs of the IFRC.

Functionality

We successfully implemented all key functionalities that we formulated during the first phase of the project. As also shown in the MoSCoW achievement table, we not only completed the ‘Must haves’ but also all the ‘Should haves’ and even one item from the ‘Could haves’ list.

Stability-Efficiency

Even though, we have every functionality implemented, we are most proud that entire application works together seamlessly. There were multiple constantly moving parts like changes in how the frontend displays results, small modifications to the response JSON file from the API or different prop requirements for the PDF export functionality. It was difficult to manage the nuances regarding changes in distant parts of the application. But in the end we managed to deliver a solution that:

• provides the correct sampling result at all times

• has a responsive and snappy user interface

• is available any time of the day thanks to a reliable API

• is bug free and test users have reported no complications.

Compatibility

Perhaps one of the most important elements of our project; the sampling tool and sampling API are both highly compatible and platform independent. The project will be developed further by the IFRC GO development team and we were able use the same technologies they currently utilise on their platforms. This not only makes it easy for the GO development team to extend our tool, but also the wider developer community because we are not using special libraries or frameworks. Overall, our end-to-end system, from the backend Django API to the frontend React application is highly compatible.

Maintainbility

Partly due to the same reasons why we can call our solution compatible, we can also say it is maintainable. We are using Python with Django and Typescript with React which is one of the most popular architectures for web applications. These technologies have been long established and documented, as a result of which our project is highly maintainable. Additionally, our codebase is open source which helps with identifying and fixing bugs, and also with overall maintainability thanks to the collective effort that goes into open source projects.

Project Management

Project management has been a strong suit of our project, especially in term 2 when the development process began. Although we set both individual and team-level weekly and monthly targets, we were able adopt to unforeseeable difficulties and overcome the challenges we faced as a team. The most important part of our project management was our weekly meetings with Rachel Yales and occasionally some other members of the IFRC team. We did not skip a single meeting with Rachel throughout the whole project which allowed us to keep her in the loop and work very closely. The first 15-30 minutes of every meeting was about walking through the new or improved parts of the sampling tool. As a result, we received constructive feedback every week and were able iterate quickly. Without knowing we internalised the ‘fail fast, learn last’ concept which ultimately helped us deliver a solution that fully satisfies our project partner.


Future Work

1. Even though the goal of our project was to develop a standalone sampling tool, the greater concept is to embed our tool on the IFRC GO platform. More specifically, the GO development team is working on an end-to-end survey design platform where our sampling tool will have its dedicated section. As the survey design platform is in early stages, embedding our sampling tool was not part of our requirements list, but it would be the final milestone to round off our project.

2. More thorough Time-location and Cluster parameter checking. As of now, our tool is checking the parameters of the sampling size calculators, but this could be improved. For example with the Cluster calculator the UI should display a warning when the cluster sizes are too far apart. The calculations on the backend are still being done correctly, but the results might not necessarily be executable in the real-world, which would be important to take a note of.

3. More customisation of the calculators. Currently, users can use four types of calculators and they have the option to sample by subgroups. However, more customisation to the input of calculators and to the calculators themselves could be added. For example, with Time-location it would be sensible to allow the user to specify how many volunteers and vehicles they have access to or what their estimated budget limit is.

4. Complete language translation for the web application. Currently, the translations are only avaialable for the content of the web application, but not for the decision tree and question card elements. This implementatino has two explanations. One, because the decision tree and question cards are generated by the backend and the translation is done on the frontend. This can easily be solved by setting up separate databases for each language. Two, the decision tree and question cards contain statistical, mathematical and technical terms which are not easy to translate. We do not have the capabilities to translate terms like margin of error or confidence interval. However, this is certainly a limitation of the current implementatio that could and should be improved in the future.