Figure 2 ScreenPlay GUI main page, including the gridbased playing surface inspired by
3.2 Affordances
The aforementioned connection that exists between the mode of interaction of the piano (and similar instruments) and that of ScreenPlay provides the basis upon which the affordances mentioned by Blaine and Fels in their physical interface/sensor guidelines from the 11 criteria for collaborative musical interfaces of ScreenPlay 's GUI are reliant. As has been covered in the Literature Review chapter of the thesis, Donald Norman (2004) distinguishes between real affordances and perceived affordances , as well as laying out four principles for screen interfaces in relation to their affordances. Because ScreenPlay 's UI is touchscreenbased its
perceived affordances are of most importance in terms of communicating to the user(s) via the graphical display the actions required to exert influence and control over the system, due to the fact that its real affordances are dictated by the tangible interaction with the screen. This is in contrast to motion control gestures which would otherwise be required with a sensorybased system; the affordances of which are real and would be far more difficult to convey to the user(s)/audience without the addition of verbal or written instructions.
Below are listed the four principles for the design of screen interfaces outlined by Norman with the aim of clarifying how perceived affordances should be used to greater effect in allowing firsttime users with no previous experience interacting with any given GUI to instinctively and intuitively understand its operational methodology, as well as the influence each of the principles has had upon the design of ScreenPlay 's GUI:
1. 'Follow conventional usage, both in the choice of images and the allowable interactions' (2004): the advantages of this serve to fulfil the aims outlined by Blaine and Fels with regard to audience transparency in the guidelines for focus in the design of collaborative musical interfaces (2003). An example within the context of HCI in music would be the graphical representations of hardware controlobjects such as drumpads, buttons, toggles, faders and rotary encoders etc., which are prevalent in touchscreen MIDI/OSC controller applications TouchOSC (Fischer, 2008present), Lemur (Slater et al., 2011present), LIVKONTROL (reference) etc. and also feature heavily in the TouchOSC layout designed as the GUI for ScreenPlay .
2. 'Use words to describe the desired action' (2004): where metalevel data is concerned in musicmaking software, clear and concise language can be used to clarify the roles and parameters of certain control objects where there may otherwise be ambiguity; especially in the case of virtual instruments and DAWs, where there are likely to be an abundance of similar controlobjects. In ScreenPlay 's GUI certain control objects are labelled to help distinguish them from others with the same or similar appearance but differing functionality; while the provision of instructional documentation relating to both the setup and configuration of the ScreenPlay suite of Max for Live MIDI Devices (displayed in a popup help window accessible from the ScreenPlayCTRL Max for Live device GUI) and how to correctly impart control over the system via the TouchOSC GUI also fall within the boundaries of this principle.
3. 'Use metaphor': Norman states that '[he] personally believe[s] that metaphors are more harmful than useful' (2004) in the context of screenbased interfaces, although, this being written more than a decade ago and before the cultural dominance of touchscreenbased interfaces in everyday life as we see today, it is somewhat outdated and no longer rings true. Both visual and verbal metaphors can be used to great effect in the UIs of screenbased ( Pixel Tune (humbleTUNE, 2010present), Patatap (Brandel, 2012present; Brandel, 2015)) and sensorybased ( La Maison Sensible (Lasserre, met den Ancxt, Ajima & Nagemi, 2015; Lasserre & met den Ancxt, 2015; Emory, 2015)) ICMSs intended for use by nonexperts and novice musicians. In ScreenPlay the use of metaphorical language is paramount to accurately conveying the effects upon the musical output of the system of the topical opposition transformations.
4. 'Follow a coherent conceptual model so that once part of the interface is learned, the same principles apply to other parts' (2004): rarely does the UI of any ICMS function in an illogical manner, as such a design would severely detract from the immersiveness of the interactive experience. This is true of ScreenPlay and also ties in with the advantages to be gained from providing each individual user in a collaborative ICMS with a UI that is the same or similar to those allocated to the other users (where multiple UIs are present/required), as outlined by Blaine and Fels' guidelines on player interaction (2003).
Two design choices made in relation to refining and streamlining the overall affordances and usability of ScreenPlay and its GUI, rather than in direct response to Norman's four principles, were to use a horizontal "timebar" to provide a visual representation of tempo, and the omission of a global play/pause button. Tempo was originally intended to be displayed on the GUI via a pulsating LED but, unfortunately, due to fluctuating WiFi signal strength and connection speed, this was not deemed a practical solution due to severe issues with instability and lag in the visual response of the LED to the pulse/tempo of the system's musical output. As a result, the flashing LED was replaced with the "timebar", which is positioned at the top of the main control/playing surface and generative/transformative algorithm control pages of the GUI (see Fig. 2 and 5), and moves from left to right over the course of a single bar. The decision not to include a play/pause button was made in order to avoid issues when configuring ScreenPlay as a multiuser collaborative interactive installation with a potentially large number of users each being provided with the controls to start/stop the entire musical output of the system, and the detrimental effect this could have on the immersion and enjoyment of users interacting with the system when not effectively communicating with one another; as might be the case in a public gallery installation of the system.
There is no real negative impact from this design choice on the usability of the system when configured as a singleuser studio compositional tool, given that, in this scenario, the user is able to access the controls in Ableton Live for starting/stopping the playback of musical output from the system directly via their computer. When in this configuration the user is also able to switch between up to sixteen individual parts within Ableton Live and the visual feedback displayed on the GUI is updated accordingly to represent the status of the currently selected part at any given time. This includes ensuring that, if the status of a part changes while another is selected, meaning that the visual feedback to be provided to the user via the GUI upon reselecting the part is required to be different than it was when last that part was selected, the correct changes are applied. Certain controls that are specific to each instrument/sound when in multi mode (such as key signature/scale, octave and velocity of the playing surface etc.) are also applied globally to all parts when in single mode to ensure the best interactive experience possible and that the integration of ScreenPlay into the compositional workflow of the user is as seamless as can be.
3.3 High Level Design Strategies and Gesturetypes in the ScreenPlay GUI