In collaboration with Apon Palanuwech.
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!
In collaboration with Apon Palanuwech.
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.
To play the game, go to www.apon.io/live/pelada on your computer. Then, access the same address in your phone.
In collaboration with Apon Palanuwech.
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:
In collaboration with Apon Palanuwech.
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.
Data
Changing to javaScript took me a while to load the data. I ended up using node.js and a specific module to read csv/tsv files. An then I translated the same parsing I have written in Processing to javaScript.
Sketches
A) 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:
I experimented with a dark background, too:
So far, the interaction was:
– click/touch on bubbles select/deselect it.
– click on timeline expands/collapse it
Final
I 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.
You can access the current version of the app here.
And download the code/check the other experiments here.
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.
Parse
I 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.
Information Architecture
I started out by sketching the app’s architecture. I wanted to have something as simple as Level for the main navigation. But also add some meaningful visual representation for the activity part.
So my goal after that was to work on those two basic parts in separate. First, I’d have the “budget” part, pretty much like in Level, but with different visuals. Second, I’d have the full activity — income and outcome —, focusing on comparisons.
Sketches
I’ve started with very rough visuals for each part, then:
Research
I started by checking some relevant financial management tools. Most mobile apps for finance ask you for the painful task of inputing every little amount of money you spend. And they don’t give you much in return, besides visualising the data you categorised yourself. Two services seem to be a breakthrough from this concept.
a) Mint
A web-based tool, founded in 2006. Mint categorises your activity automatically. It also set up some budgets for each category, which you can adjust. Though it is claimed to be a tool to help make personal finance simple, it has a lot of features and visualisations that look too technical — considering the goal of this project.
b) Level
A recently launched mobile app, Level is claimed to be “Mint for millenials.” Level is based on a really simple equation: income – (bills + expected savings) Based on that, Level gives users a total “spendable” for a day. The concept is really interesting and the visual part follows the minimalist concept:
Users have the option to check their activities too. This part is disappointing, because Level doesn’t care about categories at all. However, the idea of having a simple, straightforward way to track your money is very good.
Idea
A simple personal finance mobile app. The user should be able to see earnings and spendings.
Data
Ideally the app should connect to the user bank API. For midterm, though, I will use a static file with my own bank history.
Interaction
There won’t be any user interaction to categorize or input data. The idea is that it should be done automatically by the app — I might work on it in the next stage of the project.
The user interaction will be used for navigation only — detailing, zooming into categories, scrolling through history etc.
Visualization
I want to make this app look as less as possible like a data visualization. Though dataviz has been claimed to be a tool to engage people with data, I think that the mainstream aesthetics in the field has done the exact opposite. Over-detailed, technical-looking and complex visualizations have made data less accessible to most people.
These are some sketches for a still very rough idea of what I have in mind.
Gabriel 