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

Hi Max, Konstantin, and Rob,

Thanks for the good discussion.

I have downloaded and tested RC2 with the changes, and have the following observations:

The overall usability of the server wizard has not regressed, including any previously working scenarios, and has been enhanced by discovering the available downloadable server adapters.
Additional enhancements are appropriate regarding adding additional metadata for display properties, in addition to cache refresh policy improvements, but this doesn't negate or diminish the current enhancement that adds value to the release.
Stephen has assured me there are already open enhancements to continue to improve the user experience in Mars.2.

To be clear this is already in the RC2 declared driver tested last week.

Thanks - Chuck

Senior Architect,
WebSphere Developer Tools, Eclipse WTP PMC Lead
IBM Software Lab - Research Triangle Park, NC




From:        "Steven Hung" <sghung@xxxxxxxxxx>
To:        wtp-dev@xxxxxxxxxxx
Date:        09/01/2015 11:36 AM
Subject:        Re: [wtp-dev] Requesting community feedback for changes to the New Server Wizard
Sent by:        wtp-dev-bounces@xxxxxxxxxxx




For Max and others, you can try it out in this build: http://build.eclipse.org/webtools/committers/wtp-R3.7.1-M/20150901020140/M-3.7.1-20150901020140/
 
Thank you everyone for your feedback. There will be a PMC meeting today to discuss this feature. I'll update everyone on the results of the discussion with the PMC members.

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: "Max Rydahl Andersen" <manderse@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: Tue, Sep 1, 2015 3:50 AM
 

> I basically agree with absolutely everything Konstantin said. His UX
> critiques are informed and relevant on all fronts, and his Mars.2
> conclusion is something I also agree with. I for one would have been
> shocked to see this suddenly in Mars.1 and would have been scrambling
> to figure out what happened.

+1

I like the idea and the suggested improvements, but getting this into
Mars.1 seems optimistic (at least if enabled by default - could this be
included but have "show additional server adapters" off by default in
Mars.1 ?).

Is there a patch/build somewhere one can try the current solution ?
(just wondering since I did not spot it in the mail thread).

One of my main concerns are the comment on the wiki saying "When you
select a server node which has not been downloaded yet, it will refresh
it and do the provisioning to ensure the server can be successfully
installed" that makes it sound to me that if I use the keyboard (and I
often do ;) and scroll through the list or type out a name a selection
listener will start provisioning which dependent on the server adapter
could be long running (10+ seconds) operation to know if possible to
install.

/max

> - Rob Stryker
>
>
> On 08/31/2015 05:00 PM, Konstantin Komissarchik wrote:
>>
>> While Mars.1 does indeed allow new features, dropping a new feature
>> into a release without allowing sufficient time to react to feedback
>> is not a good development practice. I appreciate the work that has
>> been put into this, but I continue to be of the opinion that this
>> feature is unfinished as it is currently implemented and we would be
>> much better off to leave it out of the Mars.1 release. I would have
>> no objection to including it early in Mars.2 cycle, when there is
>> plenty of time to iterate on feedback.
>>
>> - Konstantin
>>
>> *From:*wtp-dev-bounces@xxxxxxxxxxx
>> [
mailto:wtp-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Steven Hung
>> *Sent:* Monday, August 31, 2015 1:37 PM
>> *To:* wtp-dev@xxxxxxxxxxx
>> *Subject:* Re: [wtp-dev] Requesting community feedback for changes to
>> the New Server Wizard
>>
>> Hi Konstantin, thank you for your feedback. Please see my comments
>> inline.
>>
>> 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 <
mailto:sghung@xxxxxxxxxx>
>>
>> ----- Original message -----
>> From: "Konstantin Komissarchik"
>> <konstantin.komissarchik@xxxxxxxxxx
>> <
mailto:konstantin.komissarchik@xxxxxxxxxx>>
>> Sent by: wtp-dev-bounces@xxxxxxxxxxx
>> <
mailto:wtp-dev-bounces@xxxxxxxxxxx>
>> To: "'General discussion of project-wide or architectural
>> issues.'" <wtp-dev@xxxxxxxxxxx <
mailto:wtp-dev@xxxxxxxxxxx>>,
>> "'Sarika Sinha'" <sarika.sinha@xxxxxxxxxx
>> <
mailto:sarika.sinha@xxxxxxxxxx>>
>> Cc:
>> Subject: Re: [wtp-dev] Requesting community feedback for changes
>> to the New Server Wizard
>> Date: Thu, Aug 27, 2015 8:10 PM
>>
>> I was on vacation with limited connectivity, so couldn’t respond
>> sooner. Comments inline.
>>
>> *From:*wtp-dev-bounces@xxxxxxxxxxx
>> <
mailto: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 <
mailto:wtp-dev@xxxxxxxxxxx>; Sarika Sinha
>> *Cc:* wtp-dev@xxxxxxxxxxx <
mailto: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?
>>
>> [sghung] Mars SR1 is still a release that allows for enhancements.
>> By providing a method of reverting to the old behaviour, we ensure
>> the corner cases and glitches can be resolved. In addition, as
>> users are exposed to this enhancement, the feedback can be used
>> towards improving this enhancement in SR2 and beyond.
>>
>>
>> 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.
>>
>> [sghung] Having the two wizards be the same sounds like a much
>> larger enhancement, which is outside of the scope of this
>> particular enhancement. Even before this enhancement, I would
>> argue that the two wizards are not the same. The New Server Wizard
>> would link back to the Runtime preferences page for server adapter
>> that already exists. If it does not exist, there is no linkage.
>>
>>
>> 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.
>>
>> [sghung] This issue has been fixed. Clicking on the tree item no
>> longer performs the validation. Once the user clicks on the
>> desired downloadable server adapter, the user would click "Next".
>> Only then, will the server adapter perform the validation. If
>> there is an error, the error message (which includes the
>> diagnostic information) will be printed out to the user on the
>> wizard page.
>>
>>
>> 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?
>>
>> [sghung] For Mars SR1, this method of using a snapshot is the
>> current approach. For Mars SR2, I have confirmed with the
>> developers that they will work on an approach that will do an
>> automatic cache update to avoid this stale cache problem.
>> Currently, if the user does click on a downloadable server
>> adapter, that particular entry will be refreshed automatically
>> (without requiring the user to click the "Refresh" button). That
>> is, if the server's update site has an updated version, this new
>> version would be installed (not the timestamp and version that is
>> stored in the cache).
>>
>> 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.
>>
>> [sghung] I agree that showing progress would be better. Currently,
>> the "Refresh" button becomes disabled while the refresh is
>> occurring. The behaviour is similar to when the user modifies the
>> compiler settings (e.g. validation). The job will be kicked off in
>> the background and if the user closes the preference page, the
>> progress dialog will appear with the "Run in background" button. I
>> will bring up this concern to the developer. I feel like having
>> the progress bar in the wizard (instead of a separate dialog)
>> would be more ideal.
>>
>>
>> 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.
>>
>> [sghung] This issue has been fixed and the explanation of how it
>> works is seen on point #2.
>>
>>
>> 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?
>>
>> [sghung] The version is cached in order to allow for future
>> validation and discovery of downloadable adapters. By having the
>> framework in place with this extra information, it will also help
>> with the automatic refresh of the cache in the future. Currently,
>> the version in the cache does not have any effect.
>>
>>
>> 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.
>>
>> [sghung] The automatic caching mechanism will be examined as part
>> of Mars SR2 by the developers. The fix will remove the need for
>> the "Refresh" button and out-of-date cache.
>>
>>
>> 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.
>>
>> [sghung] For comments #8-10, thank you for elaborating on this
>> metadata issue. I will talk with the developers on this. In the
>> future, the metadata to provide the correct labels and what server
>> would be installed would be there. However, even in the future,
>> the need for showing the downloadable server if the server adapter
>> does not react still needs to be in place. By using the currently
>> existing metadata, it can populate the New Server wizard with its
>> best effort.
>>
>>
>> 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.
>>
>> [sghung] Getting back to the New Server wizard after a refresh is
>> tricky. As mentioned before, this seems to be a limitation on the
>> Eclipse platform. For instance, I know of an extender of WTP,
>> which will bring up a dialog on startup (in some situations) or a
>> different welcome page. As a result, the New Server wizard
>> automatically coming up again would create multiple wizards shown
>> at the same time. I believe something needs to be changed on the
>> Eclipse platform side to create a proper snapshot of what's
>> happening  and then bring up the exact same snapshot on a restart.
>>
>>
>> 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?
>>
>> [sghung] yes, the wizard exits when the installation has completed
>> and requires a restart.
>>
>>
>> 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.
>>
>> [sghung] At least for the initial release in SR1, preserving the
>> old behaviour is desired in case the user does not like the new
>> approach. By getting feedback from the initial release in SR1,
>> these issues can be addressed in SR2 and beyond.
>>
>>
>> 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.
>>
>> [sghung] This issue will be fixed as described in point #6.
>>
>> 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.
>>
>> [sghung] This issue will be fixed as described in point #6.
>>
>>
>> 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 <
mailto:sghung@xxxxxxxxxx>
>>
>>     ----- Original message -----
>>     From: "Konstantin Komissarchik"
>>     <konstantin.komissarchik@xxxxxxxxxx
>>     <
mailto:konstantin.komissarchik@xxxxxxxxxx>>
>>     Sent by: wtp-dev-bounces@xxxxxxxxxxx
>>     <
mailto:wtp-dev-bounces@xxxxxxxxxxx>
>>     To: "'General discussion of project-wide or architectural
>>     issues.'" <wtp-dev@xxxxxxxxxxx <
mailto: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>
>>     [
mailto:wtp-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Steven Hung
>>     *Sent:* Friday, August 21, 2015 11:24 AM
>>     *To:* wtp-dev@xxxxxxxxxxx <
mailto: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 <
mailto:sghung@xxxxxxxxxx>
>>
>>     _______________________________________________
>>     wtp-dev mailing list

>>     wtp-dev@xxxxxxxxxxx <mailto: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
>>
>> _______________________________________________
>> wtp-dev mailing list
>> wtp-dev@xxxxxxxxxxx <
mailto: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
>>
>> Image.image001.png@xxxxxxxxxxxxxxxxxxxxx
>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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


/max

http://about.me/maxandersen
_______________________________________________
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
_______________________________________________
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