• No results found

Figure 2 ScreenPlay GUI main page, including the grid­based 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 touchscreen­based 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        sensory­based 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 first­time 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 control­objects such as        drum­pads, buttons, toggles, faders and rotary encoders etc., which are prevalent in        touchscreen MIDI/OSC controller applications       TouchOSC (Fischer, 2008­present),    Lemur (Slater et al., 2011­present),       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 meta­level data is concerned        in music­making 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 control­objects. 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 pop­up help window accessible from the         ScreenPlay­CTRL  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 screen­based interfaces, although, this        being written more than a decade ago and before the cultural dominance of        touchscreen­based 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 screen­based (       Pixel Tune    (humbleTUNE, 2010­present),    Patatap  (Brandel, 2012­present; Brandel, 2015)) and sensory­based (       La Maison Sensible      (Lasserre, met den Ancxt, Ajima & Nagemi, 2015; Lasserre & met den Ancxt, 2015;        Emory, 2015)) ICMSs intended for use by non­experts 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 Wi­Fi        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 multi­user 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 single­user 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 re­selecting 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   Gesture­types   in   the    ScreenPlay    GUI