Viz release technical check-list

[abriggs-usgs]

Since the Gages Through the Ages Visualization is next on the agenda for public release, I thought it would work to start assembling the 'viz release technical check-list' here.

• [x] Create a comprehensive checklist so that we can just check the boxes and be confident that we have accomplished everything we need to have a trouble free public release
• [x] Find a place to store the checklist and notify the team as to where to find it.

[abriggs-usgs]

I'm gonna start a list of ideas that are on my mind at the moment; we can sort and filter later. So here it goes. stuff for analytics

• go to analytics.google and create a 'property' under vislab so that you have an ID
• go to https://tagmanager.google.com/#/home and under the usgs-makerspace account create a new container
• go back to the application and the code that links the application to the new container
• in the tag manager container add auto event tracking of (at minimum) page views and link clicks
• in the application make sure the 'general' USGS script tag is added
• currently we add a couple custom dimensions through with use of the Vue Analytics plug in, we might be able to replace this in the future with functionality in Google Tag Manager (perfered route) but I have not had time to try this. So, for now make sure the application's Google ID is added to the plugging (the rest is setup in the Makerspace-base template). Stuff for deploy to prod -Modify the code in 'App.vue' to turn off the 'WorkInProgressWarning' component
• do a code 'release' in Github
• Push release to 'beta' -Get official 'green light' for prod from (Joe, maybe) - don't push to 'prod' without some official documentation of approval!!
• Go to Jenkins and build With Parameters Meta content -
• add/confirm the JSON-LD script in 'head' section of the application has current information public URL -
• we no longer have to request creation of 'pretty URLs' as they will match the folder name in AWS (provided the location will have the prefix labs.waterdata.usgs.gov/visualizations), but we do need to confirm that the public URL is (at the time of launch going to be what we named the folder early in development) , changes to this will require changes to the build process (not huge changes, but still changes)) Performance -
• Add lighthouse-ci to repos to keep track of web performance during web development https://github.com/GoogleChrome/lighthouse-ci (needs testing first)
• Find a way to test a broad spectrum of devices (browserstack?) to avoid odd hiccups.
• split the code (lazy load and modify load order as needed)
• keep in mind to use picture elements and file formats like jpg2000 jpgxhr and webp Compliance -
• Run 508 scans on an iterative basis

[mwernimont]

I thought we had a GA ID already?

[abriggs-usgs]

True, we are making a list for future applications while the information is fresh in our minds. So everything in the list should be pretty much done for Gages. This is in preparation for the Viz Release Checklist meeting on Thursday. So feel free to make note of anything that you have done recently that could apply to future applications.

[lindsayplatt]

Social media:

• Contact Web Comm to create social media campaign plan (need lead time in order to plan & get approved, ~2 weeks)
• Decide what level of broadcast is needed (national accounts? just water? every platform? just Twitter?) - Sponsor + Web Comm should decide
• Generate social media content (GIFs, images, videos) to accompany posts

[mwernimont]

Social Media Video Guidleines: https://sproutsocial.com/insights/social-media-video-specs-guide/ Social Media Image Guidleines: https://sproutsocial.com/insights/social-media-image-sizes-guide/

[lindsayplatt]

• data cited and processing methods written out (available on viz)

[lindsayplatt]

Post-release:

• Web traffic analytics
• Social media post analytics
• Team retrospective

[lindsayplatt]

Completed draft list

Performance testing (when - early and often)

during project setup

• Add website banner that says "THIS IS A WORK IN PROGRESS, DO NOT USE, NOT RELEASED" (included in base template)
• Check that the 'robots' meta tag is added to stop indexing of beta (if the base template was used, this is included)

  after the first major component has been added

• Push preliminary website to beta URL
• Test on a phone; confirm there are no obvious issues

  when project completion criteria are complete

• Tweak code bundles and load order as needed for best performance

each iteration:

• Use Browserstack to verify that application works on a variety of devices
• Use lighthouse to measure performance and notice issues
• QA Human verification that you can use the application on a mobile device without being annoyed
• QA Human verification that the desktop application is functioning

  as they arise

  Record Known Issues

• Record in Change log
• Record in Makerspace Portfolio (at release, or during quarterly summary period)

Compliance

during project setup

• USGS VisID header and footer are used (included in base template)

  prior to any demo or review

• At a minimum, verify that the application/visualization works on a mobile device
• Verify the application/visualization works on the following browsers Chrome Safari Edge Firefox Samsung Internet Internet Explorer 11 (not supported, but still needs at least a working user redirect page--included in base template)
• Check that components match USWDS (U.S. Web Design System)
• Use WAVE tool plugin to verify that we are meeting 508 guidelines

Web analytics

during project setup

• Register application with Google Analytics: go to analytics.google and create a 'property' under vizlab so that you have an ID
• Register application with Google Tag Manager: go to https://tagmanager.google.com/#/home and under the usgs-makerspace account create a new container
• Connect application to tag manager: go back to the application and the code that links the application to the new container
• In Google Tag Manager create 'auto tags' for page views, links, scroll depth (many other tag options exist, add as needed)
• Verify USGS script tag exists: in the application make sure the 'general' USGS script tag is added (should already exist if you used the base template)
• If custom dimensions required (and not using Tag Manager), verify that the custom code does what it should: make sure the application's Google ID is added to the plugging (the rest is setup in the Makerspace-base template). Currently we add a couple custom dimensions through with use of the Vue Analytics plug in, we might be able to replace this in the future with functionality in Google Tag Manager (preferred route)
  • Test that Google Analytics events/dimensions are working as expected. You can use the GA Debug Chrome plugin to watch the outbound requests, or wait for data to show up in the Google Analytics UI

when 'steps to public release' start add final tracking

• Setup specific events that you want to track for things such as image or section view. Again the preferred route is Google Tag Manager, but direct addition to the code is an option)

Social media / outreach (probable duration 2-4 weeks)

when 'steps to public release' start, so should the social media plan

• Contact Web Comm to create social media campaign plan (need lead time in order to plan & get approved, ~2 weeks)
• Decide what level of broadcast is needed (national accounts? just water? every platform? just Twitter?) - Sponsor + Web Comm should decide
• Generate social media content (GIFs, images, videos) to accompany posts (video size guidelines, image size guidelines)

Steps to public release (probable duration 2-4 weeks)

when given confirmation from the project champion that the product, in its current form, is ready

• Check that the 'robots' meta tag is present to stop indexing of beta (if the base template was used, this is included)
• Push preliminary website to beta URL (also needed for mobile & performance testing)
• Preliminary stakeholder review of beta
• Confirm public URL with Web Comm & Group Sponsor
• Data methods and references included somewhere in application
• Contributors listed in website metadata
• Final content review (IPDS for all hosted applications/visualizations)
• Reconciliation of application from final content review
• formal demo of application to Group Sponsor and IIDD Director (may be one or separate events)
• Group sponsor ✔
• IIDD Director ✔
• Take off website "this is preliminary" banner (turn off Vue component)
• Cut a release of the code
• One more ✔ (but from who?)
• Push to prod
• Celebrate 🎉

Post-release

• Team retrospective
• Web traffic analysis (probably wait a couple weeks)
• Social media post analysis (probably wait a couple weeks)

[jordansread]

Nice work.

Final content review (do we need peer review via IPDS?)

yes, we need to do this.

[lindsayplatt]

Just to clarify - we need an IPDS for every viz? Or does it depend?

[jordansread]

For every "web site" release, so any hosted viz. Not every social media file though.

[abriggs-usgs]

@wdwatkins would you mind taking a peek at the 'completed draft' a couple sections up and see if there is anything of which you can think to add?

[wdwatkins]

I added a bullet about testing to the analytics section. Looks good though!

[abriggs-usgs]

@jread-usgs and @amrhoades I went through the above draft and added some 'when to start this part' guidelines, but I was struggling with the words to describe the starting point for the 'steps to public release.' Right now, I have used the words "when project criteria are complete and the application is 'finished'". But in retrospect, I feel that for most projects this would be a vague rather than clear line. Perhaps, there needs to be some process so that the Project Champion can officially sign off that the goals of the project have been met (the scope is fulfilled/user stories satisfied/feature development is closed/etc.) and the release process has begun.

[amrhoades]

@abriggs-usgs - the gate should be: confirmation from the project champion that the product, in it's current form, is ready.

[amrhoades]

@abriggs-usgs - I'm going to remove the Gages label since this list is for all projects, not just gages.

[abriggs-usgs]

I created https://github.com/usgs-makerspace/makerspace-sandbox/issues/566 and placed it in the 'ideas' column with the label 'Makerspace processes.' The thought is that issue 566 can be used a template to create a new issue at the start of each project that will capture the entirety of the Public Release Process.

[jordansread]

re: "One more ✔ (but from who?)" on the draft list - I think that is turning out to be Adrienne (Chief of Staff) or her proxy, but that may change in the future and we will need to adapt if it does.

[abriggs-usgs]

Okay, thanks. I was meaning to get clarification on topic on Friday since you said 'and yes, I didn't forget that I need to say yes/no regarding prod'. I wasn't sure under which of your three hats you where operating when giving that 'okay' and I wanted to capture the correct titles and procedures in the 'check list'. Would it be something along the lines of this:

• [ ] Final 'push to prod' approval from Group Sponsor who has approval from Water Mission Area Chief of Staff

-- in the above, unsure on the Group Sponsor (verses Project Champion verse Division Director) and unsure at what level Adrienne's Chief of Staff title is applied.

[jordansread]

Yeah, good clarification there. I was in communication w/ Adrienne's proxy (because Adrienne was on leave) and trying to wrap up several last requests that came out of that interaction. So in that case I was handling the "One more ✔️" and we weren't quite able to get there in that case (on Friday) so I had us stand down.