Dine — Enhancing the Dining Experience
Dine is the result of a 10-week project assigned in CSE 110: Software Engineering, a course at UCSD in which 10 students are put into a team and responsible for a full software development cycle. Dine was voted first place among 19 other competing applications (representing 190 students) for best design, functionality, and presentation.
CSE 110 was designed to teach students about software development methodologies (waterfall, agile, scrum, etc), design patterns, design principles (loose coupling, high cohesion, etc) and let them apply these concepts to a hand-on project from scratch. Students functioned just like a typical team in industry: they each had their unique expertise, role, and work style. There were 200 students enrolled at the time I took this course, making up 20 teams, which were then divided into 4 ‘divisions’. Each week, teams within a division met with our Professor Gary Gillespie to get his feedback on the current progress. At the end of the 10th week, each team would deliver and present their product. The winner of each division would get to compete with the winners from the other divisions at the final round. Although there was no restriction on the allowed technology, professor Gary asked the teams to stick to the ‘restaurant’ theme, explaining our appropriate project’s name.
First thing first, I needed a team. I had several friends who were interested in joining, but we only made up half of the required headcount. Ankush A., one of my close colleagues, was also in the same situation. We joined forces. It was quite convenient because the friends I met through this team also worked with me during hackathons and outside-class projects. Ankush and I were interested in management roles and wanted to put our skills to test, so I expressed my interest in being the Project Manager and Ankush, deputy. We carefully studied each our teammate’s expertise and put them into subteams, each responsible for an aspect of the project. The subteams were Database Team (Aaron A. & Angelique C.), Algorithm Team (Elle. N & Alex T.),Front-End Software Team (Josh A. & Brittany F.), and User Interface Team (Michelle W. & Kevin T.). Ankush and I spread our effort helping teams that needed extra assistance during different instances of the development process. The intention was that each subteam could function independently without having to wait for others to complete their tasks. For instance, the Algorithm Team just needed to specify what data and structure they wanted to query from the database and the Database Team could proceed with the agreed design. The Database team could work simultaneously without having to wait for the best algorithm to be constructed.
Our team spent the first week deciding the features of our application. Since several members knew iOS programming and I strongly preferred iOS over Android, our team decided to pick iOS as our platform. This decision, as it turned out, gave us a competitive edge over other teams since there were only 2 teams, ourselves included, that developed on iOS. We did not have a name for our application at the time, but we envisioned it to enhance the dining experience (this was our tagline!).
The inspirations for Dine came from a collection of nitty picky problems we personally faced when visiting a restaurant. Whenever I looked at a menu, I would always pick the item that had the most vibrant, standout picture. We thought that if we could replace the paper menu with a digital one that included more (Instagram-quality) pictures and (way) less text, the diners would have a better ordering experience. At first, I wanted to keep our team focused, so I suggested building our application around this core feature. We had already spent countless meetings failing to agree on a set of features to implement, so I thought this approach would make sense.
The Database team immediately went to our restaurant of choice, BJ’s, website and scrape their entire menu (pictures, price, nutrition facts, descriptions, etc). The data were then structured according to an agreed database schema and stored on Parse. The Front-End Software team could also start to design how the pictures of the menu items would be presented. While waiting for the Database team to get all the pictures and successfully return them (which was a real challenge), the Front-End Software team used dummy data to proceed with their process. They also specified how they wanted to receive their images in a 2D array, giving the Database team a goal to shoot for. Again, each team could function independently without having to wait on each other, preventing delay in development.
With the influx of data and the inspiration from LA Hacks, we decided to implement a new feature: a meal-randomizer that utilized the iPhone’s accelerometer to suggest a random meal combination based on the users’ price or calories constraints. Once the user shook their iPhone, the accelerometer would be activated, giving some data which the Algorithm team would then use to determine menu items to suggest. There were well over 100 items on our database, so it was quite a pressure on our algorithm to efficiently search through the database and query appropriate results.
We were 7 weeks in, but all we had were a really nice menu and a meal generator. Everyone was worried that would not cut it for the competition. This was when I realized holes in my management plan; I should had had a better estimate of what features could be implemented during what time frame. The subteams still did not perfect their tasks; there were too few features; too many artifacts were not updated; not everyone was on the same page with the design the UI team came up with; and then HackUCI happened. Team’s morale was all time low. I panicked inside. I failed to foresee all these events.
I figured the most important thing was to boost morale and regroup. I found a tool called Flinto, which the UI team used to mock up our application with purely PNGs. Ankush and I were on the hunt for new technologies to implement new features. We came across iBeacon and AppLinks. iBeacon is a Bluetooth Low Energy device that constantly broadcasts signals, which could be picked up by any iOS 7 device. We immediately thought that we could determine the proximity of the phone with a beacon. After digging the web, we found a beacon simulator, which was essentially an OS X program that utilized the MacBook Pro’s Bluetooth chip. We immediately studied this technology and implemented a feature that we call “the Q”. Imagine there was a beacon at a reception of a restaurant (simulated by the OS X program in our case), when a user’s phone was in close proximity, the application could ask if he/she wanted to be added to the restaurant’s queue/waiting list. The user could also check their position on the queue at any point in time.
AppLinks was a relatively new technology introduced at the Facebook’s F8 conference several weeks before. Although there were very little documentation, Ankush and I managed to use AppLinks to implement the payment feature by integrating Venmo. For the first time in iOS, we could seamlessly launch another installed application, Venmo in our case, from our own application.
Things started to fall into place. I was definitely more assertive on the deadlines for each subteam. We had long coding hours most days. By the beginning of week 10, we had successfully put together everything we needed, from the application itself to all the artifacts we documented along the way. While Ankush and I were preparing for the upcoming presentation, we expressed our struggles leading a team of friends and/or apartment-mates. I personally witnessed how disastrous it could have been if I was not more assertive. Learning especially from Ankush and my teammates, I definitely felt more confident in my leadership skill; I learned about the thin line between friends and teammates. If a leadership opportunity arises in the future, I will definitely take on the role and apply what I have acquired from CSE 110 to yield even better results.
The division round came. We were up against 4 other teams in our division, one of which was the other iOS group. Their application’s concept was quite similar to ours. Ankush and I went up to present first; our strategy was setting the expectation bar as high as possible, making our product more memorable. Unfortunately, Ankush and I did not feel like we made a great connection to the audience. The presentation was too button-up, according to our teammates. We managed to pull 40% of the voting pool, though, and entered the final round the week after. Interestingly, there was a tie between 2 teams in another division, resulting in 5 competing teams for the final round. We took our final exam before the presentation; shortly prior to that, we had a chance to chat with our professor Gary, who warned us “the competitions [were] quite steep!”. Realizing we were the underdog for this round, Ankush and I put a lot of effort into our presentation. We went first, again, and delivered a more interactive, audience-oriented presentation. While the other 4 teams did a very good job with their projects, we felt like we had a stronger presentation. We pulled a total of 37% of the voting pool; we actually tied first place with another team, who integrated augmented reality technology… However, they fell short during their presentation.
CSE 110 was definitely a breathtaking and emotional ride for me as the Project Manager. I learned and grew with my colleagues. We preserved until the end and brought home a project that we would remember for years to come.