In the summer of 2017 it was decided that it would be more beneficial to execute the matchstick task via an on-line program.
Executing matchstick program on-line would bring numerous benefits to the experiment in general. But on the other hand there are also a few drawbacks to this approach.
| PROS | CONS | ||
| + + + |
More subjects It is much easier to acquire the amount of the needed subjects. |
- - - |
There is no experimenter present to guide and verify the experiment. We have to trust the subjects a whole lot more. |
| + |
Minimized preparation time The experiment does not need to be set up / reset for every subject |
- - | Much more work time spent on the program |
| + |
No need for experimenter to be present at the experiment |
||
| + |
Simultaneous experiments More experiments can run simultaneously |
||
| + + |
Experiments are more rigid Every experiment is executed in the same way in a predetermined and reviewed fashion. Experimenter cannot influence the course of the single experiment. |
||
After weighing up the pros against the cons, we determined it is indeed beneficial to make an on-line program to perform this experiment.
Program or application
A computer program is a set of instructions that can be executed on a computer. An application is software that directly helps a user perform tasks. The two intersect, but are not synonymous. A program with a user-interface is an application, but many programs are not applications. (Source)
From here on, this software, developed for the process of executing matchstick experiments will be called "application". Also, if no otherwise special distinction is provided to some software in discussion, the name "the application" will refer to the software for executing matchstick experiments.
The application
Domain name is the initial URL address one enters to the browser bar, in order to access the desired web page.
The application domain name chosen will be a simple one. Following criteria should include a simple one or two words combined in the English language. These words should encompass a special important segment or a general idea about matchstick experiment. We can also choose to go in the direction of the name of the experimenter. Such a domain name will enable subjects to easily remember the application site and enable verbal sharing and subject acquisition, The link name is actually of a secondary importance. As long as the application has a valid link, we will be able to recruit subjects via e-mail messages.
The considered ones are matchstick.eu, matchstickexperiment.eu or grenc.eu. They are currently not yet registered. Later we decided on the domain name matchstick-task.eu, as the ones mentioned before were either taken or too expensive to purchase. This decision may get reconsidered later.
Keeping track of the subject seems like a simple task. But it is not inherently so. The application will be running mainly on subject's machine to avoid performance issues and any possible lag, but this means more possible issues with data collection as we must put the trust in subject's machine. For example, if the subject loses Internet collection or if the computer powers down, we need to provide support for subject's machine to properly recover / continue with the experiment. Additionally, we have to account for malicious subjects who would try to harm the experiment. Some form of secured data collection must be made - some form of encryption is a minimum. Unfortunately, simply collecting all the data and sending it afterwards to us is therefore not a viable option. Data should be sent as often as possible in encrypted packages, that can be held in a queue in case of a bad connection and should be hard to counterfeit.
A subject may try to execute some invalid activities upon searching for all possible moves (eg. try to create a numeral 4 with a diagonal matchstick). The best course (after serious deliberation) to prevent such pointless searches seems to be to make shaded matchstick placeholders on the board, that immediately show subject all of the valid moves. This way we can suppress thoughts about invalid moves in the beginning and also make the subject focus more on the actual available moves.
User's activity should be kept to a minimum in order to eliminate effect of those actions on the task. For example, if the user has to click to turn the matchstick around, the amount of clicks required could potentially influence subject's decision. To prevent this, we will introduce automatic shadow matchstick that will pop up at closest available position and in this way show the subject what his current activity may result into. This way subject does not need to consider himself/herself with the problem of properly positioning the matchstick that he/she wants to place. This shadow matchstick may come in useful to show to the subject from where the current active matchstick (the matchstick that was removed, but not yet placed) has come from in order to dissuade putting the matchstick back to the original position. Sometimes the subject may want this, if he/she has changed his/her mind about the matchstick taken - if the said matchstick is dropped in the invalid place or back to the original position, we should disregard the move altogether - maybe just log it, in case we can use such information later.
We still have to decide what to do in case subject makes a move and then reverts it.
Regarding approach to the move-action, we have identified two groups of people, each with their own mental representation: (i) representation-grab: to this group belong subjects that think of a matchstick-move in terms of removing and then adding the matchstick and (ii) representation-drag: this group contains subjects that actually consider the move as a single unit. The most notable differences are regarding the identity of the moved matchstick. The representation-drag group considers the matchstick as an always present element that only changes its location (and/or angle) during a move-action. The matchstick simply gets dragged along the experiment plane form an old to a new location and subsequent change in two equation elements (numerals, operators) is considered to happen at the same moment and is more of a side effect of the move. The representation-grab group on the other hand focuses more on the equation-element change. With the goal of manipulating the equation elements, matchstick is removed from or added to an element and thus reshaping it. There is no necessity that the removed matchstick is the same one as the added matchstick, and there is no requirement that these actions happen is this exact order - a new matchstick can be added to an element before an old one is removed. One matchstick disappears from an old place and a new one appears in the new place. There is no requirement that matchstick in the move action retains its identity.
When implementing any methods that resemble human behaviour in the experimental set-up, we try to encompass each of the representations that are available to subjects in the physical version of the task (eg. a task with actual matchsticks that need to be moved by hand). However that is not always possible. Often it is impossible to recreate a complete activity within the program scope with all of the crucial aspects that underlay its mental representation. However, in this case we are in luck. Upon careful examination of different possible move implementations, that are generally used in similar simple computer games, we observed two two different mechanisms for performing a single move. We feel that each of them relates to different above-mentioned representational group, however further investigation is required to (dis)prove this. These action implementations are: (a) action-grab: subject clicks on a matchstick to take it from the start position and then clicks again to put it into the end position and (b) action-drag: subject clicks and holds to move the matchstick form the start to the end position, where he/she releases the mouse button. Approach (a) roughly relates to (i) and approach (b) to (ii), but this is certainly not confirmed.
It would be an interesting idea to investigate how such mental representation of the matchstick-move could influence the actual physical actions.
These approaches have no effect to the end result of the matchstick-move, but can have different features (such as faster performance) and should therefore be logged at least.
When the matchstick is on the move (being removed, but not yet placed, some form of indication should be used. A proposed solution is a small matchstick on the tip of the mouse, so the subject actually feels like he/she is moving the matchstick. The matchstick should of course adapt to the current probable end placement in accordance to the shadow matchstick. And this held-matchstick should be made a bit smaller in case it would be proved that it is blocking the view of the possible end positions of the move. This will be decided upon later.
Idea: Upon dropping the matchstick to a uncharted position in drag mode, the move should go to remove/add mode. And when clicking on the held match in remove/add mode, rotate it 45 degrees clockwise. How can this clockwise / counter clockwise influence the move?
This way we can also test if 45 degrees with operator task and 90 degrees with numeral task can influence the decisions stronger (for this it would be better to use remove/add mode without move mode - only allow one).
Colors should be as simple as possible and perhaps we should change them on a couple of occasions, if we come across a big group of subjects. It may end up that matchstick colors influence subjects' performance significantly. We have to rethink the color effect of the matchstick, matchstick head, background and shading could have on the experiment. However, we are not going to focus on this aspect in our study, as it would provide additional complexity that we simply cannot afford.
We decided to go with standard light-brown matchstick stick and red matchstick head, as matchsticks like these are most common in our stores (Slovenia, Slovakia and Austria). Buttons will be in light shade of blue, as we feel it suits the matchstick task design. There is no particular decision why we chose this - this was solely a design decision. On the blue background, text will be mostly written in white Arial font, for readability purposes. Likewise, on white background surfaces, text will be of the previously-mentioned blue color. We are going to use only before-mentioned light blue and white colors on the task page to preserve coherence.
TODO Provide actual color HEX numbers.
Multiple languages should be supported, to address multi-lingual audience. This will be also tracked.
Help general: https://www.nomensa.com/blog/2010/7-tips-for-multi-lingual-website-accessibility
Help specific php: http://www.bitrepository.com/php-how-to-add-multi-language-support-to-a-website.html
https://www.w3schools.com/php/php_includes.asp
Should we allow for pausing the experiment?
Maybe after pause, inform the subject and start a different task from the same group.
3D matchstick https://www.pixelsquid.com/stock-image/matchstick-1170344413851817973?image=B15
Matchstick_original.png source: http://www.pngpix.com/wp-content/uploads/2016/08/PNGPIX-COM-Match-Stick-PNG-Transparent-Image-500x667.png
Scroll
across browsers https://www.h3xed.com/programming/javascript-mouse-scroll-wheel-events-in-firefox-and-chrome
Old: https://stackoverflow.com/questions/7070110/flash-vs-html5-game-development-for-web-mobile
New https://www.quora.com/Adobe-Flash-or-Javascript-for-Game-Development
After careful evaluation, I decided to go with Javascript, on the basis that it is becoming more and more popular. In software this is very advantageous, as popular software is often better supported and thus made more compatible with other tools.
In the end it doesn't really matter that much, as this is a simple game, and both of these tools would enable us to make an application that would do all the things that what we require of it.
For the purposes of the experiment and application the backend side of the running program is not so important.
But we still need to make the matchstick application run and collect subject data.
The fist option to run an application online is a simple local home server. There are plenty of various server on which we can run this application (remember, we chose Javascript for its popularity). The home server has of course be able to run non-stop, so an old computer could do the trick. Next, we need to open the ports of the server and enable the application to listen for incoming activity on those ports. The following blockade is the home router - we need to configure it, so it will properly map the incoming messages to the server in local area. And the last thing that needs setting up is a dynamic domain name server (d-DNS), which will map a readable website name (eg. matchstick.eu) to our router's IP address.
After all these steps had been set up, the messages should freely flow from users / subjects to our server machine.
Recording subject responses is a very difficult task indeed. But without properly storing the recorded data, the experiment is essentially useless. A good database is thus of great importance.
To recap what data do we want to collect from subjects:
| Personal data |
|||
| Mandatory |
|
||
