Fortunately, Playtech was happening this weekend and we had a chance to playtest the game with more people. Things worked out better than we planned: we managed to have 18 people playing at once. The mechanics seems to work nice too!

We changed the game mechanics to act like a sort of soccer. The first prototypes still used the old controls, which were not very responsive. Also, allowing users to drag and rotate the bars in their phones overloaded the websockets communication.

We playtested with some friends and got to a simpler solution: use a simple swipe to move the objects. That way, the data would be sent to the server only when the users released their fingers.

Research
We spent weeks wondering about our proposals for this project and taking a look at different technologies that could help us — timbre.js, d3.js and SVG paths.
Then , we decided to go for the Lemmings idea and build it in one day, in a sort of hackathon.

Development
We split the team in server and client-side. Apon built the whole websockets communication and I started to build the game engine and visuals using a physics engine called matter.js.
It was hard to mix a physics game with Lemmings, though. The bars were terribly hard to control in a gravity-based simulation. We experimented with lots of different game mechanics — get the balls with the bars, hit the balls etc — and ended up removing the gravity from the game. Even so, the controls were not responsive enough:

a) Worm Tunes
A visual music synthesizer, inspired by the amazing Patatap. Users can draw their musical “worms” on their phones. Shapes and curves would be translated into sound and then plugged to the last segment of the collective worm. The final result would be a collective piece of music and drawing.

b) Help the Tribe
A Lemmings-like game. Users control virtual bars from their phones and should help the “tribe” — a bunch of rolling balls or polygons — overcome the obstacles and reach the final goal.

SketchesA) I started to experiment with the visual representations for the activity/timeline part. These first sketches are just an attempt to check if the data parsing is working right. Also, I needed to find a way to map the bars position to the position of the day in a month — the first sketches were just drawing a sequence of days, no matter how far apart they were.

B) Though those experiments were useful in help me deal with the data, I felt like I was falling into the same technical-looking dataviz the I wanted to avoid. So I tried to change the direction completely. These sketches are trying to give the user an overview of the transactions, instead of a time x transaction representation:

The bubbles are definitely not useful to show precise comparisons. Also, they can’t represent changes through time. Even so, I felt like they worked for a macro view of the data — and general comparisons.
I used a box2d, a physics engine, to position the bubbles and make them move.

C) I went back to the timeline and tried to make it look better, too. My idea then was to make both visualizations in the same screen. The users could have a macro view of the data by looking at the bubbles. To see the detailed activity, he/she could expand the timeline and change the focus to it.

For that idea to work, I had to change the bubbles size when switching to the timeline view. This way, they become sort of buttons/legend to the timeline, instead of a visualization:

However, the line graph is not that easy to see, particularly when compared to the bubbles solid colors. So I changed the timeline to draw an are graph — which was very time-consuming. On the line graph I could just map the transaction amount to the y coordinate. On the are chart, though, I had to sum up all transactions for each day:

FinalI uploaded the last sketch and got some people to test it. Some problems I could quickly fix:
– add a button to switch between the timeline and the bubble view. Clicking on the timeline to switch the views proved to be misleading. Most people clicked thinking they would get details about the transactions, not expand it.
– add the money values to the bubbles. Simple and absolutely necessary.
– clicking on a category/bubble deactivates all other. Though the possibility of comparing different categories was useful, the work to deactivate 30 of them before that was just too much.I think the the final result still needs a lot of improvement. I’m not sure if having the 2 views on the same screen was really useful. Also, the timeline comparisons should allow for a time-span navigation — see full activity, months or weeks, for instance. And each of them should show the aggregated data for that time span.

To sum up, I don’t think this is the final form of the app. The interaction part is still very simple and doesn’t take in account the full app navigation. Also, the visuals are far from the simplicity of the bubble part, and a lot harder to compare at the same time. Anyway, I think it was a useful experiment in trying to visualize this data.

After successfully parsing the data in Processing, I decided to switch to javaScript. I thought it would be easier to connect with a server and output as a mobile app in the future.
So I started to make quick sketches of how the budget part should look like, using regular javaScript canvas.

As I’ve written before, I was interested in making this representation as simple as possible. So I avoided any scale or other technical look. Instead, I tried to make the motion give a clue of what the colors and shapes are about — overspent, money still left etc.

Acquire
First I thought about categorizing all my myself, by copying and pasting the activity from my Chase account to a Google Spreadsheet.
That turned to be a hard and slow process. So I got a Mint account to help me with that. Though some spendings were categorized wrong, it definitely saved me a lot of time. After that, I exported the results to a .tsv file.

ParseI made some quick sketches in Processing just to get a sense of the data an possible problems I could have parsing it.

For the two sketches, each column is a day, and each rectangle a transaction. They are dimensioned according to the amount of money.
In the first sketch, each line represents a month. In the second one, all data is on the same visual level, and the vertical lines sign a month change.