We are building a visual essay writing application mainly aimed at neurodiverse and international students.
- Problem: Neurodiverse students and foreign students sometimes face difficulties planning and structuring written essays.
- Solution: Develop an online app that encourages the adoption of essay writing methods developed by our product owner.
Our product owner's students need a clear, user friendly interface to get the most out his educational method.
The key features of our MVP will include:
- Being able to write, edit and save the different sections of an essay following Oliver's method.
- Being able to export an essay as PDF or MS DOC.
- Providing the students with the resources they need to succeed.
- Students are able to choose a theme or personalised colours to support them in their planning and reading.
We are not building a video hosting platform. The product owner will provide the resources such as written copy, guides and third party hosted video recordings.
User research and consulting and designing alongside the product owner were key in developing our understanding of the priorities for the project.
- Design sprint - 1 week
- Build sprint 1 - 1 week
- Build sprint 2 - 1 week
We had 7 users of varying ages, education experience and backgrounds.
Their feedback stressed the importance of:
- Clear instructions around use and navigation.
- Having resources side by side while writing the essay.
- Having sections broken down.
- Having an option to personalise colours.
- Making sure the essay question is always visible.
- Semantic HTML.
- Aria compliant CSS.
- Reponsive design.
Users will want their essays to remain private, our product owner expressed interest in being able to delete essays to prevent malicious behaviours or mistakes. Users will also be able to reset their own password.
-
Authentication with bycrypt, session cookies and sendGrid email reset
-
End to end testing with Cypress.
-
Managing database CRUD operations.
- Supabase PostGres database
-
Using external libraries:
- Chakra UI styling library.
- Docxtemplater library to export documents in MS DOC format.
- jsPDF library to export documents in PDF format.
-
Responsive design.
-
User research and prototype testing.
-
Figma wireframing.
-
Deployment on Vercel and managing environmental variables.
-
Liasing with product owner.
-
Documenting a project.
The team :
- Discussed project architecture during the design phase.
- Confirmed and challenged our own assumptions during user testing.
- Worked together on core features and split into role specific tasks, getting continuous feedback from the product owner.
Invest more time into researching the Chakra UI library, it proved itself very useful and well documented but at the same time it has been a slight learning curve, especially since we had a limited amount of time to produce an MVP.
Dedicated more time to refactoring repeatable code into general purpose functions and components.
The user research phase brought up key aspects of the app we should focus on, that were very relevant to the target user, such as:
- A Theme Toggle Switch to offer alternative colours.
- An Accordion component to serve resorces alongside essey writing section.
- Mobile-first, responsive, accessible design.
We built an MVP covering the core user stories. The Product Owner will use the app to present the Essay Boost methodology to teachers, parents and students with the aim of getting feedback, gathering ideas for improvement and to assist students in their learning process.
In our second round of user testing during build sprint 2 we found users valued being able to delete the essays, being able to edit the essay question and wanted visual feedback on completed sections.
## Recommendations and conclusions
An admin dashboard where teachers can access students essays, provide feedback and manage users.
The Product Owner was pleased with the result and satisfied with the MVP. We also received positive feedback from our cohort and project mentors.
Explain the roles and responsibilities of all people working within the software development lifecycle, and how they relate to the project (K2)
Scrum Facilitator & Liason - Oli DevOps - Adam QA & Documenter - Paolo UX / UI - Split Responsibility
Outline how teams work effectively to produce software and how to contribute appropriately (K6) Compare and contrast the requirements of a software development team, and how they would ensure that each member (including themselves) were able to make a contribution (K6)
We distributed work by allocating features / bugs to each developer to work on and supported each other by pairing on difficult tasks. We all had a chance to cover different aspects of the build, including responsive design, querying the database and managing state.
We had daily stand ups and sprint retrospectives at the end of each sprint.
We conducted code reviews presenting our work to other team members explaning our approach.
We have taken action to make sure the app is as secure as possible but we recognise the app is not intended to secure personal information; one unintentional consequence is that passwords, emails and possibly other forms of private data could be stolen by an indiviual experienced in exploiting vulnerabilities.
An initial user research phase conducted by the product owner was followed by a Design Sprint week which included the following phases:
- Revisiting and defining the problem statement for the project.
- Defining what our app offers, how to use the app and how it will help the end user achieve their goals.
- Creating the core user stories.
- Brainstorming in relation to the challenges that might come with building the app.
- Getting inspiration from applications / websites already present on the web.
- Quickly sketching multiple ideas for the design and flow of our app.
- Producing a Figma interactive wireframe that we used to conduct usability testing sessions with 7 sample users.
- Synthesising the users feedback.
- Identifying technical choices.
- Identifying spikes to research topics.
- Server-render vs client-render vs both
We used the Next.js framework, which utilises a mix of client-side rendering for state and server-side operations for database queries.
- Relational or non-relational or no DB
We created a cloud hosted relational postgres database on Supabase.
- Self-hosted or platform-as-a-service
The app is hosted on Vercel.
- Frontend first vs DB first
We did focus on the authentication flow before working on the frontend aspect of the app, after which we had a balanced approach to back end and front end development.
Review methods of software design with reference to functional/technical specifications and apply a justified approach to software development (K11, S11, S12)
Technical choices we reviewed as a team included:
-
How to preserve state between different pages
-
Whether to implement authentication with a single dummy account; we then decided to fully implement authentication with multiple users to respond to our Product Owner's request.
-
We discussed how to implement pdf and ms doc conversion.
-
We decided to write the database queries ourselves instead of using a service like Prisma or an ORM.
Create logical and maintainable code to deliver project outcomes, explaining their choice of approach. (S1)
-
Testing with Cypress and Huski.
-
Code reviews with the team.
-
Linting with ESLINT.
-
Formatting the code using the Prettier VScode extension.
-
Refactoring repeated code into components and functions.
-
The first implementation of the spider diagram initially was stored as TEXT in the postgres database, however our product owner was keen to have sub-branching and therefore we changed the datastructure to JSON to handle the complexity of storing sub branches.
-
Testing made use of looping algorithms to automatically populate text fields across multiple pages.
-
We utilised the bycrypt library uses an algorithm to hash and compare passwords.
Apply structured techniques to problem solving to identify and resolve issues and debug basic flaws in code (S7)
We implemented end to end testing using Cypress;
We focussed on making sure every input from the user, on every section of the Essay boost app, is inserted / updated in the database and retrieved and rendered correctly on the front end.
We tested the authentication process to make sure the user can sign up, log in and log out and cookies are set and removed accordingly.
We installed Huski to use Git Hooks and run our tests suite on pre-commit.
A few bugs were detected during the development process thanks to automated tests:
There were issues when trying to retrieve and parse strings from empty rows in the database.
We deployed on Vercel.
Review and justify their contribution to building, managing and deploying code into the relevant environment in accordance with the project specification (S10)
Our sendResetEmail function worked instantaneously on the local server, however when deployed on Vercel the function had significant latency (up to 5 minutes) before the user received their email. This prompted the addition of a warning message to our user that the reset email could take time to arrive.
Any developer with experience in React and Next.js should find our project easy to understand and update. The file structure is logical, we took care in naming our variables and functions, our code has comprehensive tests for core functionality. Future developers should be aware our project is an MVP and built with delivery time as a main priority and so some elements of the code base may require additional context to fully understand.
With a review of the model.js file, the getServerSideProps functions and our cypress tests a new developer would be able to start contributing. We have included getting started information in the READ.ME