|Re: [wtp-dev] Requesting community feedback for changes to the New Server Wizard
I was on vacation with limited connectivity, so couldn’t respond sooner. Comments inline.
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).
[kosta] I understand that this is the intention, but there are a lot of details and corner cases to get right here. If UX isn’t quite right or there are caching/network glitches, then adopters are going to be dealing with user support cases when users aren’t able to installer the adapters. What is the driver for rushing this out in Mars.1 without taking the time to ensure that the feature is robust and polished?
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.
[kosta] I see this disparity causing a lot of user confusion as this page of the New Runtime and New Server wizards has before looked and behaved the same. This feature should be extended to the New Runtime wizard.
Thanks for your suggestion, Sarika will try and implement this tomorrow.
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.
[kosta] Having a pre-fetched cache in WTP distribution does avoid the problem of the initial fetch, but what is the process for updating the static snapshot? Is someone going to have to remember to do this for every WTP release?
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.
[kosta] If user initiates an action, especially from within a dialog, the progress feedback needs to be more obvious than the jobs progress indicator. A typical UX pattern employed elsewhere in Eclipse is to run the task in the progress dialog that has a “run in the background” button.
On failure, there is a message in the Logs view to help the user diagnose the issue.
[kosta] Using the Error Log view for expected failures messages is a bad UX practice. In the case of a failure of a manually-activated action, any failure should be displayed in a message box.
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="188.8.131.52507100122"/>
[kosta] What is the purpose of caching the version? This bit of data will grow stale the quickest. What happens when the cache contains an older version than what’s currently published?
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).
[kosta] Automated cache refresh can happen in the background on Eclipse startup and provides a better user experience than requiring the user to hit the refresh button manually, especially once the distribution is a bit older and the cache is so out of date that every new installation _requires_ the user to hit refresh before they can use the feature.
The separate progress dialog existed before. To add this into the wizard would be something to investigate after Mars SR1.
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).
[kosta] You are using feature name in place of server name. The two will never match. It’s not something that adapter providers can fix on their own. For instance, the dialog needs “WebLogic Server”, but the feature name will always be “WebLogic Server Tools” or “WebLogic Server Adapter”. Additional metadata properties need to be defined to allow adapter providers to supply you with server names as opposed to feature names.
Yes, the metadata provider can change how the server appears in this list.
[kosta] I don’t understand this answer. I am looking for a solution for the case where one adapter feature handles multiple server versions and the provider wants to keep it as one feature.
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.
[kosta] That sort of works. You are conflating adapter vendor with server vendor. The two don’t have to be the same, even if they are the same for all current examples.
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.
[kosta] Without ability to resume, the UX strikes me as unfinished. It contains the promise that the user can install as part of the wizard flow without actually allowing the flow to resume properly after restart. This UX issue didn’t exist in the old UI as the action to install the adapter was a separate command outside the main flow of the wizard.
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).
[kosta] My question pertains specifically to the wizard? Does the wizard exit?
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
[kosta] That’s pretty confusing UX. Why is it necessary to preserve the old UX? In my mind, if the new UX is working properly there is no need for the old one. Multiple UX paths will only serve to confuse users.
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:
[kosta] In the old UX, the hyperlink was essential to access the install facility. Once UX and caching issues in the new approach are smoothed out, users aren’t going to need to interact with those controls except in very rare cases. As such, there is little need to continue to take up the space in the wizard.
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.
[kosta] The user should not have to hit Refresh button at all, except in some very rare corner cases, so there is no need to have it in a prominent location.
Back to the top