Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.

 

From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Steven Hung
Sent: Tuesday, August 25, 2015 11:20 AM
To: wtp-dev@xxxxxxxxxxx; Sarika Sinha
Cc: wtp-dev@xxxxxxxxxxx
Subject: Re: [wtp-dev] Requesting community feedback for changes to the New Server Wizard

 

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?

 
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.

 

[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.

 
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.

 

[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.


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.

 

[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.


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"/>

 

[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?


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). 

 

[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.

 
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).

 

[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.


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. 

 

[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.

 
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.

 

[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.


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.

 

[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.


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).

 

[kosta] My question pertains specifically to the wizard? Does the wizard exit?


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

 

[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.

 
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:

 

[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.

 
Thanks for your consideration of this feedback.
 
- Konstantin

 

 

Regards,

 

Steven Hung

Software Developer
WebSphere Server Developer Tools and Bluemix Tools
8200 Warden Avenue
Markham, Ontario L6G 1C7

T: 905-413-2899
E: sghung@xxxxxxxxxx

 

 

----- Original message -----
From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
To: "'General discussion of project-wide or architectural issues.'" <wtp-dev@xxxxxxxxxxx>
Cc:
Subject: Re: [wtp-dev] Requesting community feedback for changes to the New Server Wizard
Date: Mon, Aug 24, 2015 6:36 PM
 

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.

 

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?

 

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.

 

3. When is the list of downloadable adapters initially fetched and is there visible feedback that fetch is in progress?

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

10. How is vendor/category determined for downloadable adapters?

 

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.

 

12. What happens to the “New Server”/”New Runtime” wizard if the user chooses not to restart?

 

13. Why is there a hyperlink on “Show additional server adapters”?

 

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.

 

Thanks for your consideration of this feedback.

 

- Konstantin

 

 

From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Steven Hung
Sent: Friday, August 21, 2015 11:24 AM
To: wtp-dev@xxxxxxxxxxx
Subject: [wtp-dev] Requesting community feedback for changes to the New Server Wizard

 

There is a new feature for the New Server Wizard that would be great to have in Mars SR1. This feature would allow downloadable server adapters to appear in the same tree viewer as the installed server adapters. Since this feature affects the existing New Server Wizard, it would be great to have feedback from the community. Please take a look at the following wiki for the new flow: https://wiki.eclipse.org/EDT:NewServerWizardFlow

If this feature is supported by the community, I will try and have this committed by Wednesday August 26, 2015. 

Thank you,


Steven Hung

Software Developer
WebSphere Server Developer Tools and Bluemix Tools
8200 Warden Avenue
Markham, Ontario L6G 1C7

T: 905-413-2899
E: sghung@xxxxxxxxxx

 

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev

 


Back to the top