UX Design: Icons needed for new connectors

[amysueg]

This is a...

[x] Feature request

The problem

We need to create icons for new connectors or collect publicly available brand SVGs for connectors to existing 3rd party products. We'll use this issue to track and deliver the designs and SVGs.

@heiko-braun @paoloantinori @gaughan - Please advise as to which connectors are in flight for 7.4 so we can prioritize the delivery.

fyi @dongniwang @mcoker @seanforyou23 @lboehling

[dongniwang]

Icons list:

• KNative connector
• Jira connector
• SQS connector
• Conditional flow (CBR) step icon
• Mail connector

[phantomjinx]

@dongniwang
I am currently working on an email-connector. Currently using a stand-in icon at the moment so can I request this be added to the list, please?
Have an issue for it here in case you need it.

[dongniwang]

@phantomjinx - Sure! But I thought the mail connector is not part of 7.4? At least I don't see it on the 7.4 list, I could have missed that.

@heiko-braun @gaughan - Can you please verify? Thank you!

[phantomjinx]

@dongniwang
Probably not on the list.
Have been working on it though in the background these last few weeks so should be ready for 7.4 if required.

[gaughan]

Yea not in 7.4 but if it's done we can add it

[lboehling]

Hi all, i'm attaching designs for the conditional flow step icon and the email connector icon. Let me know what you think!

@dongniwang

[dongniwang]

Thanks @lboehling !

@syndesisio/uxd @gaughan @phantomjinx Please review the icon design.

[phantomjinx]

I think the email icon is really cool! Thanks very much.

Having completed the email connector yesterday, it actually has 2 distinct connectors - one for send-email and one for receive-email. Do you think that both should use the same icon or should they be tweaked slightly differently, eg. the 'fast' lines going the other way maybe?

My PR was merged in this morning and that included the temporary icon. However, @zregvart has some good suggestions for changes so I am revisiting and will be doing a follow-up PR. Therefore, if you could let me have the icon(s) as soon as convenient then I will update accordingly.

@lboehling @dongniwang @gaughan

[dongniwang]

Can I ask why do we need two separate connectors for the email connector? Can "send" and "receive" be two actions for the connector? @phantomjinx

[phantomjinx]

@dongniwang

Sure thing. That's how I started out.

An email connector is in fact 6 separate protocols, ie. imap(s), pop3(s), smtp(s), where the first 4 are receive protocols and smtp(s) are send. Each one lives on a different port so in essence on any email computer, you will see at least a receive daemon, eg. dovecot, and a send daemon, eg. postfix. They don't even have to be on the same box.

The architecture of a connector generally implies it can be offered as an option at any point in the integration, either as a consumer or producer. For example, the odata connector exists on a single port, using a single protocol and so offers actions depending on where in the integration it is placed. With a single email connector that becomes impossible since the port/protocol specified in the connector has already restricted it to being either receive or send (but not both). Thus, it makes no more sense to allow an imap-connector as a producer as it would for an smtp-connector as a consumer.

I met this problem here and found 2-connectors solves this issue. If no actions are specified for either 'From' or 'To' patterns in a connector's json config then that connector is not displayed in the selection of available connectors.

For example:

1. Create an email-receive connector with imap protocol;
2. Create an integration and place a twitter connector as the start
3. When the options are displayed to choose a finish connector, the email-receive connector is just not visible since it offers no actions for producing.

A composite connector would always appear (despite the protocol selection) and I had to keep trying a number of tricks in case the user decided to select the 'wrong' connector for the integration position.

HTH

[gaughan]

I think this is a significant change to the UX. Pushing the decision to send or receive to the start of the interaction requires further input from the UX team I think.
Alternatively, we can offer send only in a single connector for now?

[zregvart]

I'd go with the send/receive e-mail connector split right now, in order to gather some user feedback on this.

I think we already have similar issue with the three Google connectors we have right now, you need to configure each individually. Perhaps we can think of a superset of a connection to group and configure similar connections.

[phantomjinx]

@gaughan
Sure. Am happy to go with that. Only thing, I would suggest we determine best course of action asap since:
a. email-receive & email-send connectors have already been merged and available in master so would need the former disabled, if required;
b. both connectors currently have a temporary icon which should be updated. I can update both with the same provided icon for the moment in the interim, if preferred.

Let me know how you would like to proceed.

@heiko-braun @dongniwang

[dongniwang]

Thanks @phantomjinx for the explanation! That helps!

I do feel that having to think about send or receive when choosing the connector would be a little harsh on the initial experience.

@zregvart - what do you mean by -

Perhaps we can think of a superset of a connection to group and configure similar connections.

As for icons, @lboehling is working on a set of icons (both send and receive) at the moment.

[lboehling]

icon set for both send and receive:
.

[zregvart]

@dongniwang re: #5249 (comment) To create a connection to Google related connectors (Sheets, Calendar, Gmail) users first need to setup the OAuth client id/secret in Settings and then create a connection. On the surface it looks like these are three separate items whereas they're all one: access to Google G Suite. I was suggesting that the problem with e-mail is similar, and that the solution might be to come up with a superset of connectors/connection/OAuth settings that groups functionality of multiple connectors into a single item. So users would need to configure single OAuth settings for all three Google G Suite connectors and would need to create a single connection to G Suite; and in the same way we could configure a single Mail connection that is used by two Mail connectors we have (send/receive).

Does that help?

[christophd]

@lboehling thanks for the conditional flow step icon. Looking good!

Only thing I would like to change is to rotate the icon so that the icon aligns with horizontal orientation (messages going from left to right).

[dongniwang]

@zregvart - thank you! Yeah, I think the G Suite use case is a little bit different than the email connectors. Would be great to get some feedback on what is the most intuitive and natural flow for configuring these connections. The OAuth settings flow is also a little bit disconnected from the whole create a connection flow now since we added more functionalities.

If the OAuth settings are for connections only, would it make more sense to move it to the Connection session in the navigation level?

cc: @gaughan

[gaughan]

I'm happy to leave as is for now, but consolidation should be our focus. The GSuite is another case where we could look to clean up and help the UX.

[zregvart]

If the OAuth settings are for connections only, would it make more sense to move it to the Connection session in the navigation level?

Yes they are, OAuth settings are prerequisite for creation connections for OAuth capable connectors.

I like the idea of moving OAuth settings in the new connection flow as it would streamline the Connection creation. Right now it is possible not to configure OAuth settings and try to create a connection (say for Salesforce) only to be faced with a form that might be a bit overwhelming and (I think) makes it too easy to make mistakes.

I remember having a discussion that perhaps it would be two personas involved here, citizen integrators using the new connection flow and expert integrators configuring OAuth settings, not sure if we ever validated that assumption.

[gashcrumb]

I like the idea of moving OAuth settings in the new connection flow as it would streamline the Connection creation. Right now it is possible not to configure OAuth settings and try to create a connection (say for Salesforce) only to be faced with a form that might be a bit overwhelming and (I think) makes it too easy to make mistakes.

+1 probably not for 7.4 but for sure this would make sense. I've yet to implement the oauth token acquisition on the react side, but I don't think I want to introduce any big changes while porting the functionality over.

I remember having a discussion that perhaps it would be two personas involved here, citizen integrators using the new connection flow and expert integrators configuring OAuth settings, not sure if we ever validated that assumption.

Yeah, I feel that we've kinda abandoned that a bit, and it's probably okay if we have.

[christophd]

@lboehling could you please rotate the conditional flows icon 90 degree to the right and provide a SVG version of the icon? That would be great thanks!

[lboehling]

@christophd yeah! here you go: https://www.dropbox.com/s/c1gil5aa9tnd6zb/conditionalflowicon.svg?dl=0 (can't attach SVGs to the comments here)

[christophd]

@lboehling Awesome! Thank you

[claudio4j]

I added the jira icon as SVG in the jira.json file (the base64 format)
https://github.com/syndesisio/syndesis/pull/5564/files#diff-8786ae8391201be9b0c6a7426b6ccc63

[zregvart]

@claudio4j we need the icons as SVGs in ux/connections_icons/svg the recent change (#5568) moved icons outside of the connector JSON and when an icon is placed there it can be applied to all the places we need it. There's a Nodejs project there that updates the icons in the right places when yarn icons is run.

[claudio4j]

@claudio4j we need the icons as SVGs in ux/connections_icons/svg the recent change (#5568)

I added the jira SVG icons in the mentioned directory. I will push the changes along with other changes soon, so you can review them.

[claudio4j]

@claudio4j we need the icons as SVGs in ux/connections_icons/svg the recent change (#5568)

I added the jira SVG icons in the mentioned directory as part of the PR #5564

[dongniwang]

Just checking here, are we all set on the icons for 7.4?

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!