Documentation

1. Introduction

This is the report for our project “Phones Don’t Grow on Trees”. We decided to write this report in a way that would be interesting for anyone who wants to not only understand what we did, but also to get an idea of what problems arose during all of the phases of this project, which may help if you are working on or planning a similar project. If you have any further questions, do not hesitate to contact us, we are happy to help!

1.1. Who we are

This is project was part of the Bachelors program “International Media and Computing” (“Internationale Medieninformatik”) at HTW Berlin, University of Applied Science.

We conducted this project under supervision of Heba Y. Amin and also received extensive help from Baruch Gottlieb, who had previous experience with and personal interest in the subject.

The students who were involved in this project are:

Charlie occasionally speaks to extraterrestrial lifeforms if she is not busy creating great pixel art or designing stuff. She loves cuddling her cats and uses the energy she gets from that to do amazing things last minute.  

Lucie loves to organize projects and is the glue of our group. Someone should sing a song about her love for mustaches and coffee with too much milk and an unbelievable amount of sugar. She works in her dream job at the one and only open source database and was mostly concerned with writing, researching and programming in Javascript, which she she is not exactly a fan of. She tends to be a bit bossy at times even though she calls it efficiency, and it honestly helps to get things done.

Tim always holds the opposite opinion of whatever Lucie’s opinion is and if their opinions ever matched, it would certainly be a remarkable day in history. He works as a freelancer in web development, has multiple talents he was able to use in the project as researcher and working on various front-end functionalities.

Alex works in quality assurance at a big mapping platform. He speaks five languages fluently, which is not only impressive but also helped a lot with the researching, which he was mainly concerned with. Just to keep things fair, he needs like two month to grow a beard.

Sonja is from a country where they eat a lot of potatoes, which is cool. She is very warm hearted and has a great eye for design and the ability to break down complex things into the pretties infographics you will ever see.

Manuel is a web designer, who apparently lived long enough in Spain to get totally comfortable with the relaxed Spanish lifestyle. You could say: He is the God of Javascript, which is pretty good achievement in itself. He is also very tall.

Pepe has an awesome beard. He also has a very deep voice. We all love him. He did our back-end and he does something with the interwebs in the Oranienstraße in Kreuzberg. We never really bothered asking him what he is actually doing since we were too busy admiring his beard.

Soon after starting working together we realized that our skills were quite diverse, which already came in handy very early on in the project. There were designers - which is especially nice, considering we are mostly people with a technical background - and we just as well had front-end and back-end developers, which allowed us to cover any kind of task. We had to discuss many things but after figuring out, what task could fit to whom it was nice to see that there were someone for every task not only doing it but also being into the subject and their specific topic.

We think it’s very important to find a group that works together well and brings different experiences and knowledge together so you not only work with but also learn from each other.

1.2 Introduction to the project

When we starting working on this project, it had the working title “Conflicts and Social Justice in the Economics Supply Chain”, which sums up the idea of the project pretty good. We wanted to not only gather and share information on this very delicate topic but also make it easy to understand and relate to for anyone.

We all use electronic devices in our everyday life and take them for granted, but we rarely ever think about where they come from, what they are made of and what human stories take place behind the scenes of the production chain. There are some media reports covering this topic, but they often seem very distant to us and do not make us question our own habits or force us to have second thoughts about the fact that these stories are actually connected to the devices we carry with us and use every day. That is why we also chose to not name a brand or factory in particular in our visuals: It does not really matter what company or device you use personally, since pretty much all devices have a problematic background.

 

There are two main stories we focused on after a long process of researching and working ourselves through the data we gathered. Since we thought this report is the right place to bring up the stories we could not focus on anymore, you can read up on some of the things we gathered during our research phase and the struggles we had with those.

Bearing this in mind, let’s have a closer look at the things we ended up actually having on the website. First, there is the “Discover” part of the project, which gives you an overview over the materials used in an average phone (or any modern device). We thought about a way to rank the materials, so that users not only know what they are but also where they come from and what they are used for. Since we could not find all the data on all the materials, we decided to make it open for users to edit.

The “Game” part of the project is a text based adventure game, where you learn about the everyday life of a Chinese worker. There is no winning in this game since we figured that there is no good way of getting out of this situation, which we used as a way to emphasize on the situation of many workers in the tech industry in China. We additionally decided to not have a button that brings you back to the start of the game, so the user would have to go back themselves, putting more emphasis on the fact that in real life, you cannot undo your decisions and you will have to live with your past choices.

2. Research for comic and game

2.1 “Game part”

2.1.1 Coming up with an idea

When we first looked at the topic, it seemed huge. There are so many individual stories and they are still linked to each other. It seemed impossible to bring them all together, so we had to break them down. Some of the first layouts tried to bring everything together. We realized that it would be just too much and not understandable anymore.

Very soon, we decided we should have a part on the working conditions in the factories producing the electronic supply for our devices. They are in the media but somehow, you never really stick to their stories so you just have a vague feeling that something is wrong there. We saw a lack of identification with the workers who assemble and pack devices in the factories and we wanted to change that. That was a good starting point for us and digging deeper into the topic we realized there was a lot to learn about it, which kept us going.

That is where the idea came from to put a person in the middle of the story. We made her up and based her story on the facts we found in the reports and newspaper articles. There was a lot that we could not include in our story. We had to keep a balance to make the story not too long but interesting and the facts we gathered and wanted to include.

We first thought about having a webcomic, so you can read up the story yourself. However, we then decided that we wanted to keep the tone non-judgemental to let the users decide themselves. But we thought that the possibilities for a visualization on a website are bigger than just in a comic and it would not keep someone as interested as something you would interact with. That is how we can up the idea to tell a story by letting the user decide how it continues and give them a feeling of control that would allow them to possibly affect the outcome of the story. Nevertheless, and as mentioned before, in the story we are telling, there is not much you can change about the outcome, but at least there are different endings based on the actual circumstances in these factories.

2.1.2 Data

Our first approach to find something useful was to take a laptop apart to see what modules it has and where they come from. We thought we could find out from there what they are made from and where they are made. We checked the numbers written on the parts - such as the fan and CPU - online but we could not find anything about the materials that were in them. Or where they were pre-assembled. Even manuals were rare.

Then we wanted to see what the companies producing each module would say about it. We wrote mails and filled the question forms without mentioning the title of our projects, just telling them we are students researching for a project at our university. We barely got any answers. Most companies did not respond. We always mentioned the device we wanted information about and since the laptop we disassembled was over four years old we got one response they did not produce the module we were asking for anymore and therefore do not have any information on it. In conclusion, it is pretty safe to say that the only thing we really got from this is that we did not really get anything, which in itself says something about how difficult it is to gather data again.

We continued our research by reading through recent media articles. You would find much about working conditions in the factories producing for Apple but less about the other companies, which does not reflect the actual market situation. So we researched a while and then decided to focus on five companies mainly: Foxconn in China producing for Apple, due to them being one of the biggest companies for electronic products and the most represented in the media, Wintek [German Wikipedia], HEG technology and Pegatron [Link in German], also in China and a Samsung factory in Brazil, which we found especially interesting since most factories you find data on are in China and sometimes - though also only in rare instances - in Taiwan. This reflected in our choice on the factories, which we wanted to research on.

overview.jpg

2.1.3 Working with the data

For telling our story, we based our game on a report by China Labor Watch on HEG technology and a BBC article on Pegatron. The report by China Labor Watch was the most explicit one, giving exact numbers for things like payment and hours worked.

We did not want to mix up the stories too badly. Making up a super evil company by combining all the bad facts we found would make the story unrealistic and would not have helped much to inform people about the actual working conditions of an average Chinese worker. It may shock them more, but that is not the main thing we want to achieve, which is the fact that users should learn something and relate to the stories around their devices.

We started out by making up a Chinese worker called Mei. This was going to be the person the user should identify with. To emphasize this, we chose to talk directly to the user, using “you”. You, the user, are the one experiencing the story, that was very important to us.

The writing was a very hard process. We had to decide which scene should come when and which of the data we actually wanted to work with. As mentioned before, we wanted to keep a balance of all the facts that were important to us and the idea that the reader should not be too overwhelmed by all the information. The write-up also took a lot of time for the process of compressing and and splitting up the texts again and again, so that they eventually would  become more readable.

2.1.4 Infographics


We created some infographics to have an overview for ourselves on which facts we wanted to focus on. We had the working hours, which were really important to us because that’s something everyone understands easily.

workingHours.png

We also put a lot of effort into making clear for ourselves on how much the money the workers earn is actually worth. To get a feeling for it we looked up how much everyday items cost in China but also worked on a comparison on how much money is the average income in the Guangdong province in China, the region where the factory of our story is based.

In the following infographic, the left piles of money are the wage of the factory workers with and without bonuses in USD.

wageComparison.png

While we were looking into this, we thought it would be interesting to have a chart where you could see how the wage is actually distributed.

wageDistribution.png

One of the main criticisms of these factories is that often children are working there. We wanted to see how many children were actually employed there and used the information we had from the China Labor Watch report to create this infographic.

ageWorkers.png

We used the old figure that we had created for the comic and never changed it, since it never was actually included anywhere on the website.

2.2. “Discover” part

2.2.1 Finding data on materials

After we figured out which materials exactly are in the devices, we started to describe each of them in detail. In this case Wikipedia was very helpful to understand what exactly every element is, but still there was a lot of data missing about toxicity or harmfulness of every material. Only one of them had a “Conflict Material” label in description. So we started to dig deeper. We reviewed a lot of pages from different sources in different languages. The research was quite difficult because it is a very specific field of studies, however, the pieces of information were at least not as difficult to get ahold of as getting information on specific hardware parts from manufacturers.

2.2.2 Finding data on producing countries

Second part of the material research was to find out where all the minerals are mined, in what amount and by which countries were involved overall. This part was more difficult than the previous. The information in this case were gathered from various sources: Universities of Resources around the world, independent researches and statistics from Wikipedia and other online sources.

2.2.3 Working with the data

As whole text and numbers were collected and implemented on the project site we realized that there is too much information and users would get bored very quickly. We started to shorten unnecessary details and tried to show only relevant and compressed information. As a result, we ended up with three to five sentences for each material description on our main page. As a compromise to the size limitations, we decided to put a link to Wikipedia for each material, just in case if people wanted to read more about a specific material. During the research, one of the team members discovered very good video project on YouTube about every element of the periodic table and we decided to also include these video links in the description, since we figured a lot of people would prefer watching a video rather than just reading about a material.

For the country data, we also decided to reduce the amount of data we have to work with by only focusing on the top 5 countries of origin for each material, since usually, the top producers of each material made up the largest percentage of the total production in the first place.

This research phase gave us an understanding of how complicated and unfair the electronic supply chain is around the world and how hard it is to track this entire network, mainly because most of the information is very obfuscated and almost hidden.

2.3 The Responsibility Reports

2.3.1 The Data

During our research phase, we found that multiple manufacturers have been releasing form of “Supplier Responsibility Reports”. Apple has been following this practice since 2007; they use these reports to describe current state of and past improvements to the working conditions of workers in their supply chain. These reports were relatively elaborative and overall have the appearance of an advertisement, rather than being merely a dry summary of the situation, which makes it appear as if Apple intends these reports to be read by average customers.

We also found other company initiatives, one of them being the Intel Conflict Free Minerals program, which aims to inform people about the usage of “conflict-free” minerals in Intel programs. However, these initiatives and reports often put the companies that finance them in a good light while often using tricks to distort statistical facts which would have left a bad imagine on the company or the manufacturing process.

2.3.2 Importance and impact of the reports

We chose to work with these reports because they aim to largely reflect the company’s image and the efforts that are brought forward by them; yet their authenticity, reliability and generally the way these companies collect their data is rather questionable - mainly because these reports are created with a definitive interest of putting the respective companies in a positive light.

2.3.3 The Interpretation

The analysis and interpretation of the data were an important factor in the research process. We quickly noticed that often, companies would use questionable visualizations of their data and that they generally tended to overemphasize on success instead of pointing out issues.

There were also some ethical questions which we ended up asking ourselves, such as when Apple boasts that their maximum 60 hours of work per week are met 80% of the time, we started to wonder why nobody was raising the the question if 60 hours of work per week are not already questionable in itself. Apple simply sets 60 hours for these jobs are normal, and the basis for that number is not really clear and by far supercedes normal weekly working hours of the western world.

We also noticed that some terms were misleading. Intel and other companies used the term “Conflict-free” widely to advertise their products and their “progress”, yet they only refer to conflict within the Democratic Republic of Congo with this term, which is not clear to consumers and ignores all other conflicts or humanitarian issues surrounding the mining and the later steps of the supply chain of their products.

2.3.4 Difficulties with the visualization

Problems with the visualization arose already when collecting our data. There was no easy way to analyze these reports in an automated yet meaningful manner and we would have been required to prepare an extensive automated text analysis to achieve this. On top of that, the results of our work greatly depended on the analysis of images and on the greater context of the story. This made the analysis relatively time-consuming, especially if we had wanted to compare supplier responsibility reports from previous years.

Planning the visualization was one of the most difficult tasks of the project. We needed to make sure that we filtered, compressed and explained our findings in way that would not be too bland and boring to keep people interested while also conveying the issues in these reports properly.

3. Design

3.1. “Game” part

3.1.1 Difficulties in finding a design

We were faced with the task of finding a design that would suit all our needs.

First of all it was important for us to not get lost in clichées. We wanted to stick to reality as close as possible and not influence our story with our eurocentric views. We did not have a lot of information to go on and thus it was hard to not just fill the gaps with whatever we deemed fit. On the other hand, it was also important to us that the story would be relatable. It is often hard for people from western countries to relate to such seemingly distant issues and so they often experience it more as an actual story because the whole topic is so far away from their everyday life. We tried to counteract this by using story elements that anyone can relate to.

We wanted to touch the user emotionally but not in a cheesy way. It was important to us that the user does not feel pressured into certain emotions but that these come naturally. We accomplished this by not overdrawing the situations our character is in, while not making them too boring either.

To not confuse our users, we went with clear messages and story lines and consciously avoided metaphors and potentially confusing assertions.

In-line with recent web design trends, we tried to keep the design as minimalistic as possible so the message and the story would be brought into focus. We felt like the topic is already hard to grasp and we did not want any further distractions.

3.1.2 Use cases

The first use case was about a person who is completely uninformed and came to our page to find out more about the conditions in companies focusing on manufacturing electronics.  This is a person who will need to be intrigued as soon as possible, so we needed to make sure that the story is interesting in some way from the start. We did not want to overwhelm the user with loads of text either, thus the limit of 2 short paragraphs per slide. We created the eye-catching pixel images to grasp the interest of the users and to create a deeper connection to the main character Mei.

The second use case is the opposite of the first. It is someone who already knows a lot about the topic. maybe a journalist or someone who, for some reason, did some research previously. This person will probably not learn many new things from us so the only way to intrigue him is to make the game fun and offer a new perspective on the topic. This obviously can mainly be influenced by the gameplay. Our game is a simple text adventure but it packs a punch with unexpected turn of events and unforeseeable causalities.

The third use case is your average internet user. They read one or two articles on the topic and have a basic idea of what issues may exist. They are not overly interested to delve further into the topic but if the content is served the right way, they will be intrigued. This kind of user is basically a mixture of user one and two. He will need it to be interesting looking enough to intrigue him and not to make him bored, and have sufficient information to make it interesting.

For the last use case we considered a user that accidentally stumbled upon our page by following a link. This user needs to immediately understand what our page is about and it immediately needs to captivate him because the threshold of becoming acquainted with a new topic might otherwise be too high.

It was important to us to also link the two parts of the project visually so it would be clear that they belong together. We achieved this in two different ways. Firstly we used a similar layout and used the same colours. The other shared feature was the traffic light, bringing the two pages together. It was a bit modified in the game part, into also resembling a battery, but in it’s essence it’s the same thing.

3.1.3 The pixel art

The pixel art was relatively easy to create, it was just very time consuming, because there is no efficient or automated way to create those images. This basically meant that, more or less, every pixel needed to be placed individually. Another issue we had with the pixel images is that because of their nature they have very limited expression. This meant we were stuck with about 5 face expressions. An additional issue was that the pixel art cast every image in a “cute” light. We did not want the seriousness of the topic be distorted by the images, making the whole issue seem more harmless than it is.

As a way for us to counteract the potential downplaying of the issue we decided to place videos in the game as well. This helped us to remind the user that the issue is real and this is currently happening in the world, because it is easy to forget that this is not just a game.

3.2. “Discover” part

3.2.1 Research for visualization

First step of the research was to find which materials are used in electronic devices. We soon discovered, that it is not easy to find out which raw materials are included in the parts of various devices. For time management reasons, we decided to stay focused only on the most growing and popular electronic business - the smartphones.

After some research  on this topic, it was clear that although there are some differences in smartphones from various brands, these differences are not too significant, as most of the internal parts are bought from the same producers and thus made from the same raw materials. Therefore, we only took into consideration a generalized smartphone and researched what raw materials are included in a typical smartphone. We found a list of more than 30 raw materials.

Based on the list of the materials, we collected data online about the countries where each material is mined in, the parts of the phone where it is used, as well as some general information such as it’s characteristics and attributes. This data was used on the website to inform the user about each material.

Firstly we thought of scoring the materials based on the information we collected, which would mean based on a read text personally deciding which score the material gets. We turned down this process of scoring as it would be subjective and could not be automated. Therefore, we decided to do a research on already existing rankings of materials in categories that we have considered important to include in our score.

We discovered about 9 rankings that were relevant to our project based on an online research. Out of these, we chose 5 ranking that we thought had the most relevance to our project. If you want to know more about these rankings and why we chose them, see the Methodology.

We collected all of this data in a database which can be expanded by a user input. This aspect was important for us to include, as we wanted to show that this kind of data is not easy to find and therefore we would like to cooperate with as many people as possible to help us collect more information on this topic.

3.2.2 Design of visualization

Each material in our database is assigned a score. The initial idea was to indicate the score with a corresponding color. The color scheme was chosen from a traffic light, as “Red” color means to stop and therefore something that should catch our attention and “Green” color means to go and therefore symbolizes something where there is no complication. Hence, the materials with a poor score are indicated with red shades and materials with good score with green shades.

First idea was to display materials as colored squared in a smartphone, the size of the square based on the weight of the material used in a phone. However, this was not possible due to two reasons. Firstly, we were not able to collect data about the amount of materials used in a smartphone and secondly, the few data that we were able to find were in a very big range, from 0,001 mg to 25 g.

This is why we dropped the idea and decided to use mining carts, to also connect our website more to the idea of the materials coming from mines and the situation for the workers in those mines.

4. Technical implementation

4.1 Introduction (about the process)

After tearing down a consumer netbook, an Acer One of the first generation, we started searching for the serial numbers we found on the device parts. This was sometimes the only information printed on the device itself.

More than one result led us to this site, which offers an overview of the components that are used in the approx. 170 electronic devices listed, including information like: the location of the component in the device (battery, screen, …), its function, its diameter, weight, height and length. One of the most important fields is probably the link to the PDF datasheet of the component, where we were able to find some information about the materials. If available, the list of materials present in a component is expressed as percentage or range. Much easier to find are expressions like "Lead free", in order to understand which material is not present.

The datasheets were in PDF format and also not sufficiently uniform to be parsed once the text had been extracted with an OCR tool, but we thought the information provided by electronicproducts.com could have been useful even without using the linked datasheets.

We analysed the website in order to find the API providing the information. Once found it we wrote a script to parse the XML response.

The idea was to collect some more data about which material is being used in which electronic device in order to then go a step further and analyse where the materials are coming from and in which conditions they are being produced. The goal was to assign a kind of "fingerprint" composed of these informations.

The "fingerprint", representing the quantity of each material in the device could be simply visualized in many forms and since the information is related to a specific device, we also thought we could generate a visualization for each device and make this printable as sticker.

The flow of our first prototype was the following:

The user can select a device, then a visualization will explain how much of each material is used for which part of the device. The visualization was designed to be nicely printable on stickers.

Finding more data turned out to be much more complex than expected and we definitively realized that this lack of transparency is so huge, that it should have been an important part of our visualization. This was compatible with the idea of "fingerprinting" devices, since the fingerprint could be represented as incomplete, but we generally considered to put the lack of data in the focus of the project.

There are platforms like OpenFoodFacts which, in order to gain transparency, gather information about specific products, but a platform concerning electronics is still missing. At this point we thought that our visualization should explain how much information is actually missing and should prompt the user to take direct action against this serious lack of it, adding the information (if any in possession) or automatically contacting the manufacturer, asking for detailed information about the device the user is inquiring about.

Even if we found some other information about which materials are used in specific devices, like for example the Intel Material Declaration Data Sheets, we realised that it would have been too hard to visualize the data for each existent device without leaving too many fields empty.

The visualization would have been too vague this way and the project would lose its main attraction point.

Making a visualization using available data about which material is actually used in the production of a generic smartphone would have been a more suitable approach. This way we were also able to take it a step further by adding an important critical element to the visualization. We introduced a rating system for specific aspects of the materials used and for specific aspects of the countries involved in the extraction and production process of these materials.

4.2 The first frontend

Since we were working in a very iterative process we started to built stuff that we trashed when the concept changed. The project was also a nice opportunity to work and learn about new frameworks and libraries.

The first visualisation for the content of devices was built in React.js.

We had built simple selectors and filters to select a device and a very simple visualisation which used about 4.000 dots to represent a device. Every dot would be colored according to the material it represented it would also be clickable to unveil more detailed information about the material and the part it was used in.

We had implemented some functions that calculated the amount of dots and then created a very long list of li elements, one for every dot. If we would have proceeded with this concept we would have looked into more complex visualisations and better ways to create them like SVG or on HTML5 canvas. To realize the popups we just placed a div element inside the selected li element so it would always be in the right place.

We also grouped the components of the device (e.g. Hard Disk) together this is why the visualisation has colored dots (a material) and then black dots (part of the device but an unknown material).

In this first draft we already had placeholders for concepts like users inserting data and displaying missing content. But we still wanted to be able to print device specific stickers.

4.3 The backend

At this point we still had 4 different concepts. As different as they were three of them had the need to access data in some form. So we decided it would be great to have a central database and simple api to access this information. This would also then give others the possibility to add data and would create a central place to collect such data as we did not find a source for machine readable device data (about the materials).

The API is hosted on a DigitalOcean droplet, as the other parts of the project as well, provisioned using this Packer+Ansible script in order to get Ubuntu Server with Nginx, Node.js (through nvm) and MongoDB installed, configured and started.

The nginx server is responsible for serving the required static files (frontend) and proxy-pass requests to the RESTful API, the actual application server. The application server runs on Node.js and the Sails Framework is responsible for generating API entry-points based on the models we created, providing a fully CRUD RESTful API. A script converts the Sails.js models to YAML files compatible to the Swagger specification. This way we were able to expose an interactive and machine-readable documentation of our API using Swagger-UI and Swagger-Express.

This was really nice in the beginning since we got a working API really early on in the project phase but later it would get harder and harder to implement more complex API entry-points, which should for example retrieve data from a join request to the database.

At this point we had abandoned the concept of providing specific data for each device.

The data that we had collected was stored in various spreadsheets which we could export to CSV files. We then created scripts that would automatically read the data and push it to the database.

This way it was easy for everyone to make changes in the data since some of the research was still in progress.

We did not open up the API  to everyone though, in order to prevent abuses. To be able to create or update data you had to be logged in via OAuth. Passport.js is in charge of manage OAuth logins and these are possible via Github and could be easily extended to other providers.

This means that you have to be in possession of a valid Github account to be able to change data in the database.

GETs requests does not requires a login.

4.4 The second frontend

The front end to this API was also created with React.js.

We have some rating information about the material in the database, but we do all the calculation of our final rating in the frontend. The reasons for this being is that we see this frontend as only one possible endpoint to the API and others could do other visualizations and arrive at different ratings.

Following the Flux concept the page is broken down in components that are children or siblings of each other and receive data from a store and communicate through centralized actions.

We also use “stateless components” so all the data that a component has is passed down from a parent component. For the realization of actions and stores we used the Reflux.js implementation of Flux.

4.5 The data input dialog

Since Swagger.js provides for an interactive documentation but not a fully-fledged dashboard we needed to build a place where users could easily input data that would be added to the database.

This started out as an HTML page with jQuery which communicated with the backend through the API. Later we ported it to React.js components to be able to easily integrate in with the rest of the frontend. Thanks to JSX (the react preprocessor language) this was surprisingly easy to do.

We also created sliders to add weighting to the countries that a material was mined in.

The hard part about this was that all sliders together always had to sum up to 100%.

4.6 The “Game”

The game is a text based adventure with some sugar on it. So the main work is to display text, a picture and a list of possible actions. Once an answer is clicked replace the content with the next “Group” of text, picture and actions.

We created a JSON file which contained all those “Groups” as objects. Every object would contain the text, the link to the image and an object for every possible action.

An action object contains a text, a key for the object of the next “Group” and indicators how choosing the action will affect the money and energy of the player.

We also added nice little features like css blur effects when the energy drops below a certain level, checks that would not allow you to perform actions when you do not have sufficient money or energy and a counter that will get you fired when you leave work early too often.

4.7 Putting it all together in one page

The final web page is generated out of three different parts, which also live in three different github projects:

The Visualisation frontend (including the input dialog)

The Game

The static pages of the site

and the API.

5. Conclusion

The project was quite a different experience for all of us. We were not used to having to research and to come up with the actual content and a suitable way of visualization, since usually the job of developers is much more limited, straight-forward and organized through a relatively strict hierarchy - which simply was not the case in this project. This forced us to approach it in a different manner than what we are used to, which was definitely a bit of a problem in the beginning and certainly led to some lessons being learned.

The biggest issues were in the area of time management and organizing the work as a team, which led to delays and unclear work schedules. If we approached this project again, we would most definitely try to create a stricter hierarchy and possibly utilize a task management tool such as Redmine where issues could be listed, explained and marked as resolved in later phases of the project.

Aside from that, the early phases of the project were also quite difficult, since we had to strongly focus on research and generally on the gathering of ideas and approaches for a suitable way of telling the story we wanted to tell. These are all tasks which most of us do not have extensive experience with and they ended up being more difficult than we anticipated initially which made that part of the road a bit bumpy for us, but we came out of it smarter.

Aside from these practical lessons, we also learned a lot about the topic of our work itself. The research phase revealed quite a bit of the tactics of the industry to us and it certainly led us to question our own purchasing behavior and the practices of a whole industry which ultimately is the basis of our our own standard of life.