House Ads Progress
Intro
HouseAds components are in a varrying state of completeness. This document attempts to clearly and concisely define areas that need attention while also making the steps remaining clear. I've attempted out outline clear risks that we may want to consider mitigation on NOW rather than later.
APIs should have special care taken for them as they were a rush project. They were ignored for far too long with no assignment or ownership taken and they languished as a result.
Terminology:
MMBE = Mystery Machine BackEnd (not cheerios)
FE = Mystery Machine
Points preceeded with a value (e.g. 1 - ...
or 5 - ...
are listed by importance. 1 is feature critical 5 is a minor QoL improvement with no flow affect, just experience. Bullet points are informative rather than directive.
General incomplete Features:
- Edit (new) - Save Ad (AKA create unscheduled ad)
- Preview - Submit Ad (AKA complete ad)
- Delete Ad
- Duplicate/Edit/Preview existing
- the staging of data on the front end for this is done. the submission plan is not.
- Finalization and validation of MMBE APIs
- MMBE API for ad saving is incomplete, including uploading the asset information.
- Sitehub API
- Sitehub Fallback Ads
- Sitehub adjustments for APIs.
This looks like a long list, but hopefully it isn't in reality. I've just broken down each feature as discretely as possible.
Website:
HA-133 Cheerios File Upload:
1 - I suspect this will take docker work to mount the hard dir into the mm container
HA-66 Home:
1 - Delete API call is not made.
1 - Delete API is questionable
suggested input: HouseAdID Suggested output: 200OK process: update HouseAd with HouseAdID given to have HouseAdStatusID=0. reload the page or remove the object from the user's current data set and move on.
1 - Duplicate functions as if it were a normal edit. Forwards to template which doesn't make sense IMO. We probably just want to pass data with the ID's and UIDs stripped and have edit key on empty IDs
2 - A Date of "NEVER" is indistinguishable from the user actually choosing that date. We display the date instead of "NEVER" which probably will confuse the user.
HA-68 Calendar:
5 - This page is poorly mobile responsive.
HA-76 Template:
2 - Filters are unresponsive until DOM completes loading
3 - Slow loading is a bad UX.
3 - Filters force the object to reload.
HA-80 Edit:
1 - Submission does not occur.
1 - API For submisision is questionable
Proposed input: entity_id, entity_type, file stream of asset, compositionTitle, templateID Output: one FULL house ad object reccomended, but minimum is houseAdID. See info bullet below for steps.
5 - Page retains old data and preloads that before loading current. is mildly jarring
-
The file uploaded as the asset should be the key-value pair of template text value -> new text value. This is inconsistent with some old documentation. As of my exit, this change has already been planned but not tested or prototyped.
-
The submission of a completely new house ad here is a highly orchestrated set of steps presented roughly here:
1. copy the file stream to the content server. (done first since this takes ~2 minutes to trigger normally, give it the biggest head start)
2. create the manifestFile for this object.
3. create a HouseAd Object using the title from the request params. Stub out duration=15, weight=n(predefined number, choose a value we can deprecate or work with later), HouseAdStatusID=1. record the HouseAdID
4. Using entity_id and entity_type, link the HouseAdID from 3 to the entity.
5. Create the composition Object, using the HouseAdID from 3 and HouseAdTemplateID from request params. Stub HouseAdCompositionTypeID=1. Save HouseAdCompositionID.
6. Generate the Asset object, Using the ManifestFileID from 2, save HouseAdAssetID.
7. Using HouseAdCompositionID from 5 and HouseAdAssetID from 6, link them.
- Updating an existing house ad should be the same as above, except we already have all the IDs from each step. so upsert is an update if IDs are present, insert if IDs are not present. This is important since it is a procedural/staged submission. URL should be idempotent when IDs are present.
HA-71 Schedule:
2 - A "NEVER" date does not translate on edit. We take the date as the date.
HA-72 Preview:
1 - Submit needs to actually make the api call.
1 - API for submission is questionable.
Proposed submission data: input: houseadID, start date, end date, weekdays output: none needed, can return entire ad, will likely be ignored.
General:
1 - Edgecast URL is stubbed in right now and needs to be obtained from the data itself or somewhere else.
2 - Date inputs are inconsistent in formatting Validate that the dates submitted mean what we think.
4 - Dates across the site are odd. "NEVER" end translates to a date and we never translate it back for display so the display shows 2099 end date when the user selects never.
5 - House Ads is missing an icon. Home page is weird as a result, sidebar is weird and "house ads" text is the home button for the app as a result.
-
Logo will require a change in the template files as they stand.
-
If a user has adblock or something similar, API calls will be disabled and the app won't function
🙃 If we rename the word "ad" out of the MMBE API URLs it won't be blocked anymore. -
AdPreview component used on the home page and the edit pages is the same thing. It currently has not been tested for text replacement off a file from the front end. in theory it shouldn't be an issue, but needs to be tested.
Dev Knowledge:
- Running locally needs the "Cors Everywhere" plugin or else templates and such won't work right.
Sitehub:
1 - APIs are incomplete. There are 3 requred: 2 GET, 1 POST
Get are defined here: http://dc-gitrepo-01.ntn.com/kbungo/local_ad_manager/tree/master/server#sitehub-aggregate
POST is roughly defined here: https://jira.buzztime.com/projects/HA/issues/HA-85
1 - HouseAds still has URI stubbing in place for dev use.
1 - fallback ads do not exist and will need to be massaged into the app before release
1 - Settings.SiteHub.HouseAdsEnabled for enabling houseads to run