Multi-device experience design: supporting an equal flow
of fantasy sport platforms played on different devices
SUBMITTED IN PARTIAL FULLFILLMENT FOR THE DEGREE OF MASTER
OF SCIENCE
Wesley Liefhebber
11802979
M
ASTER
I
NFORMATION
S
TUDIES
H
UMAN-
C
ENTERED
M
ULTIMEDIA
F
ACULTY OF
S
CIENCE
U
NIVERSITY OF
A
MSTERDAM
July 27, 2018
1st Supervisor 2nd Supervisor
Dr. Frank Nack Dr. Dan Buzzo
Multi-device experience design: supporting an equal flow of
fantasy sport platforms played on different devices
MSc Thesis: Information Studies (Human Centered Multimedia)
W.B. Liefhebber, 11802979
University of Amsterdam wesley.liefhebber@student.uva.nl
ABSTRACT
Platforms serve their customers across many different devices. Each device has its own characteristics. Therefore, platforms have many different applications which have their own interface design and architectural structures. However, when using these devices in-terchangeably, it sometimes occurs that users are not able to find functionality or information which they are used to on another device, which leads to frustration, disorientation and decreased user navigation. Therefore, this study will focus on what the effect of designing for an equal flow is on the UX of a fantasy sports plat-form. During this study, a literature review revealed that a shared Minimum Viable Product (and architecture), visual language and interaction types have an influence on the equality of the multi-device flow. These parameters were implemented into a prototype and evaluated, showing that the architecture of a platform is most important in giving a familiar feeling and being able to find func-tionality and information. Further research on this topic should include how a shared understanding of important tasks within the MVP can be achieved and how structures of various platforms can be synchronized to improve multi-device and multi-platform usage.
KEYWORDS
Multi-device, UX, fantasy sports, interaction design
1
INTRODUCTION
Currently, platforms are serving customers their services across many different devices. On each individual device, the platform is presented differently due to the specific limitations and oppor-tunities of each device. According to Chiang et al. [3], paradigms describing the design for desktop devices do not work on mobile devices, since the size of both devices is different. Additionally, Chiang et. al. [3] also addresses that mobile devices are limited to their size or limited to a single window, while a desktop application is not limited to these constraints. This implies that both of these interfaces should be designed according to the design rules of that specific device, whereby this process is calledmulti-device experi-ence design [13]. Additionally, devices support different interactions, such as tapping or swiping, which create different in- and outputs [15]. All factors above indicate that a platform has multiple design approaches regarding each individual device, to optimize the UX on each specific device.
Regarding the difference of devices, tasks that users want to per-form on a platper-form (running applications on both devices) might be different in terms of interface appearance (visual) and the se-quence of steps to perform a task (structure). According to Yanez et al. [27], on a mobile device tasks are typically relatively different
from where users are familiar to compared to a traditional desktop device. This implies that tasks could involve more or less steps to follow, or that some tasks involve different steps during execution. Additionally, information that is needed to perform a task could be hidden or located somewhere else on a mobile device compared to the desktop version of the application [27], meaning that the architecture of a platform is different on each device.
According to Levin [13], the concept of using different devices in daily life can be called amulti-device world, in which devices are connected together and where users switch between them while completing tasks. Therefore, it is possible that users perform a certain task while using various devices [11], for example a task that is started on a mobile device and finished on the desktop. As stated earlier by Yanez et al. [27], the flow of performing tasks is different compared from desktop to mobile devices. This implies that to perform a certain task, different steps have to be undertaken to complete the task on different devices, leading to frustrations [7]. Think about updating a profile on a platform. The way to get to the profile settings might be very different on each device (different steps to get there). When a user is used to the way of updating his or her profile on a desktop device, it might be possible that once the user changes to the mobile application, the user is not able to find the profile settings, leading to frustrations.
Functionality or information might be located on different places or might be missing in the architecture of a platform on each differ-ent device which leads to differences in approaching and performing tasks. These differences lead to disorientation and confusion when people use the platform in a so-calledmulti-device way. According to MacKay et al. [14], users’ familiarity is very important for plat-forms and websites, in which users establish a mental model of the page when they first visit. A very important aspect related to this is the concept of transitional volatility as described by Danielson [5]. This concept explains that platforms may change over time and are experienced differently on multiple devices which can cause disorientation and decreased user navigation [5, 14].
Since the differences between devices lead to disorientation and decreased user navigation when using multiple devices [5, 14], the goal of this research is therefore toinvestigate the effect on user experience (UX) of a multi-device platform designed for an equal flow when played on mobile and desktop devices.
To put these concepts into practice, this study focuses on the interface of so-calledfantasy sports platforms (FSPs) played on differ-ent devices. These platforms are based upon real-world competition data (from sports such as basketball, football or cycling), whereby participants compete against each other to enjoy sports outside of the stadium, often together with friends. These fantasy leagues
typically start with a draft in which participants select a team of athletes who will generate points based upon their achievements in the real-world. The participant with the most points after the league is finished will win the competition [9].
First of all, in section 2 the proposed research questions during this study are described. Secondly, the methodologies that were used are presented in section 3. Thirdly, the results of the research are covered in section 4, 5 and 6. Lastly, the conclusion, discussion and future work are presented in section 7, 8 and 9.
2
RESEARCH QUESTIONS (RQS)
There are a number of research questions (RQs) that should be answered in order to achieve the goal of this research, as stated in the previous section. First of all, it is important to investigate how an equal flow can be achieved on multiple (different) devices of a platform (RQ1). This implies that design parameters should be defined that might have an influence on the equality of the (user) flow, when using a platform on different devices. Secondly, knowing what influence the design parameters have on an equal flow between multiple devices, it is important to investigate how this would be visualized in the context of a fantasy sports platform (RQ2). Lastly, it is important to validate if the proposed fantasy sports platform will enhance the user experience (UX) when the design is created based upon the design parameters that imply flow equality on different devices (RQ3). All these questions finally gives an answer to the main research question (MRQ). The following research questions were covered during this study:
•MRQ: What is the effect on the UX of a multi-device plat-form designed for an equal flow, when played on mobile and desktop devices?
•RQ1: What design parameters support an equal flow of plat-forms used on different devices?
•RQ2: How would a fantasy sports platform with an equal flow on different devices look like?
•RQ3: How would the UX of a fantasy sports platform be affected by designing for an equal flow on different devices?
3
METHODS
The research follows theDesign Science Approach as described by Wieringa [26]. Wieringa describes both a design and an engineering cycle. Within the design cycle there are three phases to be men-tioned: (1) the problem investigation phase, (2) a treatment design phase and (3) the treatment validation phase. The design cycle is the first part of the engineering cycle, which also involves the im-plementation of the treatment in the real world and the evaluation of that implementation. For this study, there is solely focused onthe execution of the design cycle.
Regarding the first phase, Wieringa [26] states that this phase is required to prepare for the design of a treatment, by first investi-gating and learning about the problem and the characteristics of a possible solution (building a theoretical foundation). Therefore, during the problem investigation phase there was focused on defin-ing design parameters that support an equal flow when usdefin-ing a multi-device platform (RQ1). The exploration of these design pa-rameters was done by performing a literature review. The literature review was conducted by using theStructured Literature Review
(SLR) approach as described by Kofod-Petersen [12], to structure the way of retrieving relevant literature that was used during the literature review.
Secondly, during the treatment design phase, an artifact was which potentially treats the problem as stated above [26]. Within the context of this study, the treatment design phase entails the process of defining how a fantasy sports platform would look like when the design is made to support an equal flow on different devices for one single platform (RQ2), according to the design parameters defined in the first phase.Prototypes of both the mobile and desktop interface of the fantasy sports platform was made by using InVision1.
Thirdly, the artifacts (prototypes) created in the second phase was evaluated and validated by performing so-calledusability tests. These usability tests show whether the UX of such a fantasy sports platform is affected by designing for an equal flow on different devices (RQ3).
4
PROBLEM INVESTIGATION
During the problem investigation phase the first research question proposed in section 2 was answered. To answer this question, a literature review was conducted (4.1), while afterwards, the design parameters for creating a multi-device experience on a platform was defined (4.2).
4.1
Structured Literature Review (SLR)
To formally structure the synthesis process of available information, the Structured Literature Review (SLR) method by Kofod-Petersen [12] was used. This method includes multiple steps regarding for-mulating a query to retrieving documents based upon relevancy. The formed query includes multiple constructs, in which the in-tersection of the constructs should give an answer to RQ1. The constructs have alternative terms, whereby an overview is given in Table 1. Although each different digital library has a different implementation regarding the formulation of a query, all queries used were derived from the query below:
(design ∨ interaction design ∨ UX design ∨ interface design) ∧ (flow ∨ user flow ∨ task flow) ∧ (device ∨ mobile ∨ desktop) ∧ (application ∨ platform) ∧ (multi-device) Furthermore, after retrieving the papers (N=57), nine papers (15.8%) were excluded based upon not being written in English or not being accessible (see Table 2). Afterwards, from the 48 papers, 11 were found relevant to RQ1 and were therefore selected (see Table 3). A description of these 11 selected papers can be found in Appendix A. The selected papers were used during the process of defining design parameters, which are discussed in the next section.
4.2
Design parameters
To define what a so-called design parameter is, it is important to investigate what a the concept of a parameter is. Typically, parame-ters are a combination of certain quantities of a system, that show a certain output [21]. To put this definition in the context of this
1InVision. https://www.invisionapp.com/
Table 1: Main constructs and alternative search terms used during the SLR. Main construct Design Flow Device Application Multi-device Term 1 Interaction design User flow Mobile Platform
Term 2 UX design Task flow Desktop Term 3 Interface design
Table 2: Exclusion of papers based on selection criteria during SLR, inspired by Da Silva et al. [4]. Digital library Collected papers Included papers Excluded papers
Google Scholar 28 28 0
Scopus 11 11 0
Science Direct 18 9 9
Total 57 48 9
Percentage 100% 84.2% 15.8%
Table 3: Selection of papers regarding relevancy to RQ1 during SLR, inspired by Da Silva et al. [4]. Digital library Amount Duplicate papers Irrelevant papers Selected papers
Google Scholar 28 0 19 9
Scopus 11 0 10 1
Science Direct 9 1 7 1
Total 48 1 36 11
Percentage 100% 2.1% 75% 22.9%
research, this implies that certain design elements and design ap-proaches (properties) have an impact on the design and therefore an impact on the flow during the multi-device usage of a platform. As seen in the work of Levin, there are a number of design approaches with respect to designing multi-device applications. The three main design approaches are the consistent (4.2.1), continuous (4.2.2) and the complementary approach (4.2.3) and are described below. Afterwards, an answer to RQ1 is given regarding the design parameters that were used during the second phase (4.2.4).
4.2.1 Consistent approach. According to Levin [13], the consis-tent approach entails the process of replicating the same conconsis-tent across different devices, with respect to individual characteristics of each device. This implies that a consistent designed application does not have to be identical, but it implies that the same content is ported to each device and displayed whereby the designs are made as consistent as possible, with respect to the individual devices (such as screen size). This implies that there is a continuous trade-off between consistency within the ecosystem of the application and the optimized experience per device [13], meaning that simply copying a platform from a device to another device is not a good practice. While on the other hand, making applications completely different shows problems as stated above [13]. Regarding the de-sign differences of individual devices, the desktop version shows an overview while the mobile has more focus towards a specific selected element. Although this introduces differences in interac-tion, the location of the functionality or information is on the same place (in the architecture), and therefore the design is considered as consistent [25].
First of all, as seen in the work of de Oliveira and da Rocha [7], creating a consistent design involves creating a solid conceptual
model for a multi-device application. A conceptual model is defined as a description that involves the main concepts of what a system does, how it behaves and how it looks regarding the understand-ing of the user [19]. This implies that a good practice would be that the conceptual model is shared among all different devices, meaning that from the user perspective, the mental model that is created should be the same and applicable to each individual device. de Oliveira and da Rocha [7] describe an example of this situation, in which checking account balance (task) should be performed the same way on a mobile phone as on a ATM machine. This implies that the amount of conceptual models is not equal to the amount of devices, regarding the concept of Conceptual Multi-Device De-sign (CMDD) [7]. Levin [13] underlines this concept, by stating that it is important regarding the consistency approach to keep the Minimum Viable Product (MVP) consistent across all devices. The MVP is considered as the features that are vital for the experience, meaning the core tasks that are being performed on a platform [13]. Additionally, O’Leary et al. [17] points out that it difficult for users to learn different interfaces and interaction conventions. According to Vo [24], by designing the User Interface (UI) consistently, the user is able to benefit from so-calledtransfer of training [24]. This implies that when a certain system is consistent, people learn how to perform a certain task on a specific device and when they move over to a complete different device, thanks to the consistency they still can recall what they have learned. This means that people do not or generate less inconsistencies with their present mental models when performing the same task on a different device, which implies there is no need to readapt which causes frustrations, un-certainties and distrust regarding the platform of use [7]. Therefore, the architecture is important for users to create a clear mental model
and to provide a consistent structure and flow [13], to enable users to transfer the mental model from one device to another accessing the same platform.
Secondly, Levin [13] defines that it is important to have a com-mon (visual) language and terminology shared acom-mong the different devices of a multi-device application, since it stimulates the cogni-tive and affeccogni-tive connection between devices.
Thirdly, devices are different regarding their input and output. According to Bangor and Miller [1], a GUI or full-screen website is not portable, whereby other interfaces and types of interaction become important. For example, interaction with a mouse and keyboard are not typical for a mobile device, where touch is the standard. As seen in the work of Dolgobrod [8], touch is more intuitive compared to a keyboard and a mouse, but is not as precise. This implies that this is a huge factor in designing an application, since zones of interaction and elements should be adapted to this type of input. Additionally, Dolgobrod [8] states that mouse-based interactions are not applicable on mobile devices. For example hovering, which is widely used among the (desktop) web to show drop-down menus, is not possible on mobile. Therefore, during the design stages it is important to investigate how certain tasks are being performed and that they are performed without using device-specific interaction types. Additionally, Dolgobrod [8] states that although interaction zones are different per device, for example the bottom of the screen is easier to interact with compared to the top of the screen on a mobile device, design should also stick to conventions and existing mental models of users. For example, navigation is typically performed by using an F-shaped pattern [8]. To outline a different type of in- and output, speech is a form that is independent from the device being used [1], which is according to Vo [24] a so-calleduniversal remote control. This implies that a range of different devices can be accessed in the same universal way, hence making the UI more coherent [24]. However, environmental aspects are different for each device type, which could introduce new problems (e.g. too much background noise to interact via speech, or switch from a private to public setting) [6, 17].
Although the consistent design approach has a number of ad-vantages such as a shared experience across various devices, it also features a downside. Making a design consistent also implies that the advantages of specific devices are lost [13].
4.2.2 Continuous approach. While making the design consis-tent, it is suggested that since the conceptual model is equal across all devices, there is an optimization in flow [24]. However, Levin [13] states that this does not mainly involve the flow of tasks shift-ing between devices. For example, a task might be started at a sshift-ingle device, but then could be finished on another device. This process implies that there is a continuous cycle of events across different devices to comply to the specific goals of users.
The idea behind the continuous approach is that each device picks up where the previous device has left of [13]. This means that there is some kind of service which is accessible through mul-tiple devices. Väänänen-Vainio-Mattila et al. [22] calls this concept cross-platform service access, under which it should be pleasant and easy to switch devices and whereby data is synchronized between the various devices [17, 22]. O’Leary et al. [17] state that data syn-chronization between devices is key, since this picking up a task
from the previous device implies that the device understands where the user has left of. A good example of such a service is Netflix2, a platform where users can watch video content on various devices. The service knows which content the user is watching, and when the user changes device, he or she can continue watching on that device without having to search for the content again (and the specific time marker). Additionally, Vaananen-Vainio-Mattila and Waljas [23] proposes that it is important (as we have seen earlier in the context of consistency), that the user can perform the same tasks on each device of the platform to make such interactions and switching between devices properly available. When functionality is not available on mobile for example, the user can switch to that device but is unable to finish the task.
To perform tasks or certain activities, Levin [13] distinguishes both a single and a sequenced activity flow. Within the single ac-tivity flow, the same acac-tivity is carried over multiple devices, for example (as we have seen earlier) watching a movie. A sequenced activity flow involves a sequence of activities that lead to a certain end goal, for example managing content on a platform. Within the context of a fantasy sports platform, this is typically involving more activities (e.g. picking athletes, selecting a captain) to reach the end goal. This can also be seen as a decomposition of a task, in which one task has multiple sub-tasks which can be performed on different devices [20].
As Nielsen and Budiu [16] suggest, to design applications for mobile devices, it is important to hide information or functionality on a mobile phone when it is irrelevant in a mobile context [8]. This is important to reduce cognitive load to the user [1]. Although this might seen as a good practice, it can also lead to confusion as seen earlier, since information is hard to find and is conflicting with the mental model of the desktop application. It is therefore important to inform users when functionality is not available or what types of functionality are assigned to which specific devices, to make sure people are aware of functionality being not available [1]. The choices of functionality per device are made based upon whether functionality is accessible on a specific device, made based upon the MVP we have seen earlier [13] and based upon user needs to comply to their user goals. In most cases though, most of the functionality will typically be shared among all devices [1], and devices are used interchangeably. Additionally, as Vaananen-Vainio-Mattila and Waljas [23] suggest, when changes are made to the service, it has to be presented to the user, in which cross-platform usage would become more seamless regarding the clarity of the UI. Lastly, when cloud services are being used, an improved task flow and the concept of being up-to-date can be facilitated [22]. Again, as we have seen earlier this allows a process to be continued on another device without having to save and load and distribute to the other devices [17], which causes a distorted task process.
4.2.3 Complementary approach. As we have seen in the pre-vious section, devices may have different types of functionality, whereby the devices can also be complementing each other. This leads to the complementary approach, which involves interaction between the application run on multiple devices of a platform [13]. According to Levin [13] this includes collaboration between users and between devices. For example, other devices may take
2Netflix. https://www.netflix.com
a part in the experience of other devices. An example of this is online gaming application that are being played on mobile phones, whereby people are involved real-time.
Secondly, devices are able to complement each other by having different types of functionality. For example, a second screen appli-cation on a mobile phone for a TV or a specific desktop appliappli-cation can be seen as complementary. In this way, one of the devices serve as a controller for the other device. This also implies that not all devices contain the same types of functionality, but this has to be clear to the user (the user knows that the mobile application is only able to control the other device, meaning that both devices are used at the same time and not separably). This implies there are different roles which user assign to the devices, for example the device having the role of a hub, remote or a notifier [17].
The complementary approach is not the main focus of this re-search, since the case of a Fantasy Sports Platform does not include a controlling or complementing device, but focuses on being able to perform multiple tasks on all device-types.
4.2.4 Design parameters. To define the parameters that influ-ence flow while using multiple devices, Levin [13] showed that the approach for consistency, continuity and complementarity are key factors in how multi-device platforms are designed and how events are being processed.
First of all, regarding consistency it is important that only one conceptual model is defined and ported to all different devices [7], in-cluding visual language and content. Additionally, the MVP should be consistent over all devices [13], meaning that tasks should be performed the same way as on the other devices, since this would lead to less readaptations and therefore less frustrations, uncer-tainties and distrust towards the platform [7]. The most important factor is the architecture that should remain consistent over the variety of devices [13].
Secondly, the continuous approach suggested that tasks can be performed on different devices and that multiple devices can be used to reach one specified goal, either the task being single or sequenced [13]. Therefore, (cloud) synchronization between devices was found to be important [17, 22]. When functionality is not available on a certain device, or when big changes are made to a device, this has to be informed to the user since that implies that certain goals can not be reached from a particular device within the platform, which can cause frustrations [1].
Thirdly, the complementary approach showed that devices do not have to be consistent when it is clear that one of the devices is complementary to the other (main) device. For example, second screen applications serve as a controller to extend the experience of the main device [13].
The three main concepts described by Levin [13] indicate that they influence how a task can be performed on multiple devices, meaning that these concepts can be seen as design parameters. This implies that these concepts can be tweaked until they perfectly fit the user needs and the flow of tasks a user wants to perform. When a device is assisting another device, this implies that there is another role which describes the complementary approach (which gives a pleasant flow), or a device should perform the same tasks and should be pleasant to switch (which we are looking for in this study). Addi-tionally, when a task is divided into multiple (sequenced) sub-tasks,
it is very important that devices are synchronized and display the same content when switching devices in order to make it possible for users to continue their tasks and to comply to their goals.
4.3
Fantasy Sports Platforms
Fantasy Sports Platforms are based upon real-world competition data of sports events, in which participants compete against each other as an additional experience to enjoy sports. All of these plat-forms are typically located in a web environment or as a native app on mobile devices [9]. The prototype made in section 5 is based on Scorito3, although there are many other examples involving many different sports, such asFantasy Premier League4andProfcoach5. As seen in Scorito, users are not able to create a poule in the native mobile app, informing the user to use the desktop (website) version. This implies that one of the (important) tasks is not performable on all devices, which is contrary to the conclusions of de Oliveira and da Rocha [7].
5
TREATMENT DESIGN
In this section, an artifact (prototype) was created to define a suit-able solution to the problem [26]. First of all, requirements were defined based upon the MVP (5.1). Furthermore, this section covers the definition of a conceptual model (5.2). Lastly, the prototype (5.3) and the technical specifications (5.4) are described.
5.1
Requirement development
To retrieve requirements that fit the typical needs of a FSP user, two personas and their respective user scenarios are described in Table 4 and 5. According to Jurca et al. [10], a persona is a fictional person or character that represents a typical user of the platform. Both personas are based upon user profiles of the application Scorito, a FSP which was earlier introduced in subsection 4.3. Additionally, the user scenarios describe a story which involves the user (persona) and the range of typical activities or typical problems that the user might encounter during the usage of the system [10].
Table 4: Persona 1: Hans de Noteboom. Name Hans de Noteboom
Age 41
Gender Male
Interests Sports (football, cycling)
Hans de Noteboom is a 41 years old male interested in sports. Together with a group of cycling friends, he decided to create a fantasy league for the upcom-ing Tour de France, whereby afterwards Hans invites all his friends. Hans decides upon which cyclists he selects for his team and he changes his formation on a daily basis, regarding the real life events that oc-cur. After the league is over, Hans knew he did not picked the right cyclists this year, finishing last in the leaderboard.
3Scorito. https://www.scorito.com/
4Fantasy Premier League. https://fantasy.premierleague.com/ 5Profcoach. https://www.profcoach.nl/
Table 5: Persona 2: Theo de Vogel. Name Theo de Vogel
Age 23
Gender Male
Interests Sports (football), gaming
Theo de Vogel is very interested in sports and watches a lot of football matches each week. One of his friends asked him to compete in a fantasy league of friends regarding the upcoming World Cup in Russia. Theo accepts the invitation and picks football players from all over the world. Every match stage, he changes his team to obtain the maximum amount of score. Theo picked some players that played very good on the World Cup. Therefore, Theo became first in the leaderboard, earning him prestige from his friends.
As seen earlier, the consistency of performing the same tasks the same way on multiple devices is key in creating an equal ex-perience [13]. Therefore, it is important to define the Minimum Viable Product (MVP). An important requirement is that the MVP is ported to all devices, since people do not have conflicting mental models about different functionalities for each device on one single platform. As seen earlier, having different functionality on each device (some tasks can not be performed) means that users have to readapt their model, which can become frustrating [7]. A MVP can be defined as’that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort’ [18], meaning that the MVP insists on the core functionalities needed to serve the target audience. The core tasks (and therefore requirements) for a FSP are described below:
•Create poule The user is able to launch the application and create a poule in which friends can compete. After the user created a poule, he or she should be able to invite friends, select a squad and view results and the leaderboard of the specific poule.
•Invite friends to poule After a poule is created or the user is in a poule, he or she is able to invite other users of the platform to the poule.
•Accept invite to poule The user is able to accept (or de-cline) invites from other users to compete in their poule. •Select a starting squad Once the user either created or
ac-cepted an invite to a poule, he or she should pick a starting squad based upon a certain budget. This starting squad can-not be changed afterwards (as long as the real life season continues).
•Select a match-day squad The user should be able to select different players each match-day from his starting squad that will earn score.
•View results of match-days After each match-day, the user should be able to see the results.
•View athlete information Each (selected) athlete earns score, which the user should be able to view, including in-formation about the athlete.
•View leaderboard During the whole poule, the user should be able to view the standings.
Some of these requirements are dependent regarding the type of poule. For example, it is possible that score is not earned on individual athlete-level, but based upon team performances, which would alter the tasks a bit. Additionally, all tasks should be available on both devices [13]. When a user is able to create a poule on the desktop but not on a mobile device, this inconsistency can lead to frustration. However, if this is the case it is important to inform people about these decisions [1]. In the context of this study, some elements however are hidden to lower complexity, which will be further explained in subsection 5.3.
5.2
Conceptual Model
In order to let users develop a clear mental model of the platform, Benyon et al. [2] state that designers should conceptually design the system so that it fits their expectations and is easily learn-able. As seen earlier, creating a conceptual model is key for the consistency of the platform, regarding the concept of CMDD [7]. By making sure that the conceptual model is consistent over the range of used devices, the process or flow of using devices interchangeably for one platform can potentially be easier and more coherent [24].
According to Benyon et al. [2], various design concepts should be defined, including the architecture for the design and consideration of the organization. Regarding the structure (architecture) of the platform, a sitemap has been constructed showing the different pages and their relationships. All the pages are featured on all devices (every part of the architecture is available on all devices). In the case of not designing for flow equality, the site-maps of the mobile and desktop version would look different, showing more content and information on the desktop and therefore combining pages together (and therefore moving information and functionality in the architecture). In Appendix B, the sitemap can be found.
The concepts involved in this research are furthermore focused on creating a team of athletes, changing it on a matchday basis and creating poules or accepting invites to poules. Furthermore, according to Nielsen and Budiu [16], when creating applications it is important for people to be able to recognize icons and habits that occur in most applications, since that implies that users can use already existing mental models of other applications whereby the level of confusion and disorientation is lower. As we have seen earlier, having a consistent approach, this would also potentially positively impact the multi-device use of the platform [7]. Therefore, icons such as user icons and cog wheels for settings were used, which are known for other platforms as well. An icon framework called FontAwesome6was used, since this has been implemented in many applications and websites, and is therefore recognizable.
5.3
Prototype
Since we have stated the MVP and conceptual model, these both are implemented in the final prototype. Regarding the prototype, the tasks that an user has to perform are equal on both the mobile and the desktop prototype of the FSP application. The choices made during the design stage of the prototype are based upon the findings of phase one (4). In Appendix C, the screens of both the mobile and desktop prototype can be found. Below, the various choices are further explained and analyzed regarding the consistency of the
6FontAwesome. https://fontawesome.com/icons/
MVP (5.3.1), shared visual representations (5.3.2) and device-specific interactions (5.3.3).
5.3.1 Consistent MVP. To reduce complexity in the prototype, there has been chosen to hide all the competitive elements (budgets for selecting a squad) or fake these (such as leaderboards and score per player), since this is not the main focus of the study, and is hard not testable in a short time. This means that for example the focus is on selecting and editing a squad, instead of picking a starting squad and only being able to choose from those athletes, which is common for FSP applications [9]. This also means that, due to the clickable nature of the prototype, teams are prefilled (meaning that the selection of the starting squad is skipped, but tasks remain included).
Figure 1: Comparison of the structure of the home screen on both mobile and desktop, indicating the same functionality but a difference in appearance.
The two applications visually look different (see Appendix C, Figure 1 and Figure 2), for example a comparison of the page for editing a squad shows that the desktop prototype has more visual information, but the interactions and clickable elements are retained for both devices (consistent, but not identical). Information that is not vital for performing a task the same way can be removed on a smaller device, as stated by Levin [13] earlier. In Appendix D, the use cases are displayed showing the steps needed to perform the tasks explained earlier in the context of the MVP (5.1).
Another example of the differences between interfaces but con-sistency regarding the architecture is the poule page shown in Figure 2. For example, the desktop screen is divided into a sidebar with the elements of the poule and a frame which changes accord-ing to the selected element on the left. On the mobile version, these elements will lead to different pages. Conceptually though, each element still has a different page on the desktop prototype, while all elements can be reached the same location and on the same page, indicating consistency during poule-specific tasks. Furthermore, both versions contain different (visual) information, such as the desktop version having the feedback in terms of shirt color (based upon position or based upon team), but there are no differences regarding the performance of a task, which is most important (and prescribed by Levin [13]). Therefore, although interfaces are differ-ent of both applications, tasks should be performed the same way with the same amount of steps.
Lastly, both prototypes accidentally contain the same amount of available functionality, meaning that the content is fully ported
across all devices. This implies that the architecture of both de-signed devices is consistent (regarding the sitemap seen earlier in subsection 5.2) and therefore should insist on a consistent structure and user flow during the multi-device usage of the platform [13].
5.3.2 Shared visual representation. As Levin [13] stated, it is important to have a shared visual representation, so the cognitive and affective connection between the applications ran on the two devices is stimulated. The representations are not identical, for example the poule elements on the home screens are different, but contain the same icons, colors and font formats. As indicated earlier, the framework FontAwesome was used for the icons, since these are icons that people are familiar with since it is implemented in many applications and websites.
5.3.3 No device specific interactions. As Bangor and Miller and Vo [1, 24] stated, having a universal remote control can be benefi-cial for making the UI more coherent. In the prototype, there are still differences due to the differences of the device regarding the input of the user. The desktop interaction is based upon mouse interactions or touchpad interactions, while the mobile prototype is touch-only. The tool used to design the prototype (InVision Studio7 distinguishes many forms of interactions, including tap, hold and swipe-gestures. There has been chosen to use the tap-gesture on all devices and elements in the prototype, which implies that there are no differences regarding device-specific interactions (such as swiping is in most cases exclusive to mobile devices such as tablets and phones).
5.4
Technical specification
As seen earlier, Fantasy Sports Platforms (FSPs) are being played in a cloud environment and mostly on multiple devices. There are no complementing factors in these type platforms, since the platforms propose a solution to fill in team data on each device. This implies that the design approach fits into the description of the consistent approach of, creating one application which content is being ported to all available devices [13]. Furthermore, there are some technical aspects to be mentioned regarding the continuous (cloud) usage of the proposed FSP application.
Firstly, the synchronization of the application is very important. As seen earlier, to switch properly across devices, data synchro-nization is necessary since the data then is able to ’follow the user’ regardless of the device he or she is using [17, 22], making the data device independent. For example, users might select athletes on one device and later finish the selection process on another device. This implies that multiple small sub-tasks can converge into one main goal (preparing the draft, managing the content). The data synchronization currently is faked in the prototype, but is a vital part in the multi-device usage of a platform, since when there is no synchronization people get frustrated that data is not available [17]. Therefore, when creating a FSP platform, using cloud services is vital, since the applications retrieve information from the cloud and display it on the screen, rather than having to synchronize each single device.
Lastly, regarding the requirements of a device that runs such a platform it is important that the device has an internet connection
7InVision Studio. https://www.invisionapp.com/studio
Figure 2: Comparison of the structure of the poule page on both devices, showing the (visual) differences between the devices. to perform the data synchronization. Additionally, the proposed
FSP application is typically run on browsers for desktop and (native) apps for mobile device. At this moment, the prototype is created as an implementation of two native applications, but this could be extended to a browser-based application (website) with the same identical characteristics.
6
TREATMENT EVALUATION
In the treatment evaluation phase, the treatment that was designed in the previous phase (prototype) is tested and evaluated by poten-tial users of a FSP application. In subsection 6.1, the setup for the usability tests is explained. Afterwards, the findings of the usability tests are discussed in subsection 6.2.
6.1
Setting up the usability tests
As explained earlier in subsection 5.3, competitive elements were removed from the prototype to remove complexity, since it is not in the scope of this study. The prototype was evaluated by using so-calledusability tests. These tests followed a set of tasks which the participant performed with the prototypes (same tasks on both mobile and desktop) and afterwards a set of questions was asked. These questions were focused on the performance of tasks on both devices and the equality of the experience (regarding the switch from mobile to desktop). This means the usability tests were held to find out if both devices shared the same experience due to the consistent architecture, while still having interface differences. The tasks that the participant had to perform were the same as the tasks mentioned in the MVP, described in subsection 5.1, and were executed on both devices. The devices used during the test were an Apple iPhone 6S and an Apple MacBook Pro 2017 13,3". The tests were all hold when sitting at a table in a relatively quiet place, which is one of the typical locations where a FSP would be played. The usability tests were held in Dutch, since all the participants (N=11) spoke Dutch. The form that was presented to the participant can be found in Appendix E. It includes the specific tasks the partic-ipants had to follow as well as an introduction to the platform and FSPs in general (for the participants that did not knew what these
platforms stand for). Lastly, summaries of each individual usability test can be found in Appendix F.
6.2
Findings from usability tests
As seen earlier, the participants were asked to follow a set of tasks on both the mobile and the desktop device and were asked questions related to the switching between the devices and the differences between performing the tasks on both devices. All participants (except P5) stated that both the applications shared the same kind of architecture, which made the applications share a same experience. For example, a large group of participants (P1, P3, P4, P6, P7, P9, P10 and P11) stated that the second device was easier to pick up, while others (P2, P4 and P8) stated that the visual aspects showed a feeling of recognition. Due to both of the applications sharing the same architecture, it was more easy to find functionality and information, since the participants stated that they practised the application on mobile, and they could apply the knowledge to the desktop application (as stated by P7 and P11). Additionally, one of the participants (P7) indicated that he expected both applications to cover the same functionality, meaning that users expect both applications to be able to perform the same tasks.
Regarding the interactions, participants (P3, P4, P8 and P11) stated that on both devices it was clear how buttons and other UI elements would be behave when being clicked and that the same terms and concepts were used. The shared visual components created a feeling of recognizability according to the participants. For example, P11 mentioned that the drop-down menus during player selection showed were familiar, especially regarding the behaviour of the buttons (after clicking, a drop-down menu showed up). Since the architecture of the application was clear and the interactions where familiar on both devices, the participants (P6, P8 and P9) suggested that it could be possible to skip some steps in the process of executing a task if this architecture is known. For example, P8 stated that a desktop device contains a larger screen, which could include more buttons to different pages (such as going back to the user profile, instead of going to the home screen first). Importantly, the functionality should still be accessible on the same way as the other device.
Another aspect the usability tests revealed is that users use mod-els from other application and apply it to their new unknown appli-cation when they are learning it. For example, the participants (P5, P6, P8, P9, P11) stated that they were unfamiliar to the way how the invites were represented. They expected the functionality to be located on the home screen with an mail-icon, but it was located under ’add poule’. This caused the participants to not being able to find the functionality, on both devices. After using the mobile device though, the participants (P6, P8, P9 and P11) indicated that they made the same error on desktop, but directly knew how to fix the problem due to earlier experiences on the mobile device. However, P5 stated that she forgot where the option was located on the mobile device and therefore showed inconvenience with performing the same task on the desktop version.
P3 mentioned that the applications were not completely iden-tical, which could even be extended to fit the devices better. For example, in some cases buttons can be made larger on a mobile device compared to the desktop device, without causing mental model differences. This also implies that the architecture of the application is the most important factor in a pleasant feeling during multi-device usage of a (FSP) platform.
Preferences regarding device type were mostly based upon the contextual aspects (P1, P2, P3, P7, P9, P10 and P11) or personal pref-erence of the device (P4, P5, P6 and P9), indicating that the mobile device was easier to pick up and do some small tasks like replacing an athlete or viewing the leaderboard. However, P9 mentioned that when the tasks become more complex, he eventually would pre-fer the desktop version. On the other hand, P8 and P10 prepre-ferred the desktop version since it had more visual information such as athlete heads in the ’edit squad’-section, but this was only related to the fact that it was more fun, indicating that there was no pref-erence in performing tasks and finding information related to the architecture, lay-out (structure of the interface) and interactions.
7
DISCUSSION
There are also some limitations that need to be mentioned. First of all, during the selection of constructs in the first phase of the SLR execution, there might also have been chosen for the concept of ’mobility’, which has links to the mobility of devices, transfer of data and multi-device usage.
Secondly, the designed prototype focused mostly on executing tasks on both devices and not on the competitive elements, which have more to do with synchronization between the devices. For platforms such as FSPs, most of the times the data is stored in the cloud and accessed by the devices when needed. However, the experience on other platforms might be different when there is synchronization of files stored on the device itself (i.e. may take time, may be frustrating when not synchronized).
Thirdly, the prototype contained a port of all functionality of the MVP to all devices, meaning that every task was executable on both devices. In other cases or platforms, this might not be the case. For example a platform that allows making pictures on mobile has different types of tasks than the desktop version (which might be more useful for organizing pictures). In that case, the tasks each device can perform are different, which includes that the user has to be made aware of which tasks can be performed with which
device. Additionally, when this is not done, there might also be a difference in interpretation of important functionality regarding the user and the designer of the application. For example, when a designer states that editing a profile is not a task to be performed on a mobile platform (and therefore does not implement it), this might become frustrating to users who think this is a functionality which should be included on mobile. This implies that there might be more differences regarding the complementary approach which was out of the focus for this study.
Lastly, speech was found to be device-independent and there-fore a good solution towards a multi-device usage. However, using speech might lead to new problems such as awkwardness in public, or problems with noisy places.
8
CONCLUSION
In order to provide an answer to the main question (MRQ) stated in section 2, a SLR was performed, a treatment (prototype) was designed and evaluated afterwards. There were some elements that showed impact on switching between devices, and the experience that is involved during the switching process.
First of all, this study showed that an equal MVP is very im-portant when there is a multi-device usage of the platform, since information and functionality is available on each device. Addi-tionally, the architecture is important in terms of location of this information and functionality, which is located on the same familiar place on all devices, which is shown to be an important factor in the transfer of a mental model from one device to the other device. This implies that executing the MVP on each device and in the same way has shown to be important regarding a pleasant flow on multiple devices. Additionally, there should be a balance between what the users expects and what the designer thinks is the core functionality of each individual device (and the overall platform itself). When those two actors share the same vision, users will understand what goals can be achieved on which device and are not confronted with devices that cannot perform certain (in their vision) important tasks.
Secondly, visual interface design is an important in creating an equal experience. Elements that shared the same look and same interaction afterwards (e.g. buttons popping up drop-down menus) showed a familiar feeling to the user, knowing the behavior of the element when clicked. This also implies that using the same interactions (tapping) on both devices is beneficial for the clarity of the UI during multi-device use of the platform.
Another conclusion from the usability tests is that when the architecture of a platform is known (after some practice on one of the devices), some shortcuts can be implemented to speed up the process of tasks. However, the shortcuts may introduce new problems regarding a shortcut not being present on each device (for example accessing the user profile on desktop from each page and on mobile only from the home screen).
Lastly, it is found that current existing mental models have an impact on how the platform is perceived and how each individual device is used. For example, users might expect information or functionality being located at some place in the platform because of other experiences, which show problems when there is multi-device usage of a platform.
Concluding, having an equal MVP, architecture and conceptual model for each device within a platform is important for an equal UX of a multi-device platform on each device. Meaning, the effect on the UX of a multi-device platform when designing for an equal flow is that the UX is enhanced when the conceptual model can be transferred from one device to the other device (which the pa-rameters above take care of). This implies the perspective during design shifts. Instead looking to optimize the UX for each single device, there is a focus on how the combined experience of devices can be optimized to be served as one service. These results would be applicable to any other type of platform rather than FSPs. For example, each platform that has differences in the architectural model or the conceptual model for each device is likely to have disoriented and frustrated users regarding the problem of this study. Therefore, having an equal MVP, equal architecture and conceptual model would be beneficial for each platform to overcome these kind of problems.
9
FUTURE WORK
As seen earlier, the prototype involved a port of all functionalities to both devices, meaning that all tasks were executable. However, in some cases, there might be chosen for a complementary approach, in which devices have different functionality on each device, which complement each other (think about making photos on an app and not on a desktop). Future research should point out how users can be made aware of what functionality is included in which device, where there is no port of the MVP to all devices. Additionally, there should be researched how designers and users can create a shared understanding of what functionality a specific device has, regarding the difference in interpretation of important functionality regarding the user and the designer of the application. As seen earlier, it might be possible the user wants to perform some certain task but the designer has not included it for the device-type.
Secondly, during the evaluation phase (6) there arose a problem regarding the usage of the mental model conflicting with mental models from other applications. It is almost sure that there are differ-ences in how information is being presented on mobile and desktop (e.g. a hamburger icon on mobile, menu already fully displayed on desktop). It is important to design these differences based on earlier experiences and familiarity to the user (enabling them to find what they want on both devices). Most importantly, there can also be differences based upon the architecture of the application (as seen in this study, regarding the invites-section). Normally, these are the things a usability test reveals (which is a good indication), but there should be further researched how these conflicts might be prevented during the design phase to optimize multi-device and multi-platform usage. Since regarding this study it is mostly rele-vant to the architecture of an application (knowing where to find information or functionality), this means that there should be a framework for organizing a (FSP) platform.
Thirdly, during the treatment evaluation phase (6), the partici-pants stated that steps can be removed when the architecture of an application is known, leading to shortcuts to various functionality and information. This might lead to new implications (such as the shortcut not being present on another device), and therefore needs to be further looked into.
Lastly, speech is device-independent and therefore a solution towards the multi-device usage of platforms. Therefore, further research should look into this topic.
REFERENCES
[1] Aaron W Bangor and James T Miller. 2008. Multimode 11 Interfaces: Two.HCI Beyond the GUI: Design for Haptic, Speech, Olfactory, and Other Nontraditional Interfaces (2008).
[2] David Benyon, Phil Turner, and Susan Turner. 2005.Designing interactive systems: People, activities, contexts, technologies. Pearson Education.
[3] Ching-Liang Chiang, Chi-Pang Chiang, Chih-Wei Tai, and Chao-Yi Chen. 2013. Mobile device interface with dual windows. (Dec. 3 2013). US Patent 8,600,446. [4] Tiago Silva Da Silva, Angela Martin, Frank Maurer, and Milene Silveira. 2011. User-centered design and agile methods: a systematic review. InAgile Conference (AGILE), 2011. IEEE, 77–86.
[5] David R Danielson. 2003. Transitional volatility in web navigation.It & Society 1, 3 (2003), 131–158.
[6] Waltenegus Dargie, Anja Strunk, Matthias Winkler, Bernd Mrohs, Sunil Thakar, and Wilfried Enkelmann. 2007. A Model Based Approach for Developing Adaptive Multimodal Interactive Systems.. InICSOFT (PL/DPS/KE/MUSE). 73–79. [7] Rodrigo de Oliveira and Heloísa Vieira da Rocha. 2007. Conceptual Multi-Device
Design on the Transition between e-learning and m-learning. InAdvanced Learn-ing Technologies, 2007. ICALT 2007. Seventh IEEE International Conference on. IEEE, 332–334.
[8] Maxim Dolgobrod. 2013. Developing a user interface for a cross-platform web application. (2013).
[9] Lee K Farquhar and Robert Meeds. 2007. Types of fantasy sports users and their motivations.Journal of Computer-Mediated Communication 12, 4 (2007), 1208–1228.
[10] Gabriela Jurca, Theodore D Hellmann, and Frank Maurer. 2014. Integrating Agile and user-centered design: a systematic mapping and review of evaluation and validation studies of Agile-UX. InAgile Conference (AGILE), 2014. IEEE, 24–32. [11] Amy K Karlson, Shamsi T Iqbal, Brian Meyers, Gonzalo Ramos, Kathy Lee, and
John C Tang. 2010. Mobile taskflow in context: a screenshot study of smartphone usage. InProceedings of the SIGCHI Conference on Human Factors in Computing Systems. ACM, 2009–2018.
[12] Anders Kofod-Petersen. 2012. How to do a Structured Literature Review in computer science. Document released as a guide to performing a Structured Literature Review at NTNU 19 (2012), 2014.
[13] Michal Levin. 2014.Designing Multi-device Experiences: An Ecosystem Approach to User Experiences Across Devices. " O’Reilly Media, Inc.".
[14] Bonnie MacKay, Carolyn Watters, and Jack Duffy. 2004. Web page transformation when switching devices. InInternational Conference on Mobile Human-Computer Interaction. Springer, 228–239.
[15] Fiona Fui-Hoon Nah, Fan Zhao, and W Zhu. 2003. Factors influencing users’ adoption of mobile computing.Managing E-Commerce and Mobile Computing Technologies Book (2003), 260–271.
[16] Jakob Nielsen and Raluca Budiu. 2013.Mobile usability. MITP-Verlags GmbH & Co. KG.
[17] Katie O’Leary, Tao Dong, Julia Katherine Haines, Michael Gilbert, Elizabeth F Churchill, and Jeffrey Nichols. 2017. The Moving Context Kit: Designing for Context Shifts in Multi-Device Experiences. InProceedings of the 2017 Conference on Designing Interactive Systems. ACM, 309–320.
[18] Eric Ries. 2009. Minimum viable product: a guide.Startup lessons learned (2009). [19] Yvonne Rogers, Helen Sharp, and Jenny Preece. 2011.Interaction design: beyond
human-computer interaction. John Wiley & Sons.
[20] Gerd Szwillus. 2011. Task Models in the Context of User Interface Development. InModel-Driven Development of Advanced User Interfaces. Springer, 277–302. [21] John Dezendorf Trimmer. 1950. Response of physical systems. (1950). [22] Kaisa Väänänen-Vainio-Mattila, Jarmo Palviainen, Santtu Pakarinen, Else
Lager-stam, and Eeva Kangas. 2011. User perceptions of Wow experiences and design implications for Cloud services. InProceedings of the 2011 Conference on Designing Pleasurable Products and Interfaces. ACM, 63.
[23] Kaisa Vaananen-Vainio-Mattila and Minna Waljas. 2010. Evaluating user ex-perience of cross-platform web services with a heuristic evaluation method. International Journal of Arts and Technology 3, 4 (2010), 402–421.
[24] Chuong Cong Vo. 2010. A Task Computing Framework for Taskable Places. (2010).
[25] Weigang Wang and Manuele Reani. 2017. The rise of mobile computing for Group Decision Support Systems: A comparative evaluation of mobile and desktop. International Journal of Human-Computer Studies 104 (2017), 16–35.
[26] Roel J Wieringa. 2014. Observational Case Studies. InDesign Science Methodology for Information Systems and Software Engineering. Springer, 225–245. [27] Rosa Yáñez Gómez, Daniel Cascado Caballero, and José-Luis Sevillano. 2014.
Heuristic evaluation on mobile interfaces: A new checklist.The Scientific World Journal 2014 (2014).
Appendices
A
SLR: PAPER DESCRIPTIONS
Table 6: Selected papers during SLR to define the design parameters in subsection 4.2 and a description why they were selected (regarding their relevancy to RQ1).
Reference Digital library Description
[1] Google Scholar Bangor and Miller describe that devices have different in- and outputs, which can cause different interaction patterns. There is described that speech and tactile in-teraction are device-independent, and could be suitable to be a universal remote control. Bangor and Miller also state that users should be informed when certain tasks can not be performed on a certain device. The findings of this study are relevant since they describe how frustrations can be prevented and how having a universal interaction pattern supports an equal UX on multiple devices.
[6] Google Scholar Dargie et al. describe that there are multiple aspects that define how devices are being used and what their characteristics are. Dargie et al. describes that environmental aspects influence interactions and the choice for device types being used, which is relevant to knowing what context might influence the design choices on a multi-device platform.
[8] Google Scholar Dolgobrod states that certain interaction types are not suited for each device. This finding is relevant to the context of designing for a multi-device platform, since this means some interaction types are not possible on each device and therefore need to be considered during the design stages.
[13] Google Scholar Levin proposes multiple strategies or approaches to design a platform for a multi-device usage. Furthermore, it shows that roles of multi-devices or the design approach has an influence on the UX of a multi-device platform, and therefore can be seen as design parameters.
[17] Google Scholar O’Leary et al. describe that shifts in context influence the way how we perceive and use devices, while on the other hand, this study describes that specific roles (e.g. hub, remote or notifier) can be attached to a certain device, indicating that there are differences in the tasks that can be performed on both devices. This is relevant since to design for equality, devices should include the same set of functionality and therefore should not have differences in their roles.
[20] Google Scholar Szwillus states that tasks can be decomposed into multiple subtasks, which can be performed on multiple devices. Knowing the sequential steps of performing a task (task decomposition, as seen in the Use Cases), it is therefore relevant since these tasks should be performed equally on all devices.
[22] Google Scholar Väänänen-Vainio-Mattila et al. state that synchronization and data access is key for the design of a personalized multi-device service. Väänänen-Vainio-Mattila et al. also states that mobile tasks should fit the user needs on that specific device. Both findings show relevancy since they are a big factor in using multiple devices while accessing the same service.
[23] Google Scholar Vaananen-Vainio-Mattila and Waljas state that differences between devices should be clear for users, while on the other hand the cross-platform (or in this context cross-device) usage should be seamless. This implies that Vaananen-Vainio-Mattila and Waljas states that for designing a multi-device platform, it is important to have the most important tasks to be ported to all devices to let users complete their tasks. [24] Google Scholar Vo has some interesting findings regarding the transfer of conceptual models from one device to another device, indicating that when the transfer is smooth (without readaptations), the UX of a multi-device platform is enhanced. Additionally, having a universal interaction on all device was seen as beneficial to make the UI coherent.
[7] Scopus de Oliveira and da Rocha introduce the concept of Conceptual Multi-Device Design (CMDD), which is relevant to the research question since it shows that one concep-tual model should be carried over all devices to succesfully design a multi-device platform. Therefore, this can be seen as a parameter to design for an equal UX. Addi-tionally, present mental models should not conflict with the new model according to de Oliveira and da Rocha.
[25] ScienceDirect Wang and Reani make a comment on how mobile and desktop applications are presented and show that there is a difference in presentation regarding the viewpoint (overview or focused) of a device. There was found that having such differences do not influence the consistency of a platform, when the information is on the same architectural location.
B
FSP SITEMAP
Figure 3: Sitemap of the proposed FSP, containing the different interactions between different pages and their components.
C
FSP PROTOTYPE
Figure 4: The login page of the FSP application on both mobile and desktop.
Figure 5: The home page of the FSP application on both mobile and desktop.
Figure 6: The add poule page of the FSP application on both mobile and desktop.
Figure 7: The create poule page of the FSP application on both mobile and desktop.
Figure 8: The invite friends page of the FSP application on both mobile and desktop.
Figure 9: The confirm add poule page of the FSP application on both mobile and desktop.
Figure 10: The view poule page of the FSP application on both mobile and desktop.
Figure 11: The edit squad page of the FSP application on both mobile and desktop, indicating equal structure.
Figure 12: The edit squad page of the FSP application on both mobile and desktop, containing selection menus, indicating equal structure.
Figure 13: The leaderboard page of the FSP application on both mobile and desktop.
Figure 14: The view match-day page of the FSP application on both mobile and desktop, indicating equal structure.
Figure 15: The view athlete page of the FSP application on both mobile and desktop, indicating equal structure.
Figure 16: The requests page of the FSP application on both mobile and desktop.
D
USE CASES
For all use cases, logging in and logging out of the application are steps that have been described. However, these steps are not necessary (only once) when the user is performing multiple tasks during one session. Even, the user can remain to be logged in on the platform, meaning that the logging in process only is done once.
D.1
Create poule and Invite friends
Table 7: Use Case: Create poule and invite friends. Use Case: Create poule and invite friends Primary actor User
Conditions User has an account
Result User has created a poule and invited friends to this poule
Activity flow
1. The user logs into the application 2. The user clicks on add poule 3. The user clicks on create poule 4. The user fills in the poule details 5. The user submits the poule details 6. The user clicks on invite friends
7. The user fills in the usernames of his friends 8. The user fills in submits his friends
9. The user clicks on go to overview 10. The user clicks on his personal settings 11. The user logs out of the application Alternative flow 6a. The user clicks on go to overview
D.2
Accept invite
Table 8: Use Case: Accept invite. Use Case: Accept invite Primary actor User
Conditions User has an account
Result User has accepted an invite to a poule
Activity flow
1. The user logs into the application 2. The user clicks on add poule 3. The user clicks on view requests
4. The user selects the request he wants to accept 5. The user clicks on go to overview
6. The user clicks on his personal settings 7. The user logs out of the application Alternative flow
5a. The user clicks on invite friends
6a. The user fills in the usernames of his friends 7a. The user fills in submits his friends
8a. The user clicks on go to overview
D.3
Edit squad
Table 9: Use Case: Edit squad. Use Case: Edit squad Primary actor User
Conditions User has an account
Result User has edited his squad selection (selected another athlete)
Activity flow
1. The user logs into the application
2. The user clicks the poule he wants to manage 3. The user clicks edit squad
4. The user clicks on the athlete he wants to swap
5. The user selects the athlete that he wants on this position 6. The user clicks back to the overview
7. The user clicks on his personal settings 8. The user logs out of the application
Alternative flow 4a. The user clicks on the empty field, where he wants to add an athlete
D.4
View athlete information
Table 10: Use Case: View athlete information. Use Case: View athlete information Primary actor User
Conditions User has an account
Result User has viewed a specific athlete’s information
Activity flow
1. The user logs into the application 2. The user clicks the poule he wants to view 3. The user clicks view squad
4. The user clicks on the athlete he wants to view 5. The user views the information of the athlete 6. The user clicks back to the overview 7. The user clicks on his personal settings 8. The user logs out of the application
D.5
View match-day result
Table 11: Use Case: View match-day result. Use Case: View match-day result Primary actor User
Conditions User has an account
Result User has viewed a result of a match-day
Activity flow
1. The user logs into the application 2. The user clicks the poule he wants to view 3. The user clicks view match-day results
4. The user clicks on the match-day he wants to view 5. The user views the results of the match-day 6. The user clicks back to the overview 7. The user clicks on his personal settings 8. The user logs out of the application
D.6
View leaderboard
Table 12: Use Case: View leaderboard. Use Case: View leaderboard Primary actor User
Conditions User has an account
Result User has viewed the leaderboard of a poule
Activity flow
1. The user logs into the application 2. The user clicks the poule he wants to view 3. The user clicks view leaderboard
4. The user views the ranking of the users on the leaderboard 5. The user clicks back to the overview
6. The user clicks on his personal settings 7. The user logs out of the application
