After engaging in a session of user testing, I’ve been busy updating my Processing code to reflect the feedback that I received.

The main piece of constructive criticism that I got was that the project would be improved by utilising a more interesting, more colourful colour scheme. I have since come up with a way to do this which works around a previous dilemma I was having – which colour to use. The sketch now uses a different random colour for the visuals each time the drawing function starts (either when the program is first run, or after each playback is over). To implement this in a way that still allowed for a visual colour change to coincide with the playing of the audio notes, I decided it would be easier if I first made a few small changes to my existing code.

The new colour mode of the sketch.

The new colour mode of the sketch.

To achieve what I had in mind for the colouring of the notes, I first changed the colour mode of the project to HSB. This stands for hue/saturation/brightness, as opposed to the red/green/blue of the previous RGB colour mode. This is a change I made so that I could easily change the saturation and brightness levels of the colour in correspondence with several other factors of the project.

A random colour.

Changing the colour with the size value.

In the note class I had previously defined, I changed the colour variable to be assigned the value of a new global variable I created called segColor, which is given a random colour value in the setup of the sketch. Then, this colour is modified upon the initialisation of a ‘note’ object, so that the colour varies with the amplitude of the sound it produces and the size of the circle drawn to the screen. This is achieved through altering the saturation value of the colour to a mapping of the z parameter (which also defines size and amplitude) between 0 and 100. This causes faster motions by the user to correspond with bigger circles, more vibrant colours and louder sounds. I think this is a good implementation as it forms a strong link between the elements of the project.

The 'flash' function.

The ‘flash’ function.

It is important for my vision of the project to have the appearance of a note visibly change in some way while its sound is being played to the user, so that it is clear that the two things are related. To achieve this previously, I had the notes turning red to indicate playback. However, this no longer makes sense with the variable colours of the project. Instead, the brightness of the random colour of the notes (which is initially defined with a brightness value of 80), is now increased to 100 for a short period of time, before gradually fading back to its original value. This creates a ‘flash’ of brightness in the note, and very effectively lets the user know which note is being played back. To achieve this, I added a ‘flash’ function to the note class, which simply increases the brightness of the note’s colour and sets a variable to declare that the note has flashed.

The code that causes the brightness of the note to fade.

The code that causes the brightness of the note to fade.

Then, in the drawCircle method of the class is a check for this value to see if the note has increased in brightness. If it has, the brightness is reduced by 2 and the colour updated, until the brightness is once more at its starting value and the note has returned to its initial colour. This creates a gradual fade back to to the starting colour, which makes the transition seem more organic and less jarring for the user.

An additional issue, which I did not point out in the user testing post  but which has since become apparent, is that the sketch was found to start to slow down once the notes ArrayList held too many values. This is because each frame, all of the circles need to be drawn and at each playback the entire list of notes needs to be played. To counter this issue, I implemented a piece of code so that the ArrayList is reset and the canvas cleared if the list holds more than notes.

The code to clear the list and the screen.

The code to clear the list and the screen.

This is useful, as previously there was no way to clear these things without restarting the sketch, and I needed to find a method of doing this before finalisation of the project anyway. One concern I had with doing it this way is that some of the collaborative aims of the project would be lost, as multiple users would be less likely to be able to work together to produce one audiovisual design without it being very short as the previous work would be cleared. However, the limit being set where it is still permits multiple drawings to merge together in this way, as long as they are kept to a reasonable length. This unfortunately is a necessity if the project is to be kept usable, without noticeable slowdowns which reduce the quality of the interaction with the work. Ultimately I do not think the work is negatively impacted overall by implementing this function.

Return of the testers

I asked the testers from the previous testing session to have another look at the project with these changes made to it, to see what their opinions were on (what I hoped would be) the final version of the work.

Their feedback was massively positive, which pleased me to hear. The new colour scheme was approved of, and they agreed that setting the size limit on the list of notes improves the overall usability of the project. The changes seemed to go down so well, in fact, that at the end of the testing when I tried to close the project, one of the testers asked me to leave it for a minute because he was enjoying interacting with it.

This positive feedback is great to hear and I’m confident that, with the issues that were found in my rounds of user testing resolved, I have produced a project which I’m happy to call a final version and take into the Weymouth House foyer for display on the public screens.