fbpx

Building Obie.ai for Stride

Whether you work in a small team or a larger enterprise juggling and finding the right internal knowledge when you need it is no easy task. And for teams that rely heavily on messaging (which most organizations do), it’s especially easy to allow conversational knowledge to not be turned into institutional knowledge. These days it’s all too common to have business units put into isolated groups that rarely talk, share information, or collaborate. When specific knowledge does need to be found it’s hard to search for the information, know if the information is up-to-date, or worse there can be too much information to sort through. Information just lives in too many places. We created a bot in Stride to tackle this.

If you are thinking of bringing your bot from another platform to Stride, here are some lessons we learned launching our app and how we solved key problems. We’ll cover why we chose to use particular commands, give an architectural overview of the application, and walk through considerations we took when building Obie for Stride.

First, some context

Messaging does a great job of keeping communication in one place. It makes for a great archive of information. We all know how to search; it’s pretty simple. You type in what you are looking to find. The problem? Getting information from the deepest archives is a challenge.

For example, looking for a file you accessed a few weeks ago (noise) while only remembering the topic, a few queries, and a bit of context on the content (signal) but not the file name can be a frustrating experience. You have a good idea of what to look for, but there are a lot of places the file can exist and lots of files with similar topics, queries, and context. How can we impact the signal, and reduce the noise?

At Obie.ai, we tackle this signal and noise issue using messaging, behaviour-based machine learning, and natural language processing to help teams share and access knowledge organization-wide: the bigger the company, the harder the challenge exists of accessing and sharing knowledge. With every search, teams can be more focused and informed with fewer interruptions. Our goal is to ensure employees can get access to relevant knowledge at their fingertips. Whether you have an intranet, Google Drive, GitHub, Confluence, or other Atlassian tools like Trello, knowledge is dispersed and siloed across the organization, making some information inaccessible. Finding information should be an easy process. A defined single source of truth to search for knowledge streamlines the search process for both the employees and organizations looking to make information easier to find so that you can get more done.

We were lucky to have heard from many teams, developers and product managers who use a wide range of productivity, developer, and project management tools about common pitfalls: finding information across sources within an organization can create a virtual firehose of information. People didn’t want more knowledge sources. We needed to figure out how to continually reduce the noise so that people can find what is relevant, quickly.

Our journey building bots on messaging platforms began in 2016. As a team who has been tackling knowledge management for some time now, we feel that messaging has afforded us unique opportunities that we’ve never been able to tackle.

While building Obie from a prototype to a fully functioning Stride app, we learned some tips and tricks that might be useful for those bot developers hoping to transition their bot to Stride or those looking to build something new. Here are a few takeaways from our efforts to create a valuable experience:

1. If you’re building a bot for the first time, try not to bite off too much

After being in the bot ecosystem for some time now, we found that the most useful bots typically provide easy ways to get information or collect information using the conversational interface and other interfaces available to them.

We knew that we had to build a quick prototype with Obie’s knowledge retrieval functionality front and center. The prototype of our Stride app was going to be very simple, but still valuable.

In addition to the send/receive messaging endpoints, it involved leveraging the following Stride APIs:

User Details: Returns useful information about a given user like their real name, email, and photo.

Usage Example

getUser: (cloudId, userId, cb) => {
auth.getToken((token) => {
request({
url: `https://api.atlassian.com/scim/site/${cloudId}/Users/${userId}`,
method: 'GET'
headers: {
'Authorization': 'Bearer ' + token
}
}, (err, httpRsp, body) => {
if (cb) {
cb(JSON.parse(body));
}
})
});
}

Conversation rosters: Returns a list of user Ids for users in the given conversation.

Usage Example

getConversationRoster:(cloudId, conversationId, cb) =>{
auth.getToken((token) => {
request({
url:
`https://api.atlassian.com/site/${cloudId}/conversation/${conversationId}/roster`,
method: ‘GET’,
headers: {
‘Authorization’: ‘Bearer ‘ + token
}
}, (err, httpRsp, body) => {
if (cb) {
cb(JSON.parse(body));
}
});
});}

We developed the Alpha in about a week at StrideCon. StrideCon is more or less a hackathon week at Mountain Winery in Saratoga, CA, attended by Stride developers and designers. This experience was a unique and timely opportunity that gave us the resources to move quickly. We had entertained talks internally about working within new APIs and we were interested in understanding what it was like to work within the Stride API. This opportunity helped us understand what it would take to bring Obie from other messaging apps into Stride.We tested it and demoed Obie at StrideCom.

With the help of the Atlassian designers and developers we created a solid proof of concept that helped skyrocket our understanding of the Stride ecosystem. After this experience, we decided to focus on how we were going to translate more of our core product experience into Stride past the Alpha.

2. Communicate early to your users what your bot does

There should be some information that explains the value of your bot (what it can do) communicated early. You’re going to get users installing just to play around, so it’s a good idea to demonstrate or talk about the value very early on. This is especially important if you want users to invest the time in going through a lengthy onboarding process.

We focused heavily on educating users through an onboarding process where we could be as specific as possible so new users understand what the bot can or can’t do. After a design review with the Atlassian team, we made several iterations to the onboarding to ensure we communicated our value proposition much earlier than we initially intended.

3. Make the first impression count

We rely heavily on messaging to introduce users to what Obie can do and we get a sense of users sentiment and first impression — when they are happy and when they are frustrated — using Dashbot, a bot analytics platform that enables developers to measure user engagement, and Amplitude, which allows us to track the web experience of the user experience in addition to the bot experience. We focus extensively on user experience — we measure every click, question, and user reply to make sure the experience with Obie is better than nudging, asking a peer, or going into the knowledge sources directly.

A neat endpoint we use unique to Stride is the built-in configuration status for apps. We make it mandatory for users to complete onboarding/configuration before using Obie. While Obie is awaiting configuration, there is a status indicator beside his app icon in the side toolbar so that the installer is aware that configuration is required before proceeding to use the app fully.

To do this, we use:

Conversation Configuration State: Updates a given conversation’s configuration state, where configured is either “true” or “false”.

Usage Example

updateConversationConfig: (cloudId, conversationId, status, cb) => {
auth.getToken((token) => {
request({url: ‘https://api.atlassian.com/app/module/chat/conversation/chat:configuration/obie-config/state',
method: ‘POST’,
headers: {
‘Authorization’: ‘Bearer ‘ + token,
‘Content-Type’: ‘application/json’
},
json: {
configured: status,
context: {
cloudId: cloudId,
conversationId: conversationId
}
}
}, (err, httpRsp, body) => {if (cb) {
cb();}
})
});
}

This configuration status is important for us since in order to have a good experience, users must first configure Obie within their environment. We’ve found that onboarding with Obie is crucial for success; by guiding the user through connecting an integration and performing their first search, they get the feel of how Obie works. Once the user has completed onboarding we unlock Obie for regular use.

4. Sidebars and Cards: Take advantage of new design challenges for unique opportunities

It’s important to think of the type of information you are sending to Stride. Stride has a numerous amount of opportunities to allow developers to display information within its environment. We came up with a unique way to interact with Obie because of what Stride offered.

Stride Sidebar & Cards

Stride Sidebars provide a free for all in terms of design and development. Apps can display custom HTML hosted by your app in the right sidebar, like a list of meetings, relevant documents, or open tasks, to displaying contextual information relevant to the conversation.

We found it useful to display documents related to the search for our particular use case. One thing we took into consideration while embracing the freedom HTML provides was to ensure there is a consistent user experience with Obie and Stride. It’s difficult to create a consistent user experience without guidelines so we used Stride design guidelines to create the consistent user experience the user audience would understand.

We found it beneficial to leverage Stride App Cards. App cards offer information at-a-glance and leverage a wide range of design options. When a user asks Obie a question, instead of showing a list of results within the conversation window, we leveraged the metadata and put this information into an App Card . This user experience ended up being quite favorable even though it wasn’t an experience we were used to. The Sidebar allowed us to avoid making the conversation too crowded by displaying only the top result in the conversation window, and then the rest of the results in the Sidebar.

Related Guides


Takeaways

Obie integrated into Stride turns Stride into an intelligent source of truth, where you can keep your knowledge up-to-date and access knowledge wherever it lives. In Stride, you can surface relevant information and see how up-to-date information is. Through our focus on listening to our users, relentlessly pursuing a favorable user experience, and making data-driven decisions, we’ve learned that each encounter with a bot builds trust and your goal as you develop your bot is to build a trusted coworker.

We’ve only scratched the surface of the Stride API, but hopefully you’re now sufficiently excited to build something awesome! Even if your mission and product aren’t tied to the things we aim to solve, hopefully our learnings from this process will help inform your decisions about specific aspects of your bot and save you time as you build it in Stride. We’d really love to see how you use it, and if you do create a great bot in Stride (or move your bot over to Stride), don’t forget to let us know on Twitter. If you have any specific questions about the journey feel free to reach out and we’ll be sure to help!

Written by John Kyeremeh, Head of Growth, & edited by the Obie.ai team.