HOPE Daily Log

We are building HOPE as our Tech for Better final project for Founders & Coders FAC26.

Contributors: Iman Ghellache, Gal K Jones, Laura Keating, Dominic Simpson

• Our Tech for Better app, HOPE, is designed to help people who are homeless access free food that is about to chucked away by vendors, whether large chains such as Pret, or individual restaurants. Our Product Owner (PO) is Eric.
• Initial brainstorms confirmed that the app will have two routes:

1. Food vendors giving away the food
2. Users - homeless people who need to access the food.

• The user will need to be able to reserve the food item(s) being given away, and pick up the food from that vendor.

20/3/23

For design week, the group worked together

1. Vendor's route
   In our initial design, the landing-page' would have an 'I'M A VENDOR' button that would lead to a sign-up page. Once the vendor signs up, they would then be directed to the vendor-upload page, in which they would be prompted to enter some details about themselves (who they are, their address, and phone number). After this, they would then find themselves on a food-upload page, where they could upload details of the food that they would be giving away. At this point, they would also see a dashboard/navigation bar from now on, giving them a number of options, including a business-account page that lists their details, including an FAQ section:

2. User's route
   In our initial design, the landing-page would have a 'FIND FOOD' button that would take the user to a find-food page. If they click on each individual food item, that would then come up with a food-description page, where they can then reserve that item. However, we envisage that at that point they would then be prompted to sign-in before being able to reserve that item.
   At that point, they would also see a dashboard/navigation bar - but, crucially, one that's different from the vendor dashboard / navigation bar. Therefore, we will need to create two distinct NavBar components, with different icons. The user will see a question mark that will lead to an information page; meanwhile, the user would also have their own account page, which lists basic details like full name and email address, as well as some FAQs:

And here is the figma wireframe landing-page in interactive mode:

21/03/23

• After a wireframe review with Eric, during which he advised against the vendor having to upload details from scratch of the food that they would be giving away via the food-upload page, we agreed that we will have an existing database of food items instead, rather than the vendor having to create them for the first time. The food vendor would then be able to select from a page, our-food, where these food items would come up, including setting the quantity:

• If the vendor clicks the 'SAVE' button in the second image above, they are then redirected to a manage page, where it lists what's avaialable at that vendor address:

• We conducted usability testing sessions with a number of members of the public, to check the efficacy of our prototype. Users were given a link to the interactive version of our Figma wireframe, so that they could experience the routes through the app and see it visually. The questions that we asked each users, of both a quantitative and qualitative nature, were:

1. How would you sign in as a food vendor?
2. How would you navigate to your business account as a vendor?
3. How would you upload a food donation as a vendor?
4. How would you edit a food donation as a vendor?
5. How would you search for food as a user?
6. As a user how would you edit or create your account?
7. How do you feel about the colour palette used in the HOPE clickable prototype?
8. How was your overall experience moving around the app?
9. What else would you like it to do?
10. Anything else you feel we should know?

• This feedback allowed us to assess how easy our prototype was to navigate with people who were experiencing the prototype for the first time. It helped us tackle a whole number of issues, including confidentiality of user and data; NavBar icons being unclear; protected routes; and how and what would be displayed when filtering food. Based on our usability testing analysis feedback, we produced 'Traffic Light Analysis' - a spreadsheet showing a visual colour code corresponding to user feedback, with each user a separate column:

• Our feedback included the revalation that our colour combination of red and green pallette failed accessibility tests, including for those who are colour blind. The colour contrast was hard to read. In response, we updated the colour pallette in our prototype in Figma, contrasting fully green and purple:

• Meanwhile, due to the stigma involved with free food, and as a step to reassure the user that the experience is essentially confidential, we modified the user-account page, so that it would list each Pick Up code correlating to each reserved food order, which the user could just state at the point of picking up food. This could mean that their name doesn't even have to be given:

23/03/23

The group met with Ben and Rihards who will be our mentors. We also agreed on our tech stack for this project after a number of discussions:

• React
• Next.JS
• Supabase for authentication
• Airtable for database
• Tailwind for CSS
• Cypress Testing

24/03/23

First day of build

27/03/23

TESTING

• Dominic installed Cypress Testing, and successfully ran a basic check to test that the sign-in / sign-up functionality works:

describe('Sign In Functionality', () => {
  it('Logs in successfully', () => {
    cy.fixture('testData').then((testData) => {
      cy.visit('http://localhost:3000/sign-in');
      cy.get('[type="email"]').type(testData.email);
      cy.get('[type="password"]').type(testData.password);
      cy.contains('button', 'Sign in').click();
      cy.url().should('include', 'http://localhost:3000/sign-in');
    });
  });
});

• The above test only works if it is accompanied by a data object in the testData.json file, contained within the fixtures sub-folder of the root cypress branch. This data object ensures that any emails and passwords can be passed in can be verified, rather than having to hard code them each time.

{
    "email": "test@example.com",
    "password": "password"
  }

• He also learned a lot more about how end-to-end testing works compared to component testing.

FORM

Iman and Gal worked using React Hook Form in order to capture data entered by the vendor on the upload-vendor-form page.

AIRTABLE

Gal rendered data from airtable onto the page using useEffect

UPDATE STOCK PAGE

Was able to fetch from db and render on page. To allow the rendering of page to wait on the data, we needed to resolve to a promise. By making getRecords a Promise, it ensures that the data is properly fetched and returned to the getServerSideProps function before rendering the page.

VENDOR DETAILS UPLOAD FORM

28/3/23

Contacted mentors for possible code review Wednesday afternoon

Vercel failed to deploy and we got a 404 error on the manage-food page due to new Airtable api key not being uploaded to the vercel account page. This is important because the vercel deployment doesn't have access to our .env.local files where our Airtable api keys are kept.

LK: Available-food

Created available food page, fetched vendor data from Airtable and added links to buttons to ensure paths are correct

DS: Sign-in

• Added CSS to the Sign-In page. This turned out to be tricky, given that he was syling a 3rd party Component (Supabase's Auth component, used to handle sign-in / sign-up verification). The solution turned out to use the appearance prop, which helps you style elements in a 3rd party Component:

<Layout pageTitle='Sign in' isBusinessPage>
      <div className='flex justify-center font-cursive text-custom'>
        {!session ? (
          <>
            <Auth
              supabaseClient={supabase}
              providers
              appearance={{
                style: {
                  button: {
                    padding: 10,
                    borderColor: '#540375',
                    backgroundColor: '#540375',
                    borderRadius: 7,
                    width: 200,
                    marginLeft: 50,
                    color: '#F5E8DA',
                    textTransform: 'upperCase',
                  }, [etc.]

• The CSS used above does not employ ordinary, vanilla CSS. It is a special kind of inline CSS that uses camelCase. This can be seen with the CSS command textTransform: 'upperCase',for example, which would not make sense in vanilla CSS, where it would be text-transform: uppercase;. Something similar applies to the marginLeft command above. Additionally, this version of CSS does not allow px or rem measurement to be added to numerical values.

29/3/23

• find-food page created and can fetch from multiple menus (bases). The food is then rendered with associated restuarant included. Error when collaborator doesn't have an associated menu.

• reservation-successful page built and random code generated
• 
• 

• Recipient user story issues added to kanban board
• 

30/03/23

• LK: error fixed with find-food db queries so that every collaborators menu items are fetched. Button hover color changed to helped accessibility. Quantity conditional statement added to find-food page to prevent rendering of card for foods that are not available. Researched how to pass props through a link using React-Router-Dom

• Sprint review: most of our estimates and actuals matched

• Sprint planning: We planned sprint 2 and added stretch goals.

• DS: added an automatically generated four-digit pick-up code to the reservation-successful.js page. This involved not just employing Math.floor and Math.random() in order to do this, but using it together with useEffect and useState hooks, given that that project is employing React. This ensured that both the server-side and client-side were adequately hydrated.

const ReservationSuccessful = () => {
  const pageTitle = 'Reservation Successful';
  const [pickUpCode, setPickUpCode] = useState(0);

  useEffect(() => {
    setPickUpCode(Math.floor(Math.random() * 9000) + 1000);
  }, []);
    ...
     <p className='text-accentcolor2 text-center font-sans text-lg leading-1.5 m-0 max-w-30rem px-6 mx-auto'>
          Your Pick Up code is: {pickUpCode}

• DS: added a Cypress test for the vendor details upload form on vendor-upload-form.js. Some of the inputs are input fields, and others are text-area fields, so the test had to be coded appropriately.

describe('Vendor details form', () => {
  it('Submitted vendor details successfully', () => {
    cy.visit('http://localhost:3000/vendor-upload-form');
    cy.get('input[name="companyname"]').type('Pret');
    cy.get('textarea[name="description"]').type('We sell food');
    cy.get('input[name="companyhours"]').type('08:00-18:00');
    cy.get('textarea[name="address"]').type('100 High Street N16');
    cy.get('input[name="phonenumber"]').type('01010010101');
    cy.get('form').submit();
  });
});

3/4/23

• looking into optimising the find food page. Possible fixes include, pagenation and React query.
• Modal fix

4/4/12

• DS: Implemented the vendor-account page, which shows the vendor's details on the screen.
  Implementing this page meant gathering data from Airtable on the vendor's specific name, address, and description, and displaying that data on the page, which involved modifying an existing getServerSideProps() function so that it displayed elements from the Collaborators table in Airtable. Meanwhile, a find method had to be run on this Collaborators table in a function called VendorDetails, which took the collaborators array as a prop. This function used the useSupabaseClient and useSession hooks to get the current user's email address and match it with the email address of a collaborator in the collaborators array.

export default function VendorDetails({ collaborators }) {
  const pageTitle = 'Vendor account';
  const supabase = useSupabaseClient();
  const session = useSession();
  const collaborator = collaborators.find(
    (collaborator) => collaborator.Email === session?.user?.email
  );

Then the return statement used a simple conditional statement (represented by &&) to display the collaborator's name, address, and other fields drawn from Airtable on to the screen:

  return (
    collaborator && (
      <>
        <Layout pageTitle={pageTitle} isBusinessPage>
          <div className='flex flex-col m-4 items-center'>
            <p className='text-accentcolor2 text-center font-sans text-lg leading-1.5 m-0 max-w-30rem px-6 mx-auto'>
              Name: {collaborator.Name}
            </p>
            <p className='text-accentcolor2 text-center font-sans text-lg leading-1.5 m-0 max-w-30rem px-6 mx-auto'>
              Address: {collaborator.Address}
            </p>
          </div>
etc...