Inspiration

This app was inspired by a classmate whose younger brother has Autism. This classmate pitched an idea for a phone app that would allow people to take and upload photos to the app, as well as share their gallery with other people. This app allows not just people with Autism, but people who are non-verbal or have difficulty communicating, like stroke victims, to easily communicate with people around them.

Users can access all the photos they would need in a small, light smartphone. This is much more mobile than carrying a heavy photo album, which would be the other alternative. Additionally, it has special capabilities that set it apart from general photo-storing apps (read more below).

What it does

This app has an intuitive, easy to understand interface. People can upload photos from their camera roll to their gallery in the app. People can then divide their photos into different categories, which they can customize. On the home page, there's a search bar that users can use to search by the image's name. They can also filter by categories using the drop-down menu next to the search bar!

There is also a gallery sharing feature (think of Google Docs!), so people who need to view the same gallery can have access to those photos. The gallery-sharing feature is especially useful and sets this app apart because it allows for use cases such as in physical speech therapy. A family member could securely share their gallery with the speech therapist. Another use case is families who have a non-verbal child - They can share their gallery with the teacher at school, and the teacher needs to simply install the app and log into their account to gain access to the gallery!

How I built it

Our team built the app with the frontend being React Native, and Django framework for the backend. We used an SQLite database because everyone was familiar with that from previous classes.

Challenges I ran into

The biggest challenge we ran into was working as two separate teams. We had a frontend team and backend team because of the way the class was designed, also to better organize our large 8-person team. It seemed to make the most sense to just split the teams in that manner.

However, this sometimes made communication difficult because frontend and backend would organically work at different paces, one team sometimes moving faster than the other, so this affected us later when we would try to integrate frontend and backend. Sometimes frontend would be redesigning a portion of the UI that we were ready to test by tying with our endpoints, or we were still debugging an API endpoint that frontend wanted us to integrate with the UI already. (This means combining the UI from frontend with the functional API endpoints from backend so that when we ran our app in the iOS simulator, when we clicked something on the UI, it would actually execute actions. A good analogy for this for non-technical people would be like building a house. Think of frontend like the beautiful wallpaper for the house, the fancy faucets, the overall design of the house. The backend would be the actual pipes that connect running water to said faucets, and electricity and wires that would power the house.)

The next challenge I ran into was learning how to exactly integrate frontend and backend. Although I have experience with frontend, I have never had to directly tie the frontend and backend of an app together. Also, I have worked with React Native/React and python, but separately. The kicker was figuring out how to connect these two different languages. This was a very large challenge I ran into, but reading more about serializers, Redux, the store, and actions helped illuminate the fog a bit. It also helped a lot to have a partner who was working on the same portion(s) of code as me. We would bounce ideas off each other. Pair programming really helped with this portion of the code. We also wrote our own API end points.

Of course, as a team, we overcame both problems. For the communication problem, we simply communicated openly as a group in our Slack, to ensure that everyone was on the same page. As for the second challenge, it was nothing a few group coding sessions couldn't fix. We found that meeting up in person worked best to knock out tying frontend and backend. (I would like to thank the teammates who made time to meet with us and code on the big TVs! I am impressed by your work ethic.) By our Beta Release, we successfully tied frontend and backend and had a working MVP! Our professor said we exceeded expectations, and when we had to deliver Omega and our final presentation, I could tell he was still very impressed. =)

Accomplishments that I'm proud of

I'm very proud of my collaborative ability to work with other people. Even when our group was tired of trying to figure out a particularly difficult bug, I maintained a cool, calm demeanor. It is not useful to complain, because it needs to be done. So, I would speak in a positive way and reframe situations so they do not seem as dreadful. For example, I will say, "Don't worry, that won't be too bad. We've done this before," if we have some part of code we know we need to write. I won't say, "Yeah, this sucks!" or something like that. I'd rather say nothing at all if it's going to be negative. I lead our team by sticking to our coding session plans and (hopefully) inspiring my team members to work by working hard myself. They may exude an air that suggests they want to leave, which is understandable, but I will stay strong and exude an air that says, "We can do this!"

I am also proud of my ability to admit when I am wrong or ask for help if I am confused/lost. I am not afraid to admit that I do not know something, or have made a silly mistake. I believe this made our overall group atmosphere a lot calmer and less intimidating, as we are essentially a group of strangers who must work together with the commonality that we are passionate about accessibility. Because I am always doing my best, I do not feel bad even if I made a mistake. When my team members point out a mistake I made when writing code on the big screen, I correct the error and thank them for catching it. These small, quality acts determine our overall group relationship, so it's important to treat my team members with respect at all times. Life doesn't come with instructions, so I make mistakes! =)

Third, I am proud of my substantial contribution to the project codebase. At the beginning of our project, when we were debating what our tech stack would be, I offered some ideas. When we collectively decided to create a Django app (originally we wanted to use Flask), I set up the entire project directory, admin site, and a few test models. After our entire team was brought up to speed, I attended almost all of the group meetings, writing a lot of the code base during these sessions. I also met with our unofficial backend team leader, pair programming with her to ensure we were on a good track for our Beta Release deadlines. Even though our team had a flat structure, in that we were all peers, I would best describe my position as "second in command," to our unofficial backend team leader, who I would describe as our unspoken leader.

Finally, more generally, I found that I am the kind of person that is capable of navigating professional relationships with all kinds of different personalities. The key is being calm, using neutral language, and to always frame things in a way so that people do not feel attacked. It is not what you say, but rather how you say it. I maintained cordial relationships with all of my teammates. I find it also helps that I am the kind of person who generally leads by doing, rather than talking. Action is more powerful than words sometimes. Make sure your actions are moving you in the direction that you want to go in. =)

What I learned

The lessons that I learned... Let's dive in.

1) A good tech stack for making cross-platform apps is a React Native frontend with a Django backend. We chose to use React Native because we have all worked with JavaScript/React.js. We also learned that it was excellent for making cross-platform apps, as we managed to get our app running through localhost on both actual iPhones and Android phones for our Beta and Omega presentations. We initially used Flask due to all of us having experience in it from EECS 485 (Web Systems), but upon further research, it was decided that we should all use Django because it offered the same functionality with the added ease of taking care of our database for us, as well as having an admin site to visually inspect our tables. If we had only researched more at the beginning of our project, we would have started with Django and it would have saved us time and effort.

2) Spending a lot of time to plan out the architecture of your code is ultimately more time-efficient (avoid wasting time fixing technical debt!). It is crucial to properly plan out the code architecture, database schema, and such of your application before actually diving into the coding. As the person who actually designed the database initially, I made the mistake of not using foreign keys to connect objects in our database. Thus, when we deleted a user or made some changes, our database became out of sync. We then had to redo our database before Beta release, which was time that could have been utilized to work on other parts of the project had we done a better job initially. It also taught us the importance of following UML class diagrams and ensuring that our database relations did indeed reflect the diagrams we designed.

3) Good communication between team members is essential to the success of a project. The reason why I say this is because our team experienced a lot of difficulties tying frontend and backend due to breakdowns in communication between frontend and backend. Although this was frustrating, it definitely strengthened our backend team's internal bonds, as well as individually making us more respectful communicators to each other, more cognizant of how we speak to one another. This translated to our team having much better communication within ourselves, and when we met up in person, we were able to work very well together. That is actually how we overcame the challenges of tying frontend and backend; We would simply meet up and hash it out together. For that, I am incredibly proud of my team for overcoming the obstacles placed before us so that we had successful releases each time.

4) It's important to have clear, unique, function and variables names, as well as documentation! Finally, we ran into difficulties understanding code we wrote earlier when we were trying to learn and tie frontend to the backend. The reason is that we had similarly named functions. To be precise, we had: galleries_detail, galleries_to_images, get_all_home_gallery...! As a result, we had to spend precious time re-understanding the code, deleting the unused code, and editing the remaining function and its variables and other areas in the codebase that used such code so that we would not run into this issue again. This taught us all how important it is to really think about whether the names we choose for functions and variables are really as explicit and clear as they can be. That is, is the code I am reading conveying exactly what I mean to say, no more and no less? This is incredibly important for all of us as we enter the workforce, as we will be working on projects whose codebase will be much larger than the app we wrote for this class!

Finally, I learned that I love working with like-minded, passionate individuals who simply want to get together and CREATE. It is excellent when I can go to a place where I know people are ready to create and have fun, and we are able to throw ideas and use our brains. It is important to me that people are able to separate the idea from the person and not take inconsequential events personally. I enjoy a peaceful environment that supports creativity and intellectual discussion.

With that, I would like to close and say I am incredibly grateful for the opportunity to collaborate in such a large, diverse team of people, giving me a taste of what it would be like to actually be in the workforce. I look forward to what the future holds for me.

What's next for Project Jason

Project Jason is a stand-alone MVP app that will not be continued.

Share this project:

Updates