Hi Jerad, On Tue, Sep 6, 2016 at 3:14 PM, Chamalee De Silva <[email protected]> wrote:
> > Hi Jerad, > >> >>>> Why do we have a checkbox in the beginning of the row? IMO I think >>>> having 2 checkboxes in the same row in 2 different places will confuse the >>>> user. >>>> >>> In a table row, the first checkbox is to select the gateways where the >>> API to be Published. And the checkbox that I have newly added (Use >>> Defaults) is to select to get the Gateway URLs from the environment >>> configuration. So they are for two different purposes. >>> >> >> Still i'm not getting why we are using a checkbox there, let's have a >> chat on this. :) >> > > Thusitha is working on this to add a label (table header) for the checkbox > displayed in the beginning of the table row to avoid confusing the user. I > think that may help. > >> >> >> And is there any reason we are not giving enabling/disabling transport >>>> type inline within the table? So user don't have to go back to >>>> configuration section again if he/she wants to enable it. >>>> >>> >>> What I understand from this comment is as following. Please correct me >>> if I am Wrong. >>> As an example in a situation where only *http* is enabled for >>> Transports in the Configuration section of "Manage" page, >>> - if a user unchecked the Use Defaults, both the *http* and *https* >>> text boxes get enabled. >>> - At that time the http and https checkboxes in the configuration >>> section (transports) will be checked. >>> - if that URL text boxes are enabled and if user save and Publish the >>> API, the URLs for both http and https will be displayed in the store taking >>> from the environment configuration or from the user input. >>> ..................... >>> >> >> Configuration section and Gateway environment section both are in the >> same page itself right? Correct me if i'm wrong. >> Because if it is, IMO asking user to scroll-up back and enable the option >> breaks the user experience. >> > I think the way you see at this is not correct. User is not supposed to scroll back and enabled it, because when user comes to this point, they already know and have decided if they want http/https. So what we do here is only showing custom URL for what they have already selected. So I don't see a problem if we think of the real use case. @Chamalee: Do we allow overwriting the API context and version here in the custom URL? AFAIK, we don't. Please correct me if I'm wrong. In that case, don't you think appending context and version to the custom URL and show it in UI (as I mentioned in a previous reply) will be helpful to the user? Thanks, Bhathiya -- *Bhathiya Jayasekara* *Senior Software Engineer,* *WSO2 inc., http://wso2.com <http://wso2.com>* *Phone: +94715478185 <%2B94715478185>* *LinkedIn: http://www.linkedin.com/in/bhathiyaj <http://www.linkedin.com/in/bhathiyaj>* *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* *Blog: http://movingaheadblog.blogspot.com <http://movingaheadblog.blogspot.com/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
