Movtrak is an android application that allows users to save, collect, and talk about all the movies and shows that they've watched.
I lead a team of 4 in designing and developing this application for a client. We managed the project via the Agile method, reporting directly to and updating the client on progress. Phases of this project included ideation, UX + UI design, research, requirement gathering from the client and potential users, implementation, and testing.
This project was built using Java and the Android SDK on a Git repository. Mockups of the design and prototyping was done using Photoshop and inVision, respectively.
View the source code here.
We had 10 weeks to deliver on the requirements of this project, from start to finish. First, we met with the client to determine the requirements and a realistic scope for this time frame. The goal was to create an android application that would make it simple and delightful for users to store, share, rate, and write notes on the movies/shows they have watched.
Once launched, some of the metrics we would use to gauge success were:
- daily active users/monthly active users
- time spent on the app
- average number of saved movies per user
- average rating of each saved item
- percentage of items saved that had notes
- success of search functionality
- time spent on search
- number of items saved from search results
- number of searches in a given session
defining the user
We, along with the clients, decided that our target audience would start with college-aged young adults, who were actively engaged with media. This person would watch at least 1 movie/show in any given month, and wanted a place to record this experience for personal or social reasons.
We then created user stories for our determined scope of the application. We chose a few to tackle in our first sprint. These included the following:
- As a user, I can search for a movie/show.
- As a user, I can view a page about a specific movie/show.
- As a user, I can add or remove a movie/show from my collection
- As a user, I can rate a movie/show on a scale of 1-5
Starting with with the user stories we had created in the planning stage, we created a user flow diagram to determine what pages were needed. I was personally heavily involved in the design stages. I sketched some ideas of the pages by hand. We discussed the tradeoffs of the options as a team, then I created mockups and played with colors.
The mockups were created in Photoshop, then made interactive in inVision. I tested this prototype with the team, as well as the client. We did additional usability testing with fellow students at Penn. Once we had the main components, I tested details such as color schemes, button shapes, etc. on different people as well. We wanted the product to be easy to use, and novel but not jarringly unfamiliar.
We then set about building the user interface itself using Java and the Android SDK .
We started developing the app iteratively, making sure to complete each set of user stories' functionality before demoing them to the client and making sure we were still on the same page. We all worked on a shared Git repository, taking ownership of certain tasks and contributing to different aspects of the application.
We decided to use the IMDb external API to access a database of collection of movies for the application. This would allow search functionality, as well as the addition of non-random movie items. In other words, the user would only be able to add movies that actually existed in the database.
We used several different data structures to store the data locally, and implemented several sorting algorithms with which a user's collection of movies could be sorted. All the functionality of the application was written in Java.
Testing the code was different from what we were used to. This application was super visual, which allowed us to test almost all visually, rather than via unit tests, etc. This made it simple to determine whether we had fulfilled the user cases we had set out in the beginning, but also made it more difficult to think of extreme corner cases the more code we wrote. We made sure to keep an ongoing list of edge cases based on potential real life scenarios to test on each iteration.
for the future
During the course of this project, I had noticed room for improvement in several areas. Working together in a group of people who are very busy is never easy, but communication and meeting frequently was crucial when multiple people are responsible for contributing actual code.
I didn't start off leading the team, but not long into the project it was clear we needed more structure and direction. Leading without any authority or official title was definitely not clear-cut. It was a lot of understanding what each person's strengths were and what they wanted to get out of the project.
Keeping the clients in the loop during the entire process was super crucial because each time we presented, we were given feedback or tweaks to the requirements that we could not have forseen from the start. Working iteratively, and checking in constantly with the clients and getting user feedback allowed us to create a much more meaningful and successful product.
The future of this app is to add more modes of media to the application, such as books, which introduces new user experience problems to solve.