#pseudo-heatmap effect | Explore Tumblr posts and blogs

yea15000413-blog · 7 years ago

Text

Project Week 4 (05/03/2018)

This was a very busy week for me. Essentially, I had to finish designing and actually build the applications used for the testing phase of the application. This is on top of having to prepare for a face to face meeting with the client. Development of the of the applications went smoothly though. This is in part to the effective use of pseudo code and prior design work done in earlier weeks, which meant I was simply implementing what I had already designed. Overall, I am happy with how this process went. Condensed logs of the application building process are provided below.

Build 0.01(Created form and added randomised form order array)

The code for this build was simple and therefore was fast to code without errors. The layout of this form will need to be rearranged before the final build, but as is, this is a functional design for building and testing. As can be seen in the below images, the form accepts user input appropriately and the frmOrder array is appropriately randomised to ensure a different order of forms each time the program is ran.

Build 0.02(Created file creation and added second form (form1))

I decided to use the exact date as the file name for each log, to ensure that each log has a different name. This would exploitable in a public release application, however, this is a research application, which will only be used in controlled and monitored environments, so this solution is good enough and saved some time coding a proper file naming schema. One issue I ran into, however, is that dates are printed, by default, with “/” and “:” characters in. This caused a crash as it would think the file name is a path and not a file name.

To solve this, I replace all of the “:” and “/” chars with “-“ chars. This gives an odd file name structure, however, each file name is unique and easy to organise, and this is all that is required for this application.

The new form opens and data is passed through correctly, as seen below:

Build 0.03(Added time taken to complete form)

This works as intended. By recording time taken to complete each form, I will be able to analyse which forms are the fastest for users of each device to use.

Build 0.04(Added input accuracy using Levenshtein’s algorithm)

The addition of this feature was challenging and time consuming. However, despite the challenge, this was implemented without any significant problems. The only issue with the addition of this feature is that sometimes the values were generated correctly, but would not display in correctly, leading to a confusing output. This was due to text formatting errors in my code. I will improve this by tidying my code in a future build, as at the moment it is functional, but not that clean and easy to read. Below is evidence of the new feature working as intended.

Build 0.05(Added mouse tracking)

Originally, I was planning on using the website using the website http://www.heatmapper.ca/. However, it turned out that this did not support the type of data I was going to be working with (tables of raw x and y position data in the .csv format). Upon further research it turned out that there were no online tools suitable for my needs. Therefore, I had to use statistical analysis language R. R is a very simple language, and thus only took a day to learn, this was still an inconvenience through.

The program now outputs mouse data and I can create detailed heatmap graphs from said data in R, as shown below.

Build 0.06(Added Forms 2-5 and end form, as well as cleaned up code)

Forms 1-5 are currently identical, except the renaming of a few variables to make the output correct to the form it is currently on. Despite this sounding like an easy copy and paste procedure, it was more complicated than that. Due to the way things are named in Visual Studio, it required a time-consuming process of going through all code and changing many small variables and values. Eventually, I managed to do this accurately, and now all forms work as intended. The end form is a simple form which quizzes users on the forms they have completed. However, when I first built and tested this form would display incorrect values for each form. This was because I had not accounted for the fact that the user would have used the forms in a different order than just 1-5, due to the randomisation. To fix this I fed the randomised order into the end form and arrange the user’s quiz answers appropriately. All forms work as intended (output file and heatmaps) and are now easier to add future features to due to the cleaned code.

Build 1.00 (Implemented GUI designs into each form)

The application is now finished. All features work as intended and the forms are set up to generate data.

Colour Tester Logs

Build 0.01(Copied Layout Tester Application and changed questions at end)

This application is essentially a copy of the layout tester with a few modifications. As such, the first step was to create a duplicate of the layout tester and make a few slight changes (such as removing one of the questions in the end form). This provided a very solid frame to add the interfaces that test colour to. As this is essentially a duplicate of an already functioning and tested application, everything works as intended. To see the testing for this code, please refer to the layout tester application.

Build 0.02 (Added generic template to all test forms to be coloured in the next build)

The form design chosen for this was a simplified version of one of the forms from the layout tester. It was not necessarily chosen because it was the best form, but because it is one of the simplest; this should help reduce extraneous variables, so that colour is the only factor between tests. All duplicates of the form work as intended.

Build 1.00(Applied the different colour schemes)

The application is now complete. Each form has been designed to test different hypothesis about the use of colour when coding Windows applications. All features work as intended, so this application can now be used by test participants to test said hypothesis.

Meeting with Client

At the end of the week, I had the face to face meeting scheduled with the client. This provided a perfect opportunity to discuss the switch to using R to generate the heatmaps. As this was a face to face meeting, it was easy to show and discuss with the client the very minor changes to the project plan this would cause. The client agreed to this and signed off a change request form. The changes to the testing application build phase of the project and the change request form are shown below.

0 notes