WikiTree Apps Project Browser Extension Planning

Date: [unknown] [unknown]
Location: [unknown]
Surname/tag: wt_apps

Notes on the new browser extension that will be developed by the WikiTree Apps Project.

See Chris' post in G2G.

The code will be hosted on GitHub.

An updated version of the extension will be released every [?].

All features added need to have an option to be turned on or off. They must default to off.

All features must follow the Style Rules (example, no inserting non-recommended HTML tags into bios).

Contents 1 Name? 1.1 Suggestions 2 To-dos 3 Other Questions 4 WikiTree App Interfaces 5 Testing 6 People Interested in Working on It 7 Helpful Links

Name?

The browser extension should be for advanced users, so the name might reflect that. Though something like WikiTree Sourcer is actually great for new users who have trouble creating citations. I.e. it helps with the learning curve.

Suggestions

• WikiTree Addons
• WikiTree Advanced
• WikiTree Alto
• WikiTree Assistant
• WikiTree Beyond
• WikiTree Boost / Booster
• WikiTree Enhanced
• WikiTree Extras
• WikiTree Helper
• WikiTree Tools
• WikiTree Ultra
• WikiTree Xtended
• WTX
• WikiTree (if there is only one WikiTree extension)

To-dos

• Set up Google account
  • Should this be the primary Search Console account so that we can set the Official URL as the verified wikitree.com site? Homepage and Support URLs can go to Space and/or G2G pages as needed.
  • Analytics Tracking on the extension?
• Set up Apple account
• Set up Mozilla/Firefox account
• Create basic files
  • Needs an options page
  • Global Variables (e.g., ProfileID)
  • Need a vision for how it will evolve to come up with a good file structure
• Agree some coding standards (e.g. indentation style)

Other Questions

• Should there only be one uber-extension?
  • One option would be to have two - one for working with other sites (many sites in manifest.json and many sites in options) and one for working on the WikiTree site (working with WikiTree apps and the API)
• What should be used for storage? Cookies? LocalStorage? IndexedDB?
  • For Sourcer & AGC chrome.storage (either local or synced) has been sufficient. What might we want other storage for?
• How often should it be updated? (Weekly? Monthly?)
  • Sourcer and BEE have updated frequently (sometime several times a week) without issues. Is there any reason for a schedule other than "when something is ready to release"? What are the considerations? Dev team coordination? User impact? Dev time involved in doing a release? (for Sourcer this has increased now three stores are involved).
  • I believe this was suggested to limit the number of overall releases needed. Updates alone could be a full time job for a small (or 1-person) team when multiple developers are contributing. Steve Harris 20:40, 13 April 2022 (UTC)
• Which browsers will it be available on?
  • Chrome
  • Firefox
  • Safari
  • Edge*
  • Opera*
  • Vivaldi*
  • Brave*
  • Kiwi* (good for Android Tablets)

*All support Chrome extensions

• What data can we use from Aleš? (Such as template definitions).
• Manifest version
  • Currently there is no choice: have to use MV3 for new extensions on Chrome and have to use MV2 on Firefox and Safari. Eventually Firefox and Safari should support MV3.
• Minimum spec (which browser versions to support)
  • Currently Sourcer requires Firefox 89 because it uses dynamic module loading in the content script.
• How to handle multiple browser support
  • Do we use a build script that puts together the extension folder for each browser since they need different manifest.json files?
  • Are there branches in the code for different browsers and different manifest versions? Or is this handled by a build system?
• Should we use a minimizer or bundler?
  • AGC & Sourcer do not currently.
• Should we use any 3rd party libraries?
  • Some extensions are using jQuery
  • WikiTreeX uses genScrape
• Goals for extension size, memory usage, performance
  • Whether to use dynamic loading of modules for example
• If we manage functions through a Menu listing (e.g., a menu option to print the Bio), do they still need an Off/On switch in settings?
• Should we support internationalization (chrome.i18n)?
• Would the repository on GitHub be public?
  • What would the license be?

WikiTree App Interfaces

URL Parameters for WikiTree Apps

• BioCheck
• Fan Chart
• Profile Overview
• Surnames Generator

Testing

• Regression tests (e.g. locally using node.js or browser automation)
• Test version for people to manually test

People Interested in Working on It

• Jamie Nelson - development and testing
• Ian Beacall
• Tommy Buch - testing; maybe some development
• Thom Anderson - testing; maybe some development
• Greg Clarke
• Steve Harris - Development and testing
• Aleš Trtnik - Port of WT+ extension. It is focused on Editing Bio and other pages. Main WT+ Extension features are Template adding and editing, Bio cleanup, Sourrce pasting, EditBOT support on Category pages,...
• Rob Pavey - Though focused on WikiTree Sourcer right now

Helpful Links

• Chrome extensions
  • https://developer.chrome.com/docs/extensions/mv3/getstarted/
• Safari extensions
  • Apple guide on generating Safari extension from a Chrome one
  • Some notes on the Safari clipboard write security restrictions