Skip to content
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

Feedback: Mailjet API Settings Location #127

Closed
dshastry opened this issue May 10, 2017 · 7 comments
Closed

Feedback: Mailjet API Settings Location #127

dshastry opened this issue May 10, 2017 · 7 comments

Comments

@dshastry
Copy link

Noticed a little thing this morning which I thought was interesting and would like to discuss. What are your thoughts about moving the mailjet API key/secret into the settings menu as opposed to where they are currently in the "send" panel? From a UI standpoint I think that it's redundant information that's taking up real estate and that you only have to enter once and never touch again (hopefully). Also since the fields are technically "live" it's easy to modify this important information by mistake if not paying attention. I did this when I was in a hurry a few days ago and had to login to mailjet to get the proper credentials again.

From a UX standpoint just seems to fit better under the settings/config area. Maybe that additional real estate in the send panel could open up more area for additional target emails or a contact address book/recently contacted? 😃 (hint #126 , #125 )

Thoughts @meriadec, @ngarnier ?

@meriadec
Copy link
Contributor

I think you are right on that point.

But in the first usage, the user will open the "send" modal, then will fill up email infos, then will have to close it to open settings modal, fill API infos, then open again "send" modal.

What do you think about having an "accordion", in the "send" modal, that is closed when API infos are already filled?

@dshastry
Copy link
Author

I was assuming that once you enter the API info the app would save it until either modified or deleted. That's what I've seen in terms of best practice within other SaaS solutions. So working with that assumption, the user would only enter the API info once (probably when they install the app) and then never worry about it again till they have to change it. Is there a reason they have to enter the API info each time they send an email?

@dshastry
Copy link
Author

Also that way the only transactional UX part of the whole sending process happens solely within the send modal. No need to ever go to settings unless they are entering new Mailjet creds

@meriadec
Copy link
Contributor

Yes, that's right but I was talking about the very first sending, when user has not fill yet the API info. He will naturally open the "send" modal, to actually send, then he will see that he must open before another modal.

So I personally prefer to have "Mailjet specific" settings contained in the send modal, but we can totally hide/reduce visual importance when API creds are filled.

I confirm that user will never have to fill multiple times its credentials, that would be horrible 😄

@dshastry
Copy link
Author

Ah I see your point. Is there a way to display a message/alert to go to settings to fill in API credentials if they are missing or invalid? Maybe also not display any sending fields if no API credentials are entered? That way they don't have to be present in the sending panel, but still solve the issue of people not being aware they have to enter them.

yes, I do agree that if there's a strong business case to have them in the send modal then maybe the best is to put them in an accordion to collapse and give less visual priority.

What do you think?

@meriadec
Copy link
Contributor

meriadec commented May 12, 2017

So now, when infos are already filled, they are collapsed by default when opening the "send" modal.

@dshastry
Copy link
Author

Love it!! Great solve @meriadec!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants