On the date of the checkpoint, you will need to have your live demo ready to go by the beginning of the class. Some background information/content has been provided by your clients:

• For Image Aesthetics: Detailed notes and some starter resources on this topic - note that this content was written prior to the first client information session, so some responses are now outdated. One of the students independently contacted the client with some questions and got additional answers. I'm sharing this so that everyone can have the same access to information. As mentioned before, please do NOT contact clients independently during this project.
• Charity Donation: code template to use in conjunction with the course template folder structure. In addition, download the DLL file into the template folder. Use your IDE to open the project, go to the KelownaSoftware.Domain.Common file and remove the package KelownaSoftware.Platform, then add a project reference to the DLL file. Save and it should build correctly. More instructions with the new DLL that should work now.

Milestone #1: Set Up and Toy Application

For Milestone #1, all the projects will have a basic working web application that has:

• user accounts and authentication for each user group
  • For Image Aesthetics: User accounts may not be the best solution. Students are free to suggest alternatives such as those mentioned during the client information session. The solution should give the admin the ability to track/flag/remove "bad" responses and give the user the ability to go back to edit their own previous responses. The client provided a personality test as an example questionnaire site hexaco personality test. It doesn't require logging in or creating an account to take the test, and only asks for consent, and then shows a sequence of questions. This is the preferred delivery. The administrator should have the ability to review the collected data in CSV format (as a future feature).
  • All other projects should have accounts that differentiate at least one target user group and one administrator user.
• basic pages to demonstrate meaningful navigation from a use case
• proper routing setup
• proper permissions on specific pages - navigation of such pages will need to demonstrate the permissions are working on those pages
• dockerized project
• test framework setup with automated test cases
• database setup with sample data
  • For Image Aesthetics: SQLite is preferred.
  • For Transactions Querying: Get the PostgreSQL database setup with mock data or actual data if you want to get Plaid API working. Use Prisma ORM to query the PostgreSQL database.
• add, change, delete data from at least one of the pages (make sure the database is updated)
• basic consistent design, use of basic CSS, nothing fancy required
  • For Transactions Querying: Use TailwindCSS
• common UI elements such as navigation, headers, and footers should be present (although they don't have to be polished, just get the infrastructure setup)
• repo README.md to have a general overview and system architecture diagram that reflects your CURRENT system setup - if you want to include future components, please clearly indicate which items are not yet implemented; if you got feedback from in-class discussions, please revise and update your design based on that feedback.

Milestone #2: Minimal Viable Product

For Milestone #2, the features required for each project theme are:

• Image Aesthetics:
  • set up actual image questions (pairs or triplets or quadruplets) in the database, or preferably: in a subfolder on the server along with a text file (JSON or other) that specifies the experiment configuration
  • the experimenter can set the experiment parameters (e.g., the number of questions in an experiment) via a plan text configuration file (JSON or other)
  • the website runs an experiment by first asking basic demographic questions about the user and storing that data, then generating questions in random order for an experiment for a given user and recording that data (image order per question should also be randomized)
  • experiment progress is shown (e.g., how many questions remaining)
  • the participant can go back to edit a response (so long as they have not been shown their results)
  • at the end of each experiment, the website shows a simple statistic for each question (with image thumbnails) to the participant revealing their own response and what percentage of the stored participant data also reported that response, like a Twitter survey poll
  • the application needs to have multilingual support in the infrastructure - demonstrate this with English and French in the app
  • gather similar types of images to create a total of 50 image questions in the database
  • conduct the experiment with 10 people (not working on this project from any team) to create an initial labeled database
  • conduct the experiment with one TA and one professor of this course
  • based on your experiments, document/self-assess in a timestamped file in the repo:
    • what feedback do you have from running the experiments yourself?
    • what feedback did you receive from your participants, the teaching staff, and the client?
    • what changes to the app do you want to make based on those experiences and feedback? create issues in the repo for the items that you want to change
  • a proposal on the algorithm used to understand what makes images more aesthetically pleasing (format: bullet points, proper English pseudocode, max 2 pages)
  • a proposal on the algorithm used to generate aesthetically pleasing images (format: bullet points, proper English pseudocode, max 2 pages)
• Charity Donation:
  • vendor profile page, account information, ability to persist across multiple events
  • administrator account to manage vendor accounts
  • vendor dashboard showing donation statistics and event statistics
  • customizable donation amount per event by the vendor (not a range of dollar values)
  • attendee sign-up form and vender-enabled email verification (on a per event basis)
  • populate a list of selectable charities with associated charity information - charities should populated automatically from an accredited/trustworthy source
  • ability for vendor to add (not delete) charities to the charity list
  • ability for vendor to customize logo and colours of the site
  • the application needs to have multilingual support in the infrastructure - demonstrate this with English and French in the app
  • vendor gamification infrastructure with the vendor leaderboard designed and implemented
  • donor gamification infrastructure with the donor leaderboard designed and implemented
  • a proposal of 10+ gamification features for both vendors and donors (format: bullet points, proper English pseudocode, max 2 pages; e.g. if you propose badges, explain which types of badges and the rules that rewards a badge)
• Insurance Policy Checks:
  • the application needs to have multilingual support in the infrastructure - demonstrate this with English and French in the app
  • extract (all) text from PDF for new policy and expiring policy into ASCII
  • analyze policy format and identify relevant sections of focus, focus on documents from one insurer
  • analyze and extract relevant non-text data for premiums, deductibles, and limits (e.g., numbers, tables, dates, date periods, etc.)
  • analyze and extract relevant text from paragraphs for exclusions, coverage, and options - use existing information extraction techniques (e.g., named entity recognition, pronouns, etc.)
  • identify problematic data to flag and confidence of discrepancy
  • highlighting the data/text in the new policy PDF programmatically to show the discrepancies and confidence of the discrepancy
  • repo README.md or a linked .md file:
    • update your system architecture diagram to reflect the current state of the system(s)
    • document clearly the steps used in your approach
• Transactions Querying:
  • create and initialize a REST API using TypeScript
  • connect to Plaid API and store transaction data in PostgreSQL, successfully pull data from it and display results in a dashboard on one of the pages
  • determine which types of user queries should be handled (e.g., transaction lookup, budget analysis)
  • set up Pinecone for storing and indexing relevant transaction information
  • use mock transaction data and queries to test query performance
  • handle simple queries about transactions and purchases
  • consider variations of the same queries - how to find variations of new queries automatically? (plan for it now, do it later)
  • the application needs to have multiple currency support and user profile settings in the infrastructure - demonstrate this with CDN and USD
  • dashboard for transaction summary reports
  • repo README.md or a linked .md file:
    • update your system architecture diagram to reflect the current state of the system(s)
    • document the results of your test queries and suggestions for improvements

(Tentative) Milestone #3: Deployment and Added Features

For Milestone #3, all the projects will focus on the following:

• make necessary changes to the web app based on feedback from the last milestone
• deploy web app on UBC server for peer testing
• incorporate feedback from the client session, teaching staff, and peer testing sessions

Additionally, we have the following project-specific requirements:

• Image Aesthetics:
  • incorporate feedback on proposed algorithms and implement both algorithms
  • report on performance results of the algorithms - what metrics will you use to measure performance?
  • ensure the app uses https
  • repo README.md or a linked .md file:
    • update your system architecture diagram to reflect the current state of the system(s)
    • document clearly the steps used in your algorithms
• Charity Donation:
  • QR Code for live URL to easily open on other devices
  • implement 2 gamification features per person (more details to be determined based on proposals and feedback)
  • ensure the app uses https
  • put in security measures for storing donor information
  • ability to export post-event summaries as CSVs
  • add gamification metrics to vendor and administrator dashboards
  • create an event dashboard view
  • repo README.md - update your system architecture diagram to reflect the current state of the system
• Insurance Policy Checks:
  • report on performance results of your current system - what metrics will you use to measure performance?
  • incorporate feedback on the current comparison approach (more to come based on feedback from Milestone 2)
  • extend the application to handle documents from different insurers for comparing new and expiring policies
  • report on performance results with these new documents
• Transactions Querying:
  • ensure the app uses https
  • handle complex queries:
  • automate synonym lookup and alternative phrasing for new queries
  • handle queries related to budget analysis
  • alerts for detecting bad spending habits
  • repo README.md or a linked .md file:
    • update your system architecture diagram to reflect the current state of the system(s)
    • include clear instructions on how to run the web application and the web server with docker

(Tentative) Milestone #4: Polished Application and Handover Materials

For Milestone #4, all the projects will focus on the following:

• incorporate feedback from the client session, teaching staff, and peer testing sessions
• Implement "nice to haves" (details to be updated closer to the beginning of the milestone)
• repo README.md or a linked .md file:
  • update your system architecture diagram to reflect the current state of the system
  • include clear instructions on how to run the dockerized web application and any other separate systems

Additionally, we have the following project-specific requirements:

• Image Aesthetics:
  • include clear instructions on which files/folders are needed to deploy the project without docker