First of all, thank you for the detailed description and screenshot!
This functionality is currently not possible.
By the way, your plugin looks really good. The recommended approach is to have a single entry point for your plugin and then to have separate items on the left which load different views on the right (as it is in your case). The SDK team is preparing a new sample plugin which will demonstrate exactly this.
We are planning to give plugin writers more freedom with regards to the object navigator, however, currently you cannot add a list of custom objects in the object navigator.
Thank you for the quick reply.
Please let me know where can i see the sample plugin for the recommended approach. Will it be available with the next update to html-client-sdk?.
Currently i am using html-client-sdk-188.8.131.5200-6311399.
Yes, the new sample will be available in the next vSphere release.
The new sample creates an extra column for the list of chassis, which uses a huge amount of screen estate whilst leaving the navigator pane almost empty with only three static menu options.
Is it possible to show a list of registered objects in the navigator pane for a global page, similar to the automatic relatedObjects navigation panels that appear when a custom object is selected in 6.0, 6.5 and 6.7? If not, can the navigator pane be dynamically customised at runtime to show a similar tree structure to the VMWare-owned views?
The new APIs were also supposed to bring a mechanism for hooking refresh events from the back-end (e.g. following task completion), but I can't see any sign of them in the documentation. Did these not make this release, and if that's the case when will a supported mechanism be available?
Yes!! I agree completely, we use the Custom Objects as well - they are a very important part of our plug-in - so please keep them!!!
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 2017 at VMworld, dedicated webinars, the SDK Fling and 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 opening the 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 on usability (mentioned in the previous point) than the current way of forcing 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 plugin it 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 but we 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 extensibility so 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 this deprecation 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.
VladiWhat is being deprecated is essentially the limited precooked custom object extensibility.
"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)."
I'm afraid that's simply not true (or you are missing the point). Loading the 6.5 SDK "chassis-b" sample - even on the 6.7 UI - clearly shows the left navigator automatically populated with relevant, contextual objects - see attached screenshots. When a custom object type is selected, quick links to all objects of that type appear in the object navigator ("chassisb-1.png"). When a specific custom object is selected, a list of relationships appears at the top of the object navigator, and when a relationship is selected all of the related objects appear at the bottom of the navigator ("chassisb-2.png"). Whilst the style hasn't been updated, the functionality and use of screen space is all there. Whilst it could be better - configurable to support specific types/tree-type views, using Clarity style, etc. - it's better than just a blank white page.
"The overall look&feel of vSphere is Clarity everywhere"
There is a lot more to UX ("look and feel") than simply using the "Clarity" theme/style. If plugin developers cannot implement similar functionality to the VMware-provided UI, that's a serious problem.
"What is being deprecated is essentially the limited precooked custom object extensibility"
Whilst having a blank canvas might be suitable for *some* plugins (as it is for some VMware-provided pages, such as "Policy and Profiles"), having an object-based workspace is definitely suitable and necessary for others (as it is for the VMware-provided objects such as "Host" and "Datastore").
For many plugin applications, the object-oriented model fits perfectly with their use case, and the whole purpose of the plugin is to extend the vCenter UI so that it fits in seamlessly. If you only provide a blank canvas and require every plugin to implement everything from scratch, there is very little advantage to a plugin at all, and it will feel very clunky and inconsistent - end users might as well just use a different tab in their browser and a totally separate UI.
Your suggestion of hiding the navigator pane means that a custom one wouldn't be the same size if resized, etc. - this will give a quirky/inconsistent behaviour and look like a bolted-on hack rather than a seamless, native experience. Similarly, forcing every plugin to re-implement all of the current VMware object framework - the standard tabs across the top, Actions drop-down, etc. - won't exactly match the VMware-provided ones; there will be jarring disconnects in addition to all of the reinventing-the-wheel effort required for plugin developers. If you really want to go that route, please provide example code that *identically* implements the layout and style of the VMware-native objects:
1) Navigation pane with a dynamically built tree of objects / related objects
2) Global views for an object that include the global header/actions drop-down, Summary/Monitor/Configure subtabs, treeviews within the subtabs, etc.
3) List views that support right-click Actions menus for VMware-owned objects (i.e. identical to right-clicking on a datastore on the "Host > Datastores" tab), including disabling unavailable options etc.
Items 1 and 3 are currently impossible in a custom plugin; the custom object support provided in 6.5/6.7 at least provides a minimum level of capability, but even that would be lost if custom object support is removed.
As an additional note, the lists of related objects that appear in the Navigator pane when viewing a custom object fully support the right-click Actions menu (including both related VMware objects and related custom objects) - something that is currently impossible to implement inside a plugin.
Thanks. Now I got your point of view and understand why you consider the object-centric approach seamless.
Unfortunately with regards to how (vSphere and custom) object types and lists are used vSphere (and your) customers don't agree with you. VMware research shows that the whole Global Inventory Lists (the only place of menu access for your custom objects) is ordered at 83rd place in terms of visiting frequency. That means that customers just don't go there and use the tree, search and other navigation means to browse and manage their inventory. Do you really want to depend on such a screen even if your custom object list looks neat there?
So this object-based workspace that you mentioned is not suitable and not necessary neither for "Host" and "Datastore", nor for plugin custom objects! People just don't use it.
Now, if custom objects should move that should obviously happen inside your own plugin category (demonstrated in the HTML Sample).
With regards to how your custom object list is presented inside the plugin category there are 2 options:
1. Current solution with list of objects populated in the Object Navigator (e.g. like "Content Libraries"). I agree with you this is beneficial when the user selects a specific custom object but it is redundant when the whole list is opened on the right.
2. HTML Sample solution with a single link to your inventory where the objects are presented in any way you find suitable - list, dashboard, etc. (in your case I guess you will prefer a table similar to the ones of the vSphere objects).
Option 2 has a lot more upside for the future and supports the current use cases. Please keep in mind its goal is not to demonstrate "identical" experience but complete and improved one. For example:
- Do you need a custom object Monitor or Configure tab with a treeview that contains a single item? The answer is clearly No, yet the old solution was forcing that on the plugin eating up your real estate. No less than 80% of plugins that have custom objects fall into this category.
- What is the current Summary tab if not a single UI tab containing your content? The plugin owns it anyway.
The HTML Sample already shows how to have a similar but better experience with the Summary/Monitor/Configure design or even completely remove it as it is not part of the extensibility.
That said, I agree the HTML Sample does not cover all the aspects of a plugin and we are going to extend it. This is just the first version.
Thanks a lot - your feedback has been extremely valuable!
We will take it into acount to make sure the HTML Sample recommendations can fully replace the old custom object usability scenario.