Posted May 29, 2018 04:56 PM
Hi Chris and Cathy,
Thank you for the feedback, always appreciated. You are raising a lot of points that require detailed attention. I will try to answer as in-depth as possible. Apologies for the long reply:)
Generally, the UI extensibility has been trimmed down decreasing the dependencies of the plugin to the Client and its Data Service. This brings a lot of UX, performance and usability benefits - please check the details on this below.
This has been socialized already in 2017at VMworld, dedicated webinars, the SDK Flingand the Forum.
On the point about the sample real estate consumption:
The HTML sample is demonstrating a more compex UI based on horizontal Master-Details view. This is just one way to display this data. If that is not prefered by your plugin you can always handle it by a simple Clarity list, by openingthe custom object on the whole screen (like it is with the predefined behavior)or by using a vertical Master-Details view.
On the point about the left navigator:
It is acknowledged that the left navigator is taking a lot of space in the plugin scenario. This is no better with Client-handled custom objects (just open a single chassis from the old ChassisA to observe the behavior). We are looking into ways to improve on this for plugins but I don't think the suggested options are viable.
What do you think about an option to hide the Object Navigator pane whenever the user selects your plugin? This would let you take over the whole width of the screen and handle the navigation yourself.
> "The new sample is a significant regression in usability from the original 6.5 samples"
The new sample demonstrates the recommended organization of a plugin especially regarding its global views and custom objects. There is no change to the recommended extensibility on vSphere objects so the sample contains only VM actions for now. Apart from the custom object changes this is no other usability change.
> "it feels far less integrated into the UI"
Exactly, and this is the goal based on research of user reports from the field.
There is no heavier impact onusability (mentioned in the previous point) than the current way offorcing a user to chase down which screen, section, custom object, etc. maps to which plugin when they have 5-10 plugins installed.
So what do customers do when one plugin misbehaves on a shared screen? -> They disable all plugins, including the perfectly operational ones.
What do customers do when one plugin has defined a very slow adapter for their custom object? -> They again disable all plugins to make the Client run with acceptable performance.
This is what we are fixing with the current design of loose integration with the Client. If one plugin misbehaves it will not impact your plugin and your users.
> "and the overall look+feel of vSphere"
That's not really correct. The overall look&feel of vSphere is Clarity everywhere. Object Lists are one of the few leftovers in the HTML Client that do not conform to the rest of the UI and are still not Clarity but Kendo grids. When this is fixed it would be only beneficial for the pluginit it is already there (e.g. VMware plugins like NSX have already switched to Clarity grids).
> "the recommendation to move away from custom objects seems a major step backwards"
Given the above user perspective the suggested approach makes plugin requests for data more performant (not going through the limited Data service), allowing plugins to develop their custom UI features on the custom objects (e.g. dashboards, links and icons which many of you requested inside the custom object lists and those were not avaialble) instead of enforcing a fixed UI on plugins.
By all means the future of such more flexible approach is a lot brighter than the old solution.
What is being deprecated is essentially the limited precooked custom object extensibility.
With regards to the deprecation:
Custom object extensibility has already been deprecated with 6.5U2 and 6.7GA in the last month. This means that the feature is fully supported butwe are announcing our intention to remove it at some future point. This can only happen at a major vSphere release which is a standard API lifecycle for any software out there.
There are many plugins using custom object extensibilityso we are not going to just break all those solutions out in the field. Also we completely understand this is work on your behalf.
For that reason despite the 2017 announcements thisdeprecation goes out now to provide an additional leeway for plugin writers to plan accordingly.
A decision to stop supporting it in vSphere would come based on partner adoption data and feedback received. Please also note that custom object extensibility will not be available for plugins which need to support VMware Cloud.
As far as the refresh frontend APIs are concerned:
The modal dialog support for refresh from a user action in a modal is part of 6.7GA.
The experimental model-changed API that is part of the Fling did not make it to the release. It has been considered a partial solution for the refresh scenario (e.g. does not cover long running tasks, etc.) so a more all-round solution is in the works.
Does all this make sense?
Please let me know your thoughts.
Cheers,
Vladi
What is being deprecated is essentially the limited precooked custom object extensibility.
