Document how to use resource bundle Web UI about personfinder

[nworden]

Do you know when the last time the bundles feature was used? I'm wondering if custom repo messages (homepage messages, footer messages, etc.) might cover the use cases the resource bundle system was designed for. Since resource bundles seem pretty error-prone, and the code to support them adds some kinda significant complexity, I think we should consider getting rid of the bundle feature if we don't need it.

[zestyping]

Hi! Just saw this float by in my inbox and thought I'd chime in. The resource bundle system, as I recall, was created to make it possible to override or localize any part of the UI without having to deploy a code change. For many of the Person Finder deployments while I was on the team, it was a lifesaver to be able to instantly override anything or add translations on the fly while we were in the heat of a response, instead of building and testing. I think you could evaluate this decision on the basis of whether the possibility still exists for conditions like that.

…

On Wed, Feb 20, 2019, 13:52 Nick Worden ***@***.*** wrote: Do you know when the last time the bundles feature was used? I'm wondering if custom repo messages (homepage messages, footer messages, etc.) might cover the use cases the resource bundle system was designed for. Since resource bundles seem pretty error-prone, and the code to support them adds some kinda significant complexity, I think we should consider getting rid of the bundle feature if we don't need it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOaNv3XckRowDv5e-IOzYtKBbFBN3Xtks5vPcOpgaJpZM4DhXqR> .

[nworden]

Wow, it's Ping! It's great to hear from you! Thanks for your input, it's definitely useful to have background on what resource bundles were developed for.

I think we have two sets of things to consider:

• What the system gets used for. I suspect it's gotten less use over time as PF has matured and there are fewer surprises during a response.
• Whether resources bundles are still how we want to address the use cases we have, especially since we're moving to React for the non-lite UI. Although I imagine we could technically treat the compiled JS as a resource like anything else, I don't think it'd be pretty (as we'll certainly want to compile the JS in advance either way for performance reasons).

[zestyping]

Yeah, compiled JS wouldn't make sense as a resource. The resource editor is supposed to be a human-facing UI for making quick edits by hand. I could see it being used for text (inserting helpful information into the UI, or adding translations that weren't previously prepared), or small formatting changes (maybe you need to change something in a way that goes a bit beyond a home page custom message), or images (maybe you want to post a custom message on the home page that includes embedded images, so you need somewhere to put the images, and resource bundles are a natural fit because the images might have localized versions).

…

On Thu, Feb 21, 2019 at 3:02 PM Nick Worden ***@***.***> wrote: Wow, it's Ping! It's great to hear from you! Thanks for your input, it's definitely useful to have background on what resource bundles were developed for. I think we have two sets of things to consider: - What the system gets used for. I suspect it's gotten less use over time as PF has matured and there are fewer surprises during a response. - Whether resources bundles are still how we want to address the use cases we have, especially since we're moving to React for the non-lite UI. Although I imagine we could technically treat the compiled JS as a resource like anything else, I don't think it'd be pretty (as we'll certainly want to compile the JS in advance either way for performance reasons). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOaNj0cgH7NPdmfPEcuzJ95in_-FzM9ks5vPyV9gaJpZM4DhXqR> .

[gimite]

Oh Ka-Ping! Long time no see.

To elaborate what Nick said: We are switching to use React to construct UI, which means that majority of our UI will be written in JS (precisely, JSX) and gets precompiled. So we will no longer be able to use (current) resource bundles to tweak UI. We may be able to develop a new resource bundle system which works with React, but it sounds nontrivial.

Looking into history of our resource bundle in production, it was probably in 2015 when we used resource bundle in the last time. We updated the resource bundle several times after that, but it was probably just to keep it consistent with the production resources.

That said, it is true that it was historically useful, and it is also true that its usage has been significantly reduced over time.

And it was also the cause of several production bugs in the past when it got out of sync with the production code.

Considering all above, I'm personally OK to remove it. But we should probably hear Pete's opinion too from operation perspective.

[zestyping]

Out of curiosity, why are you rebuilding it in React? Is it just to change the look?

…

On Thu, Feb 21, 2019, 20:31 Hiroshi Ichikawa ***@***.*** wrote: Oh Ka-Ping! Long time no see. To elaborate what Nick said: We are switching to use React to construct UI, which means that majority of our UI will be written in JS (precisely, JSX) and gets precompiled. So we will no longer be able to use (current) resource bundles to tweak UI. We may be able to develop a new resource bundle system which works with React, but it sounds nontrivial. Looking into history of our resource bundle in production, it was probably in 2015 when we used resource bundle in the last time. We updated the resource bundle several times after that, but it was probably just to keep it consistent with the production resources. That said, it is true that it was historically useful, and it is also true that its usage has been significantly reduced over time. And it was also the cause of several production bugs in the past when it got out of sync with the production code. Considering all above, I'm personally OK to remove it. But we should probably hear Pete's opinion too from operation perspective. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOaNjclBfsoWJBnYI1ypXJRwYP4lppdks5vP3KMgaJpZM4DhXqR> .

[nworden]

Yeah, it's about aesthetics. We've gotten some feedback internally that it doesn't "feel modern."

[zestyping]

It seems like a shame to invest a lot of effort in a rewrite with potential costs to functionality or stability, if the reasons are indeed purely aesthetic. Shouldn't decisions about development priorities and about keeping or removing functionality be primarily driven by good arguments for what will help people contact their loved ones?

[nworden]

To get more precise, I'm going to separate this into two questions: a) why are we implementing a redesign and b) why are we doing it with React instead of sticking with Django templates.

Why we're implementing a redesign: I guess this is really the question I had in mind when I replied two comments up. I'm not sure there's anything that makes this redesign significantly different from any other product that gets a UI redesign after a period of time (this isn't the first time PF has seen a "UI upgrade", after all). If aesthetics didn't count for anything, there are a lot of ways we could reduce technical complexity, but they count for something so here we are.

As for why we're doing it with React: we considered implementing the redesign with something simpler (most likely using the underlying Material components for web directly within the existing Django templates), and I won't deny that that option might be a better fit for our current feature set. However, we're exploring some new response-related features* that would involve substantially more frontend logic (such that we'd want to be working with something like React if/when we implement them), and we're not going to have the time to rewrite the frontend twice anytime soon. Given the time/opportunity to rewrite the frontend once, ultimately it seemed like a good idea to use our rewrite on a move to React so we'd be in a better position later on.

* They're not fully baked yet, but if you're interested in discussing those potential features further, LMK and I can set up a VC (with you, me, and Pete) to talk more about it.