Agreed - this is something we've discussed but not yet implemented.

thanks @nwmac How can the community get involved and contribute this feature ?

Beyond https://github.com/SUSE/stratos-ui/blob/master/docs/development.md do you have recommendations on how the community can suggest user experience designs prior to contributing the implementation of such feature ?

Is there public UX documents (wireframes, sitemap, scenario.s..) maintained for the other features that could be updated/enriched to describe such 1st class support for service instances/plan ?

I would love to get community contributions for this feature - at any level - from the user experience thru implementation.

Let's start with getting the UX worked through for this feature.

The UX resources are not publicly available at present - let me take an action to add them to the documentation and then yourself and others can perhaps suggest what the UX should be for this feature. Do you have any suggestions for what would work best for you, in terms of us working together on the UX for this? One option is to have the designs in GitHub as docs and use PRs and the workflow around that to add comments etc.

thanks @nwmac !

One option is to have the designs in GitHub as docs and use PRs and the workflow around that to add comments etc.

That would be great. I hope tool licensing and availability in operating systems (Linux or Windows) won't be an obstacle to collaboration on the UX design source documents.

@gberche-orange Picking this up again now we have started Angular 2 work.

I have created a placehiolder page for services work - see: https://github.com/cloudfoundry-incubator/stratos/blob/v2-master/docs/planning/services.md.

I hope to flesh this out and start to get UX design in there.

I reviewed our existing UX resources and they are way out of date.

Very interested in your thoughts on the design for this - if you have time, maybe you could add some notes to the services doc above and if you have any mockups etc, feel free to add them into the ux folder in the docs/planning folder.

Thanks @nwmac !

I'll PR against this planning doc. 1st thoughts in the meantime, regarding a global navigation of services vs a hierarchical drilling down from 1)CF instance, then 2) org, then 3) space, and finally 4.1) app and 4.2) route (as leafs). Navigation therefore is likely to require such hierarchical concept support. Following are marketplace related resources that would display based on the user selection in this hierarchy:

Resources globally visible to a CF instance (and hence suiteable for a side bar navigation independently or org/space selection) are:

• service brokers (when user has admin permissions)
• public service plans

The resources that are contextual to a given org are (in addition resources of enclosing CF instance):

• private service plans made visible to the org

The resources that are contextual to a given space are (in addition resources of enclosing org):

• space-scoped service brokers
• service plans of space-scoped service brokers
• space owned:
  • service instances.
  • service keys
  • user-provided-service
• shared service instances from other orgs

The resources that are contextual to a given app include are (in addition resources of enclosing space):

• service binding

The resources that are contextual to a given app include are:

• service binding

The resources that are contextual to a given route include are:

• route service mapping

@gberche-orange Thank you.

I can update the notes to include your input.

With "Applications", we currently aggregate apps from all Cloud Foundry endpoints that are connected - you can then choose to filter to see just those from one CF, and then filter further by org and space.

I was assuming we'd do the same for Services - does this make sense to you?

@nwmac thanks for your answer, and sorry for late followup

I was assuming we'd do the same for Services - does this make sense to you?

The UI probably needs to distinguish "service" resource (sometimes worded to users as marketplace) from "service instances" resource which is instanciated in a particular space.

In term of UX, it may be easier to have two distinct pages with distinct left hand-side links:

• a "marketplace" page listing "service" resource displaying service metadata (description, logs, documentation, service plans)
• a "services" page listing "service instances" resource displaying service instance name, service name, service plan name and dashboard url.

An alternative is to have a single "service" page displaying two distincts resource types (e.g. sequentially or in tabs)

The form to create service instances may need to appear both

• close to where the "service" resource is displayed (e.g. in marketplace page when displaying details about a service) and confirm the org/space into which the service would be created.
• in the listing of the "service instances" resource where a "+" button would prompt to select visible

For "service" resource the drilldown by CF endpoint, org and space, may need to aggregrate calls to multiple CF API endpoints to match the service access control / service plan visibility concepts. In other words only display services with service plans public, or service plans explicitly made visible in the selected org, or private space-scoped service plans. This is necessary to display non public services that are made visible in a specific org, or private-scoped services only visible in a single org.

The corresponding logic in the CF CLI illustrates this filtering.

This approximately corresponds to the CC API calls

• list all services
• for each service list all service plans
• for each service plans, check whether its public attribute is set
  • otherwise find a service plan visiblity which is associated with current org or space

Note that for the service instance creation forms to support JSON schema support discussed in #1434, the front-end api would need to return the full service plan entity response including the schemas node

"schemas": {
      "service_instance": {
        "create": {},
        "update": {}
      },
      "service_binding": {
        "create": {}
      }
    }

Please let us know if this could make sense to have UX and technical meetings when sprint 26 (focusing on services) starts.

@irfanhabib great to see progress on the catalog view contributed into #1752. It seems that the current view properly displays services with public service plans as well as services plans with a service plan visibility restricted to an org.

However, we don't see a way to filter services by org/space, as suggested into #1391 (comment)

Please let us know if/when it could make sense to have UX and technical meetings on the service catalogue view. You can reach us on slack through melchia and bercheg ids

@gberche-orange The current service catalog view is a basic first attempt. We will be adding more bits to it over the coming weeks. We intend to expand the section to show service plans, service instances, service bindings and add support for CRUD operations for service instances and bindings.

We would definitely be interested in getting feedback when we've fleshed the section out a bit more.

@gberche-orange I definately would like to have working sessions with you to go through the UX for this. Irfan has started building some of the functionality - in order to get some things in place - but the UX is early placeholder and I hope we can work together to decide the best UX and implement that.

I've schedule a meeting this Thursday (I dropped a note in the CF #stratos slcah channel) - mainly as a kick-off, we could discuss in that the best way to move the UX forward - minimum would be to schedule a meeting together.

Great to see V2 improvements on 1st class marketplace support in the 2.0 version, including support for space-scoped services.

Testing against 549fdea we'd like to suggest the following UX improvements to the marketplace view:

• rename "services" into "marketplace" into the left hand side navigation
• add a new page for each service definition which displays additional information (beyond the marketplace page)
  • the service long description
  • the service plans (and not the aggregated number of service plans) as depending on the current logged in user, the visible service plans differ) along with their description and meta-data (including price)
• add ability to drill down available services (i.e. their visible plans) per org/space (as service plan visibility depends on the current orgs or even spaces for space-scoped users).

@troytop might be useful to close this issue, since the backlog project did not seem to close it automatically back in oct 2018.