wso2 / product-apim

Welcome to the WSO2 API Manager source code! For info on working with the WSO2 API Manager repository and contributing code, click the link below.
http://wso2.github.io/
Apache License 2.0
845 stars 785 forks source link

[3.0.0] API tabs should be ordered giving priority to main functionalities #6150

Closed tgtshanika closed 5 years ago

tgtshanika commented 5 years ago

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.

64925785-509dae00-d813-11e9-8312-b094a56423ce
bhathiya commented 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
nuwand commented 5 years ago

+1 for the above.

mushthaq33 commented 5 years ago

+1. That order look fine.

dushansilva commented 5 years ago

+1 looks good, and yes its better to move business plans to under runtime configuration

Krishanx92 commented 5 years ago

+1 for @bhathiya suggestion.

rmsamitha commented 5 years ago

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.

shaniR commented 5 years ago

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.

menakaj commented 5 years ago

+1. If we can group all the items into Design and Runtime, is much better I think.

isharac commented 5 years ago

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.

kavishkafernando commented 5 years ago

+1 for @bhathiya's suggestion.

HiranyaKavishani commented 5 years ago

+1 for @bhathiya's suggestion.

bhathiya commented 5 years ago

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.

bhathiya commented 5 years ago
  1. Why is scopes a high level topic, and not inside resources?

+1 to take that inside resources.

  1. 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. +1 to move lifecycle to a lower level. Maybe after API defintion ?

-1 for the reason in the previous comment.

  1. 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.

bhathiya commented 5 years ago

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.

isharac commented 5 years ago

Business plan and the endpoint can be given at api creation page. If so next priority comes to the Lifecycle

bhathiya commented 5 years ago

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.

erangatl commented 5 years ago

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

image

bhathiya commented 5 years ago

+1

isharac commented 5 years ago

+1 for capitalized text