# Reflection Remco

## Expectations

So when signing up for the filter bubble machine project. My first expectations were that it was going to be a seriously complex issue with a lot of maths involved. Because it is still an ongoing research project from *Marcio Fuckner* and *Yuri Westplat*, I had the expectation that we wouldn't have all the resources available to work with. However, after the first meeting with *Marcio* and *Yuri*, I had a clearer idea of how the project was going to go. Regarding the communication within the group, we had a clear idea of how to approach the project and were convinced that the collaboration would be pretty easygoing. 

Besides the expectations of the filter bubble project, it is also our final test of the Web Design and Development minor. Of course, that also comes with different expectations. During the 4-5 month period we learned a lot about different browser technologies, real time web, accessibility, progressive web apps and also more in depth diving of client side JavaScript. My expectations for implementing what technologies to choose and what to sideline, were that browser technologies would be on a lower priority because the end-users are going to be experts visiting the site on a desktop for research. We were noted that the client would like the implementation of websockets, so real time web would be more prevalent. I also expected not to really use the course WAFS (Web Apps From Scratch) because it is mostly client side JavaScript and that would influence how much the end-user has to download to access the application.

Regarding the user experience, we were working together with students from the minor User Experience Design. My expectations for the collaboration with them was that we would receive a largely finished design in the first weeks, and then collaborate on smaller issues like accessibility and improving the user experience. To then ultimately receive a completely new design in the last weeks.           

## Reality

### The courses in the minor

So after the 5 weeks of development, let's look at the expectations and their reality. So of all the 6 subjects we followed during the minor. I used web apps from scratch the most, our project for the biggest part based on client side JavaScript. Mostly because we used the D3 library and after my first code review with Robert there was no need for a backend. One thing we did learn during this course, were the various states to give the end-user more feedback about the application never truly came to mind, and was a fault on our part. Another one of my expectations was that it wouldn't be preferable to load large amounts of JavaScript client side. Even though D3 is a very lightweight library, the visualization did get slower because of the large amount of data.  

This might be solved by using websockets, which was something the client desired. However, the way the data we received from the socket connection and the way the API delivered the data, even a lecturer told us that it was a really difficult way to implement the data into D3. In hindsight, we should have put more time into getting the websockets to work with D3 and deliver more concise feedback to Marcio the person responsible for the API and the websocket. During the project, only one person was responsible for the socket connection. 

Even though our application uses mostly client side JavaScript, we did decide to have some kind of backend code mainly for the websockets otherwise the backend would be redundant. So we did use some knowledge gained during the progressive web apps course. But then again because in our use case we knew on forehand that our users would be using the application on a desktop environment. Therefore, it wouldn't make sense to make it a “downloadable” app. However, it could be convenient to have some sort of offline environment for when a journalist makes a session and runs the simulation to cache the result. 

Of course, we also used a lot of CSS, when working together with the UX-students they had a lot of iterations of the design. So during CSS to the rescue, we learned about custom properties and not using classes and IDs. During CSStR they also told us that it is beneficial to use some classes but that you should also be able to use other CSS selectors. I experienced that first hand when working on the styling during two iterations. Because writing classes on everything without some clear guidance and good naming convention, it gets really hard to understand the CSS. So getting comfortable with CSS selectors helped with cleaning up the HTML structure and made more sense out of using classes and IDs.

During the project, we didn't use browser technologies. The client told us during the first meeting that the focus should be on getting a working desktop environment so that it can be tested by real journalist in a later stage during the research. Because the application is going to be used by experts, we believe that technology constraints aren't that big of an issue and that the journalists should have access to a desktop or laptop device with a browser running JavaScript. 

### Collaboration

Our collaboration within the team went smoothly in my opinion, we made clear agreements before we started actually coding. Everyone was almost present every day. If there would've been one person that was absent the most, then that would be me because I wasn't feeling too well during the third week. There was only one issue that bugged a team member and me a lot, and that was that one person didn't follow one of the agreements we made regarding modular working and writing in ES6. But we were able to manage that, and he solved most of the issues.   

The collaboration between us and the other students from the other minor went well, and we were communicating. So after the first week, we sat together to discuss the project. We asked them some questions on how they would resolve some issues, everyone seemed positive to work on the project. However, on this minor we were always present at the HvA working on the project. The other students didn't have that luxury or drive to continuously work on the project. Their designs weren't changing much until the last week, what was expected. The questions we asked them, they never truly seemed to try to solve that issue. Part of it was because they never had a conversation with Marcio and barely grasped the idea of the filter bubble machine and what the data represented. Communication however was still positive, and we tried to do both our best to deliver a respectable prototype. 

The collaboration with Yuri and Marcio went very well, whenever we had questions about the API Marcio was very easy to reach to ask questions and was happy to resolve minor bugs and issues with his API.   

## In the future…

For future projects, it would be more efficient to not directly start coding and start with a clear goal in mind. For starters, if we made an activity diagram in the first place, we would've spotted the different states way earlier in the process and were probably more compelled to implement them in our project. It would also make for a more complete application. Something else that could've improved our workflow is to designate time to some issues we put in our project. This would've helped to solve the socket issue and how to resolve it in parts, instead of only putting one person on the project and letting him drown in questions when the rest was working on something else. Also, when we required something of the UX-students, instead of complaining after the fact, we could've been clearer with our questions. 

Still, I've learned a lot about working in a team, and I am a glad to take all this experience to different projects.