Escambo needs some love in its UI

[CleoMenezesJr]

Hello everyone, I have a thousand plans to continue bringing new features and many of them need design. Libadwaita made a lot of things easier in this regard, but to have an easy-to-use interface that follows GNOME's Human Interface Guidelines.

In the near future, I want to bring it to GNOME Circles, but I feel it needs to be redesigned.
Feel free to bring ideas. Thank you very much in advance.

[bragefuglseth]

I don't have a lot of experience with API testing, but I could probably provide some design input. The general structure of the app seems good to me, but these stick out on the first page:

To add a query parameter, I have to:

• Activate the toggle
• Click "go to edit parameters"
• Type in the desired key and value
• Click "add"

I don't think the switch is needed here. If I don't want to use query parameters, I just don't add any / remove existing ones.

I assume that API testing often involves changing query parameters quite a lot. If my assumption is correct, we should consider inlining the list of query parameters, instead of having them on a separate page. This would make them quicker to access and tweak.

I'd imagine something like this instead of the current workflow:

• Click an "add" button directly on the Endpoint page
• Type in desired key and value in a dialog that pops up
• Confirm

For editing the body, I'd imagine this workflow:

• Click the "body" row
• Use a view switcher in the subpage header bar to change between "form data" and "raw".

No switch needed here either.

Also, maybe a "reset settings" button somewhere would be nice?

I can draw a mockup of the Endpoint view based on these suggestions if needed, to clarify what I mean.

[CleoMenezesJr]

Thanks for all the suggestions. And yes, mockups would help me a lot. A visual north would be nice. When I have a little more time, I will respond better to each of your points.

[CleoMenezesJr]

@bragefuglseth

I don't think the switch is needed here. If I don't want to use query parameters, I just don't add any / remove existing ones.

Yes, actually, I didn't want to create more and more options in View Switcher. The truth is that I would like to leave them all on the same Endpoint page, it would make more sense.

Also, maybe a "reset settings" button somewhere would be nice?

It is the idea to implement it as soon as possible.

I don't have a lot of experience with API testing

I really want to make something like Postman, you can take it as an example. Even the next feature I was going to implement is the Environments (I explain here: #34), so I would leave the View Switcher with 3 options Endpoints Request, Enviroments and History.

edit: Actually Endpoints is not fine. The correct thing is that it is called Request

[CleoMenezesJr]

Well, I took some time to revisit the design and came to a conclusion: I needed to create a widget to do what I needed. Instead of using a View Switcher to separate between Parameters, Body, Cookies, etc.; now I'll use a custom widget for that, where GtkBox will change depending on which option is chosen.
Pros:

• The user will follow the same view of the Request
• A friendlier interface similar to other Clients

The Stack Switcher will now be used for features that are not directly involved with the Request. This will help in the future to add options like Collections.

Of course, I still need to keep changing some things, but this is certainly the way.