mystikhub / sweng-12 Goto Github PK

We misinterpreted the statistics that should be shown for this chart. In mostPopularVoucherSize.json, we should be counting and comparing the percentages of the different sizes of voucher sizes purchased (5, 3, 10, etc.) and reporting their percentages. Since the vouchers.json file doesn't report the stores or schemes these voucher packages were purchased for, we can only come up with this statistic on all stores.

Update the voucherCount.js file to support queries for individual stores, as well as all the stores (and return the correct data accordingly). It already supports statistics for all the stores, just need to differentiate between all stores and individual stores, then for individual stores return data for the store being asked for.

We should discuss whether or not we should use a NoSql database on our backend. Our client uses Firebase and we could tie our version nicely when we hand over the code bundle.

• Ask the client if the lack of a NoSql database would be a deal breaker

Update the multiStore.js file to support queries for all stores (and return the correct data accordingly).

Variables include api_server, chart width, and chart_height

We should come up with some kind of expected output from making a request to /customer_growth on the back end, to help developing the back end route and the front end chart. Deciding on the format of the expected response early should help both teams get the feature done quickly.

This chart should show a growth chart displaying the amount of all time users, overall and by store

From the client specification:
The web app should scale correctly for stores with numerous locations and numerous
schemes. The dummy store I will be providing for you has 2 location and 2 loyalty
schemes. However I may later provide you with a different dummy store that has a
different amount of locations and schemes, and the code should work the same.

We should come up with some kind of expected output from making a request to /voucher_purchase_counts on the back end, to help developing the back end route and the front end chart. Deciding on the format of the expected response early should help both teams get the feature done quickly.

This chart should show how many vouchers/voucher packages have been purchased

From the client specification:
The web app should scale correctly for stores with numerous locations and numerous
schemes. The dummy store I will be providing for you has 2 location and 2 loyalty
schemes. However I may later provide you with a different dummy store that has a
different amount of locations and schemes, and the code should work the same.

A businesses retention rate (what percentage of customers from 60-30 days ago have also collected a stamp in the last 30 days)

Decide on making this a bar chart or a pie chart.

Find a way to make each of the charts use the same two colors as from our client's screenshots. Ideally, these values would be accessed by each chart from the same res.js or colors.js file.

From our client's screenshots, the primary color was #FA7268 and the secondary color was #00C1C0

Update the totalRedeemedTotalUnredeemed.js file to support queries for individual stores, as well as all the stores (and return the correct data accordingly). It already supports statistics for all the stores, just need to differentiate between all stores and individual stores, then for individual stores return data for the store being asked for.

As well as that, please change the query parameter ?scheme= to ?store= for clarity

This route should follow the format we discussed:

example: /multi_store_customers?store=001

{
    "multi_store_customers": 10, // Customers that visited more than one store
    "single_store_customers": 20 // Customers that only visited the store in the store asked
}

Only look through different stores, different schemes from the same store is OK

Originally posted by @MystikHub in #6 (comment)

We should come up with some kind of expected output from making a request to /redemption_rate on the back end, to help developing the back end route and the front end chart. Deciding on the format of the expected response early should help both teams get the feature done quickly.

This chart should show per loyalty scheme, what percentage of users who have stamped have redeemed a reward for that scheme

From the client specification:
The web app should scale correctly for stores with numerous locations and numerous
schemes. The dummy store I will be providing for you has 2 location and 2 loyalty
schemes. However I may later provide you with a different dummy store that has a
different amount of locations and schemes, and the code should work the same.

I realized that most charts will need some way of selecting which store the data should be displayed for. Rather than having a selector for each widget, I thought it would be a good idea to follow our client's current solution where the top of the dashboard has a single dropdown for the store to use for all the charts on the dashboard.

Discuss below

We should come up with some kind of expected output from making a request to /retention_rateon the back end, to help developing the back end route and the front end chart. Deciding on the format of the expected response early should help both teams get the feature done quickly.

This chart should show "A businesses retention rate (what percentage of customers from 60-30 days ago have
also collected a stamp in the last 30 days)".

From the client specification:
The web app should scale correctly for stores with numerous locations and numerous
schemes. The dummy store I will be providing for you has 2 location and 2 loyalty
schemes. However I may later provide you with a different dummy store that has a
different amount of locations and schemes, and the code should work the same.

Update the retention.js file to support queries for individual stores, as well as all the stores (and return the correct data accordingly). It already supports statistics for all the stores, just need to differentiate between all stores and individual stores, then for individual stores return data for the store being asked for.

Make a new Vue.js component for the chart which will use the /voucher_purchase_counts route. API specification is in issue #25.

We should come up with some kind of expected output from making a request to /loyalty?by=age on the back end, to help developing the back end route and the front end chart. Deciding on the format of the expected response early should help both teams get the feature done quickly.

This chart should show loyalty (average days between stamps) by age group

From the client specification:
The web app should scale correctly for stores with numerous locations and numerous
schemes. The dummy store I will be providing for you has 2 location and 2 loyalty
schemes. However I may later provide you with a different dummy store that has a
different amount of locations and schemes, and the code should work the same.

The chart "Growth Of Customers" should show the growth of customers from all of that business' stores with overlaid lines on one chart.

Update the stampTotalTrend.js file to support queries for individual stores, as well as all the stores (and return the correct data accordingly). It already supports statistics for all the stores, just need to differentiate between all stores and individual stores, then for individual stores return data for the store being asked for.
Also, the data returned for individual stores should only return the data for the schemes from that store

For the store selector on the front end, we need a way of getting a list of all stores. We only need something simple like:

GET request to /all_stores:

[
    "001",
    "002"
    // Other stores to show up down here
]

Update the actualTotalsPie.js file to support queries for all stores (?store=all)

As well as that, please change the query parameter ?scheme= to ?store= for clarity

We should come up with some kind of expected output from making a request to /multi_store_customerson the back end, to help developing the back end route and the front end chart. Deciding on the format of the expected response early should help both teams get the feature done quickly.

From the client specification:
The web app should scale correctly for stores with numerous locations and numerous
schemes. The dummy store I will be providing for you has 2 location and 2 loyalty
schemes. However I may later provide you with a different dummy store that has a
different amount of locations and schemes, and the code should work the same.

Make a back end route, /retention_rate that returns the number of customers from 60 - 30 days ago that have also collected a stamp in the last 30 days. We have decided on the following format for the back end response to this route:

{
    loyal_customers: 55,
    not_loyal_customers: 34
}

Possibly under another folder in the repo called "back-end-reference" should include an express app as simple as possible, only returning the example response for each route. Should be similar to unit tests.

Make a new Vue.js component for the chart which will use the /voucher_purchase_counts route. API specification is in issue #25.

We should come up with some kind of expected output from making a request to /loyalty?by=gender on the back end, to help developing the back end route and the front end chart. Deciding on the format of the expected response early should help both teams get the feature done quickly.

This chart should show loyalty (average days between stamps) by gender

From the client specification:
The web app should scale correctly for stores with numerous locations and numerous
schemes. The dummy store I will be providing for you has 2 location and 2 loyalty
schemes. However I may later provide you with a different dummy store that has a
different amount of locations and schemes, and the code should work the same.

Create a backend route, "/all" that returns the contents of the rawpurchases.json file from our client.

We should come up with some kind of expected output from making a request to /stamps_collected_totals on the back end, to help developing the back end route and the front end chart. Deciding on the format of the expected response early should help both teams get the feature done quickly.

From the client specification:
The web app should scale correctly for stores with numerous locations and numerous
schemes. The dummy store I will be providing for you has 2 location and 2 loyalty
schemes. However I may later provide you with a different dummy store that has a
different amount of locations and schemes, and the code should work the same.

We should come up with some kind of expected output from making a request to /voucher_package_size_popularity on the back end, to help developing the back end route and the front end chart. Deciding on the format of the expected response early should help both teams get the feature done quickly.

This chart should show what the most popular voucher package size is

From the client specification:
The web app should scale correctly for stores with numerous locations and numerous
schemes. The dummy store I will be providing for you has 2 location and 2 loyalty
schemes. However I may later provide you with a different dummy store that has a
different amount of locations and schemes, and the code should work the same.