Codegeist 2022 - The DEISER story 🚀
This year we've participated in the Atlassian Codegeist 2022 and this is the DEISER Story of how it was.
What is Codegeist?
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.
Our Codegeist 2022 story
We would like to share the steps we took and some lessons learned.
Chose the team members
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!
Find product gaps or user pains
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.
Build in an Agile way
Ideation
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.
Design
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:
- Changes in the colors of the box to inform without reading about the different ticket statuses.
- Add valuable information such as the position of his ticket in the queue, average response times or if the queue is open.
- Discard adding other data with could have a lot of value for users but was not possible to obtain
.
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.
Development
During these weeks we have learned several things related to Forge app development:
Use Custom UI front end to have more customization possibilities
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:
- Components are not extensible
- The page layout cannot be modified
- All components are rendered in the server. This last topic is really interesting but offers poor performance on component interactions because the user has to wait for a client-server communication after them.
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.
Check you can get what you need with the API
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 first
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.
- Finding the queue position of the ticket can perform poorly if the project has lots of issues with running SLAs. For that, we decided to show a particular ticket position if it is under 100 and a 100+ position otherwise.
- Getting the average time for ticket attendance can perform poorly too. Every SLA is a custom field in Jira, so it is important to know what custom field it is before searching for issues. In that case, we only need two requests to Jira to get the data we need to calculate the average time: one to get the SLA custom field info and the other one to search for issues looking only at this SLA custom field data there.
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.
Retry REST API requests
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.
Take care of the platform quotas
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.
Improvements
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.
Marketing
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.
The result
Discover in the Codegeist page how Waiting List works or if you prefere you can watch our video:
Conclusion
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!
Bonus
Any resemblance of Laura with the real Laura, is pure coincidence 😜
Was this helpful?
Thanks!
Leo Diaz _ DEISER
About this author
Member of #DEISERTeam | Head of Product
DEISER
Madrid
22 accepted answers
2 comments