Kati Kuusinen
email: kkuusinen@uclan.ac.uk

Are Software Developers just Users of Development Tools? Assessing Developer Experience of a Graphical User Interface Designer

Software developers use software products to design and develop new software products for others to use. Research has introduced a concept of developer experience inspired by the concept of user experience but appreciating also the special characteristics of software development context. It is unclear what the experiential components of developer experience are and how it can be measured. In this paper we address developer experience of Vaadin Designer, a graphical user interface designer tool in terms of user experience, intrinsic motivation, and flow state experience. We surveyed 18 developers using AttrakDiff, flow state scale, intrinsic motivation inventory and our own DEXI scale and compare those responses to developers' overall user experience assessment using Mann-Whitney U test. We found significant differences in motivational and flow state factors between groups who assessed the overall user experience either bad or good. Based on our results we discuss the factors that construe developer experience.

Another approach for designing and developing GUIs is to use a GUI designer which often is a WYSIWYG (what you see is what you get) editor that allows the designer/developer to produce GUIs by dragging and dropping UI elements on screen layout. This approach can, for instance, help those UI designers who are less experienced in programming to produce more implementable design and developers would only need to refactor the produced code [23]. Or it could help a developer somewhat knowledgeable in user experience (UX) issues to produce design that a UX specialist could only review to ensure the quality of use.

.

This paper has two main contributions. First, we present our DEXI scale developed for assessing the particularities of DX. Then we explore which factors of UX, flow state experience and intrinsic motivation correlate with developers' overall UX assessment regarding the assessed GUI designer (Vaadin Designer, https://vaadin.com/designer) thus contributing towards increased understanding of developer experience. Finally, we discuss these findings in relation to both related research and our previous findings on DX of integrated development environments.

The rest of this paper is organized as follows. Section 2 introduces background and related work. Section 3 describes the survey study method including description of the procedure and participants. Section 4 presents survey results. Section 5 discusses the results and section 6 discusses the validity and possibilities for future work. Finally, section 7 gives concluding remarks to the paper.

Introduction

Software development, especially the design and development of the graphical user interface (GUI) strongly benefits from the developers' ability to emphasize with the user and understand user needs. Simultaneously, it requires numerous technical skills to create GUIs. Traditionally GUI development has been done manually via application programming interfaces (APIs) which generally are interfaces to components often represented as libraries. Thus, when using APIs, developers program the GUI by calling required widgets and components via the API and giving parameters for them manually. The resulting GUI is only visible after it is runnable. Often in such approach, GUI is first designed and drawn by UI (user interface) designers separate from front-end developers. The design is often communicated to developers as ready-made static images of the future GUI, which might not be fully implementable as such [START_REF] Ferreira | User experience design and agile development: managing cooperation through articulation work[END_REF], [START_REF] Ferreira | Values and Assumptions Shaping Agile Development and User Experience Design in Practice[END_REF], [START_REF] Kuusinen | Agile user experience development in a large software organization: good expertise but limited impact[END_REF].

Considering notation, we will use "GUI designer" throughout the paper to refer to software and "UI designer" to refer to a person.

Background

Traditional GUI development has based on desktop screen model born in 1980's [START_REF] Myers | Past, present, and future of user interface software tools[END_REF]. The model, based on windows and menus on a desktop computer screen used with a physical keyboard and a mouse was dominant from 1980's to around millennium when handheld devices started to become more common [START_REF] Myers | Past, present, and future of user interface software tools[END_REF]. In fact, the desktop GUI generally still works in a similar fashion it was introduced in the 1980's. Mobile devices, however, have introduced new design challenges with their small-sized screens, virtual keyboards on touch screens, voice control mechanisms etc. [START_REF] Kuusinen | On Designing UX for Mobile Enterprise Apps[END_REF], [START_REF] Myers | Past, present, and future of user interface software tools[END_REF]. In addition, interoperability demands of cross-platform environments introduce additional requirements for GUI design: The variety of platforms and operating systems has never been as massive as it is today. Furthermore, embedded systems and internet of things bring totally new kind of considerations on the research field of human-computer interaction.

GUI Designers

Commonly used GUI designers, sometimes called also GUI builders, include Eclipse Window Builder, Flex Builder, JetBrains Swing GUI designer, Netbeans Swing GUI Builder, Sencha Architect, and Vaadin Designer. GUI designers offer a visual interface to the underlying component and widget libraries. Therefore, designing the UI with GUI designer software can help to mitigate the problem with unimplementable design often seen when UX designers produce UI design as static UI images that developers need to interpret and amend for implementation. Such problems have been reported, for instance in [START_REF] Ferreira | User experience design and agile development: managing cooperation through articulation work[END_REF], [START_REF] Ferreira | Values and Assumptions Shaping Agile Development and User Experience Design in Practice[END_REF], [START_REF] Kuusinen | Agile user experience development in a large software organization: good expertise but limited impact[END_REF].

In general, GUI designers help reduce the number of lines of code developers need to write for the GUI since those tools generate part of the code [START_REF] Myers | Past, present, and future of user interface software tools[END_REF]. They also make GUI development faster [START_REF] Myers | Past, present, and future of user interface software tools[END_REF] and can help UI designers and developers cooperate better and the designer to produce more implementable design compared to the use of static UI images as design artefacts [START_REF] Kuusinen | BoB -A Framework for Organizing Within-Iteration UX Work in Agile Development. Will appear in Integrating User Centred Design in Agile Development in[END_REF], [23]. In cross-platform environments where GUI needs to be designed for several platforms, creating design manually is timeconsuming [START_REF] Myers | Past, present, and future of user interface software tools[END_REF]. The variety, functionality, and use of GUI design tools has grown rapidly during the mobile era. Moreover, digital prototyping and design tools have replaced paper prototyping in many organizations because of their fastness to use, repeatability, and detailed look and feel [START_REF] Kuusinen | BoB -A Framework for Organizing Within-Iteration UX Work in Agile Development. Will appear in Integrating User Centred Design in Agile Development in[END_REF], [23]. In addition, responsive design (design that scales based on the screen size of the device) makes the use of paper prototypes difficult as the designer cannot design fixed-sized screens and with paper prototypes it is hard to understand what will be visible for the user at once [23].

In addition to actual GUI designer software, there are numerous prototyping tools available for rapid prototyping before the GUI building. Those include, for instance, Balsamiq, InVision, and Pencil. These tools differ from GUI designers in that they are mostly intended for sketching and making mock-ups and prototypes instead of creating the production version of the UI.

User Experience

The standard definition of user experience (UX) is as follows: a "person's perceptions and responses resulting from the use and/or anticipated use of a product, system or service" [START_REF] Iso | Ergonomic requirements for office work with visual display terminals (VDTs) -Part 11: Guidance on usability[END_REF]. Commonly, UX is understood as subjective, context-dependent, and dynamic [START_REF] Law | Understanding, scoping and defining user experience: a survey approach[END_REF]. It is affected by user's expectations, needs and motivation, system's characteristics such as purpose and functionality, and the context of use including physical, organizational and psychological aspects [START_REF] Hassenzahl | User experience -A research agenda[END_REF]. One of the most commonly referred models of UX, the hedonic-pragmatic model divides user experience into hedonic or non-utilitarian dimension and pragmatic or instrumental dimension [START_REF] Hassenzahl | The Interplay of Beauty, Goodness and Usability in Interactive Products[END_REF]. Hassenzahl [START_REF] Hassenzahl | The Interplay of Beauty, Goodness and Usability in Interactive Products[END_REF] further divides hedonic quality into two sub dimensions of identification and stimulation while instrumental quality contains mostly items related to usability and usefulness. Usability is often seen as a necessary precondition for good UX [START_REF] Hassenzahl | User experience (UX): towards an experiential perspective on product quality[END_REF], [28].

Developer Experience

Developer experience (DX) is a recent concept addressing the experience of software development [START_REF] Fagerholm | Developer experience: Concept and definition[END_REF]. Whereas UX occurs in relation to the use of software, DX addresses the creation of new software. Consequently, UX does not cover all aspects of DX [START_REF] Fagerholm | Software developer experience: Case studies in lean-agile and opensource environments[END_REF]: Developers use development tools in order to create software that provokes experience in the user. On the other hand, developers are users of development software and thus it can be argued that the concept of UX can be applied also to software developers. What makes the developer special, however, is the dualistic nature of being simultaneously both producer and user of software.

Fagerholm's concept of DX [START_REF] Fagerholm | Software developer experience: Case studies in lean-agile and opensource environments[END_REF] presents that DX is the sum of cognitive, affective, and conative mental processes of developer in a context consisting of social and technical environments in which they interact with other developers and numerous technical artefacts (Figure 1).

Figure 1. Concept of developer experience [8]

The concept of DX aims at providing an intuitive abstraction of the vast variety and quantity of human factors that influence developers and the outcomes of software development [START_REF] Fagerholm | Developer experience: Concept and definition[END_REF]. While UX considers the context of use, DX considers the context of development. DX includes also aspects beyond software tools, such as development processes, modeling methods, and other means of structuring development tasks. Some of these aspects are embedded in tools such as GUI builders while others are part of organizational practices. The software development activity and environment differ in significant ways from other information-intensive activities and environments. For example, software development requires a nested understanding: developers use software installed on a computer system to build another software system that is to be used by users to accomplish their task in their particular domain providing them desired UX. Also, developers frequently configure and extend their tools, and are in effect continuously developing both the development environment and the end product at the same time.

Motivation and Flow State Experience in Software Development

One of the current influential theories of motivation is the self-determination theory from Deci and Ryan [START_REF] Deci | Self-determination theory[END_REF]. They distinguish between intrinsic and extrinsic motivations. Intrinsic motivation refers to engaging in a task because of it is inherently pleasurable and satisfying whereas extrinsic motivation refers to engaging in a task because of its outcomes, the task is used as a means to lead to the outcome [START_REF] Deci | Self-determination theory[END_REF].

Developer motivation is as an important factor in software development. Majority of studies on motivation in development context report that developers are distinct from other occupational groups with respect to motivation [START_REF] Beecham | Motivation in software engineering: A systematic literature review[END_REF]. "The work itself" is the most commonly cited motivator, but there is a lack of detail regarding what aspects of the work is motivating, how motivational processes occur, and what the outcomes of motivating developers are [START_REF] Beecham | Motivation in software engineering: A systematic literature review[END_REF], [START_REF] Franca | Motivation in software engineering: A systematic review update[END_REF]. Investigations into affective aspects of software development show the importance of considering also affect. The presence and variation of developers' emotions over time has been documented [START_REF] Shaw | The Emotions of Systems Developers: An Empirical Study of Affective Events Theory[END_REF]. Programming tasks are influenced by mood [START_REF] Khan | Do moods affect programmers' debug performance?[END_REF], and happiness has been found to have productivity benefits [START_REF] Graziotin | Software Developers, Moods, Emotions, and Performance[END_REF]. This underlines the importance of considering affective aspects both for purposes of well-being and outcomes.

Flow experience refers to a state of concentration so focused that it amounts to absolute absorption in an activity [START_REF] Csikszentmihalyi | Flow: The psychology of optimal experience[END_REF]. Applicable to both work and leisure [START_REF] Csikszentmihalyi | Optimal experience in work and leisure[END_REF], flow builds on intrinsic motivation and internal reward over the achievement rather than on external goal or recognition. Its effect can be characterized as being totally focused on a particular task at hand, so that the person becomes fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. While immersed, three conditions have to be met to achieve a flow state [START_REF] Csikszentmihalyi | Flow[END_REF]:

1. One must be involved in an activity with a clear set of goals and progress; 2. The task at hand must have clear and immediate feedback; 3. One must have a good balance between the perceived challenges of the task at hand and their own perceived skills, so that there can be confidence in one's ability to complete the task at hand.

These three conditions of flow state experience are comparable with what the literature has found focal for software developers and development work. For example, clear goals, technically challenging work, knowing the purpose of tasks, making good use of skills, and getting feedback are widely reported motivators of software developers [START_REF] Beecham | Motivation in software engineering: A systematic literature review[END_REF], [START_REF] Sharp | Models of motivation in software engineering[END_REF]. In addition, the core of software development work is writing the program code, which demands the ability to concentrate and work alone for several hours [START_REF] Capretz | Making sense of software development and personality types[END_REF]. Both these motivators of developers and the nature of development work makes the concept of flow state experience interesting in the context of software development.

Method

Our research has an overall goal to increase understanding of DX. We aim to clarify how flow state experience, intrinsic motivation, and UX are intertwined in software development and with developer experience. This will enable improvement of development tools to better support developers' ability to experience flow in their work and to enhance developers' intrinsic motivation towards their work. Our hypothesis is that these factors make developers' work more enjoyable and increases their productivity. We have previously conducted a similar study in the context of integrated development environments [START_REF] Kuusinen | Flow, Intrinsic Motivation, and Developer Experience in Software Engineering[END_REF]. This paper reports a survey study that was organized for two main reasons. 1) To examine the relationship of flow state experience, intrinsic motivation, and developer experience and 2) to evaluate the DX of a commonly used GUI designer called Vaadin Designer. The survey was organized together with Vaadin Ltd, the provider of the GUI designer under evaluation.

We present the following research question:

What kind of relation does developer experience and the ability of Vaadin designer to fulfill developers' needs have with flow state experience and intrinsic motivation?

Survey Contents

We conducted a survey study measuring developers' self-reported experiences considering a particular GUI designer. Our web survey consisted of the following four scales:

1. the Short Dispositional Flow State Scale (SDFS-2) [START_REF] Jackson | Long and short measures of flow: The construct validity of the FSS-2, DFS-2, and new brief counterparts[END_REF] used in its entirety, 2. parts of the Intrinsic Motivation Inventory (IMI) [START_REF] Ryan | Control and information in the intrapersonal sphere: An extension of cognitive evaluation theory[END_REF] including questions related to interest/enjoyment, perceived competence, effort/importance, and perceived choice, and 3. the short version of the AttrakDiff-2 (SAD-2) [START_REF] Hassenzahl | Needs, affect, and interactive products-Facets of user experience[END_REF] used in its entirety, and 4. our own Developer Experience Scale (DEXI) [START_REF] Kuusinen | Flow, Intrinsic Motivation, and Developer Experience in Software Engineering[END_REF]. The scales, except DEXI, were selected since they are widely used and validated. They are also short enough to be combined in a survey.

In addition, we asked for overall UX assessment (OUX) and overall ability of the GUI designer to fulfill the needs of the respondent (NFS) as follows: "How would you rate the overall user experience of Vaadin Designer?" using a seven-point Likert scale from "Bad" (1) to "Good" [START_REF] Deci | Self-determination theory[END_REF], and "How well does Vaadin Designer respond to your needs?" using a seven-point Likert scale from "Not at all" (1) to "Completely" [START_REF] Deci | Self-determination theory[END_REF]. All other measurements are compared to OUX assessment. NFS has no special role in this paper, it is used only as one of the independent variables. Furthermore, we asked the following open-ended questions considering the use of GUI designers: "In your opinion, what are the best qualities of Vaadin Designer?", "How could Vaadin Designer better support your development work?", and "Describe the ideal way of creating UI". Finally, we also asked demographics including experience of software development in years, experience of the particular GUI designer (seen it in use, used it [once or twice, a few times, several times, regularly for less than a month, regularly for over a month but less than a year, regularly for over a year]), age, country the respondent was based in (list of countries provided), size of the organization they were working for (individual developer, micro organization (<10 employees), small (10-100), mediumsized (100-1000), large (over 1000 employees)), and the user group of the GUI designer they belonged (UI designer [they design the UI, someone else does the coding], UI developer [they produce the code], evaluator [typically architect or lead developer who assess the feasibility of different technologies for the organization], other).

Next we present the used scales in detail. We measured the frequency with which developers experience different dimensions of flow during software development activities by using the Short Dispositional Flow State Scale (SDFS-2) [START_REF] Jackson | Long and short measures of flow: The construct validity of the FSS-2, DFS-2, and new brief counterparts[END_REF]. We used a 7-level Likert scale, ranging from 1 (never) to 7 (always). The instructions for the questions were "Please evaluate how often (from 1 = never to 7 = always) you experience the following while you are doing development work with Vaadin Designer". The SDFS-2 measures nine dimensions of flow, each with one item (Table 1). In addition to the nine SDFS-2 items, an additional item was included to measure the experience of frustration: "I feel frustrated". Table 1. SDFS-2 scale. Dimensions of state of flow and related survey items [20] The experience is extremely rewarding

Flow item Survey question

Intrinsic Motivation Inventory (IMI).

Since the original IMI is long and partially repetitive, and shorter versions have been commonly used [START_REF] Mcauley | Psychometric properties of the Intrinsic Motivation Inventory in a competitive sport setting: A confirmatory factor analysis[END_REF], we used a shortened version (Table 2). Utilized scale included selected items from the following IMI subscales: interest/enjoyment (the actual self-report measure of intrinsic motivation), perceived competence, effort/importance, and perceived choice. Framing of the question and assessment scale was according to IMI. Thus, the question was as follows: "For each of the following statements' please indicate how true it is for you' using the following scale", and we utilized a seven-level scale ranging from 1 (not at all true) to 7 (very true). The short version of AttrakDiff-2 (SAD-2) was used as such [START_REF] Hassenzahl | Needs, affect, and interactive products-Facets of user experience[END_REF]. It contains four items (word-pairs) for both practical (PQ) and hedonic quality (HQ), and one for measuring goodness and beauty each (general quality GQ) (Table 3). We formed our own DEXI scale for measuring additional items related to developers' UX, or DX. Thus, we aimed at construing a scale that would be relevant for software development. We selected word-pairs for DEXI from the dataset of a meta-study considering the often used UX items in research tailored for work-related systems [START_REF] Sundberg | The importance of user experience related factors in new product development -Comparing the views of designers and users of industrial products[END_REF], amongst concepts that have been used to describe DX [START_REF] Fagerholm | Developer experience: Concept and definition[END_REF], and amongst those characteristics of development platforms developers find beneficial [START_REF] Gass | PaaS Characteristics for Productive Software Development: An Evaluation Framework[END_REF]. We utilized the structure and wording of AttrakDiff in DEXI. We selected 5 items (DEXI_P) measuring pragmatic quality and 6 items (DEXI_H) measuring hedonic (nonutilitarian) quality. One item (DEXI_G) measured general quality (Table 4). DEXI scale was piloted with students in a code camp experiment and used in a study reported in [START_REF] Kuusinen | Flow, Intrinsic Motivation, and Developer Experience in Software Engineering[END_REF].

Procedure

We organized an online survey to evaluate Vaadin Designer, a commonly used GUI designer. The survey was organized together with Vaadin ltd, the provider of Vaadin Designer. The survey had a front page presenting informed consent statements adopted from World Health Organization's Informed consent form template for qualitative studies [START_REF]World Health Organization, Informed consent form template for qualitative studies[END_REF]. Participants were informed of the organizer, purpose, target respondents, contents, and confidentiality of the survey as well as of the expected completion time and treatment of the information they will provide. We instructed only those who have been using the GUI designer to respond to the survey, and to respond only once. The survey was available for the respondents for four weeks. However, no notifications were sent for the request of the company.

Respondents

In total, we got 20 responses of which 18 were valid. Organizations of the 18 respondents were as follows, individual developers: 4, micro businesses: 4, small businesses: 3, middle-sized businesses: 4, and large businesses: 3. Mean experience from software development was 10 years ranging from 1 to 25 (SD: 7 years). Three of the respondents considered themselves UI designers, 9 were UI coders, 4 were evaluators and 2 were full-stack developers. Regarding the experience of the assessed GUI designer, one respondent had only watched a demonstration or somebody else using the GUI designer, 4 had tried it once or twice, 4 had used it a few times, 4 several times, 2 had used it regularly for less than a month, and 3 had used it regularly for more than a month but less than a year. Given this, respondents can be considered experts in software development but novices in using the GUI designer. Respondents' mean age was 36, SD 10 years, range 21 to 59 years. The respondents were from all over the world: Germany: 4 respondents, India: 2, Spain: 2, US: 2, and 1 from each of the following: Belgium, Columbia, Ecuador, Hungary, Indonesia, Italy, Portugal, and Romania. Thus, 11 respondents were from European countries, 3 from Americas, and 3 from Asian countries.

Analysis

The design of data analysis was finalized after the data gathering to suit the small data set of 18 valid responses. Thus, we approach the research question "what kind of relation does developer experience and the ability of Vaadin designer to fulfill developers' needs have with flow state experience and intrinsic motivation?" from two angles with two statistical methods using SPSS. First we run a more robust statistical test, namely Mann-Whitney U test on the data and compare between those respondents who assessed their overall UX with Vaadin Designer high and those who assessed it low. Second, we run Kendall's Tau correlation analysis on the data to address which items in each scale correlate with the overall UX assessment. Both Mann-Whitney U test and Kendall's Tau correlation analysis are nonparametric methods suitable for smaller and non-normal datasets. In Kendall's Tau correlation analysis, we calculate the correlation between OUX and each item in SDFS-2 and IMI. In using Mann-Whitney U, we test for equality of means to compare responses of those developers who assessed OUX in the seven-point scale 3 or lower (close to "bad") and those who assessed OUX 5 or higher (close to "good"). In the valid dataset, there were 8 respondents that considered the OUX of the GUI designer bad (ratings 1-3) and 9 who considered it good (ratings 5-7), thus one of the respondents assessed OUX with four, neutral, and this assessment was discarded from the analysis. We name the respondent groups "OUX_bad" (ratings 1-3) and "OUX_good" (ratings 5-7), respectively. Our null hypothesis for Mann-Whitney U is as follows:

H: "The distribution of [each survey item] is the same across respondent groups OUX_bad and OUX_good."

The hypothesis states that respondents assessing OUX as bad (group OUX_bad) cannot be significantly separated from those assessing it good (group OUX_good) in their responses to DX, UX, intrinsic motivation, and flow state experience. If the hypothesis is not supported, it means that there is statistically significant difference in responses between those groups.

Impact of Demographics

We ran Kendall's Tau and Mann-Whitney U test between OUX and demographic variables where feasible. There were no significant correlations and the null hypothesis remained for all demographics: there were no statistically significant differences in the demographics between groups of OUX_good and OUX_bad, i.e. between those who assessed overall UX high (good) and those who assessed it low (bad).

Results

We present first the Mann-Whitney U test results, continue with Kendall's Tau correlation analysis and end the results section with answers to the open-ended questions.

Mann-Whitney U Test Results

Table 5 presents only statistically significant values of Mann-Whitney U test to save space. These are the items for which the null hypothesis is not supported. Thus, for all the items in Table 5, there is a statistically significant difference between those respondents who considered the overall UX of the GUI designer bad (1-3) and those who considered it good (5-7 on a seven-point scale from bad to good). It means these items can also be used to differentiate between those groups of respondents. For example, respondents who do things spontaneously and automatically without having to think also consider the overall UX good significantly more often than those who do not, and vice versa. These results indicate that it is important to support developer flow and prevent frustration to ensure good developer experience.

Participants who assessed UX of Vaadin Designer high enjoyed using the Designer more and considered themselves more skilled with the Designer significantly more often than participants who assessed UX low. Furthermore, they were more spontaneous in their tasks and felt frustration significantly less than low assessors. Thus, in this data set, flow state experience (challenge-skill balance in particular) and intrinsic motivation towards the tool had an impact on user experience assessment.

Of the UX items in SAD-2 and DEXI, the null hypothesis was not supported for 2 of 3 word-pairs measuring general quality, for 5 of 9 word-pairs measuring practical quality and 2 of 10 measuring hedonic quality. In DEXI scale 6 out of 12 word pairs (50%) were able to differentiate between OUX_bad and OUX_good whereas SAD_2 was able differentiate between those only with 3 word pairs out of the total 10 (30%). Moreover, no word-pairs measuring hedonic quality in Short AttrakDiff 2 were able to differentiate OUX_good and OUX_bad whereas two word-pairs, namely motivatingdiscouraging and enjoyable -unenjoyable in DEXI were. However, larger datasets are required for further evaluation of the scales.

Kendall's Tau Correlation Analysis

As expected, overall UX assessment (OUX) strongly correlated with need fulfillment (NFS), rτ = .84, p = < .001. This finding is in line with Hassenzahl's results [START_REF] Hassenzahl | Needs, affect, and interactive products-Facets of user experience[END_REF].

Correlations between OUX and individual items in Short AttrakDiff 2 and DEXI scales are presented in Table 6. What is notable is that 9/12 (75%) of word-pairs in DEXI scale significantly correlated with OUX while only 4/10 (40%) of SAD2 had a significant correlation with OUX, all of the latter measuring pragmatic or general quality. Otherwise there is nothing surprising, the majority of the word-pairs correlate with OUX which can be anticipated as all the items are to address UX.

Intrinsic motivation. OUX had a significant correlation with both items that measure intrinsic motivation in relation to the assessed GUI designer, namely I enjoy using Vaadin Designer very much and I am pretty skilled in using Vaadin Designer (Table 7). The first mentioned measure interest/enjoyment while the second measures perceived competence, both related to the tool under evaluation. Other items had no significant correlations with OUX.

Flow state experience.

Regarding flow state experience, OUX correlated with the following items. I feel frustrated, the experience is extremely rewarding, the way time passes seems to be different from normal, I have a feeling of total control, I do things spontaneously and automatically without having to think, and I feel I am competent enough to meet the high demands of the situation (Table 8). Thus, there was a significant correlation between OUX and perceived competence item both in IMI and SDFS-2 as well as between OUX and enjoyment in IMI and autotelic experience in SDFS-2. These findings are in line with our previous results considering integrated development environments [START_REF] Kuusinen | Flow, Intrinsic Motivation, and Developer Experience in Software Engineering[END_REF]; perceived competence and items assessing enjoyment were correlated in that study too.

Responses to Open-Ended Questions

Respondents considered the GUI developer makes the GUI creation process faster compared to the traditional method. They also liked that the GUI developer enables rapid feedback gathering on the actual working UI. They desired for full support on drag and drop feature in that the whole UI could be created simply by placing components on screen. Moreover, they asked for proper support for web UIs and responsive design and that the GUI designer would create proper code based on the UI design on selected programming language instead of HTML. Ideally, the system should also offer support for user involvement in the UI design process.

Discussion

Research Question Revisited

This paper addressed the following research question: "What kind of relation does developer experience and the ability of Vaadin designer to fulfill developers' needs have with flow state experience and intrinsic motivation?"

We addressed the research question first in terms of scale items' ability to differentiate between respondent groups with low and high overall UX assessment (OUX_bad and OUX_good), respectively. The null hypothesis was rejected for flow state experience scale item "I do things spontaneously and automatically without having to think", the additional item "I feel frustrated", and intrinsic motivation inventory items "I enjoy using Vaadin designer very much", and "I am pretty skilled in using Vaadin Designer" which means that on these items, there is statistically significant difference between responses of those developers assessing OUX good (OUX_good) and those that assess it bad (OUX_bad). Second, we addressed the research question with a correlation analysis. The same IMI scale items resulted from both analyses: "I enjoy using Vaadin designer very much", and "I am pretty skilled in using Vaadin Designer" correlated with OUX assessment and could differentiate between OUX_bad and OUX_good. This result is in line with our previous finding: intrinsic motivation was a significant predictor of DX in [START_REF] Kuusinen | Flow, Intrinsic Motivation, and Developer Experience in Software Engineering[END_REF]. A number of flow state scale items were correlated with OUX, including the two items that were able to differentiate between OUX_good and OUX_bad. Mann-Whitney U test is more powerful than correlation analysis and thus it is expected that the correlation analysis includes the results of the test.

Discussion on Related Research

We got similar results in two previous studies. In our study with integrated development environments, hedonic quality was on the borderline of being significant predictor of DX (p = .05) while DX could not be predicted from pragmatic or generic quality [START_REF] Kuusinen | Flow, Intrinsic Motivation, and Developer Experience in Software Engineering[END_REF]. Moreover, in a study on work-related systems [START_REF] Kuusinen | Towards understanding how agile teams predict user experience. Will appear in Integrating User Centred Design in Agile Development in[END_REF], we found that rather than the system being professional, respondents appreciated that the system made them feel professional about themselves. Similarly, in this study, system being creative was not associated with DX while the system making the developer feel creative was. In fact, many of the DEXI scale items measuring hedonic quality address the emotion the system evokes in the respondent rather than qualities of the system (motivating, promotes creativity, increases respect, and brings me closer to others). Furthermore, of word pairs measuring pragmatic quality, simple-complicated has been difficult to interpret in work-related context and it does not correlate significantly with DX in this study. Our explanation is that simple systems generally cannot address all the complexity many work-related activities require. For instance, software development has often been described as complex whereas constructing physical buildings is only complicated [START_REF] Coplien | Lean architecture: for agile software development[END_REF]. Similarly, it is not straightforward to interpret the word pair 'technical -human' of AttrakDiff [START_REF] Hassenzahl | The Interplay of Beauty, Goodness and Usability in Interactive Products[END_REF] in development context which is both technical and human.

'Limited -extensive' and 'informative -uninformative' were important for DX considering IDEs [START_REF] Kuusinen | Flow, Intrinsic Motivation, and Developer Experience in Software Engineering[END_REF] while they were uncorrelated with DX in this study. Our explanation is that IDEs unlike GUI designers need to be extensive because software systems often are unique and base on new technologies and their combinations whereas GUIs often are conventional and base on design conventions while more interesting solutions are hidden from the user beneath the presentation layer. Moreover IDEs are large development environments whereas GUI designers are inherently much more limited systems.

Research on GUI designers and GUI design tools is scarce. There are papers on developed designs on new GUI tools but research on their usage on this century seems to be nonexistent. To our knowledge, Myers [START_REF] Myers | Past, present, and future of user interface software tools[END_REF] is still the most extensive article on the topic. There was a workshop on "The Future of User Interface Design Tools" in CHI conference in 2005 [START_REF] Olsen | The future of user interface design tools[END_REF] but the extended abstract nor the few citing papers do not contain articles on GUI designers or developer work on GUI creation. Also research on developer experience is still scarce.

Figure 2 summarizes our statistical test results both from the study on GUI designers presented in this paper and on IDEs presented in [START_REF] Kuusinen | Flow, Intrinsic Motivation, and Developer Experience in Software Engineering[END_REF]. Based on these studies, the most relevant factors of flow state experience and intrinsic motivation are enjoyment and reward the work offers. Sense of control was a significant predictor of DX in [START_REF] Kuusinen | Flow, Intrinsic Motivation, and Developer Experience in Software Engineering[END_REF]. Perceived competence and challenge-skill balance help the developer to manage with demanding tasks while working spontaneously and automatic without having to think is often understood as working under flow state experience. These are commonly mentioned motivation factors in related research [START_REF] Beecham | Motivation in software engineering: A systematic literature review[END_REF] and our research connects them with development tools and developer experience of those tools. Advanced technologies motivate developers in their work [START_REF] Beecham | Motivation in software engineering: A systematic literature review[END_REF] and development tools are often intertwined with utilized technologies.

Developer Experience

Limitations and Future Work

The most obvious threat to validity is arguably the small respondent number, 18 software specialists. This is particularly critical for correlation analysis, especially considering the large number of connected variables. Small sample size can cause fluctuation in correlation values which makes the analysis less powerful and thus reduces the likelihood of reflecting a true effect. It also prevented us from using more powerful methods. For Mann-Whitney U test the respondent number is sufficient although the test would have benefitted from a larger sample size.

Further studies are needed to validate DEXI scale and to gain better understanding on the concept of DX. In addition, the population was diverse which can be seen both strengthening the results but also making the data incoherent. Our results however, are in line with our previous results considering another dataset on DX of integrated development environments [START_REF] Kuusinen | Flow, Intrinsic Motivation, and Developer Experience in Software Engineering[END_REF] which is to increase the likelihood of reliability in this study.

The results cover only one GUI designer. Thus, larger respondent populations and users of several GUI designers ought to be studied. Moreover, to compare the DX of APIs and GUI designers in larger scale remains another interesting topic for future research. In addition, user groups such as UI/UX designers and UI/front-end developers and their needs could be studied separately or in comparison to increase the understanding of how designers and developers can better work together. DEXI scale could also be evaluated in the context of end user development and to compare developers' and end user developers' experiences. Finally, it could be interesting to study if there was a difference between developers' assessment of overall UX score and overall DX score and how those relate to UX and DEXI scales. To conclude, this study does not come without its limitations but it serves as one opening to further DX studies and it is also one of the scarce studies on GUI designer tools.

Conclusion

This paper presented a survey study on developer experience (DX) of a GUI designer tool. It introduced DEXI scale for assessing DX of development tools. We presented both quantitative and qualitative results on DX, measured with Short AttrakDiff 2 [START_REF] Hassenzahl | Needs, affect, and interactive products-Facets of user experience[END_REF], a commonly used UX scale and DEXI scale specifically designed to assess DX. We found a statistically significant difference in responses between those developers who assessed the overall UX of the GUI builder good and those who assessed it bad considering both their flow state experiences and intrinsic motivation. Our results suggest that developer experience can be improved by fostering the developer's interest and enjoyment, offering rewarding experiences, supporting challenge-skill balance and feeling of competence. Finally, supporting action awareness and providing a sense of control are also key factors of good DX. Considering what software developers appreciate in GUI designer tools, we found that making the GUI design process faster and ensuring early feedback on the working version of the GUI under development were especially liked. Finally, the optimal way to create GUIs was often described as having full support on drag and drop and on responsive design, involving the user in the process, and the ability of the GUI designer tool to export the design into specific programming language instead of HTML code.

  Challenge-skill balance I feel I am competent enough to meet the high demands of the situation Action awareness I do things spontaneously and automatically without having to think Clear goals I have a strong sense of what I want to do Unambiguous feedback I have a good idea while I am performing about how well I am doing Concentration on task I am completely focused on the task at hand Sense of control I have a feeling of total control Loss of selfconsciousness I am not worried about what others may be thinking of me Transformation of time The way time passes seems to be different from normal Autotelic experience

Figure 2 .

 2 Figure 2. Most relevant factors of intrinsic motivation and flow state experience to developer experience.

Table 2 .

 2 Selected subscales and survey items of IMI[34]

	Subscale	Survey item
	Interest/Enjoyment	I enjoy UI creation very much
		I think UI creation is a boring activity
		I enjoy using Vaadin Designer very much

Perceived competence I am satisfied with my performance at UI creation I am pretty skilled in UI creation I am pretty skilled in using Vaadin Designer Effort/Importance It is important to me to do well in UI creation Perceived choice I use Vaadin Designer because I have no choice DX and UX assessment. Both DEXI scale and Short AttrakDiff 2 were used in the survey to assess DX or UX of the particular GUI designer tool. The wording from AttrakDiff [15] was used with both scales as follows: "With the help of the wordpairs, please enter what you consider the most appropriate description for Vaadin Designer:"

Table 3

 3 Short AttrakDiff 2[START_REF] Hassenzahl | Needs, affect, and interactive products-Facets of user experience[END_REF]

	Measurement	Word-Pairs
	SAD_General	Bad -Good
	SAD_General	Ugly -Beautiful
	SAD_Practical	Confusing -Structured
	SAD_Practical	Practical -Impractical
	SAD_Practical	Unpredictable -Predictable
	SAD_Practical	Simple -Complicated
	SAD_Hedonic	Dull -Captivating
	SAD_Hedonic	Stylish -Tacky
	SAD_Hedonic	Cheap -Premium
	SAD_Hedonic	Creative -Unimaginative

Table 4

 4 DEXI scale

	Quality	Survey question	Source
	DEXI_G	Recommendable -Not recommendable	[33], [37]
	DEXI_P	Efficient -Inefficient	[13], [37]
	DEXI_P	Flexible -Inflexible	[13]
	DEXI_P	Easy to learn -Difficult to learn	[13], [37]
	DEXI_P	Limited -Extensive	[13]
	DEXI_P	Uninformative -Informative	[37]
	DEXI_H	Motivating -Discouraging	[9], [37]
	DEXI_H	Increases respect -Decreases respect	[37]
	DEXI_H	Enjoyable -Unenjoyable	[37]
	DEXI_H	Promotes creativity -Suppresses creativity	[2], [37]
	DEXI_H	Engaging -Uninvolving	[2], [37]
	DEXI_H	Brings me closer to others -Separates me from others [2], [9],
			[13], [37]

Table 5 .

 5 Statistically significant Mann-Whitney U test results between respondent groups OUX_good and OUX_bad for NFS and all subscales (OUX, SDFS-2, IMI, SAD-2, DEXI). N = 17

	Survey item per subscale	U	p	r
	How well does Vaadin Designer respond to your needs?	3.50	<.001	0.77
	I do things spontaneously and automatically without having to
	think	8.50	<.01	0.65
	I feel frustrated	6.00	<.01	0.71
	I enjoy using Vaadin Designer very much	8.50	<.01	0.65
	I am pretty skilled in using Vaadin Designer	11.00	<.05	0.61
	SAD_G Bad -Good	2.00	<.001	0.81
	SAD_P Unpredictable -Predictable	12.00	<.05	0.58
	SAD_P Practical -Impractical	7.00	<.01	0.69
	DEXI_G Recommendable -Not recommendable	6.50	<.01	0.70
	DEXI_P Easy to learn -Difficult to learn	10.00	<.05	0.62
	DEXI_P Flexible -Inflexible	9.00	<.01	0.64
	DEXI_P Efficient -Inefficient	5.50	<.01	0.73
	DEXI_H Motivating -Discouraging	1.00	<.001	0.83
	DEXI_H Enjoyable -Unenjoyable	6.00	<.01	0.71

Table 6 .

 6 Results of Kendall's Tau (rτ) correlation analysis between overall UX (OUX) assessment and individual items of SAD2 and DEXI scales. Legend: SAD = Short AttrakDiff 2, G = general quality, P = practical quality, H = hedonic quality, n.s. = not significant. N = 18

	Measure Items

Table 7 .

 7 Results of Kendall's Tau (rτ) correlation analysis between overall UX (OUX) assessment and individual items of IMI subscale. N = 18

	Intrinsic motivation item	rτ	p
	I enjoy using Vaadin Designer very much	.560	<.01
	I am pretty skilled in using Vaadin Designer	.490	<.01
	I think UI creation is a boring activity	.350	n.s.
	I use Vaadin Designer because I have no choice	-.290	n.s.
	It is important to me to do well in UI creation	-.150	n.s.
	I enjoy UI creation very much	.100	n.s.
	I am satisfied with my performance at UI creation	.090	n.s.
	I am pretty skilled in UI creation	.040	n.s.

Table 8 .

 8 Results of Kendall's Tau (rτ) correlation analysis between overall UX (OUX) assessment and individual items of SDFS-2. N = 18

	Dispositional flow state scale item	rτ	p
	I feel frustrated	-.740	<.001
	The experience is extremely rewarding	.570	<.01
	The way time passes seems to be different from normal	.500	<.01
	I have a feeling of total control	.490	<.05
	I do things spontaneously and automatically without having to think	.460	<.05
	I feel I am competent enough to meet the high demands of the situation	.420	<.05
	I am completely focused on the task at hand	.290	n.s.
	I am not worried about what others may be thinking of me	.260	n.s.
	I have a good idea while I am performing about how well I am doing	.100	n.s.
	I have a strong sense of what I want to do	.090	n.s.

Acknowledgment

I want to thank all the survey respondents for their valuable contribution. I also want to thank Vaadin for making the study possible. I am grateful for my contact person in the company for their help in organizing the survey. This research has been conducted while I was working for Tampere University of Technology, Finland. My research has been supported by TEKES as part of the Need for Speed research program of DIGILE (Finnish Strategic Centre for Science, Technology and Innovation in the field of ICT and digital business).


Enes Yigitbas
email: eyigitbas@s-lab.upb.de

Stefan Sauer
email: sauer@s-lab.upb.de

Engineering Context-Adaptive UIs for Task-Continuous Cross-Channel Applications

Keywords: Model-based Development, UI Adaptation, Multi-Device UI Development, Cross-channel Applications, Task-Continuity

The user interfaces (UIs) of interactive systems become increasingly complex since many heterogeneous and dynamically changing contexts of use (platform, user, and environment) have to be supported. Developing UIs for such interactive systems often requires features like UI adaptivity and seamless task-continuity across devices, demanding for sophisticated UI development processes and methods. While existing engineering methods like human-centered design process and model-based UI development approaches serve as a good starting point, an integrated engineering process addressing specific requirements of adaptive UIs supporting task-continuity across different devices is not fully covered. Therefore, we present a model-based engineering approach for building context-adaptive UIs that enable a personalized, flexible and task-continuous usage of cross-channel applications. Our engineering approach supports modeling, transformation and execution of contextadaptive UIs. To show the feasibility of our approach, we present an industrial case study, where we implement context-adaptive UIs for a cross-channel banking application.

Introduction

Today users are surrounded by a broad range of networked interaction devices (e.g. smartphones, smartwatches, tablets, terminals etc.) for carrying out their everyday activities. Due to the growing number of such interaction devices, new possible interaction techniques (e.g. multi-touch or tangible interaction) and distributed user interfaces transcending the boundaries of a single device, software developers and user interface designers are facing new challenges. As the user interfaces of interactive systems become increasingly complex since many heterogeneous contexts of use (platform, user, and environment) have to be supported, it is no longer sufficient to provide a single "one-size-fits-all" user interface. The problem increases even more if we consider dynamic changes in the context of use. In this case, allowing flexible and natural interaction with such devices requires additional features like UI adaptivity to automatically react to the changing context of use parameters at runtime and task-continuity for supporting a seamless handover between different devices. For illustrating the problem, we introduce a real world example scenario which is derived from the banking domain.

While customers accessed banking services solely via isolated channels (through banking personnel or ATM) in the past, using different channels during a transaction is nowadays increasingly gaining popularity. Depending on the situation, customers are able to access their banking services where, when and how it suits them best. In the world of Omni-Channel-Banking, customers are in control of the channels they wish to use, experiencing a self-determined "Omni-Channel-Journey". For example, if the customers pursue an "Omni-Channel-Journey" for a payment cashout process, they can begin an interaction using one channel (prepare cashout at desktop at home), modify the transaction on their way on a mobile channel, and finalize it at the automatic teller machine (ATM) (see figure 1). It is important to notice, that each channel has its own special context of use and eventually the contextual parameters (user (U), platform (P), and environment (E)) can change if there is a channel switch. Thus, Omni-Channel-Banking brings the industry closer to the promise of true contextual banking in which financial services become seamlessly embedded into the lives of individual and business customers. However, the advancement from Multi-Channel-to Omni-Channel-Banking (compare table 1) is a difficult task for developers of such systems. Developers are facing the following challenges:

Multi-Channel-Banking

Omni-Channel-Banking Fixed channel usage Flexible channel usage Separation of channels Integration of channels Data redundancy in channels Data synchronization between channels Little or no channel switch Continuous channel switch Table 1. Multi-Channel-Banking vs. Omni-Channel-Banking -C1: Support for modeling and adaptation of heterogeneous user interfaces (UIs) satisfying different contexts of use (user, platform, environment). -C2: Support for a flexible channel usage depending on the context. -C3: Support for a seamless handover between channels allowing task-continuity.

When the user moves from one device to another, the user is able to seamlessly continue her task.

According to Petrasch [START_REF] Petrasch | Model Based User Interface Design: Model Driven Architecture und HCI Patterns[END_REF], the effort of implementing an application's user interface constitutes at least 50 percent of the total implementation effort. Developing separate applications for each potential device and operating system is neither a practical nor a cost effective solution, especially if we consider heterogeneous contexts of use as they were described in the example scenario above. Model-based User Interface Development (MBUID) is a promising candidate for mastering the complex development task in a systematic, precise and appropriately formal way. For tackling the above mentioned challenges we present a model-based engineering process for context-adaptive UIs which integrates human-centered design aspects into the development process. Our engineering approach provides specific support especially for modeling, transformation, and execution of context-adaptive UIs enabling task-continuous usage of crosschannel applications.

The paper is structured as follows: First, we describe some background information and related work in the area of engineering methods for UIs, covering multi-device and cross-channel UI development as well as UI adaptation. Then, we present our model-based engineering approach for the development of context-adaptive UIs supporting task-continuity. After that, we present the instantiation of our engineering approach based on a case study from the banking domain. Finally, we conclude with a summary and an outlook for future research work.

Background and Related Work

In recent years, a number of approaches have addressed the problem of engineering user interfaces for different contexts of use. Our work is inspired by and based on existing approaches from the area of model-based UI development, adaptive UIs and distributed user interfaces (DUIs). In this section, we especially review prior work that explores the development of multi-device, cross-channel and adaptive user interfaces (UIs) supporting task-continuity.

Multi-device UI development

The development of multi-device UIs has been subject of extensive research [START_REF] Paternò | A logical framework for multi-device user interfaces[END_REF], where different approaches were proposed to support efficient development of UIs for different target platforms. On the one hand, model-based UI development approaches were proposed which aim to create multi-device UIs based on the transformation of abstract user interface models to final user interfaces. Widely studied approaches are UsiXML [START_REF] Limbourg | USIXML: A Language Supporting Multi-path Development of User Interfaces[END_REF], MARIA [START_REF] Paternò | MARIA: A universal, declarative, multiple abstraction-level language for service-oriented applications in ubiquitous environments[END_REF] and IFML1 that support the abstract modeling of user interfaces and their transformation to multidevice UIs including web interfaces. In [START_REF] Yigitbas | Model-Based Development of Adaptive UIs for Multi-channel Self-service Systems[END_REF], we present a specialized approach for model-based development of heterogeneous UIs for different target platforms including self-service systems like ATMs. On the other hand, there are also existing approaches like Damask [START_REF] Lin | Employing patterns and layers for earlystage design and prototyping of cross-device user interfaces[END_REF] and Gummy [START_REF] Meskens | Gummy for multi-platform user interface designs: shape me, multiply me, fix me, use me[END_REF] following the WYSIWYG paradigm. While Damask is a prototyping tool for creating sketches of multidevice web interfaces, Gummy is a design environment for graphical UIs that allows designers to create interfaces for multiple devices using visual tools to automatically generate and maintain a platform-independent description of the UI. While above mentioned approaches support the development of multi-device UIs regarding specification and generation of UIs for different target platforms, they do not cover mechanisms to support channel switches and data synchronization between different target platforms at runtime.

Cross-channel UI development

Previous work by the research community has covered concepts and techniques to dynamically support the distribution of UIs by supporting task-continuity for the end-users. One of the concepts is called UI migration, which follows the idea of transferring a UI or parts of it from a source to a target device, while enabling task-continuity through carrying the UI's state across devices. In [START_REF] Yigitbas | A Model-Based Framework for Multi-Adaptive Migratory User Interfaces[END_REF], we present a model-based framework for the migration and adaptation of user interfaces across different devices. In [START_REF] Paternò | Ambient Intelligence for Supporting Task Continuity across Multiple Devices and Implementation Languages[END_REF] and similarly in [START_REF] Luyten | Designing distributed user interfaces for ambient intelligent environments using models and simulations[END_REF], the authors present a solution to support migration of interactive applications among various devices, including digital TVs and mobile devices, allowing users to freely move around at home and outdoor. The aim is to provide users with a seamless and supportive environment for ubiquitous access in multi-device contexts of use. In the case of web applications, most solutions rely on HTML proxy-based techniques to dynamically push and pull UIs [START_REF] Ghiani | Push and pull of web user interfaces in multi-device environments[END_REF]. An extension of this concept is presented in [START_REF] Nebeling | Interactive development of cross-device user interfaces[END_REF], where the authors propose XDStudio to support interactive development of cross-device UIs. In addition, there is also existing work on the specification support for cross-device applications. In [START_REF] Yang | Panelrama: enabling easy specification of cross-device web applications[END_REF] for example, the authors present their framework Panelrama which is a web-based framework for the construction of applications using DUIs. In a similar work [START_REF] Hamilton | Conductor: enabling and understanding cross-device interaction[END_REF], the authors present Conductor, which is a prototype framework serving as an example for the construction of cross-device applications. While above mentioned approaches support the specification and development of cross-channel UIs for different target platforms, they do not address combining the aspect of UI adaptation for different contexts of use with task-continuity.

Adaptive UIs

In recent research works, adaptive UIs have been promoted as a solution for context variability due to their ability to automatically adapt to the context of use at runtime. A key goal behind adaptive UIs is plasticity, denoting a UIs ability to preserve its usability across multiple contexts of use [START_REF] Coutaz | User Interface Plasticity: Model Driven Engineering to the Limit![END_REF]. Norcio and Stanley [START_REF] Norcio | Adaptive Human-Computer Interfaces: A Literature Survey and Perspective[END_REF] consider that the idea of an adaptive UI is straightforward since it simply means: "The interface should adapt to the user; rather than the user must adapt to the system." Based on [START_REF] Akiki | Adaptive Model-Driven User Interface Development Systems[END_REF] we can generally differentiate between the following types of adaptive UIs:

Adaptable user interfaces allow interested stakeholders to manually adapt the desired characteristics; example: a software application that supports the manual customization of its toolbars by adding and removing buttons. Semi-automated adaptive user interfaces automatically react to a change in the context-of-use by changing one or more of their characteristics using a predefined set of adaptation rules. For example: an application can use a sensor to measure the distance between the end-user and a display device, and then trigger predefined adaptation rules to adjust the font-size. Fully-automated adaptive user interfaces can automatically react to a change in the context-of-use. However, the adaptation has to employ a learning mechanism, which makes use of data that is logged over time. One simple example is a software application, which logs the number of times each end-user clicks on its toolbar buttons and automatically reorders these buttons differently for each end-user according to the usage frequency.

A classification of different adaptation techniques was introduced by Oppermann [START_REF] Oppermann | Individualisierte Systemnutzung[END_REF] and refined by Brusilovsky [START_REF] Brusilovsky | Adaptive Hypermedia. User Modeling and User-Adapted Interaction[END_REF]. UIs with adaptation capabilities have been proposed in the context of various domains (e.g. [START_REF] Krzysztof | Automatically generating personalized user interfaces with Supple[END_REF], [START_REF] Jovanovic | Bridging User Context and Design Models to Build Adaptive User Interfaces[END_REF], [START_REF] Demeure | COMET(s), A Software Architecture Style and an Interactors Toolkit for Plastic User Interfaces[END_REF] or [START_REF] Ghiani | Beyond Responsive Design: Context-Dependent Multimodal Augmentation of Web Applications[END_REF]) and there are also proposals for integrating adaptive UI capabilities in enterprise applications (e.g. [START_REF] Akiki | Integrating adaptive user interface capabilities in enterprise applications[END_REF]). Although above mentioned approaches already present technical solutions for supporting UI adaptivity and model-based development approaches were proposed in the past (e.g. [START_REF] Clerckx | DynaMo-AID: A Design Process and a Runtime Architecture for Dynamic Model-Based User Interface Development[END_REF]), an engineering process for the development of context-adaptive UIs enabling task-continuity is not fully covered. Leaning on existing concepts of adaptive/cross-channel UIs and our previous work [START_REF] Sauer | Applying Meta-Modeling for the Definition of Model-Driven Development Methods of Advanced User Interfaces[END_REF], where we propose a meta-method for engineering advanced user interfaces, we present a model-based engineering approach for developing context-adaptive UIs enbaling task-continuous usage of cross-channel applications.

Engineering Process

In this section, we present a model-based engineering process for development of context-adaptive UIs in order to tackle the motivated challenges C1, C2 and C3. Figure 2 gives a general overview of our engineering process which is divided into four main steps:: UI Modeling, Adaptation Modeling, Transformation, and Execution and Adaptation.

Domain Model UML Class Diagram

Abstract UI Model IFML

Step 1: UI Modeling

Step 3: Transformation In the following subsections each engineering step is explained in more detail by describing the used artifacts and activities.

Front-End UI -Channel 1 Context (U 1 , P 1 , E 1 ) UI -Channel 2 Context (U 2 , P 2 , E 2 ) UI -Channel n Context (U n , P n , E n ) Application Server: Adaptation & Synchronization Back-End DB . . .

UI Modeling

For supporting the development of various UIs allowing access for different channels and minimizing recurrent development efforts in establishing the needed Front-ends, our engineering process begins with the UI Modeling step. The goal of this step is specification of an abstract UI representation that serves as a basis for the transformation and generation of heterogeneous UI variants for different channels. For accomplishing this step, we decided to use existing modeling languages standardized by the Object Management Group (OMG). As a consequence, in the UI Modeling step we make use of UML Class Diagrams and the Interaction Flow Modeling Language (IFML). In the beginning of the engineering process, the developers use UML Class Diagrams for specifying a Domain Model describing the data entities of the user interface. After that, they make use of the Interaction Flow Modeling language (IFML) that supports the modeling of the structure, content and navigation needed to characterize the UI Front-End in an abstract manner. For performing the UI Modeling step, the developers are able to use the open source IFML Editor Eclipse plugin2 that enables a complete specification of the abstract UI model referencing the Domain Model entities.

Adaptation Modeling

After modeling the core UI characteristics using a Domain and Abstract UI model, the developers need to specify adaptation rules that decide how the user interface is adapted to specific contextual parameters (e.g. user, platform and environment) at runtime. Therefore, our engineering approach provides an Adaptation Modeling step, which allows explicit modeling of UI adaptation rules. For defining the adaptation rules, we first introduce a metamodel for context modeling (Context-IFML) that serves as a basis for describing the contextual parameters in a fine grained and extensible manner. After that, we introduce an adaptation metamodel (Adapt-IFML) for specifying complete adaptation rules.

Figure 3 gives an overview of our metamodel for context modeling. The metamodel ContextModel (Context-IFML) consists of the three main classes User, Platform, and Environment that characterize the specific contextual parameters. The class User for example, is subclassified in PersonalInformation, Preferences and Knowledge, while the classes provide different attributes to specify varying peculiarities of a user. Similarly different forms of the platform and characteristics of the environment can be specified with the help of Context-IFML. This way, the developers are able to specify heterogeneous context of use scenarios and to explicitly define the events and conditions for adapting the UI. For the complete definition of an adaptation rule we introduce the metamodel for adaptation modeling (Adapt-IFML) that is depicted in figure 4. Regarding our metamodel an adaptation model consists of different adaptation rules that are structured according to the Event-Condition-Action (ECA) paradigm. While the preconditions of an adaptation rule (event and condition) are specified based on the context model, the Action class provides different mechanisms to adapt the UI at runtime. Basically three different UI adaptation operations are supported, namely Task-, Navigation-and Layout-ChangeOperation, while each of them can be aggregated to more complex UI adaptation operations called ComposedAction. Task-ChangeOperations support adaptation by flexibly showing and hiding interaction elements of the UI. By using the operations AddViewComponent or DeleteViewComponent specific UI interaction elements like tables, textfields etc. can be shown or hidden depending on the specified adaptation rule. In a similar way, the Navigation-ChangeOperation can be used for adding, deleting and redirecting links between user interface flows. This way, the navigation flow of the UI can be flexibly adapted based on the contextual parameters that are defined in the preconditions. Our metamodel for adaptation modeling also supports the definiton of Layout-ChangeOperations like ChangeFont or SplitViewContainer for dividing a complex UI view container into multiple view containers, so that small screen sizes for example are satisfied. For supporting the Adaptation Modeling step, we extended the standard IFML metamodel with Context-IFML and Adapt-IFML according to the previous description. Based on this extensions the developers are able to specify different UI adaptation rules that are evaluated at runtime.

Transformation

After finishing the modeling steps, the developers are facing the task to define transformations to generate numerous UI Front-Ends for different channels. Therefore, in the transformation step several model-to-text transformation During the transformation process, not only the mapping between the source abstract UI model and the target final user interface (FUI) is established, but also the specified adaptation rules are transformed into the target language of the FUI, so that the generated UI can adapt itself at runtime according to the predefined rules.

Execution and Adaptation

For practical usage of the resulting final user interfaces that were reached after the modeling and transformation steps, the developers need an execution environment that executes and adapts the UIs according to the specified adaptation rules. For supporting this task, we present a solution architecture enabling automatic UI adaptation and synchronization. Figure 5 platforms. The Adaptation Manager consists of five main components that work according the adaptation rules that were specified in the Adaptation Model : The Monitor component is responsible for observing context information that are provided by the Context Manager. All contextual parameters that were defined based on the Context Model are observed, so that the Analyze component is able to decide whether adaptation is needed. Therefore, the conditions for triggering an adaptation rule are analyzed and if adaptations are required, an adaptation schedule is done by the Plan component. Finally, the adaptation operations are performed by the Execute component, so that an adapted UI can be presented. The Knowledge base is responsible for storing data that is logged over time and can be used for inferring future adaptation operations. In addition to UI adaptation, for supporting a seamless handover between channels and allowing task-continuity for the user, our solution architecture includes a dedicated Synchronization Server which is responsible for storing and sharing of data (e.g. UI state or user preferences). The UI state including entered input data by the users is stored and restored so that when the user moves from one channel to another, the user is able to seamlessly continue her task on the new UI-Channel.

Instantiation of Engineering Process

In this section, the instantiation of the development process according to the previously described engineering process is presented in more detail. To show the feasibility of our approach, we first present the setting of an industrial case-study dealing with the implementation of context-adaptive UIs for a cross-channel banking application employing web-based technologies. After that, we present the instantiation of the engineering process by describing the implementation of the different steps.

Setting of the Case Study

Our "Omni-Channel-Banking" case-study supports a variety of different channels to access banking services. Figure 6 shows its overall architecture. On each device -PC, Mobile, ATM -the client application is running as a single-page web application inside a browser. Each device has an underlying Context Manager that observes and delivers context information to the Back-End Server, which is responsible for serving an application to the browser, adapted to a particular context of use, serving application specific data to the client via HTTP/REST, managing application state and UI adaptation, requesting information from a Transaction Processing Back-End and serving it to the client, sending financial transactions to the Transaction Processing Back-End for execution.

The data format for all data exchanged through HTTP/REST requests is JavaScript Object Notation (JSON).

The Transaction Processing Back-End is not part of our application, but represents an existing infrastructure for processing financial transactions. The Back-End Server communicates with this transaction processing system. The communication protocol between the Transaction Processing Back-End and our sample application's Back-End Server depends on an existing infrastructure. Thus, the Back-End Server needs to provide a custom adapter for interfacing with this system.

In our case study, PC and mobile applications are identical concerning their functionality. The main difference comes from adaptation to different context of use scenarios (e.g. screen sizes, operation through keypad/touch screen etc.). This also includes spreading of functiontionality on the mobile device over multiple dialogs, compared to the PC application. In contrast to PC and mobile clients, the application architecture of the ATM client is significantly different. This is due to the need for supporting a whole variety of ATM specific hardware devices, like NFC Reader, Card Reader, Encrypting Pin Pad (EPP), Cash Dispenser, etc. For interoperability reasons, ATM vendors are using a common software stack called XFS, which is layered on top of device specific drivers. XFS stands for Extensions for Financial Services and is standardized by CEN, the European Commitee for Standardization. Since a browser itself can not directly access the XFS-API, we delegate device control to a Device-Proxy Server running directly on the ATM.

UI/Adaptation Modeling and Transformation

For realizing the modeling (UI and adaptation) and transformation step of the engineering approach, we have implemented a model-based UI development (MBUID) process which is depicted in figure 7. This MBUID process supports the modeling of UIs and adaptation rules as well as their transformation to final user interfaces, which are the view parts of the single-page application rendered as HTML5 by the browser. Based on the open source IFML Editor Eclipse plugin developers are able to specify the domain and abstract UI model. In figure 8 the domain model and an excerpt of the abstract UI model showing the login view are depicted for the example scenario of our case study. As a complementary modeling step, the IFML extensions Context-IFML and Adapt-IFML allow the specification of adaptation rules for UI adaptation at runtime. For showing the structure of such adaptation rules, figure 9 shows two exemplary adaptation rules represented as a table. For transforming these models into final web UI views, we implemented an Xtend plugin that maps the IFML model elements to specific HTML5 elements. The Xtend plugin includes different Xtend templates to transfer the IFML source model into web UIs supporting different context of use parameters. During the transformation process, the application's view is built upon basic components with a custom look & feel, like buttons, text input fields, dropdown lists, tables, etc. As a basis for these components, we did not use AngularJS directives, but implemented components based on the HTML5 Web Components4 specification promoted by Google as W3C standard.

Our custom components are sensitive to the context of use they are being used in and adapt themselves accordingly. On mobile devices and on the ATM, for example, buttons are larger and more suitable for touch operation than on desktop devices. During the transformation process for all device classes, a button is created the same way: The following example shows how to create a text input field with a label by mapping an IFML simple field element to the following code snippet: <komos-t e x t f i e l d l a b e l=" C u r r e n t PIN" ng-model=" model . c u r r e n t P i n "> </komos-t e x t f i e l d >

In order to provide a unified layout management for our application, our model-to-text (M2T) transformation process implements a custom layout man-ager. It provides an easy to use grid layout system, based on row and column elements realized as AngularJS directives. Under the hood, it uses HTML5 Flexbox. Figure 11 shows the generated code snippet to create the login dialog that is depicted below. While the previous subsection presented our MBUID process to support the modeling and generation of view aspects of the Front-End, this subsection deals with the execution of the resulting UIs. In this context, we especially present the controller part of the Front-End, which is responsible for application logic and communication with the Back-End Server. In conjunction with this topic, we also present the aspect of channel handover and task-continuity. The aspect of UI adaptation at runtime will be explained in the next subsection.

As shown in figure 13, the Front-End consists of a HTML5/JavaScript singlepage application running in a web browser. It exchanges JSON messages with the Back-End Server through HTTP/REST. In order to support task continuity and transfer application state between devices, the current state name and its associated context are saved to the Back-End Server.

Inside a view controller and prior to saving a state, all context information necessary for recovery is added to a state-context object. This includes the UI's view-model, as well as any other necessary information associated with the current state. We implemented an AngularJS service named PersistStateService, which converts the object context to JSON and sends it to the Back-End Server, where it is stored under the name of the state, e.g. protected.main. To invoke a previously saved state, the application just needs to retrieve the current state name and invoke it: On instantiation of the AngularJS controller associated with this state, the controller calls the service's restore method to retrieve the previously stored information: Both, saving and retrieving context data for a state happens within the same controller. Each controller knows exactly which data needs to be saved in order to be able to restore itself. This information is hidden from other parts of the application. The only knowledge necessary from the outside is the name of the state, protected.main in our example.

Because of AngularJS' two-way data-binding, assigning the view-model to $scope.model immediately updates the view.

Execution and Adaptation (Back-End)

The application's Back-End is implemented in JavaScript (see figure 14) and uses Node.js8 as its runtime environment. It is built upon Google's V8 JavaScript engine also used by Google Chrome and provides a high-performance runtime environment for non-blocking and event-driven programming. ExpressJS9 , which is a middleware for Node.js, provides components for processing of requests and routing. An application sets up request handlers, which are automatically invoked when a client request arrives. Within a request handler, the request is processed, a response is prepared and returned. Request handlers communicate with the database or Transaction Processing Back-End. The document database MongoDB10 belongs into the category of NoSQL ("Not Only SQL") databases. In this context, a "document" consists of a userdefined data structure of key-value pairs, which is associated with a key. Documents can also contain other documents. The schema of a database is dynamic and can be modified at runtime. To access the database in an object-oriented fashion, we use an Object Document Mapper called Mongoose on top of Mon-goDB's Node.js driver.

MongoDB

Node.js Back-End Server

The instantiation of our engineering approach and interaction of all described technologies resulted in the demonstrator which is shown in figure 15.

Our demonstrator shows the implementation of context-adaptive UIs for a crosschannel banking web-application that supports different channels (Desktop, Tablet, and ATM) for a cash payout process enabling task-continuity for the customers.

Conclusion and Outlook

This paper presents a model-based engineering approach that supports systematic and efficient development of context-adaptive UIs for heterogeneous and dynamically changing contexts of use (user, platform, environment). The proposed engineering approach supports modeling, transformation and execution of context-adaptive UIs that enable a personalized, flexible and task-continuous usage of cross-channel applications. The feasibility of the approach was shown based on an industrial case study, where the implementation of context-adaptive UIs for a cross-channel banking web application is presented. Furthermore, industrial experiences resulted in positive feedback regarding the applicability and efficiency of the approach. However, we plan to evaluate the efficiency and effectiveness of the approach in more complex development scenarios. Future work will also cover the evaluation of usability aspects for end-users of the generated and adapted UIs as well as for the developers using the tools and languages proposed in our approach.

Fig. 1 .

 1 Fig. 1. Example Scenario: Omni-Channel-Journey with Task-Continuity

Fig. 2 .

 2 Fig. 2. Model-based engineering approach for developing context-adaptive UIs supporting task-continuity

Fig. 3 .

 3 Fig. 3. Metamodel for Context Modeling (Context-IFML)

Fig. 4 .

 4 Fig. 4. Metamodel for Adaptation Modeling (Adapt-IFML)

Fig. 5 .

 5 Fig. 5. Architectural overview of context-adaptive UIs

Fig. 6 .

 6 Fig. 6. Case-Study application architecture

Fig. 7 .Fig. 8 . 2 Fig. 9 .

 7829 Fig. 7. Implemented model-based UI development process

Fig. 10 .

 10 Fig. 10. Buttons and text fields for Desktop and Mobile

Figure 10

 10 Figure 10 shows buttons and text input fields. Their desktop representation is depicted on the left side, their mobile appearance on the right side of the picture.During the transformation process for all device classes, a button is created the same way:

  <komos-b u t t o n c o l o r s c h e m e=" c s 1 " ng-c l i c k=" c o n f i r m ( ) "> Confirm <komos-button>

Fig. 11 .

 11 Fig. 11. Desktop UI: generated code snippet and corresponding login dialog

Fig. 12 .

 12 Fig. 12. Example of a generated adaptation rule that is represented in the Nools DSL

  v a r c o n t e x t = { // t h e vie w model : viewModel : $ s c o p e . model , // s t a t e s p e c i f i c a r b i t r a r y p r o p e r t i e s : param1 : someValue , d a t a : someData } ; P e r s i s t S t a t e S e r v i c e . s a v e ( ' p r o t e c t e d . main ' , c o n t e x t , f u n c t i o n ( e r r , d a t a ) { i f ( e r r ) model . e r r o r s . message = e r r . d a t a . message ; } ) ;

$ r o o

  t S c o p e . $ s t a t e . go ( ' p r o t e c t e d . main ' ) ;

Fig. 14 .

 14 Fig. 14. Back-End Architecture

Fig. 15 .

 15 Fig. 15. Context-Adaptive UIs for a Cross-Channel Banking Web Application supporting Task-Continuity

  gives an architectural overview of the execution environment for context-adaptive UIs. The solution architecture is based on IBM's MAPE-K[START_REF] Kephart | The Vision of Autonomic Computing[END_REF] loop, where an Adaptation Manager monitors and adapts the Context-Adaptive UI that can run on different

			Adaptation Model	Adaptation Rule
			«th rows»
		Context	Ev ent	Condition	Action
	Us er	Platform	Env ironment	Va lue	Operator
			Tas k_ChangeOpe ration	Na v igation_ ChangeOperati on	Layout_ChangeOperation	ComposedAction
		AddViewComponent	De leteV iew Component	AddNav Link	ChangeFontSize	ChangeFont
				De leteNav Li nk
						ChangeColor	SwitchWidgetType
				Re direc tNav Link	Re order View Elem ents	SplitVie w Container

WebSocket AngularJS Single-Page Application

  UI Router 7 : flexible client-side routing with nested views in AngularJS -Web Components: UI components with custom look & feel -Layout Manager: custom layout manager AngularJS supports the model-view-controller (MVC) design pattern by decoupling the application's presentation layer, which is defined through HTML5 (see previous subsection), from the model and application logic by two-way databinding through a $scope object. In addition, AngularJS provides a variety of other services, including modularization and definition of custom directives.UI Router is the client-side routing component of AngularJS and the central key component to implement task continuity. The developer assigns a particular application state, identified by a name (protected.main), with a view (main.html) and a controller (MainCtrl):

	-a n g u l a r . module ( ' komosApp ' ) . c o n f i g ( f u n c t i o n ( $ s t a t e P r o v i d e r ) {
	$ s t a t e P r o v i d e r
	. s t a t e ( ' p r o t e c t e d . main ' , {
	u r l : ' / ' ,
	t e m p l a t e U r l : ' p r o t e c t e d / main / main . html ' ,
	c o n t r o l l e r : ' MainCtrl ' ,
	a u t h e n t i c a t e : true
	} ) ;
	} ) ;
		Module
		Config
		UI Router
	View		Controller
	HTML CSS Web Components	View Model $scope	JavaScript
	Layout Manager
			HTTP/REST
	USER	Device-Proxy	Back-End Server
		Server (ATM only)
	Fig. 13. Front-End Architecture
	The browser application's main building blocks are:
	-AngularJS 6 : Google's open-source web application framework for developing
	single-page applications in JavaScript

  P e r s i s t S t a t e S e r v i c e . r e s t o r e ( ' p r o t e c t e d . main ' , f u n c t i o n ( e r r , c o n t e x t ) {

	i f ( e r r ) {
	model . e r r o r s . message = e r r . d a t a . message ;
	} e l s e {
	// c o n t e x t now c o n t a i n s t h e p r e v i o u s l y s a v e d i n f o r m a t i o n
	$ s c o p e . model = c o n t e x t . viewModel ; // t h i s u p d a t e s t h e UI ! !
	someValue = c o n t e x t . param1 ;
	someData = c o n t e x t . d a t a ;
	}
	} ) ;

http://www.ifml.org

http://ifml.github.io

http://www.eclipse.org/xtend

https://www.w3.org/TR/components-intro

https://github.com/C2FO/nools

https://angularjs.org

https://github.com/angular-ui/ui-router/wiki

https://nodejs.org

https://expressjs.com

https://www.mongodb.org

This work is based on "KoMoS", a project of the "it's OWL" Leading-Edge Cluster, partially funded by the German Federal Ministry of Education and Research (BMBF).