One of the greatest ways to increase adoption and drive collaboration on your intranet is to incorporate as many of your daily work processes as possible into the site itself. When deciding if a particular application or process is a good candidate for integration there are a few things to consider:
Will the integration actually provide a better user experience?
Sometimes, not all of the desired features of the third-party application can be brought over for integration. As well, precious screen real estate in ThoughtFarmer is taken up by the third-party tool. You can end up missing out on features that the full applications provide better on their own. Additionally, if the integration is excessively complex it may not provide an ideal user experience. Instead of two tools that do what they were designed to do very well, you have one tool that is cluttered and clumsy.
The best integrations provide a seamless user experience where users may not even know that they are using a separate application. These tend to be very precise in the actions that they provide, rather then a full suite of possible actions from the third-party application.
Is the integration worth the potential extra cost and maintenance involved?
If there isn't an easy to way to embed the integration, then additional cost may be involved. For large and complex integrations the cost may be higher than the benefit is worth.
Furthermore, any custom integration adds some complexity around version management between the two systems. Changes in one may affect the integration in a breaking way. Making time to account for these changes should be part of any integration project plan.
How should the integration be implemented?
When it is time to actually create the integration there are a number of options that provide various pros and cons.
The following sections provide details on the ways in which integrations can be achieved.
The quickest and lowest cost solution is always to use the embed code from the third-party service. Often this is simple copy and paste, such as in the case of an actual YouTube video. The pros here are that you have something ready to go right away with little or no custom development required. However, the drawback is that you are reliant on the availability and support of these embed scripts directly from the third party service. There is also no control over the layout, features and design beyond what they provide as configuration options. Any changes would have to be requested from that third-party service.
Additionally, sometimes large third-party providers have an entire ecosystem of available tools that create embed code for them, usually for a fee. For example, YouTube itself provides no embed code support for channels. However, a service called EmbedSocial appears to allow just that https://embedsocial.com/knowledge-base/embed-youtube-feed/.
Another example is TagEmbed which provides Slack embed options https://tagembed.com/blog/embed-slack-on-website/.
We are unable to make specific recommendations on additional third-party aggregation services like these. Every project and organization has their own budget, security, and design requirements that should be taken into account as part of their own vendor discovery process.
We are definitely able to provide consultation as to feasibility of integration, as well as to work with provided embed code if there are any compatibility issues. Some Professional Services Development hours may be required if the compatibility issues require significant effort.
For details on how to embed code in ThoughtFarmer, please see the page Embed forms, widgets, and more.
If you aren't already familiar with the concept, iFrames are windows from one application into another. Sometimes, if a third-party service does not have embed code for what you want, you can get away with embedding an iFrame. However, this method should be used judiciously. It does not always provide the best user experience. The user may see scroll bars in the window from the parent application unless properly configured. As well, many third-party services restrict iFrames out of security concerns. Slack and Google are two major providers that restrict all use of iFrames.
Another drawback is that the entire third-party webpage is displayed. It may have additional header and navigation elements that do not make for a great user experience and clutter up the interface when embedded into another site.
However, for some very specific use cases it can be a very quick and easy win.
If none of the above solutions work, then our Professional Services team can look into a custom development project. Alternatively, any developer can leverage our custom Card API to build the integration. The main benefit here is that the integration can be built exactly the way you want provided the requirements are met. The requirements and phases for this are:
- Available APIs: The third-party service must have an API available in order to fetch and manipulate the data required for the integration.
- Authentication: The third-party service, if it requires a login, should have a mechanism so that users can access the API as themselves, OR all data and manipulations can be done as a single service account.
- Scope of changes: Custom development projects are implemented using our ThoughtFarmer Custom Card developer API. This has some limitations as it is merely a plug-in layer on top of the application. Projects that require substantial changes to default product functionality and interfaces are not a good fit and would require a Feature change request.
- Requirements, Design and UX phase: The APIs merely provide the data plumbing for the integration. All interfaces would need to be built on top of that to leverage those APIs. All features, user interactions, and interface components would need to be designed and turned into wireframes and\or mockups. If there are only simple interactions, or you are basing them on existing interfaces it may be possible to bypass this phase.
- Development phase: Based on the chosen and approved Design and UX the project can then be built out. Often we cannot accurately estimate on the development phase until the Design and UX phase is complete.
To inquire about scope and rates for a custom development project please create a request on our Helpdesk.
Feature change request
If the scope or implementation of the custom development project is not feasible then we can look into feature change requests. These are driven by our Product Planning team and mainly through our Feature Request Forum. We get many requests for changes and we use that forum to help us know which ones are most common and important amongst our clients. So we highly encourage your participation there to get your voice heard. Feature requests that are chosen to be implemented will come in a future upgrade to your ThoughtFarmer intranet as part of the ongoing licensing cost.
Please sign in to leave a comment.