ctulocal1 / 2019-district-contract Goto Github PK

Create a service worker that builds on the JSON-HTML plus shell build script to create a local routing engine. This will supplant a cache-first strategy by combining:

1. App shell template
2. Settings that choose:
   • Forms to contact Organizer/Field Rep
   • Feeds based on choices
   • Anything else that I think of
3. Hydrated contract pages or another page resulting from forms or other options available.

The menu structure was the first thing developed, but its structure will continue to evolve and see different designs and functions incorporated.

This step is pretty self-explanatory. PWAs require a set of certain sizes of icon. The larger ones can have a more complex set of information and designs. This can be done with Eric, too.

This should be a pretty easy lift. It's just a necessary part of any PWA.

Since the entry point to the web app can be from any contract article in any contract--as well as through a home page--a static site must be generate by combining the app shell code with every page of the contract and deployed to a public directory. This public directory will be the basis for Netlify to serve up all contracts as a static site.

Each static page will include manifest and service worker code to form the basis of the PWA and make it capable of download and installation.

Also, the static site deployment code will form the basis of the service worker's local routing. So that local settings and feeds can be combined with serving up the contract snippet to create a full app experience.

Decisions will need to be made about how, exactly, feeds are meant to be incorporated into the app. Do they show up on their own page? Are the visible in the menu (probably)? What about Featured Images? (Right now, a plugin manually inserts them into Description and Content of RSS feed, but this seems less than ideal.)

Also, how to inject them into the shell. Do the current feeds go into each shell for each page? Is there an easy way to make a headers-only request for the feed, to minimize network traffic? Or maybe use Push notifications to trigger updates to the feed? These all need to be explored and implemented.

Long press or right click should open context menu with choices:

• Copy text of this clause
• Copy clause with link
• Copy clause link only
• Select some text
• Copy whole article (opens share button for page)

Also, each page should have share this page button next to search button(?). That should open a menu to choose how to share (e.g. with link? just quote text? to Facebook?)

We're starting with the Passages contract because of its simplicity and availability in Word format. However, it will become necessary to choose a second contract (this will then be used to develop the contract chooser settings menu, etc.).

Once two are developed, the rest can be developed--including the district contract, once it's finalized.

This will be available from inside all pages and access settings data that can be read and set, probably from indexedDB.

A form needs to be created to contact organizer/field rep. This involves requesting data from the user: Name, return email, school or workplace. These settings must have a link/button to update.

Then a form needs to be created. This can be deployed as its own page, perhaps using the built-in service worker router. Caching strategies need to be considered for this, in case of updates.

Several forms could be implemented, including grievance submissions and inquiries around other issues. This might be an area of ongoing feature expansion.

YAML-Markdown is a good way to convert Word contracts to a format readable and writable by both humans and Javascript. For use in Service Workers, routing and static site generation, JSON-HTML is superior. JS-YAML library can already convert YAML to nice, minimized JSON, but I need to add the Markdown to HTML conversion, either before or after the YAML to JSON conversion.

Use hammerjs to take advantage of gestures such as swipe to go previous and next and long press for copy and share.