And when I say integrate, I mean:
Integrate on content
- have community widgets that show the content of a 3rd party service in an appropriate way for that specific content
- let the content look like connections content looks like in general to create a unique platform UX
Integrate on transactions
- let the user trigger transactions in the backend service to copy, share, like, comment, version, delete, modify or create (or whatever the service offers as transactions) that is the natural way for the given service by just using the widget UI without leaving the CNX platform
- try to use a similar graphical language for similar transactions in different integrated services
Integrate on events
- let the user see in connections which events happened in his integrated service locations right inside of his activity stream (and orient me) and the community activity stream as well
- "bernd has created a new folder 'Learn to integrate with OneDrive'" -> click -> open folder in OneDrive community widget, not OneDrive (kind of deep linking to a widget)
- "Peter has commented on the file 'Training.pptx': 'The chart on page 4 is too hard to read!'" -> click -> open file in preview in the appropriate widget and obey the expectations (onedrive file -> office online preview!) (maybe commenting IN the other service is directly possible in the content preview right sidebar, just like for original cnx content in Docs viewer?)
- "John liked the file 'Integration is king!'" (see above)
Integrate on permissions
- Example: If you selected to integrate with a OneDrive Folder and selected the integration option "follow community members", the onedrive folder is controlled to be shared with everyone in the community by triggering the appropriate OneDrive API calls when community members change (meaning it will also be unshared with people who leave)
- People with roles that are only allowed to read should only be allowed to read, others can also write
Integrate on search
- when people use the search lens in the upper right edge of their community, they expect to search the whole community, including 3rd party content from external cloud services
Integrate on SSO
- use oAuth or SAML or whatever works to get access into all needed information without needing additional login on every access
Integrate on mobile
- everything that was integrated into a community of mine in the desktop browser should also be available in a platform appropriate way in my mobile Connections app
As far as I can tell, this is what users expect for being a great integration.
That's why I also hope that Connections Grid will be a full service UI shop (e. g. with a treeview + list template like windows explorer or outlook shows up), delivering all you need for creating these UIs based on the Data and transactions that you get from the APIs.
That's what Appfusions did for a lot of 3rd party services. But they did not all the other things I requested.
We're in a dramatic dilemma:
The integration main method is APIs these days. BUT: APIs do not deliver UIs. So you are absolutely right: If you want to use a service visually integrated, you have to build your own UI based on the content and transactions the other service offers to you.
To me, it looks not as bad as you may think. There are not endlessly many patterns out there. You need:
And that's it. I think with these you can cover a whole lot of 3rd party content and make it show up in one of these five patterns.
+1 on search integration
+1 on SSO integration
+1 on mobile
However, the other requests more or less mean, that a Connections widget would need to act as a feature-rich custom client to the respective 3rd party app plus you'd need a model for mapping similar transactions in different backend systems to typical native transactions in Connections. I'd call that a real challenge... ;-)