Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Folder Headers #3368

Closed
NickHackman opened this issue May 9, 2021 · 2 comments
Closed

Folder Headers #3368

NickHackman opened this issue May 9, 2021 · 2 comments

Comments

@NickHackman
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Folder level headers are great for things like Authorization, Api keys, etc and are commonly used for ALL requests for a specific service so it would be great to minimize the duplication.

As discussed in this PR, with the addition of Folder Descriptions/Settings I think it should follow the same pattern as already created for Requests (Where by clicking on a Request, you can see tabs for the docs, headers, auth, etc). In this situation we get a similar user experience as Postman, but also get to add in quite a few features that have been heavily requested. Namely, Folder level headers!

Describe the solution you'd like

With the addition of Folder level descriptions, adding Folder level Headers should follow a near identical process currently for requests. This way the UX remains the same and has a pattern for users without introducing a new feature or anything else they'd have to learn to be productive and use the feature.

Example

This would appear when selecting a folder, it would also expand the Requests in that Folder. Not sure what's the best way to minimize the folder though, open to discussion on what would be the right behavior. It would also not show the entire right response window as it doesn't apply.

Insomnia-Folder-Example

Identical UX, this feature might even be super simple to implement just modifying the Component corresponding to the Request page and removing the Body/URL and Response.

Describe alternatives you've considered

The main alternative is #447, the reason why I think this is preferable is that it lessens the cognitive load and understanding of users on Insomnia to be productive, it also enables a bunch of other features in the future following the current Request page/view pattern. Another benefit would be less documentation and explanation as the feature in #447 would require a good amount of documentation to explain the feature properly! Overall, this approach effectively tries to follow the KISS principal and keep the design coherent while minimizing feature overload.

Future

There are a ton of additional features for the future that would be great, effectively the entirety of what a Request page has currently: Authorization, Docs, on the right hand side of the bar would be so cool to have Folder Plugins! Like show 3 or 4 alphabetically and then bring the rest into a dropdown menu. There's just so much here that could be opened up and a ton of good features.

@develohpanda
Copy link
Contributor

Thanks for going into this detail @NickHackman! I was looking through #447 to get some background on previous discussions about this and I think a lot of them are valid; I see a PR was also in the works but paused for reasons.

After reading through #447 it feels as though this shouldn't be a new feature request but an item of feedback into #447 - mainly because it has a mention for what you've described also (#447 (comment)).

@NickHackman
Copy link
Contributor Author

This isn't really feedback, I just wanted to propose a decent counter argument to #447 in favor of this approach.

I think this feature request is a more formal description/plan of the comment in that thread. I'd like to continue the discussion of this design choice in its own right instead of a contrast/comparison to #447.

Would love your/team/users feedback 😃

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants