Link to the final presentation #
Link to deployed solution #
Week #1 #
Team Formation and Project Proposal #
Team Members #
Team Member | Telegram ID | Email Address |
---|---|---|
Team Member (Lead) 1 | @Dirak0n | d.bannikov@innopolis.university |
Team Member 2 | @ikramkxt | i.kamat@innopolis.university |
Team Member 3 | @SensAri0 | a.kurdyukov@innopolis.university |
Team Member 4 | @a1kuat | a.alkuat@innopolis.university |
Team Member 5 | @ayaz_iu | ay.safin@innopolis.university |
Value Proposition #
Identify the Problem: Our beloved city, Innopolis, is situated at a distance from Kazan city. While this location offers numerous benefits, such as beautiful natural surroundings and a tight-knit community, it presents a challenge when it comes to traveling to places of interest like the airport or Kazan itself. Despite the availability of public transportation, citizens often encounter transportation issues. Our project aims to address this problem and provide a solution.
Solution Description: Can be found below in the Defining the Vision for Your Project section
Benefits to Users: The main benefit of our project is the opportunity for users to save money on transportation costs. Additionally, our project will provide a convenient and reliable means of transportation, particularly for routes that may have limited public transportation options. Furthermore, we believe that our project will foster social connections and community building. By providing an easy way to find travel companions, we envision the potential for friendships to form and even new startup opportunities to arise.
Differentiation: Our main differentiating factor from other existing solutions is our ability to leverage Innopolis’s strong sense of community. With our project, users not only reduce costs but also find compatible travel companions. The current local solutions, such as the ‘Иннополис попутчики’ and ‘Taxi иннополис’ Telegram groups, have significant drawbacks. The messages in these groups are exclusively in Russian, making them inaccessible to some citizens of Innopolis. Furthermore, in our focus group session, the majority of respondents who use those groups (18 out of 20 people) expressed their dissatisfaction, highlighting the groups’ current state as unusable.
Testimonials or Use Cases: Use case: There are several citizens in Innopolis who want to travel from Kazan airport to Innopolis and would be interested in sharing a ride. However, they are unaware of each other or available drivers in our community. Our project aims to connect these individuals with each other and with drivers in our community. By facilitating communication and coordination, we will help them find suitable travel companions and arrange shared rides.
Lean Startup Questionnaire #
- What problem or need does your software project address?
- Our project will address the challenge of finding travel companions for trips between specific locations within specified timeframes. It will provide a solution for both types of travelers: those who are seeking a ride and those who are willing to offer one.
- Who are your target users or customers?
- Innopolis citizens
- How will you validate and test your assumptions about the project?
- To develop the MVP of our project, we conducted a focus group and analyzed the shortcomings of existing solutions. Following the MVP phase, we will incorporate user feedback and make necessary improvements.
- What metrics will you use to measure the success of your project?
- We will monitor the number of users and gather their feedback.
- How do you plan to iterate and pivot if necessary based on user feedback?
- As mentioned earlier, we will collect user feedback after the release of the MVP.
- We will analyze the feedback to identify the most critical and impactful issues.
- During a meetup, we will establish specific integration goals.
- Our team leader will add the corresponding task to the git repository.
- A team member will assign the task to themselves and proceed with its implementation.
- Thorough testing will be performed to ensure the quality of the feature.
- Once testing is complete, we will deploy the feature.
- We will then return to step 1 and repeat the feedback-gathering process.
Leveraging AI, Open-Source, and Experts #
- AI (Artificial Intelligence):
In the current state of implementing the MVP of the project, we envision utilizing AI in the following ways:
- For team members who have a tech stack not directly related to the project (e.g., C#), tools like ChatGPT and GitHub Copilot can be immensely helpful in bridging the syntactical differences between programming languages.
- Certain blocks of code or functions can be generated entirely using AI. This has the potential to expedite the development process and increase efficiency.
- Every week, we are assigned the task of writing a significant report. Initially, we tried to work on it as a group, but we soon realized that this approach was inefficient. We found ourselves repeating information, and the report lacked proper structure and consistency. To overcome this issue we assigned technical writer (Ayaz Safin). During the writing process, I utilized a template provided by our Capstone project instructors to maintain a consistent flow of information. Additionally, I used ChatGPT to review and revise each section, ensuring accuracy and minimizing spelling errors. As a result, the final report is written in a unified style and reflects a high level of proficiency in English (C1 level).
- Open-Source: We plan to incorporate Open-Source solutions into our product to speed-up the development. For instance, some places where we might use it: frontend, time selection, telegram authentification.
- Experts in relevant domains: In the current state of the project, we do not have any requirement to consult or involve external experts, apart from our Capstone project instructors.
Inviting Other Students #
- How it all began From the outset of forming the team, we maintained an open mindset, welcoming any new members who could contribute to the successful implementation of our project. With this approach, we managed to assemble a team of five individuals. Together, we engaged in discussions to explore ideas that could simplify our daily lives. Once we settled on a project, each team member began offering their unique expertise and how they could contribute to the project’s success based on their strengths. By taking into account our collective hard skills and effectively assigning tasks among ourselves, we are confident in our ability to execute a successful project and gain valuable experience.
- Democracy As a team, we have established a decision-making process where we address major problems through team meetings. Our approach involves voting and reaching a majority consensus to determine the course of action. We have already conducted two team meetings during which we developed and refined this project.
- Totalitarianism Despite the aforementioned fact, based on our experience from previous courses like SWP, we recognize the importance of having a designated team leader. As of now, we have elected Dmitry Bannikov to fulfill this role. The primary responsibility of the team leader is to add new tasks to the GitHub repository based on the decisions made during team meetings. Additionally, the team leader has the final say in resolving any local conflicts that may arise during the project implementation.
Defining the Vision for Your Project #
Overview: #
Our project is an attempt to simplify the use of ‘Попутчики Иннополис’ telegram chat by making it more structured and available both for english- and russian- speaking users. Our vision is the easy-to-use website paired with easy-to-use telegram bot, both of which in collaboration make it easy to find fellow travellers. The website lets you filter through already existing trip requests made by other users, respond to them, create your own, and more. The telegram bot gives you notifications and sometimes opportunity to make decisions through it.
Schematic Drawings: #
Schematic representation of user interacting with our frontend
Tech Stack: #
For now, this is our preliminary outline of the tech stack we plan to use. Please note that it is subject to change, and we expect to finalize it by the end of next week:
- Backend: Go
- Database: PostgreSQL/MongoDB
- Frontend: JavaScript + React
- Telegram bot: Python
Anticipating Future Problems: #
Communication and Coordination: #
To overcome this problem we:
- created a group chat
- schedule regular team meetups We have already conducted two team meetups where we decided key aspects of our project and made important management decisions
- elect team leader
Limited Resources #
We have a limited number of resources, with only 5 students who are also juggling other subjects and personal commitments. Additionally, we have a tight deadline of 7 weeks to complete the project. To overcome this problem we:
- made important management decisions in the first week.
- will utilize all the acquired experience from past courses.
- plan to attend lectures to stay in touch with instructors.
Elaborate Explanations: #
Backend #
Backend will have access to the database where information about the trips will be stored. It will also provide an API for both the Telegram bot and the frontend parts.
Frontend #
Frontend will include a Telegram authentication page, which will help authorize users, preventing spammers and malicious actors, while also providing an easy way to contact other travelers.
The frontend will feature a main page with filtering options, allowing you to choose the time, destination, and other criteria. On this page, you can view all pending trip requests that match your filters. You can respond to existing requests or create your own.
Telegram bot #
The Telegram bot will send you notifications regarding your request, whether you created it or responded to someone else’s request. Additionally, it can serve as a convenient way to interact with the request. For example, you might receive a choice to join a driver who created a request.
Feedback
Value Proposition Good, stating for the value proposition. But it would be better if you wrote the solution. It’s ok to repeat it in another section
One drawback I see here, that not all travellers will welcome strangers. Beside groups that you mention have taxi driver deliver people. Maybe you should focus how can you incorporate them?
Use case is a bit weak. Try to think of more uses cases your solution will be used and by whom?
Lean startup question
- Very weak metric . Try to use NPS, Retention rate, visitors, number of users… etc try to google metrics to measure success in building products
AI We mean here will utilise AI applications in your solution. Not what ai tools you used during development
Vision Of The Project Good
Overall Very good report! But try to think more about AI utilizing. And explain more on the use cases 5/5
Feedback by Moofiy
Week 2 - Choosing the Tech Stack, Designing the Architecture #
Tech Stack Resources #
Currently, we are not utilizing any project-based books for the implementation of our project. However, we have discovered a short book that caters specifically to beginner technical writers, aiming to improve the quality of our reports. The book is available at the following link.
Mentorship Support #
Currently, we do not have an active mentor involved in our project. However, we are open to seeking a mentor in the later stages of our project. We believe that having a mentor would contribute to the success of our project by providing valuable guidance, experience, and insights. We understand that finding a mentor is our responsibility, and we are committed to actively seeking one to enhance our project’s outcomes.
Exploring Alternative Resources #
- Tour of Go: We have utilized the Tour of Go, an interactive tutorial, to learn the Go programming language. It has been instrumental in building a strong foundation and understanding the core concepts of Go.
- Free Code Camp YouTube videos: We have found the Free Code Camp YouTube channel’s videos to be valuable resources. These videos provide practical explanations and demonstrations that have helped us fill knowledge gaps and deepen our understanding of various aspects of our tech stack.
- Documentation: We have extensively relied on the official documentation of our tech stack. The documentation has been an invaluable resource, providing comprehensive explanations, usage examples, and references for specific functionalities, APIs, and best practices.
Identifying Knowledge Gaps #
- Report Writing:
In order to address the importance of report writing in representing our progress to Capstone project instructors, we have implemented the following strategies:
- Utilizing AI models to compensate for the lack of experience in creating effective reports.
- Assigning an entry-level book, as mentioned earlier, to guide us in improving our report writing skills.
- Seeking informative feedback from instructors to refine and enhance our report-writing process.
- Golang:
To address the issue of a team member in the BackEnd team lacking experience with Golang, we have taken the following steps:
- Utilizing the “A Tour of Go” project to familiarize the team member with the syntax and fundamentals of Golang.
- Leveraging Free Code Camp videos to further deepen our understanding and knowledge of Golang.
- Assigning a team member who is already familiar with Golang to provide support, answer questions, and offer assistance as needed.
- Adjusting the workload to ensure that the team member can work on the code after their Backend teammate completes the initial skeleton.
Engaging with the Tech Community #
While we understand the importance of engaging with the broader tech community, we have not actively sought guidance or learned from experienced professionals in our tech stack. At the current state of the project, we have not found it necessary to engage extensively with the tech community. However, we do have means to engage experts through professional networks if critical tech stack problems arise that require external expertise. We remain open to exploring online forums, groups, and attending local meetups in Kazan or Innopolis as the project progresses, should the need arise for further engagement with the tech community.
Learning Objectives #
Some of the problems we encountered and the methods we employed to resolve them were detailed in Identifying Knowledge Gaps section. In addition to those challenges, we are confident that we possess the necessary competences to commence development at this stage. The specific plan for our development process will be elaborated in the subsequent sections.
Sharing Knowledge with Peers #
We had two team meetings, and the reports from those meetings are provided below. Additionally, we maintained frequent communication within our small teams of two, allowing for detailed collaboration and knowledge sharing.
How have you leveraged AI to compensate for any lacking expertise in your tech stack? #
Yes, we leveraged AI extensively. During the course of this week, we made use of AI and open-source solutions to test multiple implementations of different parts of our project. This allowed us to explore a range of potential solutions and evaluate their effectiveness. The integration of AI was particularly valuable in facilitating the evaluation and comparison process, empowering us to make well-informed decisions and select the most suitable tools for our project.
Weekly Progress Report #
During week 2, we as a team made 2 team meetings:
Team meeting 1 #
During our team meeting, we made the decision to divide into smaller teams of two people, each responsible for a specific part of our project. This approach proved to be highly efficient in terms of communication and knowledge sharing. By working closely with a designated team member, we were able to focus on our assigned tasks and share our expertise more effectively. Any questions that arose during the meeting were thoroughly discussed and addressed. In cases where additional questions emerged between meetings, we directed them to our team leader, who promptly resolved them. This division of responsibilities and streamlined communication process has contributed to our project’s progress and overall productivity.
Backend team (DB included) #
- Ikram Kamat i.kamat@innopolis.university
- Alexander Kurdyukov a.kurdyukov@innopolis.university
Frontend team #
- Dmitry Bannikov d.bannikov@innopolis.university
- Azamat Alkuat a.alkuat@innopolis.university
Telegram bot team #
- Dmitry Bannikov d.bannikov@innopolis.university
- Ayaz Safin ay.safin@innopolis.university
Team meeting 2 #
During our second meeting, we had a productive discussion where we shared and presented the work accomplished by each team between the meetings. We also conducted a feedback session, which highlighted the effectiveness of working in small teams during this early stage of project development.
However, we discovered that there were some misconceptions regarding the overall vision of the project during our discussions. Fortunately, we were able to address and resolve these misconceptions.
The main outcomes of the meeting are as follows:
- We synchronized and clarified the vision of the project, ensuring that everyone has a shared understanding of the project’s structure.
- We decided on the specific tech stack to be used for each part of the project
- We created a schematic representation of our project, providing a visual overview of its structure and components.
- We defined the objectives and goals for sprint 1, setting clear targets to be achieved within the designated timeframe.
Backend team (DB included) #
Go + Gin, Postgres
Frontend team #
JS + React
Telegram bot team #
Python + Flask
Schematic architecture representation #
Sprint 1 #
Objectives #
The main objective of sprint 1 is to deploy all parts of our application, including the functionality we discussed, to the server. Additionally, our goal is to ensure that the different parts of the app communicate correctly. By achieving this objective, we aim to have a functional and integrated system that demonstrates the seamless interaction between the various components. This milestone is crucial as it allows us to test and validate the core functionality of our application, ensuring that it operates as intended and paves the way for further development and refinement in subsequent sprints.
Timeframe #
16.06 - 22.06
Functionality #
Backend team (DB included) #
- Implement basic CRUD API for trips (creating + retrieval)
- Save and retrieve data from DB
- Implement Telegram Webapp authorization verification + token sytem (for backend access)
- Save basic working version as container to DockerHub registry
Frontend team #
- Implement basic filter bar for choosing time and filtering through trips
- Visualize trips on the website
- Connect to backend (retrieve and send data)
- Setup Github Actions workflow for automatic Github Pages deployment
Telegram bot team #
- Regsiter a Telegram bot that redirects the user to our frontend (rendered as WebApp)
- Implement basic proof-of-concept Flask server that accepts requests from both Telegram servers (using webhooks) and our backend (which will be deployed on the same machine in Docker container on the same Docker-compose network)
- Save basic working version as container to DockerHub registry
DevOps #
- Setup Docker-compose (containers+network) with references to our DockerHub images
- Utilize rented cloud server to constantly poll DockerHub registry for new versions of our containers: update and restart the whole docker-compose network whenever needed
End? #
We have scheduled a team meeting on 22.06 to discuss and assess the outcomes of Sprint 1. During this meeting, we will review the work that has been completed and evaluate its progress. Following the assessment, we will engage in discussions regarding the further development of our project and determine the objectives for Sprint 2.
Feedback
2. Data Management
Missing
**3. UI Design **
Missing
4. Integration and APIs
Missing
5. Scalability and Performance Missing
6. Security and Privacy Missing
7. Error handling and Resillience Missing
Answering questioner Answering for the questioner is ok, You should find a mentor from the early stages, since he will provide a lot of insight to your project.
Also try to write the name of courses you found on free code camp.
So you didn’t utilise any books, you didn’t find a mentor, you didn’t engage with tech community.
Fortunately, we were able to address and resolve these misconceptions?
Overall The report is not very good, and lack a lot of details. Beside stick with the report template don’t change it and provide answers to what requested in each section correctly.
However, we discovered that there were some misconceptions regarding the overall vision of the project during our discussions. Fortunately, we were able to address and resolve these misconceptions.
So what was those misconceptions?
Beside the report have a lot of text that is not meaningful like the text above
Grade 2.5/5
Feedback by Moofiy
Week #3 #
Developing the prototype, creating the priority list #
Technical Infrastructure:
- Deployment: Together we rented a cloud server, where we use Docker for the deployment of our Backend and Telegram-bot parts. The frontend is hosted on GitHub servers via GitHub Pages.
Backend Development:
- Authorization: the backend offers versatile authentication options, supporting both traditional methods and Telegram login authorization. Telegram login ensures synchronization that the same user can be identified across the website and webapp.
- API: The backend supports basic CRUD operations with Trips. In other words, the frontend can interact with the backend on trip-related endpoints. It also includes filtration of trips based on the time interval and filters chosen by the user.
- Deployment: The backend of the application is currently deployed on a server and can be accessed through the given link.
- https://inno.co-go.chickenkiller.com/ping (look at Raw Data)
Frontend Development:
- Telegram authorization: the website is to be accessed from the Telegram app using Webapps. Our website takes and parses the authorization data that Telegram gives for further usage (in particular, for authorization on the backend).
- Deployment: the website is deployed on Github Pages here. We set up CI/CD for automatic updates. Note that opening the website from the browser instead of the Telegram bot makes you authorize manually. All the actual users will be skipping this step as they will be using the webapp.
- Basic interface for filtering through trips: we created some basic UI for selecting the time and locations for the trips you want to see. Our interface is intended to support both light and dark themes as does Telegram for a more seamless experience. Note that, for now, both themes are only supported when you visit the website via the browser, inheriting Telegram’s preferred theme is a task in our backlog.
Telegram bot development:
- Webapp: our bot is capable of opening our frontend as a Webapp.
- Deployment: our bot is hosted on our cloud server, and it is available to Telegram (via Webhooks) and to our backend for usage in the future. Our current (test) bot is on @inno_travellers_test_bot. Note that it sends some debug messages, for now, pay attention only to the link to the webapp.
Data Management:
- Backend: backend uses Postgres DB for storing and retrieving the data. It stores user data and trip data. User data includes the Telegram authorization data that we receive via Webapp, and trip data includes all that is visible on the website for each trip (departure/arrival places, time, date, etc).
- Telegram bot: currently, our Telegram bot does not access any DB. However, some of our planned features might require specific data (like the list of users) to be stored, so some lightweight DB (like SQLite) could be used in the future.
Prototype Testing
- When we attempted to combine different parts, we encountered a set of different problems, which are mentioned in the Challenges and Solutions section below.
- Additionally, we encountered a set of backend-related errors (endpoints returning weird errors, lack of environment variables on our server, unapplied migrations, etc), which we fixed.
Progress report #
Prototype Features #
If you want to see more detailed information on technical solutions that we used, you can always check our GitHub repositories with source code. All three of them (one for the backend, one for the frontend, and one for the bot) are on our organization.
Backend #
The backend implements this API, which we designed. There is also information about how we do Telegram authorization verification to generate tokens for further access to the backend.
Frontend #
As mentioned above and shown below, we created some basic UI for selecting the time and locations for the trips the user wants to see. There is also some trip visualization.
Telegram bot #
As mentioned above and shown below, we registered a bot that redirects to our frontend as Webapp. Additionally, we use Telegram’s support of webhooks to host a server that responds to both our backend and Telegram servers (reacting to the user interactions by just repeating what the user said for now).
User Interface #
Telegram bot (for now) just redirects you to our frontend as Webapp. Our UI in general still needs improvements: for now, we focus on functionality rather than style.
The user will select all the options they need (start point, end point, time, and some other filters which will be implemented in the future). Afterward, they press the ‘ok’ button to apply the filters and see the relevant trips. When the filters are applied, the ‘ok’ button is replaced with a ‘+’ button to create your trip if you don’t see any trip that suits you (this feature is still being implemented).
Challenges and Solutions #
- HTTPS for Telegram bot We have a cloud server without any domain (just IP), but Telegram API requires the URL for Webhook to be HTTPS, which requires us to have an SSL certificate for the domain. However, Certificate Authorities like Let’s Encrypt do not provide certificates for bare IP. Fortunately, Telegram accepts self-signed SSL if we provide the certificate while registering the webhook. Thus, we decided to generate SSL ourselves via OpenSSL and send the public certificate to Telegram.
- Mixed content policy While testing the deployment of our frontend that is supposed to send requests to the backend, we found that browsers prohibit HTTP requests when you are on an HTTPS website, which is called mixed content policy. Therefore, we needed to migrate the backend to HTTPS too, but this time self-signed certificates would (probably) not work, as the browser is in play instead of Telegram servers.
- HTTPS for backend To solve the above problem, we registered for a free subdomain from this service and got a certificate from Let’s Encrypt. To ensure scalability in the future, we have taken the necessary step of installing and initiating NGINX with TLS keys attached.
- Bad layout for phones Our initial UI layout was like on this site’s desktop version. In particular, our filter bar was in one line, which looked good on the desktop. However, we quickly discovered that it does not work on phones as the screen’s width on mobile devices is much smaller. Therefore, we decided to do something similar to what the website mentioned above did to its mobile version: put every filtering element in its own line. Note that there is no need for a desktop version of our site as even when you open our Webapp from the desktop, Telegram renders it in a resolution similar to the mobile one.
Next Steps #
We have Github Project for tasks and backlog, here’s a glimpse of it:
As you can see, the features that we plan to add soon are mostly on the frontend. Particularly important for the MVP are trip retrieval from the backend (which is almost done, and is probably already finished depending on when you are reading this) and the trip creation UI. Less important tasks: make UI more visually interesting, accept dark/light theme from Telegram app, visually represent/handle any errors (like failed requests to backend, etc).
After that, we would want to add more functionality to the Telegram bot. In particular, our priority is to display the trip created by the user in their telegram chat with the bot for ease of monitoring. Other bot features that we want to implement that are of lower priority: are trip request deletion from the bot, and created trip request management from the bot (+1/-1 free place for the ride).
The backend is mostly done, so we currently focus on fixing all the mistakes and errors we found there. Additionally, we would need to add more features into the backend whenever we add features to the bot (because the backend is the one that calls these bot’s features).
Feedback
Prototype Features
Missing from reports You should list her all features you will provide in the report as well.User Interface
Very basic user interface, it’s medium fidelity design. You should produce high fidelityChallenges and Solutions
Good!Next Steps
Good. You should relay think of testing with users (Usability testing)Overall
Good report, you should focus more on development of the fronted now.Grade
4/5Feedback by Moofiy
Week #4 #
External Feedback #
During this week we collected 4 forms of feedback regarding our project:
- the feedback to the reports of week 3 and earlier
- we conducted a survey and collected user feedback from their interaction with our prototype
- we encountered a scripted attack to our server
- we conducted 2 team meatings to collect feedback from people developing specific parts of our project
More about servey #
During Week 3, we successfully completed the development of our prototype and conducted a survey to gather feedback. We selected a group of 7 individuals to test our app, with the primary goal of ensuring that the solutions implemented were user-friendly and intuitive. Here are the key outcomes of the survey:
- Testers reported that our app met their requirements and satisfied their needs.
- Testers expressed that our app was more user-friendly compared to existing solutions in the market.
- Some bugs were identified by the testers (more info in testing part below)
- One tester provided a valuable suggestion to implement a new feature that would enhance the app’s comfortability. We have taken note of this feature and will discuss it in our upcoming team meeting.
These survey results have provided us with valuable insights and feedback, helping us validate the usability and effectiveness of our app while also identifying areas for improvement.
Testing #
The initial testing was conducted in the middle of the week by an unknown individual, and our server experienced scripted requests aimed at exploiting basic vulnerabilities. Fortunately, no issues were identified during this test, and everything functioned as intended.
The main testing phase involved surveyors who provided valuable feedback. During this testing, five bugs were discovered.
Iteration #
The feedback after week 3 from the instructors suggested us to focus on the frontend part of our application. Here is the list of most important updates in frontend, implemented during week 4:
- We finished integration with backend
- We now retrieve trip data from the backend and display them
- We can now create trips on the frontend, and they will end up on our backend
- We now accept the theme (light/dark) from Telegram, and our frontend supports both of them
- We improved overall design (so far, we didn’t touch the visualized trips themselves)
- We added translation into our webapp: now it supports both english and russian, and your language choice is remembered for future sessions
Here’s the current state of the frontend:
- Light theme, trip creation UI, english language:
- Dark theme, trip filtering UI, russian language:
In response to the feedback received from our previous reports, we have taken on the task of developing visuals for our project. We are pleased to announce that after Week 4, we have successfully created an icon for our project and have decided on a new project name “InnoCoGo”.
- Logo
- Logo for test bot and dev team
After the attack to our server we made a lot of to make our project as safe as possible:
- After further investigating on possible vulnurabilities, we found a possibility to send users messages from our bot. To address this issue and ensure the authenticity of the messages sent to users, we implemented Telegram’s secret_token verification mechanism. This helped us confirm that the messages originated from Telegram itself.
During our meetup, we encountered a problem with the development of our Telegram bot. The Telegram bot team prioritized tasks that were directly related to the bot’s functionality. However, we faced a significant setback in the development process because hosting the bot locally was not feasible.
To tackle this issue, we made a decision to prioritize this much easier to add “non-essential” but nice-to-have feature:
- On Telegram bot part, we prepared everything needed for local development (elaborated in README), so that it is much easier to add non-essential but nice-to-have features. Also, we decided to reevaluate task for telegram bot development that were in our backlog. An example task with rased priority (which is also our next priority for the bot) is managing trips created by you through Telegram chat.
After users conducted testing and provided feedback, a significant number of bugs were discovered on the frontend. Some of them are:
- Incorrect timezone being displayed
- Bad user experience on change between states (filtering trips <-> creating trips): input fields reset
- “Free places” on trips displays incorrect number
- DateTimePickers are too large on some devices
- Inconsistent layout
Upon further discussion, it was determined that the main reason for this was the lack of sufficient time. The frontend’s main functionality was completed just one day prior to the survey, leaving limited time for thorough testing.
Despite these time constraints, it was decided not to postpone the survey. The decision was based on the belief that the feedback received from users during the survey would still be valuable in improving the product.
While the lack of time for proper testing was a contributing factor to the number of bugs discovered, the team remains optimistic that the feedback obtained from the survey will contribute to the creation of a better and more robust product in the future.
What next #
As usual, we discussed the features that we prioritize the most during the meetup: we will be trying to fix all the problems we found and listed above.
Currently, we are awaiting Tuesday, which includes both the team meetup and lecture. This will help us ensure that our vision of the project’s development aligns with the instructors’.
Here’s a glimpse of our current backlog:
Feedback
External Feedback
Very Good, but maybe better to follow some kind of User statisifaction metrics like NPS to better utilise this feedback.Also, you should provide links to this servey to proof what you are saying and to get feedback on them.
Testing
What kind of testing you are using? How do you manage fixing / finding bugs? How of you mange bugs reporting?Iteration
Good iteration planOverall
The report is good.Grade: 4/5
Feedback by Moofiy
Week #5 #
Weekly tasks #
To accomplish this, we will focus on the following tasks throughout the week:
Scheduling relevant meetings #
During the previous week, we encountered a problem while collecting feedback. We gave the testers a software that had a significant number of bugs.
- To solve this problem, we fixed all the bugs that were identified in the previous week.
- We enlisted the help of several students who acted as quality assurance specialists.
Based on the feedback from the QA team, we identified and resolved the following issues:
The website supports two languages, but the bot supports only English #
In our first version of the Telegram bot, when we were initially testing our ‘join-trip’ feature (which is not yet released), we were told that the bot should be able to change languages as well, so we implemented it. To determine the language, we used Telegram’s language code for a specific user.
Logo is not visible in the dark theme #
Based on the feedback, we made a unique version of our logo for the dark theme: all-white. Now, it can be seen clearer on the dark background.
Language selection looks bad #
Our initial language selection looked like this (top right):
However, based on feedback, we replaced it with a flag selector:
After addressing the aforementioned issues, we conducted the main review for our users.
Prepare a feedback collection plan #
We chose to use Google Docs for collecting feedback because of the following reasons:
- Users are familiar with it: Many people already know how to use Google Docs because it is a widely used platform for creating and sharing documents. By using Google Docs for the feedback collection, we made it easier for users to provide their feedback since they were already familiar with the platform.
- It provides useful survey analysis tools: Google Docs has features that allow us to analyze the feedback we received. We can use these tools to understand the survey responses better, create charts and graphs, and get insights from the collected data. By using Google Docs, we can analyze the feedback and use the information to make informed decisions and improvements based on the survey results
Our survey includes only 6 question, because:
- we didnt want to overwhelm the reviewers
- we wanted to collect feedback only on major points of our project, as we don’t have time to implement every wish of the target audience within 7 weaks
The questions are:
- Is browser version is essential for you. This question will help us to decide whever we should include in in mvp or postpone for future development.
- UX
- UI
- Functionality
By including the previous three questions in our survey, our intention was to identify the weakest aspect of our project. These questions were designed to pinpoint any specific areas that require improvement or further attention.
On the other hand, the last two questions were left open-ended, allowing highly engaged reviewers to provide valuable feedback and inspiration for improvement. We sought meaningful insights and fresh ideas from these questions, as they offered an opportunity for reviewers to share their perspectives and suggestions beyond the predefined options.
Through this approach, we aimed to gather comprehensive feedback that would help us identify the weaknesses in our project and gather valuable input for its enhancement.
Conduct user surveys and document feedback #
During the 7-week timeframe, our primary focus was on implementing the MVP. Due to resource limitations, we decided to prioritize the feedback from highly engaged reviewers, as they represent our initial clients and their input is crucial for improving the product. The statistics presented below provide an analysis of the responses that contain meaningful answers to open questions.
Analyzing the feedback #
Based on the feedback from our engaged audience through the open-ended questions, we have identified the following common user problems:
Lack of essential features for trip management Trip removal, and trip joining are two features essential for the MVP, but they were not yet completed when we were gathering the feedback. Therefore, almost all the testers pointed out this problem.
Lack of feedback Some users pointed out that some actions (such as trip creation) lack feedback, such as a popup that says that their action was successfully complete.
Inconvinient trip filtering Some users found trip filtering inconvinient: too restrictive in some areas, and non-restrictive enough in others. For example, one of our testers shared that they would like too see all the available trips, without filters. Other users said that trips with no free places are irrelevant and should not be shown to users.
Need for more quality-of-life features Some users pointed out that there are some nice quality-of-life features that could be implemented, which would increase the quality of our product in their eyes. Some of such features include: calendar integration, more notifications of different kind to people who joined a trip.
Feedback prioritization #
After hearing the feedback, this is how we prioritize it:
- Lack of essential features for trip management is our priority number 1, and we intend to add these features in the a couple of days as they are mostly ready
- Lack of feedback would be our number 2 priority, and we are looking for to adding alerts and pop-ups in different scenarios
- Inconvinient trip filtering would be our number 3 priority, as we are not yet sure of how to improve the experience in that case
- Need for more quality-of-life features is the least important feedback for us, as the implementation of the features suggested seems unfeasiable in two weeks left before the final presentation. However, we will consider these features for after the ‘Capstone’.
Product roadmap after ‘Capstone’ #
- Currently, our main focus is on developing a Minimum Viable Product (MVP) which includes only the Telegram Web App, as it is supported with the feedback of our users. However, we have realized that this method is not suitable for certain segments of our audience. To solve this problem, we plan to provide the same functionality through a website. In order to easily expand our project in the future, we are considering this aspect while designing our architecture.
- Another important issue we need to address is ensuring the profitability of our project so that it can be properly maintained. Our main idea is to utilize the payment features of Telegram. We believe that charging a commission from the drivers who use our project to find passengers could be a good approach. However, we will tackle this issue after gaining a better understanding of the number of users, in order to properly assess the economics of each transaction.
Implementing necessary changes or enhancements #
In the first section, we discussed the features we implemented or fixed based on the QA team’s work.
By tackling the feedback according to the established prioritization, we aim to ensure that the most important issues are addressed promptly, resulting in the improvement and refinement of our software based on the valuable input provided by the survey participants.
Collecting and documenting feedback
Very good!
Feedback analysis
Very good!
Roadmap and enhancement
Very good!
Grade: 5/5
Week #6 #
Link to the final presentation #
Link to deployed solution #
Weekly tasks #
We have accomplished a substantial amount of work this week. During our sprint, we successfully addressed several bugs and implemented various features based on user feedback.
- focused on frontend and improved visuals
- fixed several bugs
- added immediate feedback on some actions: alerts and warnings
More info in backlog.
AI Integration #
The main achievement of this week is the addition of an AI translator to our project. We consider the availability in both Russian and English as a key feature, which is why we have integrated LibreTranslate as a crucial component of our project. Our decision to opt for LibreTranslate was driven by several important factors that align perfectly with our project’s goals.
Firstly, LibreTranslate is an open-source solution, which means that it is developed and maintained by a community of passionate individuals, making it transparent, accessible, and continuously evolving.
Secondly, the ability to host LibreTranslate locally on our own server provides us with a level of control and independence that is crucial for our project’s success. By having it within our own infrastructure, we can fine-tune and customize its functionalities to suit our specific requirements. This localized hosting also ensures data privacy and security, as sensitive information remains within our organization’s confines.
Furthermore, LibreTranslate’s open-source nature and local hosting not only give us the freedom to modify and adapt the tool but also allow us to seamlessly integrate it into our existing workflow and system architecture. This integration will enhance the overall efficiency and performance of our project, enabling us to deliver a more robust and user-friendly solution to our valued users.
Overall, LibreTranslate stands out as the ideal choice for us, providing the perfect blend of openness, adaptability, and security, all of which are instrumental in driving our project towards success and making it a valuable asset for our users.
Making the presentation #
During this week, another critical task on our agenda was to create a presentation that would adeptly showcase our project to the course instructors. To ensure the presentation’s effectiveness, we employed the following strategies:
Conducted two team meetings: Collaboration and communication are vital for a successful presentation. Therefore, we held two team meetings to brainstorm ideas, discuss key points, and delegate responsibilities among team members. These meetings allowed us to align our thoughts and ensure a cohesive and well-structured presentation.
Utilized previous reports: Building upon the groundwork laid in our previous reports, we gathered relevant data, research findings, and project milestones. This enabled us to present a comprehensive overview of our project’s progress and accomplishments so far. By referencing our previous work, we ensured that the presentation remained consistent with our overall project narrative.
Leveraged material from other courses: Drawing from the knowledge gained in our CEO Toolkit and Public Speaking courses, we incorporated best practices in communication, presentation techniques, and storytelling. This approach helped us craft a compelling narrative, engage the audience effectively, and deliver the message with clarity and confidence.
By combining insights from multiple sources and aligning our team’s efforts, we created a presentation that not only showcases the hard work we’ve put into the project but also highlights its value and potential impact. With a well-prepared presentation, we are confident in our ability to impress the course instructors and effectively convey the significance of our project’s contributions.