Tactile Interfaces for Television Post-production Environments

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Tactile Interfaces for Television Post-production Environments André Neiva Pereira Alves Integrated Master in Informatics and Computing Engineering Supervisor: Maria Teresa Galvão Dias June 17, 2013 © André Alves, 2013 Tactile Interfaces for Television Post-Production Environments André Neiva Pereira Alves Integrated Master in Informatics and Computing Engineering Approved in oral examination by the committee: Chair: Ana Cristina Ramada Paiva (Auxiliary Professor) External Examiner: João Paulo Jorge Pereira (Adjunct Professor) Supervisor: Maria Teresa Galvão Dias (Auxiliary Professor) ____________________________________________________ June 17, 2013 i Abstract Television has suffered big changes since its creation. With the revolution of computers, there was not only an improvement of the TV sets but also a change in the way television was made. One of the major changes happened with the change from tape-based systems to filebased systems, optimizing the overall production process. However, with the continuous technological innovation, new formats, methods and ways to accomplish tasks arise, which forces television to continuously reinvent itself as a response to the competitive market. With the mobile devices proliferation and the revolution of the touch interfaces, there is the need to adapt the actual systems to new interaction paradigms, taking advantage of their features and use cases that computers cannot address. Tablets in particular have been equipped with better processing capabilities and relevant screen sizes, which make them potential tools for complementing computers‟ tasks and assisting people‟s work. Having this in mind, MOG Technologies, a video ingest solution company, has proposed this dissertation in order to study and analyze how the television production can incorporate these devices in post-production environments. Its main goal consists in redesigning the graphical user interfaces of MOG‟s mxfSPEEDRAIL products in order to make them compatible with both desktops and tablets. To achieve this, the strengths and flaws of the current design were identified as well as the main use cases of the products. This has served as the basis to create a new concept for the system organization that allows its adaptation for smaller and touch screens. From this concept, several mockups were then implemented and tested with users. First, they were tested with collaborators from MOG and then with real context users from RTP studios. These tests were very important since they made it possible to validate the proposed solutions and to gather feedback for its improvement. This report documents the processes used and their respective results. ii iii Resumo A televisão tem sofrido grandes mudanças desde a sua criação. Com a revolução dos computadores, assistiu-se não só ao aparecimento de televisores mais sofisticados mas também a uma mudança na forma de fazer televisão. Uma das maiores mudanças aconteceu ao nível do suporte de media, com a mudança dos sistemas baseados em cassetes para sistemas baseados em ficheiros, optimizando assim o processo de produção. Contudo, a contínua inovação tecnológica leva ao aparecimento de novos formatos, métodos e novas formas de cumprir tarefas, que por sua vez leva a que a televisão seja obrigada a reinventar-se constantemente de forma a dar resposta ao mercado competitivo. Com a proliferação dos dispositivos móveis e a revolução das interfaces tácteis, há uma necessidade de adaptar os sistemas actuais a novos paradigmas de interacção, tirando partido das suas features e casos de uso que os computadores não podem abranger. Os tablets, em particular, têm vindo a ser equipados com cada vez melhores capacidades de processamento e dimensões de ecrã relevantes, tornando-os potenciais ferramentas para complementar as tarefas dos computadores e para auxiliar os vários trabalhos. Com isto em mente, a MOG Technologies, empresa de soluções de ingest de vídeo, propôs esta dissertação com o intuito de estudar e analisar a forma como a produção de televisão pode incorporar estes dispositivos nos ambientes de pós-produção. O principal objectivo consiste no redesenho da interface gráfica dos produtos mxfSPEEDRAIL da MOG, de forma a torná-los compatíveis tanto com desktops como com tablets. Assim, foram identificados os pontos fortes e fracos do actual design assim como os principais casos de uso de cada produto. Isto serviu como uma base para criar um novo conceito para a organização do sistema que permita a sua adaptação para ecrãs mais pequenos e de toque. A partir deste conceito foram implementados vários mockups que depois foram testados com os utilizadores. Primeiro foram testados com os colaboradores da MOG e de seguida com utilizadores de um contexto real, nos estúdios da RTP. Estes testes foram importantes na medida em que ajudaram a validar a solução proposta e a recolher informações para a sua melhoria. Este relatório descreve os processo usados e os seus respectivos resultados. iv v Acknowledgements I could not conclude my dissertation without thanking all of those who have helped and supported me during this process. First of all, I would like to thank my supervisor, Teresa Galvão, for all the advices, talks, meetings, emails, Skype conversations and especially for always having the right answers for the right moments. Her guidance, patience, time and sympathy helped me to overcome the obstacles and to keep my head up. I would also like to thank MOG Technologies, Pedro Ferreira and Luís Miguel Sampaio, for this opportunity. Developing this dissertation in a corporate environment made me grow both professionally and personally. For that reason, I would like to thank to all my colleagues at MOG for the shared knowledge, lunch talks and for letting me annoy them with stupid questions and non-sense proposals. A special thanks to Ricardo Serra for all the sighs and the endless discussions that made me see the other side of the equation. His friendship and great supervision at MOG helped me to keep my feet on the ground while my head was on the clouds. I would also like to thank RTP, namely to Paulo Brandão, for receiving me and making it possible to gather feedback from real users, in a real context. This was, unquestionably, a rich experience and a valuable contribution for this project. Moreover, a special thanks to my fellow finalist, João Estevinho, for all the good laughs, usability jokes, conspiracy theories and geeky talks. It was funnier with him around, without a doubt. I would also like to thank my friends for all the support and comprehension due to my absence during this journey. Thanks to them, all the effort was worthwhile. Finally, a special thanks to my parents and my sister, who taught me to never give up and helped me to become who I am. Thank you. André Neiva Pereira Alves xii Figure 2.25 – User Experience 2008, nnGroup Conference Amsterdam [32] 29 Figure 2.26 – Four main activities of a UCD methodology 30 Figure 2.27 – Basic gestures for tactile commands [38] 32 Figure 2.28 – Worldwide tablet market share by screen size band, 2011 – 2017 [1] 33 Figure 2.29 - Different ways to hold a tablet [40] 33 Figure 2.30 – Difficulty to reach screen areas when holding a tablet in landscape [40] 34 Figure 2.31 – Desktop first design approach 34 Figure 2.32 – Mobile first design approach 34 Figure 3.1 – mxfSPEEDRAIL GUI structure: session toolbar (red), panels area (blue) and status bar (green) 39 Figure 3.2 – mxfSPEEDRAIL F1000 GUI organization 39 Figure 3.3 – mxfSPEEDRAIL S1000 GUI organization 40 Figure 3.4 – mxfSPEEDRAIL F1000 conceptual diagram 41 Figure 4.1 - mxfSPEEDRAIL F1000 layout displayed in a monitor with 1680x1050 resolution 50 Figure 4.2 – Draft of the layout for S1000 (left) and F1000 (right) main screens 51 Figure 4.3 – Layout editor in mxfSPEEDRAIL S1000 52 Figure 4.4 – Login form mockup with contextualized hints 54 Figure 4.5 – Suggested help hierarchy. 55 Figure 4.6 – Location list in Asset Explorer panel (left) and its redesign draft (right) 56 Figure 4.7 – Monitor, Control and VTR panels in mxfSPEEDRAIL S1000 (left) and the merged panel draft (right) 57 Figure 4.8 – A context menu mockup that provides the “Delete” and “Mark as favorite” options on a given project 58 Figure 4.9 – Mockup of the login screen 59 Figure 4.10 – Mockup of the login screen with help hints 59 Figure 4.11 – Mockup of the projects screen before user testing 60 Figure 4.12 – Mockup of the projects screen after user testing 61 Figure 4.13 – Mockup of the project settings screen 62 Figure 4.14 – Mockup of the dialog screen asking for user to set the project resolution 62 Figure 4.15 - Mockup of the dialog screen asking for user to select the users that have access to a project 63 Figure 4.16 – Mockup of the default S1000 project screen 64 Figure 4.17 – Mockup of the default S1000 project screen (recording) 64 Figure 4.18 - Mockup of the S1000 project screen with gang-control 65 Figure 4.19 – Mockup of the scheduler screen in month view 66 Figure 4.20 – Mockup of the scheduler screen in agenda view 66 Figure 4.21 – Mockup of the dialog screen for creating an event 67 Figure 4.22 – Mockup of the application settings screen 68 xiii Figure 4.23 – Mockup of the dialog screen for creating a user 68 Figure 4.24 - Mockup of the default F1000 project screen 69 Figure 4.25 – Mockup of the dialog screen to create a new automatic rule 70 Figure 4.26 – Mockup of the “Auto” tab (close-up) 70 Figure 4.27 – Mockup of the “Asset Explorer” screen before user testing 71 Figure 4.28 – Mockup of the “Asset Explorer” screen after user testing 71 Figure 4.29 – Mockup of the dialog to preview and trim assets 72 Figure 4.30 – VTRs in the ingest room at RTP Studios 76 Figure 4.31 – Video tapes identified by project ready to be ingested at RTP studios 76 Figure 4.32 – Desktop running the mxfSPEEDRAIL S1000 application at RTP Studios 77 xiv xv List of Tables Table 2.1 - Usability methods applied to the UCD steps 31 xvi xvii Abbreviations Admin Administrator BaaS Backend as a Service CSS Cascading Style Sheets CTR Cathode Ray Tube DOM Document Object Model F1000 mxfSPEEDRAIL F1000 FEUP Faculty of Engineering of University of Porto GUI Graphical User Interface HTML HyperText Markup Language IP Internet Protocol LCD Liquid Crystal Display MAM Media Asset Management MVC Model-View-Controller MXF Material eXchange Format NLE Non-Linear Editing O1000 mxfSPEEDRAIL O1000 P1000 mxfSPEEDRAIL P1000 RTP Rádio e Televisão de Portugal S1000 mxfSPEEDRAIL S1000 SDI Serial Digital Interface SMPTE Society of Motion Picture and Television Engineers SOAP Simple Object Access Protocol UCD User-Centered Design TV Television VTR Video Tape Recorder XML eXtensible Markup Language xviii Chapter 1 Introduction Television has suffered big revolutions since its creation, in the 19th century. Even its definition has been changed in the past decades in order to include new sets of characteristics and functionalities as a result of the ever growing technological innovation. The elite-only box with black and white images has turned into a trivial object, accessible to everyone, capable of reproducing not only colored images but also high-definition multimedia content. Although these changes are clear from the outside (by simply observing our advanced TV sets), there were also big revolutions on the inside, in the way television content were (and continue to be) made. As new paradigms and new production methods arise, television has become both an essential daily object and a competitive market, becoming at the same time one of the most important means of communication in the industrialized countries. The way of developing technology has also changed over the years. In the beginning, with appearance of the first computational machines, systems were big and heavy objects made to be used by those with good technical knowledge. Systems were not designed to be inclusive but rather to be functional and pragmatic, no matter how difficult it was to operate them. Since the spread of personal computers, this way of thinking has been converging into a user-centered approach, since now users are persons from different contexts and with different technological knowledge. Since technology is now part of people‟s everyday lives, it is essential to ensure that they do not compromise or constrain users‟ tasks. Designing software is now a challenge that not only involves the incorporation of different technologies but also the understanding of the user needs and expectations, in order to provide them a pleasant experience. Different user needs and contexts has emerged concerns with different ways of interaction with computational systems. The traditional mouse and keyboard may not be efficient in some situations as, for instance, tasks that need user mobility. Therefore, new interaction ways are being studied in order to fulfill new demands. Touch interfaces are one of the interaction paradigms that has been emerged during the last years. These type of interfaces has been Introduction 2 spreading among devices, from computers to household appliances, since they are an intuitive and simple way of interaction. Besides, their flexibility potentiates its use in different areas and for different purposes. These revolutions have potentiated new opportunities that companies are being exploring in order to create innovative products. This way they are capable to offer bigger and better services and products as well as they are ready to compete with the ever-growing technological market. 1.1 Context The topic for this dissertation was proposed by MOG Technologies S.A., a leading company specialized in products and solutions for file-based post-production and broadcasting environments. Its main mission is to optimize and simplify video workflows by fostering systems‟ interoperability. MOG‟s main product, mxfSPEEDRAIL, represents a set of solutions based in MXF that includes recording, ingesting, outgesting and playout capabilities in order to assist several phases of the most common video production workflows. mxfSPEEDRAIL‟s layout was designed with desktop in mind and developed with Adobe Flex. With the mobile proliferation and the rise of free web technologies like HTML5 and JavaScript, a paradigm shift is required in order to prepare applications for new challenges and use contexts. Due to their intuitive characteristics, companies are taking advantage of touch interfaces to potentiate new use cases and to enhance the overall user experience. Having this in mind, MOG wants to adapt its mxfSPEEDRAIL solutions in order to make them possible to be accessed both from desktop and tablet. 1.2 Motivation This topic is motivated by the shift of paradigm that is being seen in the last years. As a result of the need for technological mobility, the use of mobile devices, especially tablets, has been growing (Figure 1.1) and potentiating use cases that cannot be supported by other devices. These devices have been evolving over the last years and are now equipped with powerful processing capacities, fast response and big screens, diminishing the overall gap between mobile devices and computers. This evolution has not only allowed the automation of some processes but it also allowed the exploitation of new opportunities. Introduction 3 Figure 1.1 – IDC‟s forecast about Tablet and PC shipment worldwide [1] Alongside this phenomenon, a new interaction paradigm has arisen, due to its innovative capabilities. Touch interfaces are nowadays used in several devices as they allow flexible and natural interactions. Technological innovations contribute to new ways of accomplishing tasks, namely in terms of television production. However, there are not many solutions available when it comes to the use of tablets in this area. This can be a big opportunity, since that, with the appearance of the file-based systems, optimizing workflows and support mobility are big concerns that media companies are seeking in order to face the competitive television market. 1.3 Goals The main goals for this dissertation include:  To understand the impact of tactile interfaces in post-production environments;  To create a set of proposals and design guidelines for mxfSPEEDRAIL products‟ interfaces, that allow their utilization both in desktop and tablets;  To develop and test a set of low and medium fidelity prototypes, in order to validate the proposed solution. State of Art 10 latter is called transcoding and consists in the conversion of one media format or encoding into another. Besides transcoding it can also occur rewrapping, the change of the media wrapper of the assets. Ingest can occur both with local and remote files. This process also allows the addition of metadata to assets. After the ingesting process, assets are ready to be used in the next stages of the workflow. When the size of the asset essence is too big and heavy to operate, a small resolution file may have to be created. This file is called proxy and it is a copy of the asset, with the same characteristics, but with different audio and video quality in order to ease its handling. This is particularly useful for some operations that don‟t need high definition like preview, editing and web publication, avoiding excessive memory consumptions and allowing to simplify some processes. In terms of edition, file-based systems are characterized by the nonlinear edition (NLE). Unlike linear edition, it is now possible to instantaneously access to specific parts of a clip or sequence. This way the editor has more control over the media since it is easier to manipulate it. This process is cheaper and more effective compared to tape-based systems since it only requires a computer and a video editing software, as shown in Figure 2.5. Figure 2.5 – Screenshot of a NLE software - Avid Media Composer 6.5 [9] By not depending on a physical medium, files can be advantageous over tapes since they can be accessed in parallel by various users for different purposes, while tapes impose a serialized workflow [10]. They can also be manipulated and transferred virtually, easing and accelerating it diffusion through the workflow, as show in Figure 2.6. State of Art 11 Figure 2.6 – Workflow of a file-based system [8] Although files save time in non-creative tasks [11], this type of system can have some drawbacks in terms of files format compatibility. Given the large number of existing formats and resolutions, it may be a complex task trying to integrate some type of files in some workflows. 2.1.4 MXF Format MXF (Material eXchange Format) is an open format, created by SMPTE [5] in collaboration with several video industry entities. Its creation comes as an answer to the need for video standardization over the workflows and a way to improve device interoperability. It works as a wrapper capable of transporting media material along with other data (like metadata), as shown in Figure 2.7. This means that different types of video files can be transmitted no matter its content format, making it possible to break compatibility barriers between devices and empowering the overall video production processes. One of the advantages of MXF is to allow the transmission of metadata across the workflow. This is particularly useful since it allows a better control and centralization of the assets information that neither physical documentation nor oral communication through the production team could provide. The fact that MXF was created from scratch, in collaboration with the broadcast industry and community, makes it a powerful format able to satisfy production needs. The incorporation of metadata not only optimizes the workflows but also potentiates the appearance of more powerful media management tools. State of Art 12 Figure 2.7 – Content of a MXF file [12] MOG was one of the first companies to implement and provide software solutions with this format for the broadcast market, promoting the use of standards in television workflows. 2.2 Video Production Software File-based systems led to the emergence of video software. Since media is now processed and edited virtually, there is the need of using software in order to control and operate all the files needed during the production process. There are many types of video software that can be used in different moments of the workflows, including software for video recording, video conversion, video editing and even video broadcasting. However, different workflows may require different software in order to satisfy their specific needs. In the following sections, some of these video software solutions will be described and analyzed. 2.2.1 MOG’s Solutions One of MOG‟s main products is the mxfSPEEDRAIL, one centralized ingest/outgest solution that allows, among other functionalities, video transcoding and rewrapping in order to guarantee systems interoperability across the workflows [13]. As its name states, this solution is based in the MXF format and is divided into four products, each one with a specific function:  mxfSPEEDRAIL S1000 – used for SDI recording and ingest  mxfSPEEDRAIL F1000 – used for video ingesting State of Art 13  mxfSPEEDRAIL O1000 – used for video outgesting  mxfSPEEDRAIL P1000 – used for video preview and SDI playout Clients can choose a product based in a preset list of features. There is also the possibility to customize the product according to a specific workflow in order to adapt to clients‟ needs. After its acquisition, client gets an annual license which activates and deactivates features and that can be renewed. Each product is composed by a dedicated server that deals with the required processing, and a web application made with Adobe Flex, that interfaces the system and that can be accessed either by web browser or local application (Adobe AIR application). The access to each application is done through logging in with users credentials – username and password. In terms of graphical user interface, mxfSPEEDRAIL was designed to be used in desktops, with the production environment in mind. Its layout is easy to use and customizable, which makes it handy to use in the different contexts of post-production. Its look and feel has mainly dark tones, since most production environments have no natural light. Figure 2.8 shows the connection between the four mxfSPEEDRAIL products. The next sections will describe them with more detail. Figure 2.8 – Overview of mxfSPEEDRAIL capabilities [14] State of Art 14 2.2.1.1 mxfSPEEDRAIL S1000 mxfSPEEDRAIL S1000 is multi-format recording system which permits capture audio and video from SDI and HD-SDI interfaces [15], as shown in Figure 2.9. The received signal, coming, for instance, from a video camera, is recorded into files, which may contain metadata, to local or remote storage units. It is possible to generate clips with high resolution, clips with low resolution (proxy) or both. Figure 2.9 – Example of a workflow using mxfSPEEDRAIL S1000 [15] Besides video recording, S1000 includes other functionalities like:  Editing while capturing – it allows the use of editing software to work on files even if they are still being recorded;  Live-feed recording – it allows real time capturing;  Scheduling system – it allows to schedule recordings, in order to automate the process;  Metadata logging – it allows to add additional information to the media;  VTR controller – it allows controlling VTRs internally, providing some actions like play, pause, stop, rewind, fast-forward and jogging;  Fallback storage – allows to save the output in case of main storage failure;  Multi-format/resolution – it adapts to every type of workflow by supporting the most used professional formats and resolutions;  Remote access – allows the possibility to control remotely, through the web interface, accessible through any browser with Adobe Flash compatibility. In terms of GUI, S1000 is composed by several independent panels, organized according to their functionality, as shown in Figure 2.10. It has one video monitor for video previewing that displays the video timecode and that can be replicated (up to 10 monitors) in order to support several streams control. Moreover, it has recording and VTR controls, sound control, panel for clip listing, multi-camera control (gang control) and a metadata panel. It also has a State of Art 15 status bar and a log panel for registering the events and give user information about the system‟s state. Since different operations require different functionalities, these panels can be activated, deactivated, resized and moved using the layout editor tool, easily adapting to users‟ needs. In terms of implementation, its frontend was developed using Adobe Flex while its backend was developed using Python. The communication of the application with the server is done through web services, using SOAP protocol. Figure 2.10 – Screenshot of mxfSPEEDRAIL S1000 2.2.1.2 mxfSPEEDRAIL F1000 mxfSPEEDRAIL F1000 is very similar to S1000, but it differs since its input is now files (instead of SDI channels). F1000 receives and transfers media files from and to editor, devices, servers and network folders, acting as a converter and preserving metadata [16]. By centralizing this process, it is possible to minimize errors and to streamline the workflows. Some of the main F1000 functionalities include:  Editing while processing – it allows the use of editing software to work on files even if they are still being ingested;  Transcode capabilities – it is possible for the user to control each step of the ingest process, enabling media transcoding and homogenization across the workflows;  Video edition – it allows simple editing tasks like video trimming and merging for a preliminary control over the assets; State of Art 16  Simultaneous ingest – it allows multi-clip processing, reducing their processing time.  Automatic rules – it is possible to configure the system in order to automatically process a given folder or device.  Remote access – allows the possibility to control remotely, through the web interface, accessible through any browser with Adobe Flash compatibility. As shown in Figure 2.11, F1000 has also a panel-based design, in which it is possible to select, resize and move panels. Moreover, it is possible to select between three layout presets: User Driven, Automated and Preview. Each layout preset has different panels according to its functionality. Among other panels, there is a video monitor, a device manager, a metadata panel, notifications, an asset explorer, a panel that shows system activity (progress), a session toolbar and a panel to display the automatic rules. Its frontend was also developed in Adobe Flex, the backend was developed in C#. The communication of the application with the server is also done through web services, using SOAP protocol. Figure 2.11 – Screenshot of mxfSPEEDRAIL F1000 2.2.1.3 mxfSPEEDRAIL O1000 While S1000 and F1000 are ingest tools, mxfSPEEDRAIL O1000 is an outgest solution, which means that it prepares videos to be stored and published. This allows users to manage their media export processes, in a simple and fast way. This is particularly useful since it frees State of Art 17 the video editor [17] by delegating this task to O1000. It is possible to export media to playout servers, web servers and archive servers. Some of its main functionalities include:  Direct export of Avid sequences – it allows Avid assets management and metadata maintenance, with the possibility to generate web versions;  Multi-format and resolution compatibility - it adapts to every type of workflow by supporting the most used professional formats and resolution;  Simultaneous processing – it allows the outgesting of several assets at the same time;  Remote access – allows the possibility to control remotely, through the web interface, accessible through any browser with Adobe Flash compatibility.  Background execution – system will run in background, freeing the video editor for its purpose. In terms of GUI, O1000 is very similar to F1000, as shown in Figure 2.12. Besides the panel-driven design, both O1000 and F1000 share the same type of panels. The main difference between them is the operation that each one executes. User can now choose between two layout presets: User Driven and Automated. Similar to F1000, the frontend was developed using Adobe Flex and the backend was developed in C#. The communication of the application with the server is also done through web services, using SOAP protocol. Figure 2.12 – Screenshot of mxfSPEEDRAIL O1000 State of Art 18 2.2.1.4 mxfSPEEDRAIL P1000 mxfSPEEDRAIL P1000 is a player capable of reproducing media with broadcast quality for a wide variety of platforms and channels [18]. It is compatible with most of professional codecs and formats used. Its playout capabilities provide a better quality control over the media. Some of its functionalities include:  Preview and monitoring – it allows to visualize media file with broadcast quality, ensuring quality since its ingest until its transmission;  Multi-format and resolution compatibility – it allows a precise HD-SDI preview of a wide range of formats and codecs;  Remote access – allows the possibility to control remotely, through the web interface, accessible through any browser with Adobe Flash compatibility;  Enhanced quality control – it enhances the quality control by providing a complete media player with integrated sound control that allows external monitors. Regarding its GUI, P1000 has only one layout preset: User Driven, as shown in Figure 2.13. However, it is still possible to manage panels and to display them accordingly. After logged in, the user can see a media player with timecode information, an audio monitor, a metadata panel, a notification panel and one asset explorer. Its frontend was developed using Adobe Flex and its backend was developed in C#. The remote communication is done according to SOAP protocol. Figure 2.13 – Screenshot of mxfSPEEDRAIL P1000 State of Art 19 2.2.1.5 Previous work MOG Technologies has been worrying about the paradigms shift in its products. Aware of the technological trends, it has developed, in collaboration with the Faculty of Engineering of University of Porto through several dissertation proposals, a set of guidelines and interface prototypes that have been integrated in their products, in order to improve their usability and functionality. In 2010, MOG has proposed a master‟s dissertation about the graphical interfaces use for television production software. The proposal was accepted and it results in a set of mockups and in prototypes of a news application called newsRail [19]. The main goal of newsRail was to assist the news preparation and edition by managing the news coming from different news agencies. A few months later, a new master dissertation was done at MOG aiming to continue the previous project, now from a mobile development perspective. newsRail was continued and it was developed a new interface for touch screens, based in web technologies [20]. Several mockups were made, as well one prototype and some usability tests and validations that contributed to create a set of guidelines that were later integrated in MOG‟s products. Aiming to continue the investigation about the mobile shift paradigm, in the following year another master dissertation was conducted, this time with the goal to create a metadata management application [21]. During this project, some studies about news production were performed at RTP studios, contributing for a better understanding of how touch interfaces can change the television production workflow. Some mockups were also created alongside one functional prototype to demonstrate the study results. Finally, one year after, MOG has once again proposed the study of touch interfaces application in television context, the topic of this current project. However, the goal this time is to redesign the graphical interface of its products mxfSPEEDRAIL in order to make them compatible with mobile devices. The expected output includes a set of design proposals and guidelines, as well as a prototype to test and validate the proposals. As it is possible to see, MOG has been aware of the latest technological trends that are changing the market. The appearance of new interaction paradigms motivates the study of new ways to use its products as it increases their value and potentiates workflows optimization. 2.2.2 Other Solutions Being aware of the market dynamics is an important activity in business. When designing new interfaces, it is also important to have some knowledge about what already exists and what is being done. In this section, the main competitors of MOG‟s mxfSPEEDRAIL will be analyzed as well as some video editing software. State of Art 26 Pleasing users may not be a simple task since each person has different expectations. According to David Liddle [23], there are three phases for the adoption of a new technology: the enthusiast stage, the professional stage and the consumer stage. The first stage happens when the technology is exploited. In this stage, users don‟t care if the technology is difficult to use or not, since they appreciate it in an aesthetic way. Sooner or later, enthusiasts will want to apply the technology for work purposes because they see practical value in it. This is part of the professional stage, in which the technology is used to help people work. Here, technology might be a little bit difficult to handle since people are selling their skills to use it. When the technology reaches an accessible price for consumers to buy, the consumer stage is reached. Here, technology is used in order to satisfy user‟s needs as an end consumer. If the technology is hard to use, users won‟t buy it. 2.3.1 Usability and User Experience There are two concepts that one should have in mind when designing interfaces: usability and user experience. Although they are related, each concept has a different meaning and focus regarding a specific product or service. According to its ISO definition, usability is concerned with the “effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments” [27]. Thereby, usability can be described as the qualitative attribute that verifies and measures how easy-to-use and easy-to-learn some objects are. Although these objects – software, websites, tools, machines, books, or anything that involves human interaction - are made by humans, most of times they are not designed with the human interaction in mind, which leads to problems and doubts during its use. Applying usability criteria during the design process leads to better interfaces by making them more intuitive, efficient, memorable, effective and enjoyable to use. As shown in Figure 2.24, these characteristics are referred by Nielsen as a way to achieve system‟s acceptability by users, among other factors like cost, reliability and social acceptability [28]. State of Art 27 Figure 2.24 - A model of the attributes of system acceptability [28] There are several methods to evaluate interfaces accordingly to its usability. A usability study can be conducted during different stages of a system development, in order to satisfy different purposes like requirements gathering and product validation, as shown in Table 2.1. In 1994, Jakob Nielsen suggested a new method for usability inspection – the heuristic evaluation [29]. The heuristic evaluation consists on a system inspection done by evaluators in order to identify problems according to a given set of heuristics. Nielsen has also suggested 10 main heuristics as design principles [30]: 1. Visibility of system status – The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. 2. Match between system and the real world – The system should speak the users‟ language, with words, phrases and concepts familiar to the user, rather than systemoriented terms. Follow real-world conventions, making information appear in a natural and logical order. 3. User control and freedom – Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. 4. Consistency and standards – Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. 5. Error prevention – Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error- State of Art 28 prone conditions or check for them and present users with a confirmation option before they commit to the action. 6. Recognition rather than recall – Minimize the user‟s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. 7. Flexibility and efficiency of use – Accelerators – unseen by the novice user – may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. 8. Aesthetic and minimalist design – Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. 9. Help users recognize, diagnose, and recover from errors – Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. 10. Help and documentation – Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user‟s task, list concrete steps to be carried out, and not be too large. While usability is focused on functionality, user experience is focused on the overall experience of an interaction. According to its ISO definition, user experience is concerned with “all aspects of user‟s experience when interacting with the product, service, environment or facility” [31]. It involves user‟s emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and the occurrences that happened before, during and after the utilization context. As shown in Figure 2.25, a good user experience is achieved when the product or service is useful, easy to use and desirable and it has a good brand experience. State of Art 29 Figure 2.25 – User Experience 2008, nnGroup Conference Amsterdam [32] Hence, usability and user experience concepts are closely related. Whilst usability answers the question “Can the users accomplish their goals easily?”, the user experience answers the question “How delightful was the experience?” [33]. When designing interactions, both concepts should be kept in mind, in order to meet user‟s needs and at the same time provide a full and rich experience. 2.3.2 User-Centered Design User-Centered Design (UCD) is a design methodology for the development of userfriendly products. Its main goal is to ensure that the final product fulfills users‟ expectations, by considering their needs, preferences, limitations and the overall business goal. In other words, it carefully balances the needs of users and the needs of the organization [34].This means that it is necessary to understand and to gather feedback from the user from the beginning and during the overall process of a project. This way, it is possible to create products that are easy to buy, to install, to learn, to use and to update. The UCD methodology not only increases the overall user satisfaction, but also diminishes technical support expenses, accelerates the learnability and contributes to greater market success [35]. Although there are several ways to apply these principles, there is an international standard [36] that defines the UCD methodology basis and that describes the overall process without specifying exact methods. As shown in figure Figure 2.26, this model is divided into four main activities: State of Art 30 Figure 2.26 – Four main activities of a UCD methodology  Specify context of use – by identifying use context problems and restrictions. In this stage it is important to answer to specify the users, the tasks the user wants to perform, how and why they will achieve them and in which context.  Specify requirements – by identifying business and interaction goals in order to achieve product‟s success. It must be considered users‟ needs, preferences and limitations as well as what the company wants to achieve.  Produce design solutions – in this stage, solutions are designed and prototyped. It starts with the conceptual idea and extends until the idea is translated into a tangible design. This phase can be divided in several steps.  Design evaluation – this is the most important part of the process. It includes gathering and analyze feedback from user about what was designed. This way it is possible to redesign and to change what was specified in order to fulfill user‟s needs. Ideally, this should be done with real users to get more precise feedback. Another aspect to consider in the UCD methodology is that it is transversal and multidisciplinary. This means that it may be applied both to a software and to other ordinary objects that involve user interaction (like a toaster, for instance). Several usability methods can be applied in different stages of the UCD process, depending on the purposes, as shown on Table 2.1. State of Art 31 Table 2.1 - Usability methods applied to the UCD steps [37] Analyze Design Test Card Sorting x x x Contextual Interviews x - - Focus Groups x x - Heuristic Evaluation x - x Individual Interviews x x x Parallel Design - x - Personas x - - Prototyping - x x Surveys x x x Task Analysis x - - Usability Testing x x x Use Cases - x - It is important to notice that, although these are useful methods, they should be used accordingly to its purpose, in the right stage of the UCD process, in order to take advantage of them. The same method may be more or less efficient depending on the project in which it is being applied. Therefore, it is necessary to adapt each method to each situation. 2.3.3 Designing for touch As seen on Figure 1.1, the tablet market is growing and is expected to overcome the desktop market soon. One was to justify this is that, although computers can be a powerful and useful tool, they lack mobility. Even laptops can be inconvenient in certain circumstances due to its size and weight. This is where tablets take advantage. Tablets, which are becoming more and more powerful just like computers, offer a relevant screen size in which it is possible to interact with the system, by only touching with the fingers. Although this touch paradigm is an old concept, it was only recently that it started to become stronger on the market, mostly due to its incorporation on the mobile devices. Touch interfaces had become popular by guaranteeing a simple and natural way to interact with systems without the need for intermediates (like keyboards or mice). Touch interfaces are particularly advantageous due to its flexibility. In the same touch screen it is possible to simulate several types of interactive inputs – like buttons, numeric pads, different keyboards, among others – that may be personalized and adjusted to user. Besides, the current touch screens are prepared to allow several types of touch that can be combined, allowing different types of interaction. State of Art 32 As shown in Figure 2.27, some of the main types of touch include:  Tap – touch quickly once on the screen;  Double Tap – touch quickly twice on the screen;  Drag/Slide – move fingers in a given direction without losing the contact with the screen;  Pinch – touch on the screen with two fingers, approximate them;  Spread – touch on the screen with two fingers, moving them in opposite directions;  Press – touch on the screen for a long time;  Rotate – touch on the screen with two fingers and then twist them clockwise or counterclockwise. Figure 2.27 – Basic gestures for tactile commands [38] As said before, it may be possible to implement touch sequences, combinations and small touch variations when developing for touch interfaces. However, they should not compromise the overall interface usability. User may not understand immediately which actions there are and in which context they should be used [39]. Designing interfaces for touch may be a challenging task and it should consider some aspects. First, it is important to understand that a touch interface does not provide the same stability and physical feedback as mouse and keyboard. Therefore, it is necessary to guarantee that users get and percept visual feedback as a response to their interactions. Another aspect is the screen dimension. The tablet dimension can vary depending on the manufacture. It can be small (from 7 to 7.9 inches), medium (from 8 to 10.1 inches) or large State of Art 33 (over 10.1 inches) and have different resolutions. It is important to consider this specially when designing dimensions or responsive layouts in order to make sure that all the content is readable and easy to reach. Figure 2.28 shows the tablet market share by screen size between 2011 and 2017, according to IDC. Figure 2.28 – Worldwide tablet market share by screen size band, 2011 – 2017 [1] The input precision is also something to consider. In general, touch precision is lower than mouse precision. Different screens may have also different touch precisions. Touch technology may not always be the same which means that the pressure and the area of the touch may also differ from tablet to tablet. For instance, small buttons lacking feedback can be a problem in screens with low touch precision. It is also important to understand how the users use tablets. Typically, users hold tablets with hands along the sides or they simply place the tablet on a surface and use both hands for typing, as shown in Figure 2.29. Tablets can be used in two orientations: landscape, in which the width is bigger than the height, and portrait, in which the height is bigger than the width. These two factors – how users hold the tablet and in which orientation – influence the accessibility of the touch areas. Figure 2.30 shows the areas that are easy, ok and hard to reach when holding the tablet in landscape. Figure 2.29 - Different ways to hold a tablet [40] State of Art 34 Figure 2.30 – Difficulty to reach screen areas when holding a tablet in landscape [40] Finally, when designing both for desktop and for tablet, two design approaches may be used: desktop first or mobile first. The first approach happens when a certain project is designed with desktop in mind and after that is readapted in order to be compatible with mobile devices, as shown in Figure 2.31. The second approach refers to the opposite. It happens when a certain project is designed with mobile in mind and after that, it is readapted for desktops, as shown in Figure 2.32. Figure 2.31 – Desktop first design approach Figure 2.32 – Mobile first design approach State of Art 35 Although they may seem equivalent, they are actually very different and may have a huge impact on the final product. When designing for desktop first, the project tends to take advantages of the desktop capacities, which have few or no restrictions. When adapting the project for mobile, some features are not compatible and it is necessary to remove functionality to the system. On the other side, when designing for mobile first, mobile restrictions are taken into account since the beginning of the project, which forces designers and developers to focus on the essential and then improve it according to the device. This concept was first introduced by Luke Wroblewski [41] in 2011, and it has been largely discussed since then. Analysis and Requirements Gathering 42 For these evaluations, the evaluator used Nielsen‟s Usability Heuristics. This set of heuristics consists in 10 general principles of design, as described in section 2.3.1. In terms of severity, the problems were classified from 0 to 4 according to the following criteria: 0. Don‟t agree that this is a usability problem 1. Cosmetic problem 2. Minor usability problem 3. Major usability problem 4. Usability catastrophe (imperative fix) This severity criteria was also proposed by Jakob Nielsen [42], and is based on the frequency, impact and persistence of the issues. This will help to prioritize problems and to measure the usability of the current interfaces. The complete output of the mxfSPEEDRAIL heuristic evaluation is presented in appendix A, B, and C. Since O1000 has a very similar interface to F1000, the same results gather during F1000 evaluation are valid for O1000. The slight difference is that, in O1000, the main goal is to outgest files (instead of ingest) and there is no trim functionality. 3.2.2.1 Results In a general way, the current mxfSPEEDRAIL is simple and easy to use. However there are some flaws that deserve some attention. One of the most common problems that mxfSPEEDRAIL‟s products have is the lack of consistency between each other and between other conventions. Along the evaluations, there were some similar objects that had different behavior (for instance the trash button that sometimes was meant to delete one occurrence and other times was meant to delete all occurrences) and that might lead to a difficult learning of the product. Also, some interactions were inconsistent with platform standards (for instance, after resizing a window, user expects to be able to use it without having to save its position), opposing the users‟ behavior expectation. Another problem that has led to some potential error situations is that data entered by users is always saved whether they click the save button or not. This means that users may perform operations with data that was not saved, is volatile and may be wrong (for instance empty storage profiles). This also leads to a lower visibility of system status, since that what is seen by the users might not be what is on the system‟s database. Although there is some error prevention regarding this issue, it is not efficient enough to prevent this system malfunction. There are two ways of using mxfSPEEDRAIL products: through local application interface or through web interface. Since the execution environments are very different, interfaces end up being different too. Some inconsistencies between these two environments like different Analysis and Requirements Gathering 43 features and different panels on the same product might lead to user not understanding why some features are not working (for instance the metadata shortcuts in S1000 only work in the local version, but it is still possible to see them in the web application). Also some data that appears in the local interface might not appear in the web interface and vice-versa. This should be handled carefully to make sure that users know exactly what they can do in each environment, and what data is available at each moment. Although all products have a similar looks-and-feel, there are also some inconsistencies between products. This is more accentuated in S1000, since it was developed differently from the other products. Besides the differences of how the information is organized (for instance, contrarily to the other products, in S1000 there is no metadata profile concept) and displayed, there are some interaction differences (for instance, in S1000 there is a contextual menu). This may be confusing, since that mxfSPEEDRAIL is seen as an integrated and centralized solution. In terms of accelerators, although there is some effort of speeding up user actions, there are some needed improvements like multiple selection of objects and keyboard shortcuts. In terms of user control and freedom, mxfSPEEDRAIL provides some protection against user‟s mistakes. However, there are some critical actions (like shutdown, restart and delete) that don‟t ask for user‟s confirmation. Other frequent issue is that there are some controls that are activated but do not do nothing because the system is not in the right state for them to work (for instance, there are buttons for delete and copy profiles when the system is empty). These controls are not only irrelevant information that is being displayed but also they might trick users. For the situations when the user does not know what to do there is a help button that opens the product manual. Although this can be helpful, there is no option to search for specific keywords, making problems resolution take longer. In addition, help button is not reachable with the settings window opened, making it harder for user to receive contextual help. Some controls do not have also tool tip, making it sometimes difficult to understand what they do. Apart from these problems, products are practical and easy to use once mastered. 3.3 Requirements Gathering Process In order to gather requirements for the new interface, some methods may be used, as seen in 2.3.2. This section describes the methods used and the resultant conclusions. 3.3.1 Interviews In order to have a better insight about how mxfSPEEDRAIL is being used, two interviews were planned for MOG‟s team. One interview was conducted with one person from the support Analysis and Requirements Gathering 44 team, since they are responsible both for the user assistance and user training, in order to understand how users are using the product and what the main problems of their utilization are. The other interview was conducted with one person from the sales team, in order to understand what clients are asking for and what they think about mxfSPEEDRAIL. Both interviews were conducted in an isolated room at MOG‟s offices. The interviews both with the support and the sales team are presented in appendix D and E. 3.3.1.1 Results The main conclusion taken from the interviews conducted is that users expect speed and efficiency from mxfSPEEDRAIL. Since that some operations may be repetitive, users want to achieve their goals wasting as less time as possible. In addition, this highlights the possibility to automate some processes as a high value feature for users. However, system must be flexible and provide manual handling for situations that require special attention. Some features like layout customization, metadata management, settings import/export (in order to configure multiple systems) may also be important for users. In terms of user context, it is important to notice that it may vary from client to client. However, special situations such as physical restrictions (places with limited space, studios with low light, …), equipment restrictions (low resolution screens, separately audio processing, …) and user technical knowledge restrictions (specially ingesters) must be considered. It is also important to have in mind that not all users feel confident to try alternative ways when they get lost. As stated in the interview with the support team, sometimes they end up asking to the support team where to click. This means that it should be provided a trustable, well organized and error-proof system that guides users and incentives them to explore. Like most of the people only feels like exploring a city when it is well organized and secure, the same principle goes for interface design [43]. 3.3.2 Task Analysis The aim of task analysis is to understand the way people perform their tasks, in terms of the required actions, the required objects and the required knowledge. The appendix F enumerates the needed steps to accomplish the main tasks in mxfSPEEDRAIL. By doing so, it is possible to identify the crucial steps of each operation and to get better insights for the design process. By analyzing tasks of each product, two conclusions were taken. The first is that system is normally used for repetitive tasks such as selecting files, workflows, process them and add metadata. This points the necessity for system accelerators, like keyboard shortcuts, which may speed up task resolution and improve productivity. The second conclusion is that system Analysis and Requirements Gathering 45 configuration is complex, which means that it may be time consuming and take a lot of input. Although configuration is likely to be done fewer times than the other operations (like ingest and record), it is important to consider this step since it is essential for the system to be ready to use and to work well. 3.3.3 Personas and Scenarios Personas are archetypal users invented to represent a specific type of user while scenarios are stories that explores user needs to achieve a given goal. These two techniques may be helpful throughout the design process by pointing out real situations and contexts. The following sections describe the personas and scenarios created from the collected data from the interviews and the task analysis. They served as a guide in process design, since they point the application goals and motivations and represent potential users and contexts. This was particularly useful since it was not possible to have contact with real users during the requirements gathering process. 3.3.3.1 Case #1 Name: Paul M. Smith Job: Senior Editor, Breaking News TV Description: Paul is a 43 years-old senior video editor that works for Breaking News TV, an American television company that aims to deliver the latest political and financial news in first hand to its audience. He has a bachelor degree in broadcast production and 18 years of postproduction experience. He started his career working as a video editing assistant on a small local TV for 5 years, but then applied for a video editor position in Breaking News TV, where he has been working since then. He considers himself as a very methodical person and he likes to keep everything organized. He is married and he has two young children. Scenario: As a senior editor, Paul has to ensure that new content gets published as fast as possible. This means that his team has to import video from different types of HD cameras, edit different video files in an NLE editor and send all the edited content to their playout servers, in a small period of time. This is usually a stressful job since that Breaking News TV is known for its first-hand news guarantee. 3.3.3.2 Case #2 Name: João Silva Job: Broadcast Engineer, TVS Analysis and Requirements Gathering 46 Description: João is 35 years-old broadcast engineer that works for TVS, a Portuguese TV company specialized in broadcasting sports events. He finished his master degree in electrical engineering 11 years ago and he has been working for TVS since then. The thing that he loves the most about his job is to be able to cover live events and communicate with the audience in real-time. He is a very enthusiastic person and a passionate about sports and technology. He is recently married and does not have children. Scenario: Since most live-events take place in different locations, mobility is crucial to João. He has to ensure the digitization of the video captured by the analog cameras and ensure that it gets to the streaming server in real-time, to be displayed in millions of sports fans televisions. His team will cover the next Olympic Games and João is very anxious about it. 3.3.3.3 Case #3 Name: Marie René Job: Journalist, France News Description: Marie is a 24 years-old journalist that works for France News, a French TV company that delivers national news either through its private channel and its famous website. She has a bachelor degree in Communication Sciences and she started working as journalist 2 years ago. Although she just started her career, Marie aspires to become one of the news anchors of France News. Marie is single. Scenario: Usually Marie has to cover cultural events. Besides interviewing, she has to add metadata and edit the captured video (adding for instance voice-over). 3.3.3.4 Case #4 Name: Stefan van Brummen Job: Archivist, Berlin TV Description: Stefan is a 53 years-old archivist that works for Berlin TV, a public generalist TV channel very popular in Germany that has recently turned their processes into tapeless workflows. He has a professional degree in Information and Documentation and he has been working as an archivist for 28 years, starting in a local library. After that, he had been working with radio and TV production companies. He is a very calm and open-minded person although he prefers to do his job like the “old times”. He can deal with computers although he does not like them much. He is married and he has 3 children and 1 grandchild. Scenario: The recently change of Berlin TV to tapeless workflows has arisen the need to digitalize all the old archive content. For future content searches, content metadata must be Analysis and Requirements Gathering 47 ensured during all digitization process. Stefan is one of the archivists that will be conducting this process. 3.3.4 Measurable Goals Some measurable goals were defined in order to validate the design proposals for the new solution. The following criteria will be used:  Learnability –user‟s effort in learning how to interact with the interface must be low;  Understandability – the new interface must be consistent and easy to understand;  Usability – the new interface must be easy to use;  Satisfaction – users should feel pleased for using the product. These goals will be evaluated through testing the new design with users. They will also serve as guidelines for the designing process. 3.4 Conclusions During this chapter, mxfSPEEDRAIL products interfaces were analyzed along with other related interfaces, in order to understand the current solution. The overall conclusion is that, although the current interfaces are easy to use, there are some flaws that may affect user performance and learnability. Since efficiency is important for users, the new interface should be capable of overcome these issues, providing a more satisfying experience. The next step of this project is to gather concrete ideas and solutions to solve some of the analyzed problems in this chapter along with some problems that may arise from mxfSPEEDRAIL products utilization in touch screens. In order to obtain viable solutions, it will be created low-fidelity prototypes to quickly test the ideas. They will be tested first with MOG‟s team and then with users from a TV production context, in RTP. Analysis and Requirements Gathering 48 Chapter 4 Proposed Solution This chapter describes the overall concept of the proposed solution and the main design choices made. It also documents the testing process used to validate the ideas proposed during the design phase. 4.1 Design Redesign a graphical interface is an evolutionary process. To adapt the current interface for tablet screens, some strategies were considered. The proposed solution is the result of a study that involved mainly a structure reformulation and content organization. It was analyzed how to display the current interface in a smaller and touch-based screen. Having that in mind, some aesthetic aspects like colors and fonts were not particularly tested. However, there was also some preoccupation with the size of the elements in order to make them compatible with touch interactions. As stated before, O1000 and P1000 interfaces are very similar to the interface of F1000. Considering this and due to time limitations, the proposed solution had its focus essentially on the S1000 and F1000 interface. Some of the final changes made to the current layout include:  Responsive layout instead of the current fixed layout;  The concept of project as an abstraction for a better content organization;  Auto detection of the input format;  Ingest as the main operation, trim and merge as auxiliary operations;  No need to save settings, everything is automatically saved; Proposed Solution 50  Improved user and permissions management;  Some panels were merged and redesigned;  Improved trimming with visual feedback;  Possibility to view the output files;  “Remember me” option in login form;  Improved help with contextualized hints;  Tabs instead of panels;  Two types of settings: application settings and project settings;  Improved automatic rules layout with its state feedback (ready, processing or disabled). The following sections describe the most important choices during the design process. 4.1.1 Responsive layout One of the problems raised during the analysis described in the previous chapter was the lack of space optimization. In fact, there is a lot of empty space in the current GUI of mxfSPEEDRAIL that is not being taken advantage of, as shown in Figure 4.1. This problem contrasts with the large amount of information that RTP users complained as described in section 4.3.2. There is a lot of space that is not being used and, at the meantime, there is a lot of information being displayed. Figure 4.1 - mxfSPEEDRAIL F1000 layout displayed in a monitor with 1680x1050 resolution This happens because the current layout is fixed and it was not designed to adapt to different screen sizes. This means the bigger the screen, the larger the amount of unused space, Proposed Solution 51 since the panels‟ dimensions remain the same. On the other side, users with low resolution screens may have to scroll to see all the content. Hence, one of the design decisions for this project was to implement a responsive design in which the layout adapts to the viewing environment, displaying elements homogeneously and taking advantage of the whole screen space. This is particularly useful for tablets, since their screen size is much smaller than desktops and it can range between 7 to about 10 inches, as shown in section 2.3.3. A design that adapts to the device to what is being displayed is not only a good practice but also a future-proof experience. 4.1.2 Layout structure and customization Another problem with the current interface is that, although it is possible to edit the layout, the default screen has a lot of information that most of the times the user does not need. Therefore, it was thought to apply a tab system rather than maintaining the panels. This has the advantage of grouping similar information in one place, hiding it and only displaying it when it is really necessary. Figure 4.2 illustrates the main concept differentiating, by default, the main tab and the secondary tabs. The main tab corresponds to the tab that holds the most important content: in S1000 the main tab is the player, in F1000 the main tab is the activity. The main tab is bigger than the secondary tabs and it is shown on the left of the screen, since the most common order of reading is from left to right. Figure 4.2 – Draft of the layout for S1000 (left) and F1000 (right) main screens Proposed Solution 58 Figure 4.8 – A context menu mockup that provides the “Delete” and “Mark as favorite” options on a given project 4.2 Prototyping In order to validate the design proposals described before, several mid-fidelity mockups were designed. For this purpose, Indigo Studio (v1 update 12) was used as a mockup tool, considering a resolution of 1280 x 800px. These mockups allow interaction and screen state changes. Each screen is described in the next sections. A web-based prototype was also built. Due to time restrictions and for demonstration purposes, this prototype only includes the S1000 screens. It also includes some responsive mechanisms (in order to adapt to either big or small screens). Further information can be found in the appendix H. 4.2.1 S1000 Mockups The first screen the users see when they access the system is the login screen. As shown in Figure 4.9, this screen contains only the login form for user authentication. Since unauthenticated users do not have access to the system, this form must be separated from the rest of the layout. The login form contains one “Keep me logged in” checkbox, in order to avoid logouts by, for instance, accidentally closing the browser window. It also has an option to unmask the password, to ease the password input, especially in tablets where input mistakes may be common. Proposed Solution 59 Figure 4.9 – Mockup of the login screen As seen in section 4.1.4, if users have any doubt regarding the interface, they can get more info by clicking the question mark icon in the bottom-right of the screen. This will provide contextual help by giving hints about the layout elements that are being displayed. As shown in Figure 4.10, there is also the option to see the user manual to access to a more detailed information. Figure 4.10 – Mockup of the login screen with help hints After logged in, the user sees the projects screen. In this screen, users see all the projects they have access to listed. It is possible to search for projects as well as to see their recent and favorites projects. Projects are also divided in two types: single and gang control. The first Proposed Solution 60 refers to projects where it is only possible to control one S1000. The second refers to projects where the control of several S1000 is needed. As shown in Figure 4.11, there are also three buttons in the top-right of the screen that provide access to the schedule, settings of the application and logout, respectively. To create a new project, users have to click on “Add new” at the beginning of the list. Figure 4.11 – Mockup of the projects screen before user testing As described in section 4.1.7, it was thought initially to implement a context menu to ease and empowering the interaction. This menu would be accessed in desktops by clicking with the right button and in tablets by long pressing the layout. However, this idea was discarded as a result of user testing, since users were not able to figure out that there was a new type of interaction. The projects screen was then redesigned in order to solve this problem, as shown in Figure 4.12. It now includes a specific button to delete a project, mark as favorite or even to duplicate a project, in order to ease the creation of similar projects. The redesign also discarded the single and gang-control separation, since user testing revealed that every project shall make it possible to add and control several or just one S1000 (section 4.3.1). Proposed Solution 61 Figure 4.12 – Mockup of the projects screen after user testing When creating a new project, a new screen is shown (Figure 4.13) for project setting. In this screen, project settings are grouped into eight categories:  General – for broader settings (i.e.: project name);  Input – for configuring the input signal (i.e.: resolution, frame rate and timecode);  Output – for configuring the output files, including the high and low resolution (proxy) settings;  Metadata – to select and edit the metadata preset to be used;  Locators – to select and edit the locators preset to be used;  Clipnaming – to edit the name of the output clips;  Permissions– to select which users have access to the project;  Advanced – for other type of configurations that may not be frequently required; These categories are displayed in vertical tabs. Each time that a tab is selected, its related settings are shown on the right side. This is a common pattern in tablet applications. According to Android Design guidelines [46], this is the combination of a related list and its detail view into a single compound view, and it ensures the efficiently usage of the tablets‟ screen space as well as make the navigation easier. When selecting a setting, a dialog is prompted to ask for user input, whether to select from a list of options or to enter some text, as shown in Figure 4.14 and Figure 4.15. Proposed Solution 62 Figure 4.13 – Mockup of the project settings screen Figure 4.14 – Mockup of the dialog screen asking for user to set the project resolution Proposed Solution 63 Figure 4.15 - Mockup of the dialog screen asking for user to select the users that have access to a project After configuring the project, users access the main screen of the project, as shown in Figure 4.16. As described in section 4.1.2, this screen is composed by several tabs and it is by default divided in two sections. On the left, there is the primary tab, the player tab, where media is being displayed and can be controlled. On the right, there are the secondary tabs where is possible to add metadata, see the output files or create recording events. All the tabs are listed below:  Player – this is where media and its timecode is displayed and controlled;  Overview – this is the default tab to be displayed, it lists the main project settings;  Locators – to activate locators during recording;  Metadata – to change and control video metadata;  Log – to display warning and error messages as well as keep the actions historic;  Files – to display and play the output files of the project;  Schedule – to add and control the recording events of the project; Users can also access project settings by clicking/tapping the button with the cog icon on the top-right of the screen. Proposed Solution 64 Figure 4.16 – Mockup of the default S1000 project screen When the user starts recording the input signal, the system state changes and some elements are modified, as shown in Figure 4.17. In the player tab, a “[REC]” label appears on the top-right of the video player. The start timecode as well as the output duration are registered below the recording button. The seek bar beneath the video is enabled and makes it possible to review and add locators to the recorded content while recording. In the files tab, a new item is added in order to represent the file that is being recorded. To stop recording, user must click/tap on the record button again. Figure 4.17 – Mockup of the default S1000 project screen (recording) Proposed Solution 65 The Figure 4.18 shows the interface while controlling several S1000. Each video player represents one controlled device, until six units maximum. It is possible to control all the systems at the same time or individually by using the record button below each video player. The resulting output files share the same settings as specified in project settings. Figure 4.18 - Mockup of the S1000 project screen with gang-control To go back to the initial screen (projects) users have to close the project with the „X‟ button on the top-right of the screen. The scheduler screen is similar to most of the calendar applications for tablets, as shown in Figure 4.19. It has the option to view the calendar by day, week or month. It has also the option agenda view, where all the events are listed and grouped by days, as shown in Figure 4.20. There are two ways to create an event: either by dragging one project that is listed on the right to the calendar or by simply clicking/tapping on the calendar. It will open a dialog (Figure 4.21) asking for the event type (whether a recording event or an event to reboot the system), the time and date of the event (it can be specified either the starting time and the duration or the starting time and the end time), the project (if it wasn‟t dragged) and the event periodicity (if unique, every day, week, month or year). Proposed Solution 66 Figure 4.19 – Mockup of the scheduler screen in month view Figure 4.20 – Mockup of the scheduler screen in agenda view Proposed Solution 67 Figure 4.21 – Mockup of the dialog screen for creating an event As seen before, the application settings are accessible through the button with the cog icon on the top-right of the projects screen. Here it is possible to change general configurations about the system like language, look and feel, presets and users (Figure 4.22 and Figure 4.23). Application settings use the same pattern as the project settings with the vertical tabs on the left and the content on the right. It has the following tabs:  General – it contains the overall configuration of the application (language, look and feel, date format, …);  Input – it contains the options regarding the input of the machine where the application is running;  Storage – it allows to manage the storages servers on the system;  Asset Management – it allows to manage the media asset managements on the system ;  Locators – it allows to manage the locators presets;  Metadata – it allow to manage the metadata presets;  Users – it allows to managed the users that have access to the system;  Advanced – other general configurations that aren‟t used frequently;  Import – it allows to import files that contains settings from other systems to make it faster to configure the system;  Export – it allows to export files that either contains the current settings or the application log. Proposed Solution 74 controls control both the VTR and the recorded output. In most of the tests users found these situation ambiguous and did not felt confidence about its behavior. Also in S1000, users did not find the type of project division useful, since they felt that it should be possible to control several players, no matter the type of the project, particularly in projects with two video channels. Also, in F1000, users had difficulties to understand the asset explorer screen. Although they understood the overall purpose of the screen, they had doubts about the purpose of the “To Process” list. This list was also perceived as an unnecessary element since it end up being an extra step for manually ingest an asset. Despite these problems, users find the overall interface more pleasant and clear. They specially liked the content organization, since there is less unnecessary information being displayed, decreasing the visual noise of the screens. Since it has more space, it is easier to understand its structure and consequently it is easier to use. They also found the new help structure useful, although they did explore it in detail. Some of the suggestions made by the users include the separation of the desktop and tablet use cases. They found it difficult to configure a project from the tablet perspective, considering that it involves too much input for which touch interactions may be harder and slower. Some users considered that, by having different but coherent designs for each device, it would be possible to take the most of their characteristics and to provide a better user experience. 4.3.2 RTP Testing RTP is a public radio and television service that produces several television contents. In terms of ingest workflow, RTP uses two mxfSPEEDRAIL products - S1000 and F1000 - that are located in a specific room for ingest, along with several VTRs and screens, as shown in Figure 4.30. The recorded media is delivered in this room, using tapes, as shown in Figure 4.31, and then played by VTRs while mxfSPEEDRAIL S1000 records it into files, as shown in Figure 4.32. After this process, mxfSPEEDRAIL F1000 is used to trim the files in order to remove undesired frames. The resulting files are then transferred to an edition server where they are imported to Avid Media Composer, in order to be finalized. Although the user testing at RTP was planned according to the specifications stated in the last sections, it ended up being performed differently due to time and space restrictions. Since this test was conducted at RTP studios during the office hours, the user feedback ended up being gathered through an informal conversation with one of the RTP‟s media operators and one of the RTP‟s technical directors. Although it is better to observe users than to listen to them [49] the gathered information proved to be useful since it helped to understand users‟ expectations and reactions when facing the new design. Initially, users were asked about how the mxfSPEEDRAIL is currently being used at RTP. Their answers had confirmed some of the problems raised in the chapter 3, like the difficulty in Proposed Solution 75 learning how to use the current interface and the big amount of information that is displayed. It was also possible to conclude that users were not taking advantage of all the functionalities of mxfSPEEDRAIL, since they were not aware of them all. They also confirmed the need for operation speed, especially when trimming videos. The next step was to show the new interface to the users. The same low-fidelity prototypes used for user testing in MOG were used and displayed in a laptop with a mouse. Generally, users find the new interface more pleasant and easier to learn. They specially liked the idea of using tabs to organize the information since it hides the unnecessary information and, at the meantime, it keeps the functionality. They also liked the layout structure since it favors the size of relevant content like the video player in S1000 and the activity status in F1000. The seek bar in player was also seen as a good improvement, since it eases some operations like assert trimming and video navigation. The introduction of the concept of project in the mxfSPEEDRAIL interface was also seen as a good feature for the users. As it is possible to see in Figure 4.31, most of the tapes to be recorded are identified with the project/TV show name. However, there may be tapes that do not belong to a specific project. Hence, the new solution should also provide instant access to the system functionalities without forcing users to create a project. According to users, the new solution still lacks some functionality. First, it doesn‟t support keyboard shortcuts to control the interface. Since RTP users are used to work with NLE‟s like Avid Media Composer, which allows keyboard usage as a quick way to access the system‟s functionalities, implementing keyboard shortcuts would be useful to accelerate some operations like media navigation and asset trimming. The new solution also lacks elements for sound control, as implemented in the current design. For trimming assets, some additional controls are also needed, especially marker controls like “Go to In”, “Go to out” and “Clear Marks”. These controls are also frequently used in the video edition software. When considering the use of the proposed solution in tablets, users demonstrated some reluctance. Similarly to MOG‟s users, RTP users considered that tablet and desktop should be used for different purposes in order to take full advantage of their characteristics. They stated that tablets can be useful for basic operations and especially for system monitoring. Complex operations like configuration are likely to be done with desktops since it would be faster. RTP users also confirmed that tablets would also be useful in terms of mobility, which is important for them. Proposed Solution 76 Figure 4.30 – VTRs in the ingest room at RTP Studios Figure 4.31 – Video tapes identified by project ready to be ingested at RTP studios Proposed Solution 77 Figure 4.32 – Desktop running the mxfSPEEDRAIL S1000 application at RTP Studios 4.4 Conclusions The proposed solution was designed in order to improve the learnability, understandability, usability and user satisfaction of the current mxfSPEEDRAIL interfaces and to make them compatible with touch interfaces. The new interface appears as a more structured, well organized and pleasant solution. By contextualizing the information that is displayed on screen, it improves the understandability of the system, since it only shows what is necessary for the user. Consequently, there is more space in the screen that leads to a better understanding of how the elements are grouped and their importance. These aspects contribute for an intuitive interface that offers a low learning curve, as demonstrated in user testing. However, user testing has also demonstrated that the proposed solution can be further improved for some use cases. In the majority of the tests, users spent more time configuring the system rather than using it. It also gave users a false sense of too much screens, when in fact, only two are needed to operate the system. This happened because configurations are extensive and they require a big amount of input. Since touch screens do not favor input speed, the system configuration is more likely to be done in desktops rather than tablets. However, tablets seemed to be a good option for monitoring and controlling the system since these tasks were achieved with ease during user testing. Proposed Solution 78 It is also important to note that users are still focused on the desktop usage of the application, which means that they may not be completely aware of the advantages in using mxfSPEEDRAIL in a mobile context. To overcome this, it is important to identify specific use scenarios for tablets, for which the mobility factor and the natural interaction of the touch screens are advantageous comparing to the desktop interaction. User testing was an important step to validate the proposed solution. Testing the new design with users made it possible to gather real insights of users‟ perception. This was important in order to understand, justify and readapt some of the design choices made according to the application use environment. Some of the modifications were already incorporated as seen previously. However, this is an evolutionary process, since users may assign different importance values to different things in different situations. As a part of the UCD process, the proposed solution should now incorporate some of the results gathered and continue to be tested with users in an iterative process. This will guarantee that the gap between the resulting solution and the users‟ needs is decreased. Chapter 5 Final Conclusions and Future Work Designing interfaces suitable for both desktops and tablets can be a challenging task. These are two very different devices with different characteristics, different ways of interaction and, consequently, they require different approaches. However, it is known that mobile is becoming a technological trend, which means that nowadays running an application or accessing a web page does not necessarily require a computer. Moreover, this provides an interesting new set of opportunities that favors the digital experience by making it possible to do desktop tasks on the go and with little effort. Video post-production can also be very challenging. With the appearance of the file-based systems, video workflows became more efficient but at the same time less interoperable. They may require tasks like ingesting and transcoding in order to support different formats, which may be repetitive and time consuming. Media companies are continuously evolving in order to offer better products and optimized experiences to their clients. With this project, the graphical interfaces of the post-production solutions provided by MOG Technologies were redesigned aiming to make them compatible both with desktop and tablets. On one hand, it was proved that it is possible to have an interface design for postproduction that addresses both devices‟ requirements and provides consistency and functionality. One the other hand, it was concluded that tablets can in fact improve postproduction workflows by helping controlling and monitoring the ingesting systems. They are also advantageous since they are a compact device that offers mobility. However, for system configuration, desktop seems to be the most preferred and practical device. Moreover, due to screen size restrictions, designing the proposed solution with tablets in mind has forced the Final Conclusions and Future Work 80 system to be better structured and organized, with a cleaner layout, making the system easier to learn and to use. 5.1 Accomplished Goals During this project, most of the goals and sub goals initially defined were met, along four different phases: state of art gathering, analysis and requirements gathering, designing a new solution and testing it. First, the state of art was gathered and analyzed in order to understand better the context of the project. This was successfully done as it gave insights about the video production workflows, its processes and the related software solutions. Since there was also some study about the user centered design process, it also helped keeping in mind the main usability and interaction design principles, which were useful for the next project phases. The analysis and requirements gathering was also successfully conducted since it helped to clarify some doubts, to understand the structure and the layout of the current solution, and to focus on the most important requirements for the new design. To do so, it was conducted and heuristic evaluation that resulted in a list of potential usability errors that were considered during the design phase. It were also conducted some interviews, task analysis and the creation of personas and scenarios, that made it possible to gather and define both the system requirements and the main usability goals to achieve with the new design. From the design phase resulted a concept that was reproduced in a set of mid-fidelity mockups, which solved some of the problems raised during the heuristic evaluation as well as made it possible to use the interface in both desktops and tablets. By contextualizing the screens, it was possible to fit the layout in small screens but keeping the functionality. Due to time restrictions, it was only possible to focus on two of the four products of MOG Technologies. However, since these products are very similar, the proposed solution already covers the most important elements of the other two. Last but not the least, the testing phase helped to understand the feasibility of the proposed solution, giving insights about what was improved and what needs to be improved. First, testing was conducted with some collaborators from MOG, and then it was done at RTP studios in Vila Nova de Gaia, with users from the television context. This was particularly grateful since it allowed to better understanding how the proposed solution can improve the television workflows and what the impact of touch interfaces on these environments. Final Conclusions and Future Work 81 5.2 Future Work As conclude before, tablets are convenient for monitoring and controlling the system with ease and efficiency. However, desktop seemed to be more suitable to perform configurations since they require a lot of input. Considering this, the proposed solution can be optimized and enhanced by changing the layout according to each device and its specific context. By providing a different but consistent graphical interface, it will allow to address the different use cases and use contexts of each device, which results in a better usability and a better user experience. Besides considering the differences between devices, the improvement of the proposed solution can include a new type of user: the creative user. That way, admins would be responsible to configure the system, ingesters would be responsible to monitor and to control the system and creative users would be responsible to preview media and operate it. This way the interface would be adapted in terms of functions and technical knowledge, improving its accessibility by different roles of persons involved in the video production process. Since video workflows are integrated processes, it is also important to consider that, having one global interface for controlling several products may lead to better results. As seen during the RTP testing, mxfSPEEDRAIL products are used complementarily, which means that user has to access different interfaces to control them. With one global interface, user would be possible to control and monitoring the system in one place, speeding up the process. Final Conclusions and Future Work 82 S1000 Evaluation 83 Appendix A S1000 Evaluation 6.1 Description Product: S1000 v2.7.1 Evaluator: André Alves Date: 01/04/2013 Main Goal: Ingest video from SDI input Tasks: 1. As admin, add a storage to the system 2. As admin, add a MAM to the the system 3. As admin, create a ingest profile 4. As admin, create a new ingester user 5. As ingester, ingest from stream 6. As ingester, add metadata 7. As ingester, manage streams 8. As ingester, schedule multiple (up to 5) ingests 9. Change your layout 10. Browse around the application 6.2 Results # Description Violated Heuristics Severity How found? 1 The default look and feel has low contrast. 1 3 Browsing 2 Sound control is not clear. 4 3 Browsing 3 It is possible to copy and delete a storage when there is none. 5, 8 2 Creating a storage F1000 Evaluation 90 45 Things deleted in browser still appear in remote desktop, with errors. 1, 5 4 Creating a user 46 When I create a new storage “undo” option is available (although I did not do anything). 2, 4 2 Creating a storage 47 It is not possible to write special characters like “ã”, “é” in “display name” field, but it is possible to write them in the name field (above), although they are the same. 3, 4 2 Creating a user 48 When creating a new metadata profile, same icons appear twice, and some have different behavior, (i.e. trash icon in the left column is to delete one metadata profile, but in the right section is to delete all of metadata fields). 4 3 Creating a metadata profile 49 In source fields, there is an empty column. 8 1 Creating a metadata profile 50 Combobox to change all options is not correctly identified and it is away from the column that it modifies. 6 2 Creating a metadata profile 51 When type is a list, it appears a pencil to edit. You can add several items with the same name but when you save, it only saves one. 1 3 Creating a metadata profile 52 Nothing happened when choosing a metadata profile. 4 2 Creating a clipnaming profile 53 Counter should be numbers by default instead of letters. 2 2 Creating a clipnaming profile 54 It should be possible to delete labels with the keyboard (by pressing “delete”). 7 2 Creating a clipnaming profile 55 In remote version, after changing language, there are still some options in english (i.e. shutdown, restart, help, search here,...). 4 3 Browsing 56 Help manual is only provided in english (no matter what language is selected). 10 4 Browsing 57 When creating a new user, it is possible to include “.” in the username. However, login form doesn't accept the “.” character. 4 4 Creating a user 58 Username can have spaces in it. 2 3 Creating a user 59 When I delete HiRes and Proxy there is still a combobox hidden. 8 1 Creating a workflow profile 60 Combobox in proxy is repeating HiRes combobox. 8 1 Creating a workflow profile 61 Metadata is repeating clipnaming. 8 2 Creating a workflow profile F1000 Evaluation 91 62 Advanced options have many options. 8 1 Creating a workflow profile 63 What is that number one in output and asset management? 8 1 Creating a workflow profile 64 When I login as ingester I do not see any locations, and I do not have a clue how to add them. 6 2 Ingesting files 65 In Asset Explorer, when I mark one location's checkbox there is no immediate feedback (whether it has assets or not). 1 3 Ingesting files 66 As an ingester, the “New Job” button appears although I am not able to create jobs. 3 3 Ingesting files 67 Ingester cannot choose language, and admin's language is not applied to ingester. 4 4 Browsing 68 I don't know which locations are devices, storages or MAMs, neither the state of them (online, offline,...). 1 3 Ingesting files 69 Trash button in notifications has a tooltip that isn't true 10 4 Browsing 70 Asset selection has a “asset browser” that lets ingesters adding files from folders that aren't in locations. 5 4 Ingesting files 71 In automatic jobs, the confirm button is small and hidden. 6 2 Creating an automatic ingest profile 72 It is not possible to edit an automatic job. 7 3 Creating an automatic ingest profile 73 Notifications are too big and too technical. 8 1 Browsing 74 Selected color in activity is not obvious. 1 2 Ingesting files 75 An ingester can stop flows created by the admin. 5 3 Ingesting files 76 Clear clip list does not ask for user confirmation. 3 2 Trimming clips 77 Distance between “in” point and “out” point buttons is too big. 7 2 Trimming clips 78 In and “Out” icons are not obvious. 6 2 Trimming clips 79 Activity does not have “clear all” options as in the clip list panel. 7 2 Ingesting files 80 When “Out” point is smaller than “In” point, there is an error. But user only sees the error during the ingest process (and with a technical message). 5, 9 3 Trimming clips 81 After ingesting, the clip list of a file disappears. 7 2 Trimming clips 82 Too many clicks to add a clip. 7 3 Trimming clips 83 Control buttons have no tool tips. 10 2 Trimming clips F1000 Evaluation 92 84 Clip list only appears after two clicks. 1 3 Trimming clips 85 Edit time values should avoid user to delete the “:”. 5 2 Trimming clips P1000 Evaluation 93 Appendix C P1000 Evaluation 8.1 Description Product: P1000 v2.9.11 Evaluator: André Alves Date: 29/03/2013 Main Goal: Video files playout Tasks: 1. Play a video file, pause it and then stop it 2. Choose another file to play 3. Seek a specific position in a video file 4. Find currently playing video information and metadata 5. Create a playlist with 3 videos 6. Replace the second video for another 7. Adjust sound volume 8. Browse around the application 8.2 Results # Description Violated Heuristics Severity How found? 1 Stop button is always highlighted. 8 1 Playing assets 2 Stop button is always activated (even when the movie is already stopped or there is nothing to stop). 8 2 Playing assets 3 Control buttons does not have tool tips. 10 3 Playing assets 4 Video seek bar is very similar to the controls separator line. 6 3 Playing assets 5 Video seek bar is far from controls, making seekpause operations difficult. 7 2 Playing assets P1000 Evaluation 94 6 Hover in control buttons is not distinguishable. 1 2 Playing assets 7 In playlist, each video is identified by one number (its position in playlist), rather than the name (that is only shown by hovering it), making it difficult to identify the assets. 1 3 Playing playlist 8 Eject button appears as clear playlist rather than its common eject purposes. 4 3 Playing playlist 9 Playlist created by admin appears in the ingester session. 5 2 Playing playlist 10 It is not clear which video is playing in a playlist. It should be highlighted. 1, 6 3 Playing playlist 11 It is not possible to edit a playlist. User has to “eject” all assets and then add one by one again. 7 3 Playing playlist 12 In asset explorer you user have to click twice to play an asset. In playlists, user only has to click once. 4 2 Playing assets 13 It is not possible to adjust sound volume. 3 3 Playing assets 14 It is not possible to save playlists. 7 2 Playing playlist 15 Select override time code while playing a video file does not do anything. 3, 4 3 Browsing 16 Seek bar does not color the section already played. 1 3 Playing assets 17 After clicking in play, feedback is not immediate. 1 3 Playing assets 18 It is not possible to set current position by typing a time value. 7 3 Playing assets Interview with the Support Team 95 Appendix D Interview with the Support Team This interview was conducted in MOG‟S offices, in March 11th of 2013, with Sandro Fraga, Support Engineer at MOG. 9.1 Questions about users 1. Who are the users of the application (primary and secondary users)? There are two main users: admins and operators. Admins are the ones who configure and set up all the settings, profiles and layouts. They prepare the system for operators to use, enabling them to access needed features only. Operators are responsible to use the application doing simpler operations. This hierarchy is more likely to be followed by big organizations, while there may be small organizations where the admin is simultaneously the operator. 2. How would you describe the users (user characteristics, i.e., age, experience, education, etc.)? It depends on the client. There are people of all ages, usually with higher education. 3. What is the average user background? Are they familiar with post-production and video fields? It depends on the client. Usually admins are experienced persons, familiar with video and post-production technology. On the other hand, operators may have less technological knowledge. Interview with the Support Team 96 4. When and where do users use the application (physical environment and user context)? Mainly low light rooms with lot of screens and controllers. In some cases, i.e. OB Vans, space is limited, so there is the concert of keeping the space as organized as possible. 5. How are users accessing the application? (user computer settings, i.e., connection speed, resolution, sound, etc.) Screen size may vary, but usually it is greater than or equal to 15 inches. Computers have no sound since that audio is processed separately. Local connection speed is usually fast. 9.2 Questions about tasks 1. What are users doing in the application? (users tasks, content, features and functionality) Users usually change layout using layout editor, generally keeping the workspace organized. Sometimes they even resize panels meticulously. They also use “export settings” in order to configure multiple computers. 2. Which features are most important to users? (importance) Being able to configure the system to run automatically is one important feature for most of the users. 3. Which features are prone to usability issues? (vulnerability) In gang control, stop/record buttons size are smaller than the main buttons so users keep clicking in the wrong ones. Users may take half a day to input the week scheduling in S1000. Sometimes it is hard to perceive some elements due to the default low contrast look and feel. Although there is the option to choose high contrast in settings, users usually don‟t find this feature or don‟t know that it is possible to change. 9.3 Questions about training 1. Do users find it easy to master the application? Yes, usually users don‟t have difficulty understanding the application. Training sessions are also given according to each company workflow. There is no need to explain all the features since that the company will only use some of them. Interview with the Support Team 97 2. How long does it take a user to learn how to use the application? Most of the times, training services are requested for 1, 2 days. Usually the admins are the ones who attend training sessions, and then they give instructions to operators (i.e., in case of this, do that). 3. How often are the training sessions required? Some companies ask for it. Others don‟t. 9.4 Questions about support 1. What are the most common problems that users report related to lack of knowledge about the application? Sometimes users don‟t know where to click, either because they don‟t know or they don‟t find what they need. Since not all users try to click in everything, they end up asking for support service. 2. Did the usability problems arise after the previous change of interface? No, not really. Interview with the Support Team 98 Interview with the Sales Team 99 Appendix E Interview with the Sales Team This interview was conducted in MOG‟S offices, in March 13th of 2013, with Nuno Silva, Business Developer (Northern Europe) at MOG. 10.1 Questions about users 1. Who are the users of the application (primary and secondary users)? There are users and clients. Sometimes clients are also users, like technicians and operation managers. There are two types of users: operators and administrators. 2. How would you describe the users (user characteristics, i.e., age, experience, education, etc.)? It depends on the workflow. There may be both people with high technological background and people with less technological knowledge. They can be, for instance, engineers or journalists. 3. Why they need the application? (user needs, interests and goals) Their main need is to centralize workflows and to save time and money. 4. When and where do users use the application (physical environment and user context)? There are three main purposes: post-production, news production and live transmissions. The space used for each purpose can be anything, from a garage to an open room (with more or less light). Task Analysis 106 11.3 O1000 Tasks 11.3.1 Outgest files automatically 1. Define the workflow (a) Choose the operation i. Choose the input type (c) Configure the high resolution output (if you want) i. Choose the essence format ii. Choose the wrapper format iii. Choose the output folder (d) Configure the proxy output (if you want) i. Choose the essence format ii. Choose the wrapper format iii. Choose the output folder (e) Configure how the output files will be named (f) Configure how the metadata will be handled (g) Configure the asset management of the output files (h) Configure other options 2. Choose the input folder 3. Start (a) Choose if you want to process all the existing files 11.4 P1000 Tasks 11.4.1 Play a file 1. Choose file to play (a) Open the desired folder (b) Select the desired file 2. Play Task Analysis 107 (a) Press play 11.4.2 Play files from a playlist 1. Create a playlist (a) Open the desired folders (b) Select the desired files (c) Add files to the playlist 2. Play (a) Press play Task Analysis 108 User Testing Script 109 Appendix G User Testing Script 12.1 Introduction This user test is part of the study that is being conducted regarding FEUP‟s dissertation about tactile interfaces in post-production environments. This study aims to create a new graphical interface for MOG‟s mxfSPEEDRAIL, suitable both for desktops and tablets. The main goal of this test is to understand how the proposal solution would improve the learnability, the efficiency and the overall satisfaction of the user when using this interface in the above mentioned devices. 12.2 Instructions - These mockups were designed for desktop and tablet use. Please keep that in mind while doing this test. - You are testing the mxfSPEEDRAIL S1000 (capture) and F1000 (ingest) proposed graphical interface. - Note that the first screen is an auxiliary screen, so that is possible to access to both S1000 and F1000. - These mockups have interaction. Interactions are highlighted in yellow. - Not all elements have interaction. If you need to do something that doesn‟t have an interaction, I‟ll explain. - Please keep describing what you are seeing/thinking during the test. User Testing Script 110 12.3 Workflow The editor server must receive files with the following formats: - Format: MPEG LGOP @50 - Wrapper: Quicktime - Resolution: PAL - Metadata type: AS11 - Clips‟ name: Topgear_000, Topgear_001, Topgear_002, … 12.4 S1000 Tasks 1. Log in. 2. Create a new project called “Top Gear”. 3. Setup the project according to the specifications given, and give access permissions to two users of your choice. 4. Record a file and add info to footage during recording. 5. Write some metadata. 6. Schedule one capture event in order to automatically record today at 8pm for 2h. 7. Delete the created project. 8. Create one ingester user. 9. Log out. User Testing Script 111 12.5 F1000 Tasks 1. Log in. 2. Open the project “Top Gear”. 3. Create an automatic rule that automatically ingests all the assets that will appear in the main folder of the “Input Server”. 4. Ingest one asset manually, but before doing that, play it so you can confirm that is the asset that you want. 5. Log out. 12.6 Questions 1. What frustrated you most about this layout? 2. How would you improve this layout? 3. What did you like about this layout? 4. Is there any functionality that you would like to see? 5. Did you find this new interface understandable? 6. Did you find this new interface easy to master? 7. Did you find this new interface efficient and practical? User Testing Script 112 Prototype 113 Appendix H Prototype 13.1 Technologies This prototype was built using HTML, CSS and Javascript web technologies. For fast development, some frameworks were also used: jQuery for DOM manipulation, backbone.js for MVC structure, Twitter Bootstrap for layout customization and responsiveness and Handlebars for template building. It was also used Backlift, a backend as a service (BaaS) that ease the creation of a small yet functional backend. 13.2 Screenshots Prototype 114 Prototype 115