In my previous entry, I announced I was exploring the political compass’ JavaScript files to adjust them to the needs of my project: Plotting Colombian Emblematic Memories. To do that, I had to refresh my JavaScript literacy by studying the basic elements of that language, which means studying the structure and logic of that programming system. I did check those basic elements, including JavaScript functions and loops, and I was able to understand in a much better way what was happening in the political compass’ JavaScrpit files. So today, I am talking about the content of those files and the decisions I made to move forward with this project.
Let us start by remembering that the political compass application (you can check it here) has four documents containing its code: one HTML file, one CSS file, and two JavaScript files. To review each document, you can access the code in the Github public project’s repository, but you can also create a local copy to play with it. I choose the second option by creating a local clone that I will later fork. One of the project’s JavaScript files is called chart, and the other one is called questions, and each of them plays a different role in the whole application. While the “chart” file produces the application’s graph, the “questions” file governs the behavior of the questions and the mathematical logic behind rating the user’s answers.
It is possible that what I have just mentioned is a little difficult to swallow, so I am explaining a couple of things in this paragraph by using a metaphor. Let’s imagine building a webpage project is similar to building church: you need a basic structure, materials, aesthetics, and automatized processes. Let us start by acknowledging that HTML, CSS, and JavaScript are programming languages with different functions. HTML provides the general structure and the contents of a webpage, meaning that for our metaphor HTML provides the basic structure of the project (where things go and how they connect to each other) and the materials (titles, headings, paragraphs, images, videos, sounds, etc…). CSS language takes care of the aesthetic contours of the project, including its colors, and how big or small they are. Just like it happens with building a church, it seems aesthetics are not that important, but they usually take more time and effort than building a structure. The complexity of a CSS document is a function of how you feel with your project. It is possible churches have the same function disregardless of how much work you put in visuals, but those differences may have effects on the way people relate to them. The JavaScript files are meant to run functions and interactions. Every modern church needs systems of public services (electricity, water, internet). Well, JavaScript is the code that governs services provision, also the interactions you have with it by opening or closing a door.
The “chart” JavaScript file in the application I am rebuilding was written for building and maintaining a grid representing four political identities you may have: communism, fascism, collectivism, and individualism. To be honest, I don’t know why the programmer decided to build the chart with a JavaScript document. The chart is not interactive, so I think he could have written that chart using HTML and CSS. Regardless, I made some changes to the chart file you can see in the following image. My chart does not have so many squares, and it also has different labels.
The “questions” JavaScript file was written for changing the statements users rank, to process the scores users give, and to move a box across the chart. The position of that box defines the user’s political identity in the political compass application, but in Plotting Colombian Emblematic Memories it will define the emblematic memory the user uses to make sense of the Colombian inner armed conflict. The “questions” file is made of functions and loops that where very difficult for me to completely grasp, and that is why I had to make a decision I was not initially contemplating: I won’t change the math scoring the users’ answers.
I was initially interested in messing with the math of the scale the application uses. I wanted to do it to demonstrate how much I won the new application I am building, but I realized I don’t have the time or the skills to do that. So, for the moment, I am leaving the math untouched, and I am organizing the questions of my application in a way they can work with the existing scoring principles. I tested the code with my questions and it worked, so there is no pressing need in changing the math. However, I am living an image of the codes that are defining the application’s math in case somebody wants to play with it.
Because I already have an application I can change for the purposes of defining the emblematic memories Colombian users have, in the next entry I am talking about the overall logic of my questionnaire, and the emblematic memories Colombians are likely to share when referring the Colombian inner armed conflict.
Leave a Reply