Process
We began by brainstorming different forms of data we could try to represent. Among others, we looked at weather, health, personal finances, economics, etc. In the end, we chose personal finances since we felt that it would be the easiest to work with in terms of the kind of the data we would have to deal with.
At this point, we then starting focusing on ways we could symbolize some aspect of personal finances. We all ended up focusing on budgeting - and how difficult it is to actually do. So we chose to try a slightly more psychological approach to helping people do so - a small, continuous reminder of the overall amount of your month's budget you've spent so far.
Once we achieved this point, we chose to focus on different visualization techniques we could implement to help us achieve this goal. We thought of a variety of approaches ranging from simple LED balls to a piggy bank that made the sound of falling coins when a transaction occurred. In the end, we chose to keep it simple, and simply have pennies that fell, with the amount remaining a symbolic reminder of the remainder of your monthly budget.
We iterated over a couple of designs for this, considering the use of pennies, and a basic servomotor. Initially, we began with a relatively simple design, essentially a flat funnel at whose mouth waited the servomotor. As transactions linked to the account occur, the motor releases coins based on pre-planned spending thresholds.
One issue we ran into in this design was that the pennies kept getting jammed at the mouth of the funnel. We brainstormed a few changes, including making the frame asymmetrical, so pennies would not get stuck against each other. In the end, we reduced the space the pennies could take to be a simple zig-zag path, one at a time. This simplified the process for us a lot, since we could control the exact way the pennies left the frame. We also chose to give the path a back of acrylic above the wood when we realized that it would help the coins move more smoothly. To achieve the proper open time of the servo at the bottom of the funnel (4 coins per boundary for 16 coins, we created a separate program) that did not rely on a transaction to activate the servo.
From a software side, we initially ran into issues on preventing the coins from deploying on a continuous basis. We needed it to continuously check Buxfer, but we couldn't have the software pulling data & implementing a coin-drop continuously. Thus, we chose to set up borders (in the example case, with a budget of $1000, borders of $750, $500, $250 & $0), and implemented flags to ensure that these borders would only be crossed with any effect the first time it happened. This also ensured that if multiple boundaries were crossed, the servo would open that number of times.
Another issue was occurred was related to asynchronous tasks in the code. Essentially code was executing before the Particle cloud webhook had a chance to return data and update the budget balance. This was solved by putting our conditional boundary logic that activated the servo into"void handleBudgetReceived(const char *event, const char *data)", which had the effect of only evaluating the budget state once the webhook returned data.
