-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement easily enabled "test" UI indicators & functionality for test extension builds #274
Comments
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:
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! |
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:
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... |
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. |
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. |
I'm also keeping myself assigned because there's a few Chrome Store page items that I'll need to do :) |
@jaydeepsingh25 my changes to first post checklist didn't get saved this morning - should be corrected now. |
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 |
@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:
Does this make sense to you? Are there gotchas of which we are unaware? |
@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! |
From the above checklist, two items are still pending:
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. |
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. |
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:
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.
The text was updated successfully, but these errors were encountered: