adding support for collections

[warmuuh]

i am currently looking into adding collections of requests to everest (see warmuuh/everest).
i started already by reusing the search-pane (refactoring the code a bit to be able to reuse this), so that searching collections is using the same code.
Collections in my current approach are just collections of existing requests (read: entries in requests table) with augmented name/description.
i would like to drive it to a state where CRUD of collections is possible. (later maybe postman import/export)

[RohitAwate]

Hi Peter!

Actually, this was a feature that I had saved up for once the core stuff is completed, since it is mostly just encapsulates the current logic for a new UX element. But since you've already started, I'll try to incorporate it. I built on commit 3f808d8 and without looking at the code, I have some fundamental concerns strictly from a UI/UX perspective. I hope you can be flexible, since what you're building visually affects the application and the user's workflow tremendously.

I see you've taken a Postman-esque approach to the collections tab which frankly, I'm not a big fan of. It mixes a top-level UX element i.e. the collection, with individual requests which are lower-level since they belong to that collection. You can observe this in the way it places the list of collections and requests history in adjacent tabs. I think this makes for a slightly confusing UI.

This is how I visualize Everest's UI/UX hierarchy:

The Dashboard controls the individual requests. The HistoryPane holds all these requests together.
The HomeWindow wraps around these two elements, thus reflecting this hierarchy. What remains is the 'Project' element, which we need to figure out how to incorporate into the UI.

What I have in mind is, in my opinion, a much cleaner and more intuitive approach than Postman and Insomnia. I plan to wrap the entire HomeWindow around with a bar at the top which allows for switching between different collections. The reason for this is simple: since a collection groups requests together, the hierarchy should be reflected in the UI, making for a more intuitive and natural UX.

Here's a mock-up I made in Inkscape:

The user can switch between projects using the combo box. The HomeWindow reacts to this change by displaying the requests history and tabs for the active project. New projects can be created with the 'New' button which could maybe make a small window pop up which asks for the project name, description, etc.

In my opinion, this is easier to navigate and understand. Everything related to managing the project is simply up there at the top. Everything related to the requests in that project is below this bar.

I am also not keen on calling this element 'Collections'. I think 'Project' is a much more appropriate name given that people are mostly going to be using Everest alongside their IDEs or editors which also use this term. Since they'll already have their 'projects' open in these IDEs and editors, waiting to be tested out with Everest, I feel it 'Project' sounds better for continuity's sake.

I'm sorry if I've been critical towards your work. Please don't take it personally. I'm going to have to keep my foot down on this design. As I said before, the changes you propose affect the core experience and appearance of Everest and I've to make sure they are the best for the users, especially when I'm trying to do something different from the current players in this space. So, I won't be able to accept your work in its current state. If you're open to building something similar to the mock-up, I'll be glad to help and merge your work.

On a personal note, yours is the first major contribution to Everest and it sucks that I have to decline it. I contemplated quite a lot over this but I have to stick to my vision for the project. This decision has been hard for me and again, I'm extremely sorry! :(

Let me know what you think. I would love to hear your thoughts for or against this approach.
Rohit

[warmuuh]

first of all, thank you for creating this and also for taking the time to write such a long comment :)
i would have been suprised if you just accept this anyway, glad to see that you have a vision here.
regarding that:
i think, you approach to UX totally makes sense although i must say, i dont actually care: as soon as users learn how to use it, it does not matter where the projects are residing. But having a more general "project" notion is interesting.

i think, we might have a slightly different usage pattern for everest in mind which needs to be differentiated. the current design of everest is very history-focused and from your description also very "single-project" focused as in "user develops a service and uses everest to test it". Do i understand that right?
this (the history of requests) is actually the feature i use least in postman. I am working in a SOA environment and regularly need to call 10/20 different services in a "working session". Also i need specific names for my request (i dont have the url in my head for e.g. getting the user account). Now, i could imagine having projects that encapsulate such a "working environment" but i would still think, having collections (or folders or tags or whatever the name is) would help organizing the requests in cognitive managable chunks.
As mentioned, i understand that you want to keep the UX and the logical hierarchy in sync, so i have no clue how to best design this ;) (i am not the best UX desinger at all).

in general: I really whish everest to be successful and would like to further add features in the future, such as environments and especially team functionality (the last mentioned is actually the reason why i started to fiddle around in everest, but the other features are a must have, otherwise, it would not work).
But as i did not yet invest much time in it (basically just some exercise to play around with currently), i would not mind too much if this does not get merged (or if we cannot find an agreement here on where this might go). on the other hand, i could think of driving a plugin architecture so that i could implement such a stuff without interfering with the "clean" and basic everest version.

Peter

[RohitAwate]

Hello again, Peter!

I am working in a SOA environment and regularly need to call 10/20 different services in a "working session"

I think this can easily be done with the project based approach. Its just the matter of the layout of the application. I just do not wish to mix up requests from different projects together in the same window.

Also i need specific names for my request (i dont have the url in my head for e.g. getting the user account)

I'll be adding support for environment variables into projects to make this possible.

About the named requests thing, I think that's an interesting idea. Instead of the Collections tab that you've added right now, we could place named requests under a tab called 'Requests'. Each of these requests can use the environment variables set for that project. The HistoryTab will also remain functional just as it is right now.