👲🏼 🔧 🏺 Moscow travel hack through the eyes of the participants 🚳 👩🏾‍🤝‍👩🏼 👂🏻

Hello! You have probably heard about the first hackathon in Russia on the topic of digitalization of the tourism industry. The company AeroClub IT was represented by two teams at once, and we managed not only to have a great time, but also to develop prototype projects, try our hand at an unusual work format, and communicate with other participants. Under the cut - the story of one of our teams!

When applying, it was necessary to choose one of the 10 proposed tasks (tracks). These were cases of such well-known companies as MegaFon, Facebook, PANORAMA 360, MTS Startup Hub, Aeroexpress, Pushkin Museum, Tsaritsyno Park, Discover Moscow, City of Discoveries, and Russpass.

We applied for the participation of two teams at once: “Team 73” in the track “Aeroexpress” , and “New horizons” in “Tsaritsyno” . The first one was chosen because it is close to the field of activity of our company (B2B software solutions), and in case of victory we could well continue cooperation and development. The second - the guys who wanted to escape from everyday tasks and try something new.

In the general chat of the event, they said that 1241 applications were submitted (both team and individual), and, as you might already guess, we passed the selection! And both of our teams!
The only thing left was to participate in the hackathon itself.

Hackathon

Everything was as usual on the site: registration, snack area, tables with team numbers.
At 9:30 a short opening took place: a few words from the organizers, the solemn start of the hackathon, and work began. Next, we will speak on behalf of the participants of the Team 73 team, which took on the task from Aeroexpress.

At first, we talked with the mentors: we learned what they would like to see in the decision, what are the nuances, and what to give preference to. The teams were a little surprised when it turned out that the promised resources would not be provided. According to the description of the task, we could get the Aeroexpress API, hosting, domain name, and certificate for the project. As the mentors explained, the API cannot provide for security reasons, but they did not really explain the rest. Fortunately, we had a “backup option” - personal hosting. As a result, he saved our position.

Decision

The main problem that needed to be solved was the automation of ticket sales for Aeroexpress for legal entities. persons. We did some research on the current process and were, to put it mildly, in shock. As we learned from a public offer for legal entities , first an acceptance letter is sent from the customer company as a request for the required number of tickets, indicating the details of the company. Next - the invoice is paid and, most importantly, somehow the tickets are received in the form of a password-protected archive. That is, as you understand, the minimum level of automation.

We sketched CJM (customer journey map), chose the minimum necessary functionality, and thought about the design. At some point, we reasoned as follows: each team, one way or another, will show approximately the same solutions: registration of legal entities. persons, ticket purchase, billing, and so on. To stand out somehow, you had to come up with something special. At a minimum, you need a good design, then against the general background our solution will be a little more noticeable. Fortunately, there is a designer in our other team, and she will help us with this. But you needed something else, something completely unusual for B2B. And then we decided to add integration with Alice, the very voice assistant from Yandex.

There were several reasons: the main one - we have some experiencework with her to quickly make a more or less useful prototype. Another one - B2B, as a rule, is associated with something boring and formal, and getting tickets through a talking column is something new. In addition, we have two backend developers, and pushing together in one project is not very convenient, and in parallel we will make both the main functionality and the additional one.
I'll start with the main solution - Aeroexpress Wholesale Portal. According to our idea, it consists of two parts: the front-end and, of course, the back-end.

Frontend

Our front-end is an adherent of Angular, hence the choice of this particular framework. Angular “out of the box” provides a good starting environment, in which you don’t have to bother with configuration, routing, and connecting to the backend - what you need for a hackathon. Also, our developer has been working with him for a long time and has accumulated several of his libraries with which you can save a little time on the hackathon.

As a result, we got such a frontend:

We tried to make the appearance modern, stylish, keeping the colors of Aeroexpress.

Here we have implemented the following functionality:

Search company name by TIN
Registration of a company and a contact person with an indication of the approximate volume of ticket sales per month.
Company employee authorization
Ticket order
Number of upcoming trips
History of orders
Aeroexpress manager’s personal account

We tried to make the registration of the company as simple as possible on the portal: its representative needs only to know the TIN of the legal. persons, and enter it in the appropriate field. If the name that appears is appropriate, you can continue. Registration on the portal is simultaneously an application for cooperation with Aeroexpress. Mentors suggested that it would be easier for them to consider such applications if representatives would indicate the approximate volume of ticket sales per month, for this we added an appropriate field.

At first glance, it might seem that not so much has been done, but our solution has a very beautiful and well-designed design. It was made from scratch, without using any ready-made templates. According to previous experience, hackathons often won decisions that were not so well worked out, but “wrapped in beautiful packaging”, and this time we decided to rely on a beautiful appearance. Looking ahead, I’ll say that the mentors were delighted with our design, but judged the solutions precisely by the number of implemented functions and the future prospects of applying the solution (which some teams thought through well).

Backend

Both of our back developers are seasoned sharpists (they write in C #), therefore the back is also based on .net core. Version 2.1 was chosen, because the applications on it definitely rise on a backup hosting, and it is dangerous to experiment on a hackathon - you can lose time and be left without a solution. We got the usual web-api, with blackjack and DI.
Here we have done everything necessary for the "front":

Search for company information by TIN
Registration of the company and its contact person
Password Authentication
Bearer Token Authorization
Getting User Information
Getting the list of company employees of the current user
Create Order
Sending a ticket by post after creating an order
Sending a ticket by mail to the requested user (for external integration)
Getting information about all company tickets
Listing Orders
Listing registered companies

From interesting - integration with the search for organizations by TIN or BIN in Dadata , for easy registration of legal entities . faces. In short, the backend receives a “find a company” request with the given TIN, and sends this information to the service API. In response, if the company is found, we get information about it: a short name (we give in the answer), and details. It is useful to save the data obtained somewhere, because they will be useful in the formation of accounts: it will be enough for the user to check their correctness, which is much easier than “driving in” on their own.

Voice Assistant Skill

Skills for assistants are usually web services that work with a specific request and response protocol. As already mentioned, we chose integration with Alice as a complement to the main solution. You can learn more about the protocol for working with it from the documentation , and also in the latest article about skills . In our case, the skill web service was also based on .net core.

The user should be comfortable interacting with the skill, as if he was talking with his close friend. To do this, at a minimum, it is necessary to maintain the context of the conversation, to understand what kind of object the user is talking about, and to answer on the topic. If the user deviates from the purpose of the dialogue, you need to be able to return it to the right track. And all this should happen no longer than 3 seconds - that’s how much time the Yandex.Dialog platform gives you the ability to answer. If the answer is not received in the allotted time, the dialogue will end, and the user will be told that the skill is not responding, and they are unlikely to want to return to it again.

You can cope with this task with the help of various services designed to maintain a dialogue with the user. We already had some experience with Dialogflow.from Google, so chose it. At the very least, there is an alternative from Russia for him - Aimylogic from JustAI, but I have not had to work with it yet.

In our case, a fairly simple dialogue is supposed: the user asks to send him a ticket, and if he immediately named his name, we send it. If not, we specify the full name, and then we are already sending.

Clarification of the username at any cost

In our opinion, the most difficult thing in this task is to get the name of the user. If they are not named, you need to somehow get them from the user, and only then do the desired action. Fortunately, DF (Dialogflow) allows you to do this out of the box.
To do this, in the intent (Intent), in which the name is supposed to be received, you need to add training phrases containing the full name and mark them so that this information falls into the corresponding intent parameter. If the name is recognized, the parameter will contain this value.

Marked up training phrases

Parameters of Intent

Otherwise, you need to get these parameters at any cost. To do this, mark the parameter with the full name as mandatory (a tick in the “Required” column), and specify clarifying phrases for it (“Prompts”). Now, if necessary, DF will give them back in response. And if the name is recognized - then the usual answers for this intention, as well as the action ("Action").

Clarifying Phrases

Usual answers

Then everything is simple: if the action name is received and the DF response has all the necessary parameters, we perform this action and pass the response to the user. If not, send the clarification text.

To send tickets, the skill must fulfill a request to the backend of our portal with the authorization heading and the name of the user in the body. The company will be determined by the title, and by the name it is easy to find the right user. In life, the title can be obtained by authorizing the skill, but at the hackathon we just “hardcoded” it to save time. With a full name is a little more complicated.

You can use the names recognized in DF, but there is a small problem: if the user calls himself not in the nominative case, then this parameter will also be written in the parameter. On the backend, user names are written in normal form (in the nominative case), and a spelling mismatch will make it difficult to find.

And here we noticed that in the request from Alice come recognized names, normalized and recorded in separate fields!

Recognized name

Unfortunately, the NLU of Yandex-dialogs does not cope very well with more complex names, for example Mamedov Polad Murtuza oglu, but this option is also suitable for demonstration at the hackathon.

As a result, we got such a chain:

Query diagram

By the end of the hackathon, we had all three parts of our solution ready, which we showed to the mentors. By their reaction it was difficult to say whether they liked our development or not, but, as we later learned from a personal conversation, a demonstration of integration with Alice definitely had the expected wow effect.

A technical commission also took place during the work: each team had to provide access to their repositories, and make “commits” in them at least once per hour. Also, sometimes representatives of the commission came to us and discussed the solution being developed. By the way, you can find out their impression of the hackathon here .

Winners

After the speeches of the invited speakers, the final pitches of the teams that won in one task or another began. The AeroTeam team won the Aeroexpress track. As mentors later told us (they are also the jury), it was this team that had the most thought out concept for the further development of the solution, and the guys took into account and worked on some points that even the customers themselves did not think about (unfortunately, they did not mention which ones). For victory, we lacked some details that are really interesting to mentors from a business point of view. They chose a solution that was sufficiently developed to begin its development “right now”, which means they were very objective in their decision, and this is great.

As we later learned from a conversation with the participants of AeroTeam, they gathered in a messy team: they learned about the hackathon from completely different sources, somehow got into the general chat of the event, and there they united. There were three people at AeroTeam. At some point, they were also offered a UX designer, but they refused, and did quite well without this role. The guys did not have any special prerequisites for victory (for example, in the form of some groundwork), and they managed to do such a powerful job, which, in my opinion, deservedly deserved a victory.

Our other team, unfortunately, also did not go on stage with a pitch, which means that she did not win in her track, but we will tell this story another time. In the meantime, who became the super winner of the hackathon? This nomination was given to the team, which, according to the jury, made the best decision among all the winners in one category or another - Golden PSG. They worked on a task from the Panorama 360 observation deck .. On assignment, it was assumed that visitors to the site would be photographed against a “chromakey” (plain canvas), choose another colorful background instead, and immediately print the photo. The guys went further, and their solution allows you to remove any background (and programmatically it is much more difficult to do than remove the same color) around the main object (person), and replace it with another. In our opinion, this decision is also worthy of victory.

The participants themselves are students of the budget department of ITMO. As the guys said in a personal conversation, they were always on the site, at night they didn’t go anywhere, and “plowed” for almost 26 hours out of 30 (intermittently, of course). They already had experience participating in hackathons, but the prize is being taken for the first time.

findings

First of all, it is worthwhile to devote more time to the implementation of the main decision, so that the jury can “touch” it, see it live on the prototype, and not on mock-ups and words. It is also worth considering further prospects for the development of the project. Other things being equal, judges may give preference to a decision that fulfills not only the current task, but also the accompanying goals of the customer.

Nevertheless, if you can somehow stand out - to make a beautiful design, or to implement an unusual idea, this is definitely worth using. From the experience of participating in other competitions, this can help to win, if not in the main, then at least in the additional nomination - for example, to receive a “spectator’s prize”, if any. Or the participants and judges will simply be remembered for their unusual approach.

Before the event, it is worthwhile to conduct some research of the customer’s business in order to better know its “pain” and come up with something to eliminate it. Ideas and small developments are not a “ready-made solution”, so that the rules of the hackathon will not be violated, and there will be more time in the competition itself.

You should not rely on the provision of resources by the customer, even if it is prescribed in the task. In general, one should always be well prepared for a hackathon: raise the minimum necessary infrastructure, consider publishing a project, research the API of necessary services, and the like. It is definitely worth considering a solution to such a problem as your own access to the Internet, since most of these events have difficulties with this. Here, for example, most of the time there was no stable connection. The irony is that the symbol of the hackathon was an offline dinosaur, which can be seen in Chrome when you do not have the Internet.

I would like to separately note the organization of the hackathon: in general, it was at its best. Each stage took place on time, on the site itself was also in full order: there was enough food for everyone, there were a lot of snacks. On the second day, in theory, it was possible to come to the public part after preliminary registration, but, as a result, anyone could get there. A small party with a musical group and a buffet table were a success too! We express our gratitude and respect to the organizers. Our rating - four out of five green dinosaurs - so there was something to strive for!

That was the Moscow travel hack for us: something in our solution was bad, and something was good. In any case, we will take into account our mistakes and will remember them at the next competition. In general, participating in a hackathon, especially in a team of colleagues, is great! For us, it was not only a golden experience, but also the best team building. We played very cool, did crazy things without sleep and rest. We were convinced that we can work productively on complex tasks in a short time and in a stressful situation. The main thing is to enjoy the process!

If you are interested in the technical details of the implementation of our solution - write in the comments, we will gladly tell you.
Do not say goodbye, see you at the hub
Team 73 Team, Aero Club IT

Aeroclub IT teams at Moscow travel hack

Moscow travel hack through the eyes of the participants