Implement easily enabled "test" UI indicators & functionality for test extension builds

[jeffbl]

Note that I'm using "test" as the name instead of "beta". Could go either way, but right now, the production version is beta, so having this one marked "beta" may be confusing until we indicate the production one is no longer beta... Is "test" the right word? Alternative could be "alpha" or something else?

When we want to push a test version of the extension, it needs to have some UI and functionality differences, and I'm sure we'll come up with other things as we go along. Rather than ad-hoc specifying and tweaking all of them each time, suggest we have some sort of flag we can set as part of build, along with some additional options that may be set or not, including:

• [ ] enable "(test)" suffix text in the context menu item
• [ ] On maps and charts buttons, add "(test)" to end
• [ ] specify unicorn as default server (sometimes may want to do this, other times not)
• [ ] On browser extensions page (and everywhere) change offical name to "IMAGE Extension (test)"
• [ ] On results page, have a prominent test marking "(test)"
• [ ] In options page, have a prominent test marking "(test)"
• [ ] LOW PRIORITY: specify whether developer mode should be on by default
• [ ] POSTPONE/WONTDO: Can we add "(test)" to the actual version number? Would we want to do so?

Not sure what else we might want/need to do to make sure we don't toggle lots of things back and forth manually and forget one such that it slips through into a production build or something...

Assigning first to @Cybernide since there are naming, design, and functionality issues to be resolved before this goest o Jaydeep for implementation.

[Cybernide]

Since this version is explicitly so we can get this into the hands of people to test UI functions, I would use the label "test". Also, when I've given this to our panelists in the past, I've always labeled the package "test", so it'd be good to have that be consistent.

From your list, I like the following:

• [ ] enable "(test)" suffix text in the context menu item
• [ ] On maps and charts buttons, add "(test)" to end
• [ ] On browser extensions page (and everywhere) change offical name to "IMAGE Extension (test)"
• [ ] On results page, have a prominent test marking - I think adding the text (TEST) to the heading will be sufficient
• [ ] In options page, have a prominent test marking - I think adding the text (TEST) to the heading will be sufficient

I don't think that it would be helpful to have developer mode enabled by default as that mostly results in cluttering the context menu interface, which can already be confusing to our users. Nor is it necessary to specify unicorn to be the default server, as there are times when experiments there will not provide the best outputs when we want to test only the UI. I don't think it is possible to add "test" to the actual version number, nor do I think it is necessary: I have plenty of anecdotal evidence that our panelists are not paying attention to it!

[jeffbl]

For developer mode and server choice, I wasn't suggesting locking it to those options, but having a way to set this per-release. Developer mode on by default might be a very rare case, but I can easily see us wanting to test new preprocessors/handlers that are not in production, but are running on unicorn, even for panel, etc.

Also, to clarify, I see this being used by external people like user panel, but also internally where we would all likely be running the beta so that we're getting more testing on things that are not yet in production. I'm hoping this does not necessitate yet a third extension release. :) Another option is to have another options flag that enables/disables functionality we want to test, and run it on pegasus. That would mean we'd be moving to three tiers of functionality, which I'm not eager to do right away:

1. in production on pegasus, enabled for everybody
2. in test on pegasus, enabled via an options switch (perhaps tied to developer mode)
3. on unicorn, not ready to be moved to pegasus.

For now, I'm hoping we can get away with just the one "test" extension for external and internal purposes, but let me know what you think...

[Cybernide]

Well, as an internal member of the team, I can certainly tolerate switching servers and toggling developer mode, but I suppose I can't speak for everybody :)

I say we implement the subset of changes that I marked down in my previous reply for now since I think we can agree on those and open the rest up for discussion at next tech-arch.

[jeffbl]

RE: default to unicorn, this may be necessary due to breaking changes, so I'd argue we'd want the abiltiy to do that by default. @Cybernide I've updated the checklist in the first item to reflect yours + the ability to toggle to unicorn automatically based on this. I'll raise at tech-arch today, but if no changes from meeting, and good with you, please assign to jaydeep for implementation.

[Cybernide]

I'm also keeping myself assigned because there's a few Chrome Store page items that I'll need to do :)

[jeffbl]

@jaydeepsingh25 my changes to first post checklist didn't get saved this morning - should be corrected now.

[Cybernide]

Hello, I cannot change the name of the extension on the Chrome Store page. That has to be done inside the package. Should I upload the current Nightly build and rename to "IMAGE Extension (TEST)" ? Assigning @jeffbl for making the call

[jeffbl]

@jaydeepsingh25 I talked with @Cybernide this morning, and we're thinking that a daily upload of the nightly extension as the test one on the chrome web store is way too much. What do you think of:

• nightly builds by default enable the "test" flag as outlined in this work item
• once a week (@Cybernide I'm actually thinking Friday, so that it updates for everyone over the weekend, in advance of tech-arch?) cyan uploads to Chrome Store, and everyone on team should get auto-updated over the weekend
• any problems can be brought up at tues. morning tech-arch

Does this make sense to you? Are there gotchas of which we are unaware?

[jeffbl]

@jaydeepsingh25 as mentioned in this comment, please use the checklist at the top of this work item, not cyan's one below. Shouldn't be that different if you don't do the low priority/wont fix items. Thanks!

[jaydeepsingh25]

From the above checklist, two items are still pending:

• [ ] specify unicorn as default server (sometimes may want to do this, other times not)
• [ ] LOW PRIORITY: specify whether developer mode should be on by default

Adding them in the existing code is not straight-forward and further leads to regression issues related to options page and thus refactoring the code (for options page) will be required. @jeffbl please let me if the above items are must-have, if yes, then i will create a separate github issue to refactor options page code. If not, this issue can be closed.

[jeffbl]

No, if these are very difficult they can be postponed in backlog in new work item, no problem, as part of refactoring the options page.