You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
This year we've participated in the Atlassian Codegeist 2022 and this is the DEISER Story of how it was.
Codegeist is Atlassian’s annual developer hackathon dedicated to custom apps and integrations. You can join Codegeist every year and the goal may be different every edition.
This edition it is dedicated to Forge, the brand-new Atlassian platform for Cloud app development. All DEISER Cloud apps are using Connect, so it was a great motivation for us to join Codegeist and start creating Forge apps.
We would like to share the steps we took and some lessons learned.
Recently we have created a new sub-team as part of the Product team called Discovery team. This new team will be more focused on finding different gaps within the marketplace to develop new apps that can provide the user new features that bring value to their day-to-day life. Codegeist has been a great oportunity to start working together in new ideas.
The members are:
@Laura: product designer, who lead some user interviews to create the app flow and design.
@Alvaro: developer, who have developed the app from the beginning.
@Jose: marketing, he is in charge of planing all the comunication of the app.
@Leo: team leader and product manager, who generates the idea and track the development and launching process.
I would like to give additional credits to @Fede (our support specialist) who gave us the voice for the app video. 🙏🏽 Thanks Fede!
The first app we wanted to develop was a Status board for Confluence . We found a gap related to content states. Do not think in content statuses: states are related to every version of the content, not only to a specific one.
The status board was thought to offer a board where you can find your space content organized by state. This would have helped you with your space content tracking.
But, we had not been able to develop it because we found a blocking issue and it was confirmed by Atlassian: content cannot be searched by the state at the moment in the Confluence REST API. Moreover, to get the state of the content you cannot get the whole content of the space: you need to request the REST API for each content to know its state. As long as we will manage lots of different content, if we cannot get them together, the performance will be really bad. Getting content by content is not something affordable.
So, with our first idea discarded, it was time to think of a new one. As we are really related to ITSM in DEISER and we have been recognized as ITIL specialist partners of Atlassian, we started thinking about some gaps for Jira Service Management that the Marketplace was not covering at the moment. And then the Waiting List idea was born .
With Waiting List we want to follow the ITSM transparency principle to give more details about their ticket attendance to customers. The goal here is to show the user his position in the support queue taking into count the most urgent SLA of the project.
The first thing we did was to get together and search for needs. We spoke with users that have suffer from waiting for answers and we detected a gap in which we could see that the portal shows little information,.
The main problem we found was that users were unaware of when they were going to receive the first feedback from the team, whether external or internal, it's going to be hours? days? So our app had to solve the uncertainty of the user who needs help from technical support.
What the user should receives thankswith our future app is more information about the status of their ticket in a simple and transparent way, and should allows them to organize their time according to the information received.
The design part started from a very early stage and has been iterated until the development phase.
The definition of the user journey made us detect the different emotions that a user waiting for help could feel. This involved a study of all the information that could be useful to him to know. The most important iterations during these weeks were:
Another part that we've put a lot of effort into has been the texts. We needed to communicate to the waiting user what is the status of his ticket, in a tight space. At the same time, it was important that the user didn't interpret the short messages in a negative way, we wanted to help and reassure them by giving as much information as possible. Consulting Jira Service Management agents was crucial for all this issue.
The visual part has not changed that much over the weeks. Although we've iterated on the importance of some data over others, especially taking into account correctly managing the expectations that the end user will put on the information offered by Waiting List. Here we can see one of the first designs and on the right the final result.
During these weeks we have learned several things related to Forge app development:
When developing Forge apps you can choose two options for the front end: UI Kit or Custom UI. UI Kit is designed for simple use cases. It offers you a library of components out of the box that is really easy to use. That is really great, but UI Kit has three big problems right now:
So for that, we changed in a really early phase to Custom UI. With Custom UI you can manage the front end freely but you have to take care of several things like Content Security Policy.
A Custom UI structure looks like an internal project with your front end inside the Forge structure. You will need to generate your bundles and reference them from your Forge module in the app descriptor.
For the Status board app, not having the possibility to search for content was something that discarded the idea.
For the Waiting List app, we were not able to get project SLA configuration so it reduced our possibilities to manage data to show more information to the customer.
A great learning from the Codegeist process has been that it is mandatory to validate technically your idea before developing it. There can be tons of things you want to develop but you need some extra info you cannot get using Atlassian API at the moment. But, another important thing you can learn from that, is that reaching them through their support portal or just creating a ticket in the Atlassian Developer Community can make Atlassian realize they need to extend their APIs and your idea may be valid in the future.
Performance is always important in app development and is even more important when you are developing for the Cloud.
In this case, we had found a workaround to get the data we need to develop or first app idea, the Status board, but at the cost of a bad a performance . So we decide to discard the idea.
Talking about Waiting List, we had to rethink some ideas looking to offer the best performance we can to the final user.
Making fewer REST API requests is crucial for Cloud apps' performance, but the amount of data you are working with is also important. So, if you do not need all the data you can get requesting an endpoint, try to see if this endpoint is customizable to return only what you are looking for. In this case, the search issues endpoint is customizable in the Jira REST API.
When you are working with a REST API you can sometimes get a 429 response status because you are doing too many requests in a short period of time. In that case, retrying these requests is the best approach to mitigate the problem.
In the Waiting List app development we've faced another scenario that we've solved by retrying the request . When an issue is created it can take more than a second for Jira to calculate the SLA information and this time can vary depending on different factors. Taking that into account, we are retrying the SLA information request for the ticket several times with an ascending time period protocol to show the correct information after issue creation.
There are several retry mechanisms/libraries you can use to help you here. In this case, Atlassian has documented well the information for retries.
Forge has a very well-documented quotas page. Some of them are really important and should be reviewed like the runtime limit of 25 seconds or the number of invocations.
Codegeist has been not only great for creating the Waiting List app but for planning our next steps with Forge. These quotas will make us rethink or even discard some features, so if you plan to work with Forge anytime you should look for them.
When Waiting List development was ready, different people tested it internally.
But we were not looking only for technical approvement but also for feedback. After doing internal demos we gathered much feedback and we changed some things and added new ones too, like the possibility to show to the support user directly in the ticket the same information the customer can see in the portal.
Disclaimer: for the Hackathon we didn't have all the potential of our marketing team. We took advantage of the hackathon to test some things in marketing as well.
One of the necessary parts to enter this Hackathon 2022, is to explain the app in a creative, simple, and dynamic way, so we`ve decided to generate a quick video to expose the use cases we have found in the previous research with real customers. One of the lessons learned is that the hackathon not only allows us to learn about development but also opened the door to research video tools to create content and we found Powtoon where we've created our video presentation of the app.
We didn't want to invest many resources on it, so we choose the free plan, it was covering all the needs we had and the idea we have had, we've imagined it in cartoon format.
Once the idea was implemented and the video was finished, we realized that we couldn't export without watermarks with the free account 🤦🏻♂️ , the quality was quite poor and many other complexities. Finally, we all sat down together and made the decision to upgrade Powtoon in order to present the best vide we can.
In the end, this tool was not only used by the marketing side since the whole discovery team contributed their bit. Thanks to this teamwork, we managed to do a job that we are very proud to participate in Codegeist 22.
Discover in the Codegeist page how Waiting List works or if you prefere you can watch our video:
It was a really great experience participating in this Codegeist edition. It has made us learn a lot about the Forge platform possibilities and it is key for us as we were only focused on building Connect apps and Forge is the Atlassian future for Cloud.
We've enjoyed the whole app-building process, from working with ideas to the final support, so these kinds of initiatives are great to work all together to build something that makes sense really fast.
So, after these intense weeks, we would recommend you take part in the next Codegeist . See you there!
Any resemblance of Laura with the real Laura, is pure coincidence 😜
Leo Diaz _ DEISER
Member of #DEISERTeam | Head of Product
22 accepted answers