Software Interface Decisions

A project log for The Open Bar

A robot with a web GUI that can autonomously mix and pour cocktails

Dillon NicholsDillon Nichols 04/21/2016 at 20:340 Comments

Early on, it was apparent that this project would require some sort of GUI so that the user can easily select a drink. We wanted something mobile-focused so that users can select their drinks from anywhere in the bar instead of waiting in line at some sort of kiosk. We decided to create a website instead of an app for a few reasons. Number 1, it’s a lot easier to get started using a website over an app. In our case, we have a QR code that, once scanned, loads the website directly, and uses a URL parameter to distinguish between users. We didn’t have any use cases that required the phone’s camera or bluetooth access, so we did not require the use of an app. This increases the user’s ability to get in quicker, because they do not need to get into their app store and download it first. Number 2, it’s a lot faster to implement changes and have all users up to date. This is really important in the early stages of development. And lastly, it will run on any device. Be it an android phone, iPhone, or tablet or any size.

I started on the software side of things at the beginning of 2016. I’ve had an interest in web development for a long time but have never created a large project on my own. I heard good things about the Angular framework, so I decided to use that. At the time, Angular 2.0 just started in beta so I thought it would be interesting to begin a new project with that. I followed the 5 min quickstart and tour of heroes tutorials and they were very helpful in getting started. I loved using TypeScript since it is a compiled language, which is very uncommon in web development. Atom is a great IDE with support for TypeScript. After completing the tutorials, I started on my own project. You can find that code on my personal Github. The branches on that repo are mostly the previously mentioned tutorials, but some of my new code is in there too. At the time, I was frustrated with the online support for Angular 2.0 and could not get very far with the project because I was so new to web development as a whole. I guess that is what happens when you decide to work with a project that is in beta. Due to my frustration, I made the switch to Angular 1. There are almost an endless amount of tutorials and help online for this framework, so I had no trouble progressing at a fast pace. I now feel comfortable enough with Angular that I think I could go back and work with Angular 2 on my next project, but I have no reason to change The Open Bar’s interface from Angular 1 to 2.

The source code for The Open Bar’s interface can be found on github. I started with the full MEAN stack because a coworker was using it for a project and he was very fond of it. Although I started by using Express for my page routing, I moved away from it and started using Angular’s built-in routing about halfway through the project. Right now it’s a Frankenstein of routing methods, but it would be too much work for hardly any benefit to move to exclusively using one. In the beginning when I was using express, I was also using Jade for my templating. I have a pretty extensive knowledge of HTML so learning a new language to do something that I already knew slowed me down. All of the recent view code is written in HTML and I have no reason to go back to Jade.

I also knew early on that I wanted to host using Heroku while the app was in development. I love that it uses a very similar command line interface as git, so I don’t need to learn something new to get working. I’ve also set my Heroku up so that it watches for changes in the master branch of the git directly and will automatically pull in changes as soon as they are available. This also enforces the use of branches in git for developing new code. I’m using a mLab MongoDB heroku add-on for my database storage. It allowed me to get started very quickly without any knowledge of databases. It’s a lot more powerful that I need for the simple databases that I have, but I appreciate how it’s linked to heroku.

Originally I was using Mongoose to query the database directly when I needed some information. It is incredibly powerful, and because of that, I had a hard time learning how to use it correctly. I only needed simple queries, so I moved to using monk and was impressed at how much easier it was to use for a database newbie. Eventually, I wrapped the monk database queries in an API. In a way, this slowed the application down because there was another layer of abstraction to the database queries, but I think it will allow more flexibility in the future (which I hear is bots in chat apps). I also wasted a lot of time changing my database’s JSON structures because I jumped into coding without really figuring out what I was doing first. For something as important as databases, I would suggest thinking through it a lot before getting started. Something that tripped me up for a while is the idea of accessing the database collections asynchronously. In my case, we have to access one collection using the user’s information, and then use some of the returned information to access another collection. I used Angular’s $q service for promises and deferred objects.

As I mentioned before, users have their own URL parameter that is stored in a QR code which acts as their access code to store their drinks. I spent a long time trying to keep the URL parameters in sync between pages until I found ngStorage, which I used to store the URL parameter locally, so it is persistent across pages. It was incredibly easy to use and very powerful and simplified my logic a lot.

As many other websites do these days, I used bootstrap to make my pages responsive. It’s super easy to use and just works. Unless you’re a designer, I don’t see why you would want to deal with all of the display logic on your own.

For a long time, I struggled with separating out the model, view, and controller. This is a very different point of view than I’m used to. After I wrapped my head around it, I loved the ability to create files that exclusively touched one part of the project and was able to link them together to create a pretty complicated puzzle. I could create a service that only deals with setting or getting the user, or only deals with the getting the drinks. The same thing goes for controllers that work to display only certain information. There’s a controller that displays the list of drinks which is used in two separate HTML pages by including that controller.