Closed tgtshanika closed 5 years ago
My suggestion:
Overview
Configurations
> Design
> Runtime
Resources
Endpoints
Lifecycle
API Definition
Environments
Scopes
Subscriptions (note: assuming we move business plans to under runtime configuration)
Business Info
Properties
Documents
Monetization
+1 for the above.
+1. That order look fine.
+1 looks good, and yes its better to move business plans to under runtime configuration
+1 for @bhathiya suggestion.
Isn't it better to move LifeCycle to a lower level if we consider the order of the flow? LifeCycle is something we need after creating the API, in a general flow.
1) Why is scopes a high level topic, and not inside resources? 2) What does configure mean? We are in the context of creating an API, and we have a topic "Configure" and then there are topics (also includes sub heading with the word "configuration") that still continue to create the API. I am wondering if we should still call it configure or something like settings /preferences. 3) +1 to move lifecycle to a lower level. Maybe after API defintion ? 4) I don't mind for properties also to be moved up a bit, maybe right after API definition and before lifecycle. I am not 100% clear on this, because properties also means customization, and it could be at a low level too. I am +1 with anything for this point.
+1. If we can group all the items into Design and Runtime, is much better I think.
Prefer to move Lifecycle next to the overview as when we create an api, it is in Created state. Next if you change it to publish , API will be available in the devportal and one can test.
+1 for @bhathiya's suggestion.
+1 for @bhathiya's suggestion.
Isn't it better to move LifeCycle to a lower level if we consider the order of the flow? LifeCycle is something we need after creating the API, in a general flow.
This is the most important action after creating a basic API. So I think it should not go down.
- Why is scopes a high level topic, and not inside resources?
+1 to take that inside resources.
- What does configure mean? We are in the context of creating an API, and we have a topic "Configure" and then there are topics (also includes sub heading with the word "configuration") that still continue to create the API. I am wondering if we should still call it configure or something like settings /preferences.
yeah there can be other options.
- +1 to move lifecycle to a lower level. Maybe after API defintion ?
-1 for the reason in the previous comment.
- I don't mind for properties also to be moved up a bit, maybe right after API definition and before lifecycle. I am not 100% clear on this, because properties also means customization, and it could be at a low level too.
properties is not a very critical feature and similar to business info. hence moved them down together.
Prefer to move Lifecycle next to the overview as when we create an api, it is in Created state. Next if you change it to publish , API will be available in the devportal and one can test.
Before publish we need to set business plans and endpoint. hense put after them.
Business plan and the endpoint can be given at api creation page. If so next priority comes to the Lifecycle
Business plan and the endpoint can be given at api creation page.
This is true. But if we look at the menu, they should be listed in the order of dependency IMO.
Shall we use capitalized text instead of uppercase text? This will give more space and less stress to eye. https://material.io/components/navigation-drawer/#usage
+1
+1 for capitalized text
Currently, the API tab list is not ordered according to the main steps in API creation flow. For example, after creating an API, the next major step is to define resources. But the Resources tab is the 5th item in the tab list. IMO, the order of the tab list should be sorted accordingly.