Thank you Konstantin for your detailed feedback. I have included the developer, Sarika Sinha, in this email chain.
Please see my responses in green
I love seeing improvement in this area and workflow like the one described would be a big usability improvement. Having said that, I am concerned that there isn’t sufficient time left in Mars.1 development cycle for adopters to fully test, provide feedback and get bug fixes. I’d rather see this iterated on in the Neon release.
The idea behind the fix is to ensure existing server adapter providers are not broken and that they do not need to react to this new change. If the providers choose to react, then their changes will get picked up. If not, then nothing will be broken (e.g. their server adapter will still show up and install as before).
My feedback and questions:
1. The wiki only mentions the New Server wizard. Is it safe to assume that similar changes would be made to the New Runtime wizard?
No, this feature will not be in the Runtime wizard. Having it in the New Server Wizard provides a better flow for the user, as it is easier to access. To access the Runtime configuration page (as there is no Runtime wizard), the user has to open the Preferences page. This preference page is less visible than creating a new server as the Servers view is opened by default in the Java EE perspective, so the user can more easily create a server than a runtime.
2. Install feasibility validation should not be performed on selection of item in the tree. No expensive operation should be performed on this event as users have a habit of clicking around while exploring. A better approach would be to always enable the Next button and only validate when user elects to move forward. Wizard progress bar should be used while validation is in progress. If successful, the user gets the license screen. If not successful, the user gets a page with failure details. The current approach of directing user to the Error Log is not a good practice. The Error Log should not be used for communicating expected failures.
Thanks for your suggestion, Sarika will try and implement this tomorrow.
3. When is the list of downloadable adapters initially fetched and is there visible feedback that fetch is in progress?
The list of downloadable adapters initially fetched is a snapshot created at the time of this feature's development (mid August 2015). This cache is used to ensure the New Server wizard loads quickly. When the "Refresh" button is pressed, there is progress in the Progress view showing the fetching. The progress is not in the wizard, but the user will see a background process showing up in the progress bar on the lower right corner.
4. Is there feedback when downloadable adapters list could not be downloaded? We need to ensure that we avoid user confusion when they don’t see their server listed due to network issues.
On failure, there is a message in the Logs view to help the user diagnose the issue.
5. What exactly is cached? These details are needed to help evaluate the likelihood that the cached data will be stale when a new version of an existing adapter is released.
The cache contains the following information: feature description, feature id, feature name, feature provider, and feature version. For example:
<feature description="Tools for developing applications for Oracle WebLogic Server (versions 12.1.x, 10.3.x, 10.0 and 9.2)." id="oracle.eclipse.tools.weblogic.feature.group" name="Oracle WebLogic Server Tools" provider="Oracle" uri="http://download.oracle.com/otn_software/oepe/mars/" version="8.2.0.201507100122"/>
6. Is there a policy for updating cached data without having the user click on the refresh button? I would recommend triggering a refresh job when server tools is initially activated as well as after certain number of days have expired in case the user keeps Eclipse open for a long time.
No, currently there is no policy for updating the cache without having the user click the button. Kicking off the job in the background can take more than one minute, so it is more ideal to have an initial cache (a snapshot from mid August 2015) and provide a way for the user to update the cache themselves (by clicking the "Refresh" button).
7. The installation seems to use a separate progress dialog box. It would be best to use the built-in progress bar of the wizard.
The separate progress dialog existed before. To add this into the wizard would be something to investigate after Mars SR1.
8. There is a terminology mismatch caused by mixing feature names and server names in the same tree. Whereas all entries should be a server type, some are “X Server Adapter” or “X Tools”. This could be solved by adding metadata to the adapter repo so that it advertises the list of supported server types.
The terminology mismatch is caused by the server adapter's metadata. It will be up to the server adapter providers to provide the correct metadata (but we are not forcing them to do so right now).
9. Many of the downloadable adapters support multiple server versions. This leads to the contents of the tree changing after the install is completed. Ideally, only downloadable indicator icon would change. This can be solved with additional metadata like #8.
Yes, the metadata provider can change how the server appears in this list.
10. How is vendor/category determined for downloadable adapters?
The vendor/category is taken from the metadata retrieved from querying for the server adapter. For point #5, I have pasted an example of a query where we get the feature provider (in that case, it is Oracle). That is used as the vendor/category.
11. Ideally, the user should be able to resume where they left off in the wizard after the download completes and Eclipse restarts. Upon the restart, the wizard should restart with the desired server type pre-selected and page advanced to the next page, as if the download didn’t need to happen. This requires #9 in order to know which server type/version the user intended to create.
This issue is more of a limitation on the Eclipse platform. It's definitely a nice to have and would bring convenience to this item. However, this feature would be outside of the scope of this fix for SR1.
12. What happens to the “New Server”/”New Runtime” wizard if the user chooses not to restart?
A restart is required whenever the user installs a new server adapter (e.g. Eclipse marketplace or through the Install New Software). Otherwise, the server will not show up in the New Server Wizard.
The new server type feature is marked as installed in the current configuration only after a restart. As a result, the server will show up in the wizard as "downloadable" and allow users to install (again). The behavior is similar to the old behavior if you don't restart - the newly installed Server Type will not be available until restart. If the user selects and installs it again, it successfully completes and ask for restart (this time around it goes faster as the artifacts are present locally).
13. Why is there a hyperlink on “Show additional server adapters”?
This hyperlink exists to provide the old behaviour. In case the user wants to go through the old flow, the user can uncheck the checkbok. The hyperlink will be enabled and click on the hyperlink will launch the old wizard
14. The “Show additional server adapters” checkbox and the refresh button take up valuable prime real estate in the wizard, yet most users should not have a cause to interact with these controls. I suggest moving these to preferences.
The real estate of this dialog has not changed significantly with this change. The old dialog had a hyperlink at the top of the New Server wizard too:
Going to the Preferences page is a lot harder to find for the user and the "Refresh" button approach is still preferred, so it makes more sense to keep these features in the New Server Wizard.
Thanks for your consideration of this feedback.
- Konstantin
Regards,
