Try/settings page manager

[ryanwelcher]

Description of the Change

Alternate Designs

Benefits

Possible Drawbacks

Verification Process

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests passed.

Applicable Issues

[ryanwelcher]

@helen my approach to the settings screens are to have a page for the overall settings for ClassifAI and one for each of the Services the plugin provides:

Each of the Services pages has a tabbed interface for the settings of each Provider:

Having a tab for each Provider take care of the issue of having all of the settings on the same page especially if there is a large number of settings:

This branch has the new settings system in place and has Watson refactored to work as expected. Each provider stores its settings as a discrete option. This will allow for better clean up by not having to do any surgery on a serialized array of settings.

The only part I have not tackled is how to handle enabling/disabling services. This can be managed indirectly by not having credentials stored for the Provider but I am wondering if having a dedicated on/off is a better idea.

[jeffpaul]

Does anyone foresee a scenario where someone would want more than one Service Provider for a particular Service (e.g., Watson & Azure for Image Processing)? I suppose its possible, but seems like a low probability and thus feel we can make things easier on ourselves if we expect only one Service Provider to be enabled per Service. Thus having some sort of selection of the Service Provider that then presents the settings for that provider versus showing all available Service Provider settings in tabs make be less confusing? @helen what's your UX take on this?

[ryanwelcher]

@jeffpaul @helen I was thinking about this over the weekend and I think that for each feature we introduce, there really can only be one service.

For example, if we're using Image Processing to generate alt tags programmatically, we could pass the image to all of the configured Providers but there would be no way, beyond manually inspecting the results, to determine which is the best. With a single Provider, the one with the highest confidence would be the best.

Additionally, it might be a good idea to introduce a Features page where we can pick the Provider that we're using for each feature. There is definitely the possibility that a user might what to mix and match Image Processing Providers to generate alt tags, generate captions and do object recognition.

[helen]

My thought at the moment (still subject to change, etc.) is that I like this direction and I don't think the core plugin needs to support multiple providers for a given service type. This isn't necessarily technical direction, just documenting thoughts here.

For a given service type, I think that workflow would be selecting a given provider (a select would be the MVP, something more visual like a row of logos or something might be better), inputting your credentials, and then moving into the rest of the settings if your credentials check out. A potential/likely issue here is whether various service types actually map cleanly between different providers - we should probably collate a list of service provider, service (language, image, etc.), functionality, and credential requirements to compare them. I can start on that. Otherwise we don't know if saying "enter your image service credentials for X" is actually accurate.

Related to that is when a given service does not have functionality that another does for that particular service. Available functionality would be shown because you should be able to toggle each bit on and off, but what about things that aren't available so you know what you're missing?

[jeffpaul]

All good points @helen, a doc/spreadsheet showing the service providers coverage across the service types and features therein is definitely worth starting (I can also help there), and some basic UX noting how we'd display that mapping within the settings is also probably something to get someone with availability to assist on once we have that mapping listed out. For now and the near future, we're going to have a 1-to-1 mapping of service provider and service type, so standing up something simple for now is best. We can work through all the wacky combinations and a graceful UX to support that once we determine the service providers and/or services we add next.

[jeffpaul]

I think these settings changes are a good start and can be used in v1.3.0. Now just needs to add the Azure settings for the Image Processing integration, presumably via a separate PR from @helen.