Context help on icons

[janbrasna]

Not sure if it's a bug, feature or I'm just not seeing something that's in the app already, but I've stumbled upon some icons I couldn't infer their actual function or affordance e. g. until clicked… Should all the value input icons have tooltips or just some of the (deliberately chosen) toughest ones?;)

From what is used as input label or action metaphors:

Params, Headers:

• drag icon: ok, moving up/down is simple, but a tooltip that'd say why? (i. e. changes request order…)
• checkbox: sure, param is kept in the draft but not sent, or can be sent whenever I decide later, but a hint what to use it for would be golden… (note: if there are no "green" headers/params in the tab title, only some "unchecked", it'd be nice to have some form of reminder there's some values inside, just inactive… put a number there anyway, but in grey maybe? or just a grey dot meaning there's something there, just inactive…)
• trash: easy, removing the line. yet, there's no confirmation, so a tooltip really reassuring the param would be removed would make it bulletproof…

Auth:

• user/pass icons: after any input the text placeholders disappear, so having a tooltip on the icons that username is username and password is password is kinda obvious, but still might make sense rather than just inferring user is the visible and password is the masked…, esp. when the "password" role changes with different auth types, so password doesn't have to be "password" but "token" et al. (note: changing auth types wipes the current values, maybe a dialog warning there's some auth data that would be removed when changing auth types? as to not expect them to be there after changing it back&forth…)
• (the user icon might be better off without a circle, to get more definition on non-retina screens…)
• show/hide icon: here the tooltip is present, cool. Nonetheless I'd say consider just "open eye" and "crossed out open eye" as the switch, the "closed eye" metaphor is initially hard to understand what's the shape/meaning.
• (note: empty api key values make no impact to the request, so question is if the auth tab still should show green dot, as no real auth is added…)

Body › Form:

• form attachment icon: this "clip" icon doesn't exactly explain itself until clicked, it should be hinted it's a file selector. (This one actually led me here;)…) — I see this same icon used as File body type so it's quite clear once you first fiddle with binary files, yet when only interfacing with the form values first, it doesn't make itself that obvious. Here a tooltip that a file would be chosen and passed as the param value actual contents (contrary to binary multipart) might make it a bit more understandable, as the icon is the same, but the role of the attached file is different…
• after using a file as value, there's an icon showing probably its type besides its filename, is it reflecting the mime or content?… or should I understand it as a "plaintext" metaphor; maybe a tooltip saying that the file is not attached as a file, but just its plaintext content assigned to the param name is being sent, as shown in the request preview…?
• (the dialog toggling from embedded value to binary multipart has wording that might use some language xchecking, I feel like it's missing some prepositions and articles perhaps?)
• multipart switch has no tooltip, again its function should be implied by users of such tool, yet… would be great to have a hint/reassurance why or when to use…

Body › Text › JSON:

• this is a bonus one, as the icon has a hint in default/disabled state, yet I find the message to be confusing in blank slate: "Prettify unavailable on variables" shown on empty JSON body… Probably should just be active and do nothing on empty body, not to superfluously turn on and off between typing the first braces… (i. e. not to show a weird error before even typing a single char…)

[janbrasna]

(What maybe escaped me in the file-attachment-for-value concept is that it's the =@filename equivalent of the cli… Maybe that's the missing link in the mental model or familiarity… or perhaps it's relying too much on this implicit knowledge from the cli use?)

[claudiatd]

Thank you so much for taking the time to describe all those points out @janbrasna! Fantastic really! We'll take a closer look and keep you updated 👌

[janbrasna]

Anytime @claudiatd! I'm just paying off my debt from the early beta days by going through the blank slate and onboarding to the current app version's feature set once again, trying to capture all the doubts I had while unfamiliar with the app's functionality.

Within a day this hesitation and questions quickly disappear — it just means new users have to try them all out first, to make sure they're comfortable with the actions they represent. 🎩

[janbrasna]

Oh, and one more traffic light situation, contrary to the empty API values signalled as green dot without impact to the request, I've hit the opposite — had an empty body value item, i. e. instead of "none" mistakenly left "form" body, yet no items to turn on the green dot… but still this selection added the form's content-type to the request (sent me straight to HTTP 415) — and while I kinda like the fact I can quickly set form or json content-type without any payload, just by selecting the body type and leaving any actual values empty, I'd maybe prefer an indicator that while there's no body data, the content-type is already modified…