QR Codes in the "Share Your Settings" area

[perryholden]

@blocher - In talking with others, I thought that a scannable QR code might be a good addition to the "share your settings" area, in addition to copying the settings URL. It could display below the "link to copy", and it can either be scanned from the phone directly or screenshotted/printed and placed in an area where people can scan the code for that day's prayer service (of course the latter option could already be done manually, but it'd be nice to make it easier from the app, especially from something like a tablet). There appears to be a very good library for generating QR codes in Vue: https://github.com/scopewu/qrcode.vue. The code seems to be fairly compact without adding a lot of overhead to the app. There is also a demo here, which I have been using in tests: https://qr-vue.tie.pub/

Taking default settings, here is the sharable URL string:

https://www.dailyoffice2019.com/settings?language_style=contemporary&psalm_translation=contemporary&bible_translation=esv&psalter=60&reading_cycle=1&reading_length=full&reading_audio=off&canticle_rotation=default&psalm_style=whole_verse&lectionary=daily-office-readings&confession=long-on-fast&absolution=lay&morning_prayer_invitatory=invitatory_traditional&reading_headings=off&language_style_for_our_father=traditional&national_holidays=all&suffrages=rotating&collects=rotating&mp_great_litany=mp_litany_off&ep_great_litany=ep_litany_off&general_thanksgiving=on&chrysostom=on&grace=rotating&o_antiphons=literal&family_readings=brief&family_reading_audio=off&family_collect=time_of_day&family-opening-sentence=family-opening-sentence-fixed&family-creed=family-creed-no

Uncompressed length: 770 characters

The resulting QR code is quite large, but it still scans easily when displayed on a cell phone at roughly 360px. I'm not sure how well it will print, but it does work as-is, without any modifications to the string. In order to get the QR code smaller (i.e. less complex), however, I've thought of a couple of possibilities. I'm not sold on either of them, but I wanted to mention them.

Proposal 1: Using the deflate algorithm

I've looked at a few different compression algorithms, including smaz, but I found that deflate worked the best. Here is a sample result:

https://www.dailyoffice2019.com/settings?deflate=eJx1UkFuxDAI/I1vkdpLb36LxTrYsepABM62/n3xJtvdrdQbMGZmAFegvEPGoK1X9JGp4bqxgHS3KdQ1NAHSCq0wvcKXcqn4AqNeb00NxX+8OUGYC+UQezTq99+8IuW2+LTX+luDfS7sOSUXgVqxhiDcDtoZE+y1nX4Oo18L25MriqKrGMc78+RnKLVPRlMiTie3OrOdUHVwVaY8MU0JtDm4KNf9plGhu5WFhpdNoKOEQtdiDthoH+GYdy43uYf55RS6+a8vGw2JJfAuIUFbbC3P7QRHEGyWMkNXD7YR3VMS61d/LICy+a9jxqfKuoVs6i1U80XdW35EYVjAPyi+oBkJxVTbAvSpuVyN0DO5uEhX1sbryLJAxIcgh3GWbWFSb1yDwCVYbdvhvmZ/kYLpT/XpsCdwDuNbWdH8BBv8hCbecBxgUrRvRib/T31K5Rvne1cUxNk/JxPxD53VH3g=

Compressed length: 518 characters
Length difference: 260 characters (33.7% smaller)

This size will still be fairly easy to print. If using compression, I prefer the idea of deflate because it's a well known, widely-used algorithm.

Proposal 2: Making a bespoke dictionary for substitution

https://www.dailyoffice2019.com/setting?ls=c&pt=c&bt=esv&ps=60&rc=1&rl=f&ra=0&cr=d&ps=wv&l=dor&c=lof&a=l&mpi=it&rh=0&lof=t&nh=all&s=r&c=r&mpgl=0&epgl=0&gt=1&chr=1&g=r&oa=l&fr=b&fra=0&fc=tod&fos=f&fc=0

Compressed length: 201 characters
Length difference: 569 characters (73.8% smaller)

This is just an example, and I didn't put a lot of thought into the abbreviations. But if you really want the URL to be short, this is a possibility that makes for a very not-complicated QR code. I'm less excited about this one, as one will need to remember to add an entry for each change in settings, that is, if we ever add or modify settings/options in the future. It seems messy, however, and I'm not sure if it's worth it to get the QR code a lot smaller.

Anyhow, I welcome your thoughts. We can try implementing the plain URL encoded and test it and see how well it works, if we want to start there. Or we can try to shorten it to simplify the generated QR code a bit. Or, if you don't think this is worth adding right now, feel free to say so. What do you think?

[blocher]

I do like the QR code idea and I do like option 2. As more settings were added, the link size has gotten out of control. Another idea would be a settings string that has the values in a set order with no gets so ?settings=01300124, with each digit referring to a single setting's value and enforcing an order. I'm really open to any approach you choose, but I'd like to also keep the old links too for backward computability (people's bookmarks and text messages, for example).

[perryholden]

@blocher - I do like the settings string as you had suggested. I think it works since the setting with the largest number of options is "bible translation", with 7 options (so the highest numerical value would be 6). But even if we go beyond 9, I suppose we could still use letters. With a URL string formatted like that, the QR code looks great. Do you think a URL like this, with a single GET param would work? https://www.dailyoffice2019.com/settings?settings=01234567890123456789012345678. Or are you thinking of something different?

Also, I haven't put much thought into implementing the settings string in the Vue frontend. I am not really a frontend developer (at least not a good frontend developer), so I'm not sure how best to implement it. It could be a simple helper JS that's called by the Vuex createStore method (in store/index.js), where you actually apply the settings. I don't always like hard-coding values, but we could hard-code the value mapping in that new helper JS file, or we could try and abstract that out in some way. Thoughts?

Once you reply, I'll get working on it right away, and I'll also do some pretty extensive testing when ensuring values get applied correctly, all 29 of them with all possible options! 😄

[perryholden]

Thinking further, if we go with helpers, we'd need both a "create settings string" helper and a "decode settings string" helper. And it'd use the same mapping data, so we'd want to at least abstract out the settings values for that. A JSON object somewhere? I'm just spitballing, so I welcome your thoughts.

[blocher]

I'm also hardly a front-end developer, but what you are saying sounds about right to me. The Setting and SettingOptions models both already have a numeric order field and they are exposed on the https://api.dailyoffice2019.com/api/v1/available_settings/ endpoint. I wonder if we could use those for the mapping logic? To be safe it might be worth translating numbers > 9 to a letter (or always using a letter: 0=A, 1=B, etc to give us the possibility of 26 options) per setting. I'm pretty agnostic (about how this gets implemented, that is), but my only requirement is that the old links continue to work.

[perryholden]

@blocher - That's awesome (and I didn't even know that API route existed). The only hesitation I have is that if we go with using order, we'd essentially lock in that sort order, as any future change would break past generated short codes. Are you opposed to adding an additional field to the office_settingoption table, calling it something like abbreviation? We can then use a letter instead of a number, locking that value in for good, and when adding new options to the DB, it should be pretty obvious that we need to include an abbreviation value for that new setting option.

Also, one thing we'd need to fix before we go this route is that it appears that one record is missing from that office_settingoption table for the NIV translation: https://take.ms/zjcGTe

Finally, while it's not critical for this task, you'll want to update this value as well: https://take.ms/mi4DP

Let me know about the new field idea. (And I would not break the old links working.) It's really coming along though! I can't wait to start on it!

[blocher]

The new field sounds great! I had to remove NIV because of copyright issues. I pay a license for the ESV as the main translation, but did not for NIV.

[perryholden]

@blocher - I just realized that there are extra collects that can be added / appended to the settings: morning_prayer_collects=3c4e63bf-1324-4d57-aec0-e6d306799a2d&midday_prayer_collects=&evening_prayer_collects=&compline_collects=

I am not going to shorten these. If they are ever added to settings (stored in extraCollects local storage), they will be added like this:

https://www.dailyoffice2019.com/settings?settings=BAAAAAAAAAAAAAAAAAAAAAAAAAAAA&morning_prayer_collects=3c4e63bf-1324-4d57-aec0-e6d306799a2d&midday_prayer_collects=&evening_prayer_collects=&compline_collects=

That way, it can still apply those, even though they are not part of "available settings". I think since these will be rarely used, it's okay if those URLs will be a bit longer. Do you agree?