Context-Aware UI Component Reuse for Web Service Development Environments ] Kerstin Klemisch, Mba CONTEXT-AWAREUICOMPONENTREUSEFORWEB SERVICEDEVELOPMENTENVIRONMENTS

CONTEXT-AWAREUICOMPONENTREUSEFORWEB SERVICEDEVELOPMENTENVIRONMENTS

kerstin klemisch, mba supervisor: prof. boualem benatallah co-supervisor: ingo weber, phd

PhD Thesis

School of Computer Science and Engineering Faculty of Engineering

March 2015

[ Context-aware UI Component Reuse for Web Service Development Environments ] kerstin klemisch, mba CONTEXT-AWAREUICOMPONENTREUSEFORWEB SERVICEDEVELOPMENTENVIRONMENTS

[ Context-aware UI Component Reuse for Web Service Development Environments ] Kerstin Klemisch, MBA: Context-aware UI component Reuse for Web Service Devel- opment Environments, PhD Thesis, c March 2015

[ Context-aware UI Component Reuse for Web Service Development Environments ] Remember, we all stumble, every one of us. That’s why it’s a comfort to go hand in hand. — Emily Kimbrough

Dedicated to my family, Oliver, Wolfgang, Edith, Saskia, Sven and Britta.

[ Context-aware UI Component Reuse for Web Service Development Environments ] ABSTRACT

Adapting user interfaces (UIs) to various contexts, such as for the exploding number of different devices, or specific business processes in different companies, has become a major challenge for UI developers. The support offered by current development environments for UI adaptation is limited, as is the support for the efficient creation of UIs in web service-based applications. Even with sophisticated UI development environments, UI developers still encounter many repetitive, time-consuming tasks during the UI development process. In this thesis, we describe an approach where – based on a given context – a complete user interface is suggested. The suggestions are created by a rule- based recommender system, which combines web service-bound UI elements with other UI building blocks. Rules for the UI Layout, Theme (the style sheet), Binding of UI building blocks to web services and Composition of UI components are established, and saved in a knowledge base for later reuse. Rules are created automatically based on the creation or modification of UIs. The approach has been implemented, as well as evaluated by simulating the development of 115 SAP UI screens.

[ Context-aware UI Component Reuse for Web Service Development Environments ] The most important property of a program is whether it accomplishes the intention of its user — C.A.R. Hoare

ACKNOWLEDGMENTS

This dissertation represents a culmination of efforts, and has been made possible by the assistance and support of various parties.

I would like to extend a warm and sincere thank-you to my supervisors Prof. Boualem Benatallah and Dr. Ingo Weber, for their valuable feedback, immense knowledge, inspiration, guidance, constant support and advice.

My sincere thanks also goes my thesis panel, Prof. Paul Compton, UNSW, for his helpful advice, particularly in regards to RDR technologies, and Prof. Fethi Rabhi and Dr. Srikumar Venugopal, School of Computer Science and Engineer- ing, UNSW, for their encouragement, helpful questions and insightful comments.

I’m thankful to SAP Research, the University of New South Wales and Smart Services CRC Sydney for having given me the great opportunity to write a PhD thesis in collaboration with the IT industry.

Furthermore, I thank my fellow PhD students Van Hai Ho and Basem Suleiman, who have assisted me during my thesis, and for being great friends.

A big thank you also goes to Jan-Felix Schwartz, who assisted me during the creation of the prototype for this work, and Patrick de Guzman, who implemented a second prototype based on our approach for his honours thesis.

I would like to express my gratitude to Lyn Campbell-Anderson, Daniel Cic- ciarelli, Helen Conran, Vicki Korb, Leanne Mavridis, Bev McMasters, and Terry Southwell, who performed a ﬁnal review of my thesis.

Last but not least, I would like to thank my husband, my friends and my family for their constant support and encouragement throughout this journey.

[ Context-aware UI Component Reuse for Web Service Development Environments ] CONTENTS

1 introduction1 1.1 Background 1 1.2 Problem Statement 3 1.3 Contributions Overview 3 1.4 Thesis Organisation 4 2 background and related work6 2.1 Web Services 6 2.1.1 Web Service Deﬁnition 6 2.1.2 Service Interfaces 7 2.1.3 APIs and API platforms 9 2.1.4 Web APIs and Mashups 11 2.1.5 GUI Development for Web Services 12 2.1.6 Web Services – Discussion 14 2.2 UI Development 14 2.2.1 UI Components 15 2.2.2 UI Creation with Java Swing and Java NetBeans IDE 15 2.2.3 UI Creation in Microsoft Visual Studio 20 2.2.4 UIs at SAP Business ByDesign 25 2.2.5 UI Development with Bootstrap 30 2.2.6 UI Development with DukeScript 32 2.2.7 UI Development – Discussion 34 2.3 Code Reuse and Code Search 36 2.3.1 Code Reuse 36 2.3.2 Question & Answer Sites 39 2.3.3 Code Reuse and Code Search – Discussion 40 2.4 UI Patterns 41 2.4.1 Deﬁning UI Patterns 41 2.4.2 Elements of Interaction Design Patterns 42 2.4.3 Reasons for using Patterns 43 2.4.4 UI Pattern Examples 44 2.4.5 Parties contributing to UI Patterns 45 2.4.6 The Pattern Approach at SAP 46 2.4.7 UI Patterns and their Usage in UI development 53 2.4.8 UI Patterns – Discussion 54

vii

[ Context-aware UI Component Reuse for Web Service Development Environments ] contents viii

2.5 UI and Context 54 2.5.1 Examples of Context requiring UI Adaptation 55 2.5.2 GUI Development and Context-Awareness 58 2.5.3 UI and Context – Discussion 61 2.6 Background and Related Work - Discussion 62 3 ui development knowledge, concepts and representation 65 3.1 Representing UI Components 65 3.2 Representing UI Recommendation Rules 66 3.2.1 Rule Conditions 67 3.2.2 Rule Conclusions 67 3.2.3 Data Structures for Rules 70 3.3 UI Development Knowledge, Concepts and Representation - Dis- cussion 74 4 ui knowledge acquisition 75 4.1 Context and UI Repository in the UI Recommender System 76 4.2 Investigation of SAP CRM User Interfaces 77 4.3 Rule Speciﬁcation 80 4.4 Incremental UI Knowledge Acquisition 82 4.5 Conﬁdence Score 83 4.6 Evolution of Rules 84 4.7 UI Knowledge Acquisition - Discussion 85 5 system architecture, implementation & knowledge base content 86 5.1 Deciding on a Knowledge Base Rule Paradigm 86 5.2 Prototypical Implementation of UISE 87 5.3 Class Structure for UISE 91 5.3.1 Classes forming the Rule Condition 92 5.3.2 Classes forming the Rule Conclusion 93 5.4 Knowledge Base Content Elicitation for UISE 96 5.4.1 Elicitation of the Device Hierarchy for UISE 96 5.4.2 Elicitation of the Business Scenario Hierarchy for UISE 103 5.5 Cross Platform & Context Web Services - WST 104 5.5.1 Design for WST 104 5.5.2 System Architecture and Implementation for WST 110 5.6 System Architecture and Implementation - Discussion 111 6 evaluation 112 6.1 Evaluation of UISE 112 6.1.1 Evaluation Objectives and Settings - UISE 112

[ Context-aware UI Component Reuse for Web Service Development Environments ] contents ix

6.1.2 Evaluation Results - UISE 114 6.2 Evaluation of WST 116 6.2.1 Goal of the Evaluation - WST 116 6.2.2 Evaluation Environment - WST 116 6.2.3 Evaluation Search by Keywords - WST 116 6.2.4 Experiment 1 Results - WST 118 6.2.5 Experiment 2 Results - WST 118 6.2.6 Experiment 3 Results - WST 122 6.3 Evaluation - Discussion 123 7 conclusion 128 7.1 Challenges 128 7.2 Summary 129 7.3 Future Research 129 a appendix 131 a.1 Examples for SAP CRM UIs and UI Elements 131 a.1.1 Sales Order Management UIs 131 a.1.2 Sales Order Management UI Elements 134 a.1.3 Service Order Management UIs 145 a.1.4 Service Order Management UI Elements 145 a.1.5 Contract Management UIs 164 a.1.6 Contract Management UI Elements 164 a.1.7 Examples of CRM UIs and UI Elements - Discussion 174

[ Context-aware UI Component Reuse for Web Service Development Environments ] LISTOFFIGURES

Figure 2.1 Consumer Mashup: Housingmaps.com 11 Figure 2.2 Data Mashup: RSOE EDIS 12 Figure 2.3 Enterprise Mashup: Staff Allocation Mashup seen on www.jackbe.com 13 Figure 2.4 Hierarchy of UI Components 16 Figure 2.5 UI Pattern Palette in NetBeans IDE 17 Figure 2.6 NetBeans IDE Design View 17 Figure 2.7 NetBeans IDE Source View 18 Figure 2.8 NetBeans IDE Property Editor 19 Figure 2.9 Simple UI Patterns in NetBeans IDE 19 Figure 2.10 Registering Events in NetBeans IDE 20 Figure 2.11 Simple Controls in Visual Studio 21 Figure 2.12 Data Grid View in Visual Studio 2008 22 Figure 2.13 Month Calendar Pattern in Visual Studio 2008 22 Figure 2.14 Examples of Controls and Shapes in Expression Blend [51] 23 Figure 2.15 Blend for HTML [93] 24 Figure 2.16 Silverlight Custom Button in Expression Blend [116] 24 Figure 2.17 Patterns in the SAP UI Designer 26 Figure 2.18 Deﬁning the Data Model in the UI Designer 26 Figure 2.19 Data Binding 27 Figure 2.20 Adding the Hierarchical Extension to the Data Model 27 Figure 2.21 Sales Order Management in SAP Business ByDesign- Min- imum Layout 28 Figure 2.22 Sales Order Management in SAP Business ByDesign - Max- imum Layout 29 Figure 2.23 Hiding Fields or displaying additional ones in SAP Busi- ness ByDesign 29 Figure 2.24 Commercial Bootstrap Themes available on WrapBootstrap 31 Figure 2.25 Free Bootstrap Themes available on BootsWatch 31 Figure 2.26 Labels belonging to a Bootstrap Theme 32 Figure 2.27 Carousel UI Component in Bootstrap 32 Figure 2.28 Setting up a Project in DukeScript 33 Figure 2.29 Deploying the Project for NetBeans 34

[ Context-aware UI Component Reuse for Web Service Development Environments ] List of Figures xi

Figure 2.30 “Hello World” Program for HTML and Java NetBeans 35 Figure 2.31 Choosing the Target Platform 36 Figure 2.32 Tag Cloud (www.ﬂickr.com), as shown on [109] 45 Figure 2.33 Calendar Picker Pattern [105] 45 Figure 2.34 Hierarchy of UI Patterns at SAP Business ByDesign [118] 46 Figure 2.35 Controls constituting Building Block Elements [118] 47 Figure 2.36 Building Block Elements [118] 48 Figure 2.37 Workcentre Floorplan with Building Blocks [118] 49 Figure 2.38 Floor Plans in SAP UI Design [118] 50 Figure 2.39 Work Centre Pattern in SAP Business ByDesign (Extract) 50 Figure 2.40 Guided Activity Pattern in SAP Business ByDesign (Ex- tract) 51 Figure 2.41 The UI Pattern Concept at SAP [4] 52 Figure 2.42 Standard Sales Order in SAP CRM 4.0, Transaction CRMD_- ORDER 56 Figure 2.43 Mobile Sales for Handheld 5.0 57 Figure 3.1 ER-Model of Rule Components 66 Figure 3.2 Composition of UIs by combining UI elements 68 Figure 3.3 Examples for different Layouts 69 Figure 3.4 Stylesheets for different Banks 70 Figure 3.5 Sales Order UI bound to different Web Services 70 Figure 3.6 Representation of UI “Create Standard Sales Order Mo- bile” on the Database Level 71 Figure 3.7 Representation of UI “Create Standard Sales Order Mo- bile” on the Database Level 73 Figure 4.1 Proposed Architecture of the Recommender System 75 Figure 4.2 Example of a Device Hierarchy 76 Figure 4.3 Sales Order UI Quotation 78 Figure 4.4 UI Component Sales Header 4 78 Figure 4.5 UI Component Sales Date Section 2 78 Figure 4.6 UI Component Sales Item List 1 79 Figure 4.7 Replenishment Order UI 80 Figure 4.8 UI Component Sales Date Section 1 80 Figure 4.9 Rules in our Approach, featuring four Dimensions in the Conclusion 81 Figure 5.1 Choosing the Device in UISE 89 Figure 5.2 Architecture of the Recommender System 90

[ Context-aware UI Component Reuse for Web Service Development Environments ] List of Figures xii

Figure 5.3 Suggested Create Sales Order UI in UISE and Editing Func- tionalities 91 Figure 5.4 Recommender System: Knowledge Acquisition (top: User; bottom: System) 92 Figure 5.5 Class Diagram for the UISE prototype 95 Figure 5.6 Device Hierarchy used for MDBF 97 Figure 5.7 Device Identiﬁcation used for Volantis 98 Figure 5.8 Device Format used for Volantis 98 Figure 5.9 Device Hierarchy used for Volantis 99 Figure 5.10 Device Hierarchy used for WURFL 100 Figure 5.11 Device Hierarchy used for UAProf 101 Figure 5.12 Business Scenario Hierarchy in UISE (Extract) 103 Figure 5.13 Data Model for representing UI Widgets in [38] 105 Figure 5.14 Example of a Composition in [38] 106 Figure 5.15 Example of Theme and various Templates in [38] 106 Figure 5.16 Example of Device Hierarchy in [38] 107 Figure 5.17 Example of Business Scenario Hierarchy in [38] 108 Figure 5.18 Concrete Example of Data Store in Data Base in [38] 109 Figure 5.19 System Architecture in [38] 110 Figure 6.1 Knowledge Base Size vs. Number of UIs 114 Figure 6.2 Changes for Sales Order, Contract, and Service Order UIs 115 Figure 6.3 Results of Search by Keyword for Widget Search Tool in [38] 119 Figure 6.4 Results of Search by Keyword for Google in [38] 122 Figure 6.5 Precision Measure for Search by Keyword in [38] 124 Figure 6.6 Results of Search by Context for Widget Search Tool in [38] 125 Figure 6.7 Results of Search by Context for Google in [38] 125 Figure 6.8 Precision Measure for Search by Context in [38] 126 Figure 6.9 Result of negative Search for Widget Search Tool in [38] 126 Figure 6.10 Result of negative Search for Google in [38] 127 Figure 6.11 Precision Measure for negative Search in [38] 127 Figure A.1.1 Standard Sales Order in SAP CRM 131 Figure A.1.2 Telesales Sales Order in SAP CRM 132 Figure A.1.3 Quotation in SAP CRM 132 Figure A.1.4 Web Auction Quotation in SAP CRM 133 Figure A.1.5 Replenishment Order in SAP CRM 133 Figure A.1.6 Sales Header Element 1 134

[ Context-aware UI Component Reuse for Web Service Development Environments ] List of Figures xiii

Figure A.1.7 Sales Header Element 2 135 Figure A.1.8 Sales Header Element 3 135 Figure A.1.9 Sales Header Element 4 137 Figure A.1.10 Sales Header Element 5 137 Figure A.1.11 Sales Header Element 6 138 Figure A.1.12 Sales Header Element 7 138 Figure A.1.13 Sales Header Element 8 138 Figure A.1.14 Sales Header Element 9 139 Figure A.1.15 Sales Date Section Element 1 140 Figure A.1.16 Sales Date Section Element 2 141 Figure A.1.17 Sales Date Section Element 3 141 Figure A.1.18 Sales Date Section Element 4 142 Figure A.1.19 Sales Item List Element 1 144 Figure A.1.20 Sales Item List Element 2 144 Figure A.1.21 CD Service Order in SAP CRM 145 Figure A.1.22 FSL Service Order in SAP CRM 146 Figure A.1.23 ISA Service Order in SAP CRM 146 Figure A.1.24 Online Pricing in SAP CRM 147 Figure A.1.25 Order Quotation MorePriAc in SAP CRM 147 Figure A.1.26 Service Order MorePr in SAP CRM 148 Figure A.1.27 Package Quotation in SAP CRM 148 Figure A.1.28 Service Order Header Element 1 149 Figure A.1.29 Service Order Header Element 2 150 Figure A.1.30 Service Order Header Element 3 150 Figure A.1.31 Service Order Header Element 4 150 Figure A.1.32 Service Order Header Element 5 150 Figure A.1.33 Service Order Business Partner Element 1 151 Figure A.1.34 Service Order Business Partner Element 2 152 Figure A.1.35 Service Order Business Partner Element 3 152 Figure A.1.36 Service Order Business Partner Element 4 152 Figure A.1.37 Service Order Business Partner Element 5 153 Figure A.1.38 Service Order Business Partner Element 6 153 Figure A.1.39 Service Order Business Partner Element 7 153 Figure A.1.40 Service Order IBase Section 1 155 Figure A.1.41 Service Order Date Section 1 156 Figure A.1.42 Service Order Date Section 1 156 Figure A.1.43 Service Order Date Section 3 156 Figure A.1.44 Service Order Date Section 4 157

[ Context-aware UI Component Reuse for Web Service Development Environments ] Figure A.1.45 Service Order Priority Section 1 157 Figure A.1.46 Service Order Priority Section 2 158 Figure A.1.47 Service Order Priority Section 3 159 Figure A.1.48 Service Order Priority Section 4 159 Figure A.1.49 Service Order Priority Section 5 159 Figure A.1.50 Service Order Problem Section 1 161 Figure A.1.51 Service Order Problem Section 2 161 Figure A.1.52 Service Order Problem Section 3 161 Figure A.1.53 Service Order Item Section 1 163 Figure A.1.54 Service Order Item Section 2 163 Figure A.1.55 Service Order Item Section 3 163 Figure A.1.56 Service Order Item Section 4 164 Figure A.1.57 ECC Quantity Contract in SAP CRM 164 Figure A.1.58 ECC Value Contract in SAP CRM 165 Figure A.1.59 Quantity Contract in SAP CRM 165 Figure A.1.60 Ship and Debit Contract in SAP CRM 166 Figure A.1.61 Subscr.-Loose.Pub in SAP CRM 166 Figure A.1.62 Individual Contract in SAP CRM 167 Figure A.1.63 Service Contract Header Element 1 168 Figure A.1.64 Contract Header Element 1 168 Figure A.1.65 Contract Header Element 2 169 Figure A.1.66 Contract Header Element 3 169 Figure A.1.67 Contract Header Element 4 169 Figure A.1.68 Service Contract Date Section Element 1 170 Figure A.1.69 Service Contract Date Section Element 2 170 Figure A.1.70 Service Contract Date Section Element 3 170 Figure A.1.71 Contract Date Section Element 1 171 Figure A.1.72 Contract Date Section Element 2 171 Figure A.1.73 Contract Date Section Element 3 171 Figure A.1.74 Service Contract Item Section Element 1 172 Figure A.1.75 Service Contract Item Section Element 2 172 Figure A.1.76 Service Contract Item Section Element 3 173 Figure A.1.77 Contract Item Section Element 1 173 Figure A.1.78 Contract Item Section Element 2 173 Figure A.1.79 Contract Item Section Element 3 174

xiv

[ Context-aware UI Component Reuse for Web Service Development Environments ] Figure A.1.80 Contract Item Section Element 4 174

LISTOFTABLES

Table 2.1 Comparison of Code Reuse Approaches 39 Table 2.2 UI Pattern Approaches and Communities 54 Table 2.3 Comparison of cross-Platform GUI Toolkits 60 Table 2.4 Comparison of HTML5 Mobile Development Frameworks 61 Table 2.5 Comparison of Related Work 63 Table 5.1 Reuse-API 88 Table 5.2 Build-API 88 Table 6.1 Test Cases for Experiment 1 in [38] 118 Table 6.2 Test Cases for Experiment 2 in [38] 121 Table 6.3 Test Cases for Experiment 3 in [38] 123

ACRONYMS

ICT Information and Communications Technology

UI User Interface

API Application Programming Interface

IDE Integrated Development Environment

WS Web Service

WSDL Web Service Description Language

SOAP Simple Object Access Protocol

CRM Customer Relationship Management

XSD XML Schema Deﬁnition

[ Context-aware UI Component Reuse for Web Service Development Environments ] acronyms xvi

XML Extensible Markup Language

ERP Enterprise Ressource Planning

UISE UI Suggestion Environment

GUI Graphical User Interface

URI Uniform Resource Identiﬁer

HTTP Hypertext Transfer Protocol

RPC Remote Procedure Call

REST Representational State Transfer

JSON Javascript Object Notation

XHTML Extensible HyperText Markup Language

ASP Application Service Providers

SaaS Software as a Service

EDIS Emergency and Disaster Information Service

RSOE National Association of Radio Distress-Signalling and Infocommunications

WPF Windows Presentation Foundation

MIME Multi-Purpose Internet Mail Extensions

REST Representational State Transfer

SOA Service Oriented Architecture

SAP Systems Applications Products in Data Processing iOS iPhone Operating System

SME Small and Medium Enterprises

BO Business Object

MS Microsoft

[ Context-aware UI Component Reuse for Web Service Development Environments ] acronyms xvii

CSS Cascading Style Sheets

JS JavaScript

DOM Document Object Model

JVM Java Virtual Machine

AJAX Asynchronous JavaScript And XML

Q&A Question & Answer

OOPSLA Object-Oriented Programming, Systems, Languages & Applications

PDA Personal Digital Assistant

PC Personal Computer

UX User Experience

MDA Mobile Digital Assistant

TV Television

KB Knowledge Base

MVC Model View Controller

ASP Application Server Protocol ascx Active Server Controls eXtended aspx Active Server Methods eXtended

RDR Ripple Down Rules

SCRDR Single Classiﬁcation Ripple-Down Rules

MCRDR Multiple Classiﬁcation Ripple-Down Rules

CRDR Collaborative Ripple-Down Rules

MDBF Mobile Device Browser File

XDIME XHTML Device Independant Markup Extensions

WURFL Wireless Universal Ressource File

[ Context-aware UI Component Reuse for Web Service Development Environments ] acronyms xviii

DDR Device Description Repository

PHP Personal Home Page

RDF Resource Description Framework

CDMA Code Division Multiple Access

BREW Binary Runtime Environment for Wireless

GSM Global System for Mobile Communications

WAP Wireless Application Protocol

UAProf User Agent Proﬁle Speciﬁcation

B2B Business to Business

B2C Business to Consumer

ISA Internet Sales Application

BOB Business

CD Collections and Disbursements

GS Goods Supplier

WST Widget Search Tool

[ Context-aware UI Component Reuse for Web Service Development Environments ] 1 INTRODUCTION

1.1 background

There are few Information and Communications Technology (ICT) areas as eco- nomically and socially critical today as the provision of services over mobile and Web channels. This trend profoundly impacts the effectiveness of services delivery in a variety of domains including health, banking, education, healthcare, meteorology, forecasting, media, and office tasks. For instance, over 1.2 million Apple applications were accessible in June 2014. Apple was neck-to-neck with their competitor Google, who likewise had an estimated number of 1.2 million apps on offer [85]. From a software engineering point of view, while advances in mobile and Web technologies increased the ability to deploy simple services and devices, the demand for effective development of mobile applications is rising even faster. More specifically, the development of user interfaces has been identified as one of the most time-consuming tasks in the overall application development cycle [132]. This is partly due to the fact that user interfaces have to be developed for a large number of different devices with different development platforms, such as XCode for Apple iPhones and iPads, Android SDK for Android mobile phones, or Carbide IDE for Symbian applications [63]. Modern Integrated Development Environments (IDEs) support User Interface (UI) developers by providing: reusable basic UI elements (e.g., text boxes, sliders) from generic programming libraries (e.g., JQuery [101], VCL [129]), code generation / completion for both UI and functionality as in Microsoft (MS) Visual Studio, UI to functionality binding specification, etc. However, even with sophisticated IDEs like Microsoft Visual Studio or Bootstrap [122], there are still many repetitive, time-consuming tasks that UI developers have to code manually. Ex- amples of such tasks are the repetitive drag and drop of basic UI elements (e.g., text boxes, buttons) onto a canvas, creation of UI elements from scratch, config- uration of UI element parameters (e.g., size), specification of UI screen layouts, definition of labels and descriptions. In addition to describing UI elements, developers need to develop mappings from UI elements to backend functions and

[ Context-aware UI Component Reuse for Web Service Development Environments ] 1.1 background 2

vice versa (e.g., mapping Web form ﬁelds to Web Service (WS) parameters, or WS invocation results to Web widgets). In this work, we focus on improving productivity of UI development on top of web services, as web services are widely used to provide backend interfaces to a range of applications from Enterprise Ressource Planning (ERP) software to cloud services. A good example to illustrate the reuse of backend functionality via services is Twilio [107], a provider of various Application Programming Interfaces (APIs) for messaging services such as telephony and SMS. A large number of applications have been developed on top of Twillio in a variety of domains. For instance, recently Twilio announced that 150,000 developers used its APIs to support phone calls, video conferencing and chat features including the development team of eBay and Hulu. Application development over services such as Twilio is UI intensive. When offering a service in different contexts, its UI has to be adapted to these contexts, including, e.g., the adaptation to new consumption channels, new audiences, and the change of UIs as an outcome of usability testing [33]. In addition, in enterprise applications, the adaptation to business scenarios is a major requirement in UI development. A business scenario is essentially a “complete description of a business problem” [104]. Examples of business scenarios are sales order management and supply chain management. A business scenario can be associated with a collection of reusable UI elements including UI templates, backend services, and mapping templates between the two. Adapting UI code to a given context can be complex, time-consuming and resource-intensive. In major software development projects, various techniques are used to create appropriate UI prototypes before the development phase starts. These techniques include brainstorming, mockup design iterations by experienced UI designers, and usability testing. Existing UI development and adaptation techniques have not kept pace with our ability to deploy individual devices and services. They rely on human understanding of different contexts, platforms, devices and extensive manual programming to develop UI components. This is clearly unrealistic in large scale and evolving environments. Main stream code reuse techniques assist developers in ﬁnding and reusing general code artefacts, such as functions and methods [66, 87]. Although these techniques have pro- duced promising results that are certainly useful, more advanced techniques that cater for effective and context-aware UI components reuse are needed. Whereas the backend functionality provided by code might be exactly the same on a desktop and a mobile device, the UI is likely to be different.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 1.2 problemstatement 3

1.2 problem statement

According to the challenges for UI development discussed in the previous section, we face the following problems:

• How can we represent UI artefacts and their major characteristics such as their layout, their look and feel, the way the artefacts are combined with other UI artefacts, the binding of UI artefacts to the underlying functionality? How can we give recommendations for UI artefacts based on a given context such as devices and business scenarios? How can this context be represented?

• How can we build a recommender system that can incorporate new knowledge over time, with minimal input from the developers? How can we offer the acquired knowlege for reuse?

• How can we package the named functionality into a tool that is efﬁcient and effective? How can we validate our approach?

1.3 contributions overview

In practice, we observe that UI developers often have valuable knowledge for identifying UI components that are most appropriate in a given context (e.g., UI components appropriate for sales order entry screens). We believe that sharing this knowledge is beneﬁcial for UI code reuse, and thus that integrating context-ware UI components reuse and Service Oriented Architecture (SOA) offers tremendous opportunities to increase productivity of modern application development frameworks. More speciﬁcally, based on the above observations we propose a novel approach for context-aware UI component reuse, making the following contributions:

1. We perform an analysis of the “state of the art” UI development. This includes the analysis of current UI development IDEs and the way they provide support to the UI developer, as well as the investigation of works in research discussing UI development for web services, code reuse and UI patterns, and the adaptation of UIs to context.

2. We propose a UI artefacts representation model and a rule-based UI component recommender system. The recommender system suggests compre-

[ Context-aware UI Component Reuse for Web Service Development Environments ] 1.4 thesis organisation 4

hensive UI components to developers. UI Programming knowledge is ex- ploited in the form of programming recommendations provided during UI development. In essence, the recommender system uses a context description (e.g., device type, business scenario) to query a “UI programming knowledge base”, which returns UI components that are “appropriate” for the given context.

3. We propose an incremental knowledge acquisition technique, by which newly created or modiﬁed UI components are associated to contexts and stored in the UI programming knowledge base for future reuse. The UI programming knowledge underpins knowledge-driven and context-aware UI components recommendations.

4. We discuss an evaluation of the proposed approach, including (i) two proof- of-concept prototypes called UI Suggestion Environment (UISE) and Widget Search Tool (WST) ; and (ii) a detailed feasibility and usefulness experiment based on 115 UIs from the SAP Business Suite Customer Relationship Management (CRM) software.

1.4 thesis organisation

The remainder of this work is divided in two major parts: First we describe the underlying concepts of our work, then we show the prototypical implementation and validation of our approach. Chapter 2 reflects on the UI development process and UI design support through current IDEs. It introduces us to the concept of UI patterns and their usage. It furthermore explains and compares work in research related to code reuse and code search, the adaptation of UIs to context, UI development for web services, and concepts of reuse for UIs. The representation of UI components and UI recommendation rules in our approach is discussed in Chapter 3. This includes a discussion of the rule data structure. Chapter 4 introduces the UI recommender system, which suggests UIs to the developer based on context. This chapter furthermore reflects on how UI recommendation rules are specified and how knowledge is acquired. The architecture and implementation of the two proof-of-concept prototypes is presented in Chapter 5, which includes the description of the elicitation of context.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 1.4 thesis organisation 5

Finally, Chapter 6 discusses the objectives and outcome of the evaluation.

Some ideas and ﬁgures have appeared previously in the publication Context- aware UI component Reuse [52].

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2 BACKGROUNDANDRELATEDWORK

In the “Background and Related Work” chapter, we introduce the foundations on which this work builds, and position our contributions in a bigger context. In the ﬁrst part of this chapter (Section 2.1), we introduce the concept of web services, discuss commonly used service interfaces, and explain the nature of (web service) APIs, API platforms and Mashups. Furthermore, we perform an investigation of work around Graphical User Interface (GUI) development approaches for web services. In Section 2.2, we present current UI development environments such as Java Swing and Java Net Beans, MS Visual Studio and the UI Designer used at SAP Busi- ness ByDesign, and cross-platform APIs Bootstrap and DukeScript, and explore how they support the UI development process. The reuse of and search for code is discussed in Section 2.3. Section 2.4 is dedicated to the history, nature and use of UI patterns. They represent common guidelines for UI development and foster reuse of UI components. We conclude with an investigation of current approaches for the creation of UIs related to context, and setting them into perspective to our work (Section 2.5).

2.1 web services

In this section, we introduce the terms web services, web service interfaces and data interchange formats. Service Interfaces, APIs and API platforms, Web APIs and Mashups are furthermore investigated. We conclude this section with a discussion of development approaches for web services .

2.1.1 Web Service Deﬁnition

W3C[113] defines web services as “a software system identified by a Uniform Resource Identifier (URI)” , “whose public interfaces and bindings are defined and described using Extensible Markup Language (XML)”. The definition of a web service can be discovered by other software systems, who may then interact

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.1 webservices 7 with the web service in a manner prescribed by its deﬁnition, making use of XML based messages conveyed by Internet protocols. Web services can be described by the following characteristics [43]:

• Self-contained: On the server-side, a web-service requires a web server and a servlet engine. On the client-side however, no additional software is needed. A programming language that supports XML and Hypertext Transfer Protocol (HTTP)-clients is sufﬁcient. Client and server can thereby reside in different environments.

• Self-describing: In order to deploy a web service, client and server have to be able to interpret the format and content of a request and response message. There is no need for external meta data repositories or code generation tools.

• Modular: Simple web services can be combined to more complex web services by a) the use of work ﬂow techniques or b) by calling lower layer web services from a web service implementation.

• Platform-independent: Being based on a set of open, XML-based stan- dards, web services allow for the interoperability of web services and clients across a number of different platforms and programming languages.

Web services can be used for a large variety of functions, e.g., weather reports, credit checks, stock quotations, airline reservation processes [23]. Having explained the term “web service”, we explain the nature of service interfaces in the following section.

2.1.2 Service Interfaces

Web services have an interface that is machine-readable. It can be maintained in the form of Web Service Description Language (WSDL), a standardised format which describes network services as a set of endpoints. It allows service providers to describe the format of requests to their systems independent of the underlying run-time implementation [45]. The communication of web services with other machines is provided by Simple Object Access Protocol (SOAP) messages. SOAP deﬁnes a protocol for exchanging structured data in the implementation of web services in computer networks. Messages deﬁned by SOAP consist of three parts [44]:

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.1 webservices 8

• Envelope. The envelope constitutes a framework for processing a message. The SOAP message consists of an envelope with zero or more header sections and exactly one body section. Control information such as quality-of- service attributes are stored in the header, whereas the body contains the message identiﬁcation and its parameters.

• Encoding Rules. SOAP defines a XML Schema Definition (XSD)-based data type scheme which is independent of programming languages. In addition, it provides encoding rules for data types defined according to this scheme. Encoding rules enable the exchange of instances of application-based data types.

• Communication Style. SOAP supports two kinds of communication styles: Remote Procedure Call (RPC) and a document-based style, also known as document-oriented or message-oriented style.

An alternative to WSDL-based interfaces is Representational State Transfer (REST), which is used by major representatives of Web 2.0 such as Google, Yahoo and Facebook. REST adheres to four basic principles (see [90]), which are:

• The explicit use of HTTP methods. According to REST’s principles, HTTP methods have to be used in accordance with RFC 2616 [37], e.g., GET is supposed to be used for the retrieval of data from a web server, but not for transactional operations such as adding records to a database.

• Statelessness. In order to meet the requirements of increasingly high performance demands, REST messages have to contain all data necessary for performing a request, without data being stored in a local state between requests. This enables the use of performance-improving measures like load balancing, proxies and gateways, as messages can be forwarded from one server to another.

• The exposition of directory structure-like URIs. REST web service URIs shall be easy to understand, so that the purpose and functionality of a web service can be predicted from the URI alone. In order to achieve this, REST suggests the use of a directory structure, such as in the URI “http: //www.myservice.org/discussion/topics/{topic}”. This URI denotes a discussion threading service which is used for collecting various topics.

• The transfer of XML, Javascript Object Notation (JSON), or both. The data which is exchanged between the application and the service in the http-

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.1 webservices 9

body or the request / response payload should be kept simple and human- readable. Furthermore, the relationships between the data objects should be reﬂected. The service should be constructed in a way that allows clients written in different languages and running on different platforms to deploy a service which is most suitable to them. In order to achieve this, RESTful web services use HTTP accept headers and MIME types of type JSON, XML and Extensible HyperText Markup Language (XHTML).

The previous paragraph mentioned JSON, or JavaScript Object Notation, which is a light-weight data interchange format [49]. Despite being based on a subset of the Javascript Programming Language, it is language-independent, and provides parsers for many languages. JSON can be used for serializing and transmitting data over a network connection. As an alternative to XML, JSON is mostly used for transmitting data between a server and web applications [125]. The following sections deal with APIs and API platforms, which play a role in the implementation of web service functionalities.

2.1.3 APIs and API platforms

The implementation of web service functionalities is supported by APIs and API platforms. There are a variety of APIs and API platforms as follows. APIs specify software components and their operations, inputs, outputs and related types. The purpose of an API is the deﬁnition of a set of functionalities independent of their implementation [120]. API management platforms, such as Mashery [62], consist of several components assisting with managing the API. The Mashery Partner Portal can be used to launch online portals for supporting developer partners, ease key provision- ing and enable reporting, e.g., on the methods developers are using. In addition, the portal serves as a support forum and developer blog, and as a publishing platform for interactive API documents. The Mashery API Control Center has been designed for managing different APIs from a central place, and providing limits, quotas and privileges to development partners. An API Packager gives control over resource packaging and assists with deﬁning access plans without coding. Detailed Activity Reports and partner monitoring is provided by the Mashery Reporting and Analytics section. Apigee’s API Platform [3] assists developers with the creation of apps. Apigee provides developer channel services which ease the adoption of developers and the creation of a developer community. Gateway Services can be used for creat-

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.1 web services 10

ing, managing and scaling APIs. App Services handle data conversions, sign in/sign up, storage, server maintenance and thereby act as a “Backend-as-a- Service” solution. The detection, diagnosis and maintenance of mobile apps is supported by Mobile Analytics. They are part of the Analytics Services which offer end-to-end visibility of the API ecosystem from the API to mobile apps. Alcatel-Lucent’s ProgrammableWeb (Alcatel-Lucent APIs Methodology, see [60]) is a search engine for released network operator and web interfaces, and the Open API Platform, which can handle management and accounting functions for all technical and commercial relationships between network operators and developers/ service providers. ProgrammableWeb is a repository of 2000 Web APIs and includes interfaces for Google Maps, Flickr and YouTube [2]. Enterprise Services was invented in 2002 by the chairman of the SAP AG, Hasso Plattner. The Enterprise Services architecture consists of reusable elements, also called modules, which are formed from layers of components aggregating data and application functions [48]. Application Service Providers (ASP) provide computer-based services to customers over a network. Software using the ASP model is often referred to as “software on-demand” or “software as a service” (SaaS)[121]. There are furthermore APIs for the Internet of Things such as Xively [130], a public cloud for the Internet of Things. Xively provides a developer work- bench and developer centre with API guides, tutorials and videos. It supports many platforms, gateways and devices and selective data sharing. Via the Xively Connected Object Cloud, devices, apps and services can be interconnected with third-party devices. Apart from the APIs named above, the market offers APIs for business services, such as the FedEx Web Services API [28]. FedEx offers shipping services that can be integrated into business systems, retail websites, or order management systems in order to, e.g., create shipping labels, facilitate returns, track shipments and generate reports. Apart from the API management platforms named above, innovative ideas change the API world. App stores, such as for Apple and Android, offer a platform for a growing number of apps. In June 2014, Apple announced that the iPhone Op- erating System (iOS) App Store had reached 1.2 million applications, and had already encountered 75 million downloads. Apple thereby was neck-to-neck with competitor Google, who likewise had an estimated number of 1.2 million apps on offer [85].

In the following section, we introduce Web APIs and different types of mashups.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.1 web services 11

2.1.4 Web APIs and Mashups

Web-APIs consist of a number of HTTP request messages, combined with the deﬁnition of the structure of response messages, typically expressed in JSON or XML [5]. They enable the easy combination of web services into new services, web sites and web applications, so-called mash-ups, and play an important role in Web 2.0. Mashups consist of a combination of data, functionality and/or presentation [84]. We distinguish three different types of mashups:

• Consumer Mashups are aimed at the general public. When offered together with a web-based mashup facility, consumer mashups can be an effective means to customise and personalise data and views. Housingmaps.com (see Fig. 2.1) provides an example for consumer mashups, combining craiglist real estate listings with Google Maps.

Figure 2.1.: Consumer Mashup: Housingmaps.com

• Data Mashups combine similar data from various sources into one representation. Fig. 2.2 shows the Emergency and Disaster Information Service (EDIS) of the National Association of Radio Distress-Signalling and Infocom- munications (RSOE), which derives data such as serious weather conditions, biohazard threats, seismic information from about 200 different sources, and displays them together on one map.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.1 web services 12

Figure 2.2.: Data Mashup: RSOE EDIS

• Enterprise Mashups, also called business mashups, allow for the collaboration between developers and the business. Agile development projects, where developers and customer proxies have to collaborate to deﬁne and implement business requirements, can be supported by enterprise mashups. Enterprise mashups differ from consumer mashups by the degree of integration with business computing environments, access control and security, governance, and as well by the complexity of the tools used for creating mashups. An example of an enterprise mashup is shown in ﬁgure 2.3.

2.1.5 GUI Development for Web Services

In this paragraph, we contemplate GUI development approaches for web services in general, which do not take contextual factors of any kind into account. The article of [111] focuses on an e-government scenario. The work treats the development of e-government services for multiple channels, whereat channels in this case comprehend different platforms such as mobile technologies, Internet

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.1 web services 13

Figure 2.3.: Enterprise Mashup: Staff Allocation Mashup seen on www.jackbe.com and desktop applications. The approach is limited insofar as no user guidance is provided if multiple channels of the same platform, such as desktop applications with differing screen sizes, are created. This however is given in our approach by including rules based on the characteristics of the platform such as screen size and resolution. The ServFace project aims to enable the non-technical user to create applications from annotated web services (see [94], [47], and [29]) .Like [111], the ServFace project aims at a multi-channel approach and provides platform-independent development models. [29] supports the creation of user interfaces as well as the modelling of user interactions in task-driven software development approaches. Like in [47], the concept is based on the introduction of annotations. Annotations are also used in the Dynvoker tool [98]. All named work related to ServFace lack a feature which is provided in our approach: Context in terms of business scenarios is not taken into account. There is no guideline provided to the user on how a UI has to look in certain scenarios. [82] tackles the creation of user interface from independent, loosely coupled modules with a framework based on ontologies. It aims at reducing the complex-

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 14 ity of large UI development projects via modularisation. In [83], an approach for the integration of heterogeneous UI components is created. Modularity and at the same time interoperability of the components are supposed to be preserved. Ontologies serve as a way to exchange events and data between the components. The exchange of data between components is out of the scope of our approach. The FAST project [42] establishes a concept for enterprise mashups. In contrast to traditional solutions, FAST does not allow for the mash up of heterogeneous data sources, but proposes a screen ﬂow design resulting in so-called gadgets. A FAST ontology is introduced to describe the characteristics of complex gadgets (graphical elements, user interaction models, data ﬂows), thereby the approach partly resembles the work presented in [82]. The disadvantage of these approaches is that the ontology has to be created before the solution can be used. Our approach is based on an incremental acquisition of knowledge, starting with an empty knowledge base which is gradually built up.

2.1.6 Web Services – Discussion

The development process for applications based on web services is supported by various APIs and API platforms, Mashup tools and research approaches that support and automate the code creation. Enterprise application platforms assist with the creation of corporate apps. App stores fulﬁll similar tasks in regards to consumer apps. The main focus of the named services lies on the backend functionality, providing functionality in the form of “backend as a service”. In that regard, there have been a lot of improvements in regards to organizing and using back end functionality. However, the same improvements cannot be detected in the UI space. Approaches are required that assist with making UIs and UI components reusable, and provide more UI development support.

2.2 ui development

This section reﬂects on the process of UI development with wide-spread UI Frameworks such as Java Swing, Java NetBeans and IDE MS Visual Studio. It furthermore investigates UI creation with the SAP-owned UI framework “UI Designer”, which is used for the development of the SAP Business ByDesign application. We focus on the usage of UI components in the different frameworks,

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 15 and on the level of support the frameworks provide to UI developers. Before discussing the UI Frameworks, the term “UI component” is introduced.

2.2.1 UI Components

UI components are used by various IDEs as a means to support the UI development process. They are deﬁned as “reusable, design-system speciﬁc chunks of a page” [17]. Depending on the design context, UI components may also be referred to as widgets, blocks, modules, chunks and portlets. A view or page is created by combining several UI components, with each component occupying a certain function within a page grid. Fig. 2.4 shows how UI components can be grouped within a hierarchical structure. We distinguish UI Components of different granularity, starting with

• Basic UI components such as text ﬁelds, labels, sliders. They are on the lowest level of our hierarchy, and are represented by very simple, generic components.

• More complex generic composite UI components such as calendar pickers. They are composed of basic UI components, and show a higher degree of specialisation.

• Composite UI components which are speciﬁc to a certain domain, such as sales order management headers or purchase order lists. These are highly specialised and complex components.

Examples for these UI components are visible in Fig.2.4.

2.2.2 UI Creation with Java Swing and Java NetBeans IDE

The traditional GUI creation with Java Swing happens purely through coding. Java Swing classes like JFrame (a top-level window with a title and a border), JLabel (labels), JButton (buttons) can be used to create a UI from scratch. The UI developer has full control over the user interface and its underlying functionality, however, the UI creation itself is relatively time-consuming and error-prone. The appearance of the UI can only be reviewed on compiling and exerting the code in a repetitive process. Java NetBeans IDE eases the process of UI creation with Java Swing by offering predeﬁned simple UI patterns for the typical Java Swing

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 16

Domain-speciﬁc IBM Custom Properes composite UI components SAP Note Table

Generic

Specialisaon composite UI components Autocomplete Calender Picker

Texield Buon Label Basic UI Slider components

Figure 2.4.: Hierarchy of UI Components classes. Labels (JLabel), buttons (JButton), sliders (JSlider) a.o. can simply be dragged onto the screen from a palette [100]. The UI can be constructed from UI components directly in the Design Area. The future appearance of the UI is visible and adjustable at every stage of the development process and before having compiled the code. The UI developer can also toggle between two views: the design view, where the UI is displayed, and the source view, which contains the source code of the application. The design view in Fig. 2.6 contains a JFrame object, recognisable by its blue frame. When dragging the JFrame object into the design view, the IDE automatically generates the code displayed in Fig. 2.7 between the blue, uneditable sections. The code speciﬁes the patterns typical appearance and behavior such as exiting the application on clicking the close button. The properties of the UI pattern can be changed in the property editor (see Fig. 2.8, here displaying the properties of the JFrame object). Without accessing the source code, properties such as the background colour or the window’s

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 17

: Palette 13 Swing ..., Jlabel r;;;J JButton r;;;J JToggleButton s- JCheci

~ : ButtonGroup CEJ JComboBox ~ JUst o JT extField

0 JPanel eJ JTabbedP ane lllll[ JScroiiBar bll JScroiiPane ~ JPopupMenu

Figure 2.5.: UI Pattern Palette in NetBeans IDE

~ CelsiusConverterGUI.java • I 8IB G ~------~------~ Source [ Design J l [§] ~ ~ I l:.l ~I! Ji I * $

Figure 2.6.: NetBeans IDE Design View

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 18

Figure 2.7.: NetBeans IDE Source View bounds can be intuitively changed by editing the row assigned to a specific property. Fig. 2.9 shows a user interface with a text field, two labels and a button added to the frame. The IDE provides visual cues helping to align the different components to each other. The buttons’ and labels’ names can be changed by double- clicking the components. The IDE offers furthermore support for adding application logic. Events for example can be added to buttons via the button’s context menu. Fig. 2.10 illustrates how the event “actionPerformed” is added to the conversion button by a simple mouse click. The event-handling code is automatically generated and can be modified by the developer. In this example, the code converts degrees Celsius to degrees Fahrenheit. Overall, the Java NetBeans IDE offers support to the UI developer in terms of pre-specified UI patterns, automatically generated code and a user-friendly way of changing properties of patterns without having to access the code. The automatically created UI pattern’s code cannot be changed in the source view, which

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 19

: (Jframe)- P1open1es lil> X ( P'ooertles I E\'ente coae

O Properties ~ defaultCiose-Ope-ration fFXT - i)rJ n 0 <\F . )[~ Iitle Celsius Conver:er c~ S Olhc l Fn.ptrl'=~ 31VI3)1C0"1 To,: lEI c alwaysO'l To r:Supocrted ICJ baCiqrOU'lC D .:24U,:24U,:24U. c bound ~ <\lot Set> c curs or OP.f -'1111" .-, r o;.; r · IL enaljed m c ex.lcmJe\JSl::~le 0 c focueCycle~cot 111 c • title :j ;;v.:..ku;g.5tring) ttlc •

Figure 2.8.: NetBeans IDE Property Editor

lsi) Caleiuc: onverterGUI.jsva • a (ill: ~ SoJrce [ )esgn II ~~ l:!'i ~ ~ P li I <:-:> ~ ..

Figure 2.9.: Simple UI Patterns in NetBeans IDE

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 20

Figure 2.10.: Registering Events in NetBeans IDE restricts the freedom of the UI developer. On a positive note, the IDE demands less programming knowledge and helps avoiding programming errors. The patterns however remain at the level of very simple, basic controls (equivalent to the lowest level of the UI component hierarchy in Fig. 2.4). More sophisticated, composed patterns are not available. Complex binding mechanisms, such as the binding of components to complex data sources, are missing.

2.2.3 UI Creation in Microsoft Visual Studio

Microsoft Visual Studio 2008 provides a set of UI patterns of differing granularity. Fig. 2.11 displays common, quite simple controls such as labels, buttons, text ﬁelds and combo boxes which can be added to a form window via drag and drop. Similar to the Java NetBeans IDE, the property pane allows changing characteristics of the controls, such as the text displayed by the control or its margins. The pattern comes with some predeﬁned code which is automatically entered into the application as soon as the pattern has been dragged onto the form window. In contrast to the NetBeans IDE, the pattern’s code can be changed according to the developer’s intention.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 21

• rmmllmf.mt -roJl:r!rn'lfn'!lW!;t.tmi.J!D File Edit View Project Build Debug Data Tools Test Window Help

• Debug • Any CPU • [!t custom< Too~box 13 All Windows Forms [\"!ointer ~x ~ BackgroundWorker fjji! BindingNavigator '1(} BindingSource @ Button buttonl ~ CheckBox

[[d CheckedListBox Text Field !iJ ColorDialog ~ ComboBox L

bf!J ContextMenuStrip ComboS ox r]il DataGridView ~ DataSet 'iii DateTime Picker ffiJ DirectoryEntry 1f9. DirectorySearcher

Figure 2.11.: Simple Controls in Visual Studio

Visual Studio however offers as well some more sophisticated UI patterns. Fig. 2.12 shows an example, the data grid view. It can be bound to a data source, whose contents will then be displayed in the rows of the table. Apart from the traditional Visual Studio Design View described above, newer Visual Studio releases such as Visual Studio 2013 offer the option to develop UIs in Expression Blend [69], a visual workspace for building or manipulating UIs. Blend provides a more extensive and sophisticated tool palette than Visual Studio, offering functionalities like the creation of animations, adding 3-D effects to controls and editing of HTML applications during runtime (see Fig. 2.14 and Fig. 2.15). Blend, furthermore supports the integration of Adobe artworks. Images can be turned into controls, and common Windows Presentation Foundation (WPF) controls such as buttons, scrollbars, menus can be graphically altered (see Fig. 2.16). Blend provides Windows Phone or Windows Store apps development support, as the app can be built from start to ﬁnish in the Blend Designer. Prototypes can be created in a tool called SketchFlow, and turned into a working app without requiring reimplementation.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 22

/ rormJ.cs (Deslt;J~]''' ....Stsrt Pa.;e l Ob)3ct Brow>e' •X

...... • DataGrid'View Tasks 0:1 uu:::.~:: Cdld 5wr -'=l l :~ ~ F._;niP. OP.P.t no ...... 1:21 E._.:blc CoUrnn n.co•dcrhg

DLLkiiiiJdft:ll. Wlldllt'f I I

Figure 2.12.: Data Grid View in Visual Studio 2008

~.. - .. _.. _ ··--··- .. _.. _.. _ .. _ ... _.. _ ,_ .. _.., [35 Apoa 2010 IT] Ii Mon Tue Wed Thu fri Sal Sun'~ ! ~9 ~ 01 1 2 3 4 ' 5 6 7 s 9 10 11 6 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 !im 29 30 I ' 3 4 5 6 7 8 9 0 Today: 28/04/2010 ···- ·- ···- ···-···-···- ···-o·····- ··-····- ···-···- ··- ··0

Figure 2.13.: Month Calendar Pattern in Visual Studio 2008

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 23

Mo Tu We Th Fr ~ Su :6!7:829J03ll lallout • D so 7 8 ,. 12 ,. l$ 10' :7 :s" 19 !0" 21 22 l3 14 lS 16 l7 28 29 Tabltetn lO II 1 2 3 4 s Tabltero

~ L .-_~ .., 1 Exp:.nd.:r GroupBox

0 L~~~ 0 - lextBiod<

Figure 2.14.: Examples of Controls and Shapes in Expression Blend [51]

Overall, Blend offers features known from other graphic software such as Adobe Creative Suite, and emphasises the design aspect of UI creation, whereas Visual Studio provides a code-first approach to development, using the Design View to check if the code creates the intended UI. Developers can toggle back and forth between Visual Studio and Blend, enjoying Blend´sdesign tools and binding assistance, and Visual Studio´scode completion feature IntelliSense [64]. When it comes to UI patterns, Visual Studio and Expression Blend offer more sophisticated functionalities than the Java NetBeans IDE. The UI patterns used range from simple controls to more complex patterns such as the data grid view or the Month Calendar (see Fig. 2.12, Fig. 2.13). Furthermore, developers have the possibility to define and reuse their own UI patterns, so-called user-defined controls, which allows for patterns of high complexity. The predefined patterns in Visual Studio however belong to a rather simplistic form of UI patterns.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 24

Figure 2.15.: Blend for HTML [93]

Figure 2.16.: Silverlight Custom Button in Expression Blend [116]

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 25

2.2.4 UIs at SAP Business ByDesign

In the following sections, we discuss how UIs are created at SAP Business ByDe- sign, SAP’s solution for Small and Medium Enterprises (SME). We furthermore look at technologies used for adapting SAP Business ByDesign UIs to the varying needs of different businesses.

2.2.4.1 UI Creation with the SAP UI Designer

In the following, we introduce the “UI Designer”, an IDE created by the German software company SAP. The UI Designer is used to develop the SAP solution for SMEs, Business ByDesign, and is based on the (UI) pattern approach by [1] and [102] which is discussed in section 2.4. The UI Designer starts the UI Design process by choosing a generic layout, in the following called “floor plan”, such as a Business ByDesign work centre. The floor plan is then filled with reusable UI building blocks. In the following example, the UI developer chooses the building block “Object Work List” from the “Reusable Components” Menu (see Fig. 19) In a second step (see Fig. 2.18), the developer defines the data model of the application. He clicks on the data model tab located at the bottom of the UI De- signer, and selects a namespace from the drop down list. A Business Object (BO) is chosen by clicking the icon next to the list search for the BO. In this case, the developer searches for Products and selects the “ProductCategoryHierarchyCon- troller”. The UI Designer provides furthermore support for data binding. The developer selects the DataList node and the BO Node to which the data list should be bound. Having selected both values, the button “Bind” is pressed to establish the binding (see Fig. 2.17). Similarly, the DataField and the BO field under the node are selected to bind them. In the example in Fig. 2.19, data of type “LanguageCode” will be displayed in the field languageCode of the data list. A hierarchical extension is added to the data model in the third step (see Fig 2.20). To make the table hierarchical, the DataModel tab is selected. In the context menu of the Data List, first “Add Hierarchical Extension” and then the field ChildrenAssociation is chosen and bound to the corresponding node in the BO. The node should be the resultant node of the recursive association. Similarly, the floor plan can be filled with further UI components. Compared to MS Visual Studio and Net Beans IDE, a more advanced approach is visible.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 26

Figure 2.17.: Patterns in the SAP UI Designer

Figure 2.18.: Deﬁning the Data Model in the UI Designer

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 27

Figure 2.19.: Data Binding

Figure 2.20.: Adding the Hierarchical Extension to the Data Model

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 28

The UI developer can beneﬁt from complex, SAP speciﬁc UI patterns and binding mechanisms. On the down-side, the UI developer is much more restricted in what she is allowed to do. The restrictive nature of the IDE however helps to assure a consistent look and feel of the Business ByDesign user interfaces, as developers are forced to follow certain guidelines.

2.2.4.2 Simplifying User Interfaces at SAP Business ByDesign

Fig. 2.21 shows a sales order management UI in the SAP solution Business By- Design. The solution was designed as standard software for a large variety of companies and users, all having their individual needs and differing in their individual business processes.

Figure 2.21.: Sales Order Management in SAP Business ByDesign- Minimum Layout

Depending on the business process, only a small amount of the displayed ﬁelds might be used. Fig. 2.21 shows a user interface for sales order management in its minimum layout, displaying only one tab and the most important ﬁelds. SAP Business ByDesign offers the possibility to switch during runtime

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 29 from this minimum layout to a maximum layout displaying all possible ﬁelds by pressing the “view all” button. This layout contains all ﬁelds which are available in the SAP Business Suite, the SAP business software for large enterprises (see Fig. 2.22).

Figure 2.22.: Sales Order Management in SAP Business ByDesign - Maximum Layout

The user can furthermore easily hide fields which are not needed via the context menu or display additional ones (see Fig. 2.23). The pool of fields the user can choose from corresponds to the fields of the maximum layout. Business By- Design therefore offers a quite flexible UI.

Figure 2.23.: Hiding Fields or displaying additional ones in SAP Business ByDesign

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 30

2.2.5 UI Development with Bootstrap

Bootstrap [108] is an HTML, Cascading Style Sheets (CSS) and JavaScript (JS) framework for developing responsive, mobile first projects on the web. Once developed by Mark Otto and Jacob Thornton at Twitter, Bootstrap was released as an open source product in August 2011 on GitHub. Otto and Thornton intended to develop a framework which encourages consistency across internal tools, given that the use of various libraries for interface development led to in- consistencies and high maintenance effort. In June 2014, Bootstrap became the most successful GitHub project with over 73000 stars and more than 27000 forks [122]. Since Bootstrap 3, Bootstrap follows a mobile-first approach, i.e., the framework consists of mobile-first styles throughout the entire library. The framework supports responsive web design, that is its CSS adjust to desktops, tablets and mobile phones, and automatically adapts pages to various screen sizes. Bootstrap supports the development of Websites with themes, templates for the website design. Bootstrap themes are offered online via various parties such as Wrap Bootstrap [58] (see examples of their commercially distributed themes in Fig. 2.24) and Bootswatch [81] (see some examples of their free themes in Fig. 2.25). Part of the themes are UI components such as the coloured labels in Fig. 2.26. Furthermore, Bootstrap provides several JavaScript components in the form of JQuery Plugins [122]. These deliver additional UI Components such as boxes, tooltips and carousels (see the “carousel” component in Fig. 2.27). In terms of reusable UI components, Bootstrap offers icons, dropdowns, navbars, breadcrumbs and alerts [114]. Customizable Bootstrap Components, LESS vari- ables and and jQuery plugins can be used to create customized themes and components. The components are added via simple script code which can be copied from the Bootstrap web site. A drag and drop functionality for adding components however is not provided. Bootstrap eases the life of the developers by supporting the adaptation of UIs to various platforms. The available Bootstrap themes are partially adapted to certain business scenarios (there are, e.g., themes for graphic design portfolios from Wrapbootstrap), however, the UI components offered remain on a general, non domain-specific level.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 31

:IEEH. --- - ·- - - -·

$ 11 ~ 1053

$ tO '5'310 S10 '!1.882

Figure 2.24.: Commercial Bootstrap Themes available on WrapBootstrap

...... ,...... ,...

Flatly Journal

Darkly Flatly Joumal .'"' " ...... ' <1 -' ~ U/I,>o

Figure 2.25.: Free Bootstrap Themes available on BootsWatch

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 32

Labels

Default Primary Success Warning Danger

«=IC3 fZEI!I IIaCQIB:::I Cllllllill:l3 lilCII Cll c:IIZJCE:I

Figure 2.26.: Labels belonging to a Bootstrap Theme

2.2.6 UI Development with DukeScript

carousel

Figure 2.27.: Carousel UI Component in Bootstrap

DukeScript is a set of Application Programming Interfaces (APIs) for creating cross-platform mobile and desktop and web applications [15]. It can be used to create applications in plain Java while rendering them internally with HTML5 and JavaScript technologies [39]. The business logic, written in Java and running in a Java Virtual Machine (JVM), can be clearly separated from the UI, which uses an HTML-renderer to be displayed.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 33

Applications in Dukescript can be developed in the following way [106]: When creating a new project, the type of project has to be chosen ﬁrst. In the Netbeans project template tree, multiple prepared project versions are availble. In the example below (Fig. 2.28)., the most generic one, HTML 5 with Java Application Logic, is chosen.

Figure 2.28.: Setting up a Project in DukeScript

Having deﬁned a description for the project, the location where the project is created needs to be speciﬁed. DukeScript allows to deploy a project to JavaFx, Android, iOS, various browsers (Chrome, Internet Explorer, Safari, Firefox) and NetBeans (see Fig. 2.29). Once generated, the program can be debugged by setting breakpoints, watch- points, stepping into or over lines of code, and inspecting the stack (see right bottom side in Fig. 2.30). The UI can be displayed by using an HTML Document Object Model (DOM) Browser (left bottom corner in Fig. 2.30), that allows for a preview of the resulting HTML page. From here, navigation to a CSS styles inspector and the source code is possible.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 34

Steps

: IIQQt<"' FIQio:u• • Deploy as NetBeans Module' 2. rt•o r.nw, whPn )"0111 t~pplirt~tinn run'-. nn ;;lnKlo,t t~ny '-.igniti~;;nl 3. . OC\.1110r * rfPvir-F> on thP (11.-;tnPt, •\lht rtoo't ji!lll r=tr-k;;~p it;.<;. NF>tRP'tM 4 1 :-'1'1,-.l:lt~ ' • '"""IX module and deploy it to l.Sr·l -of Net8e3ns users via plug in •. ::.·~ ·o1d portal? OS '· 310:"1\<"'1:$ Mo:fif)" SHCME/ ·•llsat-:ings.:-cml to contain :Sefinition .:>f •• lh:lBt:olll~ :••o . 5umrr.:'Y net.beans,Jnsta•'•'&!Ofl pr:>pert:,•:

OFno; hlP NRfw ... r runfiiP?

1 1<- .e.d' tn

Figure 2.29.: Deploying the Project for NetBeans

Having ﬁnalised the code, the developer can package the application to one of the target platforms via the Custom submenu (see Fig. 2.31). Like Bootstrap, DukeScript eases the deployment of applications to different platforms, and thereby the adaptation of UIs to different devices. In terms of UI reuse, the UI components offered remain on a basic, non-domain speciﬁc level.

2.2.7 UI Development – Discussion

As shown in the previous sections, UI development faces challenges in terms of the adaptation of UIs to various types of context such as business scenarios and devices. Modern IDEs provide support to the UI developer, often by offering UI components, which range from very basic components to much more complex components. Reuse of UI components however is not a ﬁrst class concept, it serves rather as an addition to the functionality of the IDE. UI development needs to be supported by IDEs that offer more and also more sophisticated UI

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.2 ui development 35

Figure 2.30.: “Hello World” Program for HTML and Java NetBeans components and thereby foster UI reuse. The presented IDEs furthermore provide no guidance to the user. In order to create a user interface, the UI developer has to have knowlegde about the elements that belong to the UI. Some of the IDEs shown allow the developer to create the UI by dragging and dropping UI components onto a canvas. However, there is no mechanism which creates the UI for the developer or suggests it to her according to the business scenario chosen. There is a need for IDEs to provide more guidance to the UI developer and offer more automisation of the UI development process.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.3 codereuseandcodesearch 36

Figure 2.31.: Choosing the Target Platform

2.3 code reuse and code search

In the following section, we review different approaches in research related to code reuse and code search. This involves the investigation of code search engines, research approaches for code reuse and Question & Answer sites.

2.3.1 Code Reuse

Code Reuse is the use of existing software or software knowledge to produce new software [30]. In order to discover and retrieve open source code for reuse, a number of code search engines are available, including Google Code Search [35], Krugle [36], Open HUB [22] and byteMyCode [10]. Apart from these search engines, the following work in research has investigated the topic of code reuse: [67] presents the source code search engine Ex- emplar, which is making use of textual descriptions of applications, API-calls,

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.3 codereuseandcodesearch 37 and the data flow among API calls to detect relevant software in large application archives. The search results based on natural-language queries are ranked according to these three criteria. [66] offer a unified approach for searching for code, selecting components and synthesising them into software projects. Their work is based on the assumption that developers have an interest in how software is interconnected, and therefore analyse the code for API-calls. APIs are seen as strong indicators of the functionality the code provides. In difference to its predecessor code search engine Exem- plar [67], this approach investigates the code itself, and not its documentation. The search engine Portfolio locates the code based on a search query, analyzes how it is used and displays this information to the developer. Like our work, [66] and [67] aim at improving the productivity of programming by identifying and reusing existing code. However, the focus of both works lies purely on the functionality of the code, not on its representation on a user interface. Our approach takes into account that depending on the context, the same functionality might have to be presented by highly differing UIs. Code search based on semantics is discussed in [87]. In difference to [67] and [66], the search for code is not based on keywords only. In addition, [87] takes method signatures or classes, test cases, contracts and security constraints into account. The derived source code is changed by multiple transformations in order to meet the requirements of the user. The strength of this work is that the user can specify in a very detailed way what she is searching for. At the same time however, the specification requires development knowledge and a clear understanding of the future solution, otherwise signatures and class names cannot be used as search criteria. The search in our scenario is based on dimensions of context (business scenarios and device characteristics), that do not presuppose development knowledge. [16] provides an approach for semi-automated reuse of small-scale source code, such as the reuse of individual methods and classes. Making use of semantical and syntactical information, the approach assists the developer with the tedious task of integrating small-scale source code into the target system, allowing the developer to focus on the most difficult tasks during the integration. The approach identifies correspondences between target code and reuse code via generalisation, evaluates the quality of the candidates for code reuse, and transforms the piece of code of the highest quality in a way that it can be integrated into the target code. Our work does not tackle the issue of integration, as we make use of UI elements that can operate independently from each other. In difference to [16], we concentrate on the user interface, not on its functionality.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.3 codereuseandcodesearch 38

Like in [87], the work of [57] bases the search for reusable code on test cases. However, [57] is exclusively relying on test cases, other search criteria like keywords are not taken into account. Test cases are used to identify code relevant for reuse and, at the same time, to test their functionality and suitability for the code. The code can automatically be prepared for the integration by slicing the code, and can be weaved into the code for testing and unweaved again. The work however, like all other work analyzed in this section, does not consider the reuse of UI. Table 2.1 lists different approaches for code reuse, the criteria used for code search and speciﬁc characteristics of the approaches.

Approach Type Search based Specific Characteris- on tics Google Code search engine keywords, [35] project label (e.g., Java, Rails, AJAX) Krugle [36] search engine keywords results can be filtered by programming languages, projects and authors Open HUB search engine keywords results can be filtered [22] by definitions (class, constructor, etc.), programming languages, projects, file extensions byteMyCode search engine keywords, tags tag cloud identifies [10] topics with most code snippets

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.3 codereuseandcodesearch 39

Approach Type Search based Speciﬁc Characteris- on tics Exemplar search engine searches doc- ranking of search re- [67] umentation sults based on application descriptions, API-calls, data ﬂow among API calls Portfolio [66] search engine searches code based on keywords Semantics- search engine keywords, source code is trans- based Code method signa- formed according to Search[87] tures, classes, user requirements test cases, contracts, security constraints Small-scale tool assists NA assist with integra- Source Code with semi- tion of reuse code Reuse [16] automated based on semantical reuse of small- and syntactical infor- scale source mation code Code Genie search engine test cases preparation for code [57] integration by slicing

Table 2.1.: Comparison of Code Reuse Approaches

2.3.2 Question & Answer Sites

Code reuse is also fostered by Question & Answer (Q&A) Sites such as

• Stack Overﬂow [27]

• Experts Exchange [24]

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.3 codereuseandcodesearch 40

• Stack Exchange [26]

Stack Overflow is a privately held website which was created by Jeff Atwood and Joel Spolsky in 2008 [127]. The site features questions and answers on a large variety of topics in computer programming [18]. As a variation to traditional Q&A sites and forums, users can earn reputation points and badges, and questions and answers can be voted up and down [78]. Accordingly, a sort of gamification of the web site is visible [127]. With over 2.7 Mio registered users and more than 7.1 Mio questions in April 2014 [77, 79], the site proves to be highly popular. Experts Exchange, founded in 1996, is a member-based Question and Answer site for users in IT-related professions. Points are awarded for answering questions or writing articles that are categorised as useful by the community [123]. While Stack Overflow’s main field of attention is programming, Experts Ex- change offers a wider field of technology-related topics including Operating Systems, Hardware, and Security. In difference to Stack Overflow, which allows for collaborative editing of answers, answers in Experts Exchange cannot be changed. The web sites use slightly different mechanisms for identifying the best answer. On Experts Exchange, the user who asked the question is asked to choose the most complete solution. On Stack Overflow, the best answer is identified by community votes [68].

In September 2009, Jeff Atwood and Joel Spolsky founded Stack Exchange, a network of Question and Answer sites. The sites were modelled on Stack Over- flow, and hold questions and answers on diverse topics in fields like Technology, Culture / Recreation, Life / Arts, Science, Business and Professional [126]. In the technology space, we can find sites on e.g., Sharepoint, Salesforce, Game De- velopment, Tex / Latex, Code Review and User Experience [25]. All sites mentioned enable developers to find and reuse code snippets or explore guidelines on how to implement a certain functionality. Stack Exchange’s User Experience site also allows searching for guidelines on how to design UIs. However, none of the sites investigated offer UI components or complete UIs for reuse.

2.3.3 Code Reuse and Code Search – Discussion

As the analysis in the previous paragraphs has shown, there are various approaches such as code search engines, work in research and Question and An-

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 41 swer web sites that assist with ﬁnding and reusing code. All approaches investigated focus on the functionality of the code, not on the user interface itself. They allow searches for e.g., API-calls, textual descriptions of applications, method names and signatures. However, they do not enable the search for UI functionality and terminology, or the search for widgets, grids, tables, buttons, etc. Accordingly, the reuse of UIs and UI components is not supported. Given the UI-intensive application development of today, there is a need for more UI reuse.

2.4 ui patterns

This section addresses the nature and use of user interface patterns. After giv- ing a general deﬁnition of UI Patterns, describing their common elements and showing their advantages, the usage of UI patterns during the process of user interface creation is illustrated.

2.4.1 Deﬁning UI Patterns

Patterns offer solutions for common design problems related to a certain context [131]. They describe best practices within a given design domain, which might be user interfaces, Web sites or object-oriented programs, or even buildings [103]. Patterns not only contain a detailed description of the problem, but also its solution, together with a manual on how to apply it [12]. Interlinking patterns of a certain domain will ﬁnd its expression in a pattern language. Originally, the concept of patterns was developed throughout the 1960s and 70s in order to ease architectural decisions. Based on contemplations about the har- mony and attractiveness of medieval cities, the architect Christopher Alexander and his colleagues identiﬁed architectural patterns, displayed as sets of design rules [102], which helped to improve the quality of life ([1],[8]). The transfer of this approach into the world of software came with several user interface patterns presented by Kent Beck and Ward Cunningham in 1987 at the Object-Oriented Programming, Systems, Languages & Applications (OOP- SLA) conference. The “Gang of Four”, as Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides are often referred to, published their award-winning book “Design Patterns” in 1994 (with a copy-right of 1995,[32]), thereby paving the way for a wide-spread acceptance of the software patterns approach. After

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 42 exploring the strengths and weaknesses of object-oriented programming, the authors described twenty-three classic software design patterns; the names of these are well-known and widely used within the software development community [12]. In our work, we focus on user interface patterns, common solutions for typical design problems in the user interface domain. They became visible with Jennifer Tidwell’s paper “Common Ground” [102]. The earliest adoption of the topic can however be found in “User Centered System Design” of Norman and Draper [75]. UI related patterns are today presented in UI pattern libraries and collections, such as [109], [105] and [55], or in UI pattern languages like in [7].

2.4.2 Elements of Interaction Design Patterns

Although UI patterns vary signiﬁcantly in the way they are described in UI pattern libraries, common elements can be identiﬁed. [99] lists up the following elements in his research:

• Pattern Name. Finding an adequate and descriptive pattern name plays an important role in the process of UI pattern creation. It enables a clear communication about design issues.

• Pattern Description. Describing a pattern in a clear and understandable way is essential for a good pattern design. Screen shots and graphics can help to make the pattern characteristics more tangible.

• Context of Use. The context of use section helps designers to decide if a pattern would be appropriate for a certain solution. This section might have to be updated frequently, as new user requirements might be discovered and new applications be developed during the life-cycle of a pattern.

• Where Used. This section describes in which production systems a pattern is actually used. Like the “Context of Use”, this section requires frequent updating.

• How it works. The mechanics of a UI pattern are speciﬁed in the “how it works” description. The descriptions can be supported by videos or screen shots.

• Specifications. Specifications inform the designer about everything he has to add to the design, such as line widths, colours, text sizes. The specifi-

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 43

cation can be illustrated with a screen shot of the pattern and describing call-outs.

• Co-requisites. Co-requisites are patterns which have to be implemented along with a chosen UI pattern. For a login component pattern, this could be patterns for changing passwords or recovering lost passwords.

• Related Patterns. Patterns which are similar to the UI pattern in question, that is, patterns which aim at the same goals, but are used in a different context, are named in this section.

• Competitive Approaches. Patterns solving similar problems, but having been invented by other parties, are presented and discussed in the paragraph “Competitive Approaches”.

• History. The “History” logs all important data related to the evolution of a pattern. Who was the creator, which changes has it undergone and for what reasons? This section provides the designer with rationales for the features of a pattern.

• Source Code. For architectures with a sufﬁciently modular structure, the source code can be given along with the pattern description. This can sim- plify the implementation of a pattern signiﬁcantly.

• Usability Results and User Feedback. Feedback provided by users about the pattern in usability tests, along with feedback from institutions like customer support, sales or other sources are collected in this section.

• Discussion. The essence of discussions tackling the design and usage of patterns is attached to the pattern description.

2.4.3 Reasons for using Patterns

What are the reasons for using interaction design patterns? [102] identiﬁes the following beneﬁts:

• Patterns serve as a means of communication, they support a common understanding of design problems and thereby ease discussions amongst designers, also coming from different disciplines, and between designers and software users.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 44

• As patterns capture the collective wisdom of designers, they provide guidance and best-practices for less experienced software designers.

• They increase the efﬁciency of UI design and development by offering solutions for common UI problems. Ideally, the patterns provide coding for design invariants and can be individually adapted to speciﬁc contexts. Ex- isting patterns might as well be reused for new user interface concepts such as 3D interfaces and virtual reality, without the necessity of reinventing the wheel.

• Patterns provide a level of abstraction which helps to identify which qual- ities make a user interface successful, independent of fashions or economic circumstances.

• The exchange of knowledge with other disciplines is simpliﬁed. Patterns might be likewise applicable in ﬁelds like book design, consumer electron- ics or the design of control panels (e.g., in cars and airplanes) and in user interface design. Lessons could be learned from other areas and be applied to UIs.

2.4.4 UI Pattern Examples

The following two examples of UI patterns shall illustrate the nature of UI patterns. tag cloud. The UI pattern “tag cloud” (Fig. 2.32, described in [109]) addresses the issue that users would like to easily discover which tags on a website are most often used and are the most popular. The pattern solves this problem by listing out the most common tags in an alphabetical order and by changing the font size and the weight according to the popularity of the tag. The pattern can be used on news sites, photo galleries and stores which allow tagging. Accord- ing to [109], the relative popularity of a tag can be easily understood through the visual display. Another advantage of the pattern is that it reﬂects user activities rather than the intentions of a site designer. calendar picker. The “calendar picker” pattern in Fig. 2.33 [105] can be applied whenever a date or date range shall be entered in order to submit, sort or ﬁlter data. The pattern consists of a box with a one-month calendar overlaying the application whenever activated. The user can select a calendar date from the

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 45

All time most popular lags

07 afrk.a amst~fd

Figure 2.32.: Tag Cloud (www.ﬂickr.com), as shown on [109] box. Alternatively, a three-month calendar may be shown. It is recommended not to use the calendar picker when the date could be entered quicker or more easily via a text ﬁeld, for example when birthdays have to be selected (a birthday 30 or 70 years back would require extensive clicking through the calendar boxes). Furthermore, it shouldn’t be offered as the only possible way of entering the date, as the user might be more familiar with alternative ways.

0 search·-- photos Photos • Venice

"""* .. flollftCIQ!tWMWII'i'!N.,.. fill"'~ lfl!lltt~""""''ss:::;;-=.,,.,=,-=="'"' .-..&JIOfrtt .-..1:~ Qn)(llY(~ DaUill.~n &11~ ~1 4<1ll2!:09 I Q, April20t9 Nay 20)9 June ~09 ~.k:lrl rlii'IIMU.. fll s.! SV'I•l~WMTI'IIl Fn SM. &.r!Uotlu•WIICTN. '*' ~ ' , l .. . , ~61liiOU 34SIIlt 7Stf011ftt:t

IZ '' t 4 1~ It 11 1t Ill 11 ·~ U 1' n 1$ 14 1:) U 11 l O II ~ 1tl02122 ~~ 24 U 1111U 2021~2:l Z1222l1A2!2527 0 2tt7 2:1 1t)O ..l42Sltl1D2t3C ll2t~

Figure 2.33.: Calendar Picker Pattern [105]

2.4.5 Parties contributing to UI Patterns

In essence, different parties can be involved in the creation of UI patterns. In [12], design patterns for ubiquitous computing are initially developed by researchers,

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 46 and later on evaluated by researchers and designers. User studies were integrated into the creation of user interface design patterns of [54]. At the German software company SAP, a department called Solution Management evaluates the needs and requirements of the software users. The User Experience Group and UI designers works on the creation of guidelines and UI patterns.

2.4.6 The Pattern Approach at SAP

SAP deﬁnes user interface patterns analogous to patterns in architecture: “A user interface pattern is an archetypical or generic design solution to an interaction problem in the context of a user task” [115]. In the following sections, we look at the type of patterns used at SAP, and at the relationship of UI patterns and tasks in the SAP approach.

2.4.6.1 Types of Patterns

UI Patterns at SAP are organised in a hierarchy of patterns with different granularity (see Fig. 2.34), ranging from simple controls and to relatively sophisticated, composed patterns. The meaning and usage of the different UI pattern types will be illustrated in the following section.

Figure 2.34.: Hierarchy of UI Patterns at SAP Business ByDesign [118]

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 47 simple controls. On the lowest level of the pyramid, very simple UI controls like labels, text ﬁelds, dropdown lists and buttons reside as visible in Fig. 2.35. The yellow box displayed in the ﬁgure contains a number of these simple controls labeled by their name.

Figure 2.35.: Controls constituting Building Block Elements [118] building block elements. They are combined to the next level of UI patterns, the UI building block elements. In this example, the simple controls con- stitute the building block element “Search Pane” (see Fig. 2.36). The graphic furthermore displays the building block elements “Toolbar with Actions”, “List Pane” and a pattern displaying “Detailed Information for an Object”, which are all composed of simple controls. the building block. Combining the named building block elements leads to a new pattern, the building block, such as the “Object Worklist” in Fig. 2.37. The nature of the building block elements and building blocks is SAP-speciﬁc,

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 48

Figure 2.36.: Building Block Elements [118] that is these UI patterns had been created specifically for SAP Business ByDesign Applications. the floor plan. On the highest level of the UI pattern pyramid is the floor plan. The floor plan is not composed of building block elements or building blocks, but rather provides an overall structure where these patterns can be integrated into, like a sort of scaffolding. The floor plan which was chosen by the UI designer in Fig. 2.37 is of type “work centre”. The pattern itself is displayed in Fig. 2.39, the floor plan filled with the building blocks “Portal Header”, “Con- textual Navigation” and “Object Work List” results in the user interface shown in Fig. 2.37. Floor plans have been created for the specific requirements of SAP Business By Design. The following section explains the floor plan UI Pattern in more detail. The user interface floor plan can be seen analogous to the ground plan of a building: There are different types of ground plans, such as ground plans for

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 49

Figure 2.37.: Workcentre Floorplan with Building Blocks [118]

family houses, office buildings, student apartments, etc. Their basic structure is defined by a corridor with doors to different rooms. Likewise, different types of typical layouts - the “floor plans” - can be identified for SAP Business ByDesign. The floor plan represents the overall layout of the UI. Different types of SAP floor plan patterns are available. Fig. 2.39 and Fig. 2.40 show examples of the floor plans “Work Centre” and “Guided Activity” at SAP Business ByDesign. The Floor plan “Work Centre” (displayed in Fig. 2.38 and Fig. 2.39 ) determines a structure with a search functionality in the header and “Favorites”, “Personalise” and “Help” menus. This basic structure can be filled with more fine-grained UI Patterns, the building blocks, building block elements and simple controls presented in section 2.4.6. They fill the room in-between, on the ground plan, they would correspond to the kitchen, the living room, the bedroom. In the SAP approach, object work lists or the contextual navigation panes (see 2.38) are examples of this kind

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 50

Figure 2.38.: Floor Plans in SAP UI Design [118]

Figure 2.39.: Work Centre Pattern in SAP Business ByDesign (Extract)

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 51

Figure 2.40.: Guided Activity Pattern in SAP Business ByDesign (Extract) of patterns. The reason behind this structure is the possibility to reuse building blocks and building block elements in different ﬂoor plans [91].

2.4.6.2 The relationship between SAP Patterns and Tasks

In order to more clearly understand further characteristics of the SAP approach, we will first introduce the term “task” in this section. Fig. 2.41 describes the relationship between tasks and composite tasks and their corresponding UI patterns in the SAP approach. The lowest level shows atomic tasks like pressing a button or entering text. These very elementary tasks correspond to simple UI controls like buttons or text fields. Tasks like searching for data are represented by pattern elements, which might be compound controls comprehending a filter row, a data row and a paging row. Tasks can be combined to composite tasks such as data inspection. The UI pattern for inspecting data could consist of a search area, several functions, and a list displaying the search results. This level of composite tasks is what SAP’s UI pattern approach focuses on. SAP furthermore clearly separates this kind of UI patterns from the overall layout, the

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 52

“floor plan”. Activities like “Inspection” correspond to Application Floorplans. There are, e.g., separate floorplans for accounting and personnel administration. On the highest level of the task hierarchy, the workflow is represented by portal floorplans or navigation, a sequence of UIs corresponding to the different business process steps to be performed for fulfilling a task like “preparing a customer visit”.

Figure 2.41.: The UI Pattern Concept at SAP [4]

The SAP pattern approach is characterized by two special features. Firstly, in order to increase the ﬂexibility of the patterns, the description of a task a user has to perform is separated from the representation on the user interface (Arend 2004). The advantage of this separation is that the user interface components can be structured according to characteristics of the device, such as a large Personal Computer (PC) monitor vs. a small Personal Digital Assistant (PDA) screen, or according to a prevailing design paradigm. Furthermore, the approach targets user interface solutions for generally applicable tasks – so-called generic tasks – only. The goal of the approach is to identify such components which can be used for a large number of applications such as the inspection of objects, which can be likewise sales orders, invoices, customers or opportunities.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.4 ui patterns 53

2.4.7 UI Patterns and their Usage in UI development

The relevance of UI patterns and reuse for UI development has been recognised by major software companies such as SAP and IBM. Online communities like [131] and [105] serve as platforms for exchanging UI elements, patterns and widgets. Some of the approaches such as [72] offer anti-patterns. These are patterns which show bad UI design that should be avoided. In the following, table 2.2 summarises how patterns are used at major software companies (IBM, SAP) and in community approaches. Many of the communities had been founded by representatives of User Experience (UX) and interaction design industry, such as Peter Morville, founder of a UX consulting ﬁrm, Diana Frurip, interactive designer, or Will Simmons, freelance digital and UX designer. As shown in the overview (Tab. 2.2) , the patterns can be classiﬁed by the platforms they had been designed for (e.g., web, desktop, mobile) and the pattern type, such as design pattern, e-commerce pattern, interaction design pattern.

Web Site Pattern Type Platforms Commu- nity

IBM design web no SAP BusinessByDesign design web no Yahoo [74] design web yes UI Patterns [105] web web yes Designing Social Inter- social inter- web yes faces [11] faces Interface Design Patterns interface de- smartphone, yes [76] sign MDA/PDA, Laptop/PC, Settop-Box Android Patterns [19] Android Android yes Mobile Patterns [95] mobile iPhone, An- no droid Inspired UI [80] mobile iPhone, An- no droid Lovely UI [31] mobile iPhone, iPad, yes Android

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.5 ui and context 54

Web Site Pattern Type Platforms Commu- nity

Mobile Design Pattern mobile iOS, Android no Gallery [71] and more Pttrns [6] mobile iPhone, iPad, no iOS Pattern Library for Interac- interaction web yes tion Design [110] design Quince [46] UI all no

Table 2.2.: UI Pattern Approaches and Communities

2.4.8 UI Patterns – Discussion

The reflection on UI Pattern has shown that the need for global solutions for common UI design problems was recognised several decades ago. Major software companies like IBM and SAP make use of UI patterns in their approaches, and online communities offer and exchange UI patterns. Accordingly, the concept of UI reuse has already been introduced into software development. However, in difference to the previously discussed UI components, UI patterns are merely guidelines that offer reusable design solutions for specific problems [17]. They don’t offer UI knowledge in a form that benefits the user without UI development knowledge, but require experienced UI developers that can interpret the pattern and implement it. In order to increase the productivity of UI development and make UI development accessible to non-expert users, apart from UI patterns UI components, reusable, design-specific chunks of a UI, are needed.

2.5 ui and context

The following section reﬂects on the challenges faced by UI developers having to adapt UIs to various forms of context. First we present a number of real-life examples for changing context and its inﬂuence on UIs. Then we discuss work in research which tries to adapt user interfaces to various dimensions of context

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.5 ui and context 55 such as different development platforms, user characteristics or environmental factors.

2.5.1 Examples of Context requiring UI Adaptation

As stated in previous sections, the UI development process can be very time consuming and tedious, not only during the initial creation of a UI, but also during the adaptation of UIs to context such as varying business scenarios and platforms.

Possible reasons for the necessity to adapt UIs to changing context are:

• Deviation from Standard Solutions. The adaption of the UI may be necessary because the business process of a specific company differs from the standard process offered by the software solution. Business processes are often historically grown and reflect the specific culture within the company. Unique bonus systems for sales representatives for example or specific functionalities handed down from legacy systems may lead to changes of the underlying logic and as well of the UI.

• Differing User Preferences. UIs may need to be changed according to differing user preferences. The sequence in which different ﬁelds, forms or tabs appear on the screen may be suitable for one company, but may not reﬂect the needs of another one.

• Adaptation to Corporate Identities. The adaptation of UIs may be necessary in order to meet requirements of different corporate identities and corporate designs. Corporate designs may differ between corporations or even within the same company. The Australian bank SunCorp has about 40 subsidiaries (like AAMI, LJHooker), which share the same software systems. To the public, they appear like independent companies, presenting the same underlying software with different layouts.

• Globalisation. Globalisation implies adaptation of the UI to the legal requirements and business process variants in different countries. The tax system of the United States differs to a high extent from the one used in France. All tax-related functionalities like pricing or invoicing require ad- justments on the UI.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.5 ui and context 56

• Changing Business Contexts. Changing business contexts may imply the need for user interface variations within the same business process. The call center application at an insurance company requires huge amounts of data to be entered during the process of claims management. In a catas- trophic scenario caused by a flood, bush fire or heavy storm, several thousand claims per day may have to be handled. In order to guarantee a quick claims management process to its customers, the insurance company may prefer to enter the most relevant data only, at least for insurants which are classified as reliable and which do not represent a threat to the insurance by fraud. Depending on the estimated reliability of the customer, the application may automatically change from a full layout to a minimum layout with essential fields for quick data entry.

• Adaptation of User Interfaces to varying Platforms Fig. 2.42 shows a standard sales order example in SAP CRM 4.0. The screen contains a large number of different tabs, ﬁelds and functionalities. The application was designed for a large variety of users, their differing business processes and needs.

Figure 2.42.: Standard Sales Order in SAP CRM 4.0, Transaction CRMD_ORDER

On mobile devices, the application has to be boiled down to the most important ﬁelds due to the limitations implied by screen size and hardware.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.5 ui and context 57

The comparison of the screens displayed in Fig. 2.42 and Fig. 2.43 (showing the SAP solution Mobile Sales for Handheld 5.0) illustrates signiﬁcant differences in terms of screen size.

Figure 2.43.: Mobile Sales for Handheld 5.0

The difﬁculty here is to determine which ﬁelds and data will enter the mobile world. The necessary restriction to certain data can never meet the requirements of all customers. Corporations which would like to display data differing from the standard solution often have to deviate completely from the standard solution. Enormous development efforts can be the outcome.

None of the IDEs presented in section 2.2 provides a satisfying answer to the issues stated above. They support the development process by offering UI components ranging from simple to very sophisticated ones, and by automizing and simplyfying typical development tasks. However, the easy adaptation to different corporate identities for example is not given. An IDE diminishing the

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.5 ui and context 58 effort needed for the adaption of screens to different platforms and business scenarios would be of interest.

2.5.2 GUI Development and Context-Awareness

Various attempts to integrate UIs and context-awareness have been made in different research projects. The approaches are differing in terms of which type of context is taken into account and which devices they refer to. Context-awareness for mobile UIs during runtime is realised in [9], and during design time in [61]. In [9], user interfaces of mobile devices are automatically adapted to user context-changes, as well as to different screen resolutions or ori- entations. UIs adapt to specified user contexts by the use of style sheets. [61] generates UI containers for mobile devices and adapts UIs to platform specific characteristics and user tasks making use of heuristics. [56]’s work aims at providing native user interfaces to mobile devices based on the context of the user, whereas the context-awareness in this work is not task- driven like in [133] or [61], but refers to environmental factors and user data. An approach not restricted to mobile devices called “CRUISe” [86] aims at the dynamic composition of user interfaces via web services. The work differs from the other proposals presented insofar as it not making use of annotations like [47] , and is not based on predefined structures or preindexed documents, but is encapsulating generic, reusable web UI components as so-called User Interface Services. All approaches named rely on hard-coded rules development and do not support incremental UI reuse rules capture. There are assumptions made about what users prefer, and all knowledge about the system behaviour has to be captured before the implementation. Our approach provides more flexibility, as user interfaces can be adjusted to varying needs and preferences, and rules can be extended or changed accordingly. Heuristics are introduced in [96] in order to ease UI customisation tasks during the development phase. The work furthermore uses a knowledge base which stores the users’ preferences in order to adjust UIs to users’ needs during runtime. A solution which is even more user-oriented than the work of [9] or [61] results. This approach however does not take platform characteristics into con- sideration. Knowledge-based systems are enhanced with machine learning algorithms in [50] and [40] in order to adapt user interfaces to context. [50] intends to cre-

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.5 ui and context 59 ate self-optimising UIs for mobile phones. Based on contextual factors like time, location, and last action performed predictions for the priority order of applications are derived, and the machine learning proposes the predicted application to the mobile user to enable faster navigation. However, this approach does offer solutions for adapting the application UIs themselves to different contexts, as they remain static. [40] adapts user interfaces to tasks and context. The context considered in this work comprises platform, user (such as user profile, level of knowledge) and environmental (noise level, luminosity) factors. Users’ tasks point to related business components. Task-driven UI adaptation can be realised together with changing the UI according to different user contexts. In contrast to our approach, the association between context and UI patterns is however fixed, there is no way to change relationships between entities during run time. [134]’s objective is to improve the usability of e-Commerce applications. This is achieved by reducing user interfaces to the UI components actually needed to fulfil the users’ tasks. The focus lying on the adaptation to users’ tasks, the approach resembles [61], but refers to e-Commerce desktop applications instead of mobile scenarios. The main weakness of this approach is that process variations, such as adding products several times instead of only once, are not considered. Such variations are covered by our approach by the possibility to increase the number of line items and by adding, replacing or deleting UI components. Another way of adapting UIs to context offer cross-platform GUI toolkits [124]. GUIs implemented with these packages are platform-independent, and can be ported to mulitple platforms without changing its source code. Table 2.3 shows a comparison of current cross-platform toolkits. Some of these approaches provide adaptations to various devices, but remain on a basic to generic composite UI component level. In table 2.3, we have classified the complexity of the UI components provided by these toolkits in accordance with the hierarchy of UI components given in Fig. 2.4. Similar classes are included in modern cross-browser/device GUI frameworks such as the HTML5 Mobile Development Frameworks described in [92]. A comparison of such frameworks can be found in table 2.4. The named frameworks provide development support for HTML5 / Javascript applications on mobile phones, tablets, desktops and Televisions (TVs). Although multiple platforms and devices are supported by these frameworks, guidance in terms of what UI elements correspond to a certain scenario is not provided.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.5 ui and context 60

Framework Standard Platform complexity of UI components CEGUI C/C++ Windows, Mac, basic Linux FLTK C/C++ X11, Windows, Mac basic GTK+ C/C++, Perl, X11, Windows, Di- generic compos- Python rectFB, Quartz on ite Mac OS X IUP C/C++ Windows, X11 generic composite JUCE C/C++ Windows, X11, Mac generic composite Qt C/C++ Windows, Linux, OS- generic compos- X, iOS, Android ite Java/Swing Java Windows, OS/2,X11, generic compos- OpenLook, Mac ite Pharo Smalltalk Windows, X11, Mac generic composite Mono/GTK# C# Windows, Mac, generic compos- Linux ite

Table 2.3.: Comparison of cross-Platform GUI Toolkits

Framework Standard Apps Platform

Mobello HTML5, mobile web, any platform JavaScript smart phone, support- tablet ing HTML5, JavaScript DHTMLX JavaScript mobile web iOS, Android Touch The-M-Project HTML5, tablet, mobile, iOS, Android, JavaScript Kindle Kindle Fire, Blackberry, Surface

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.5 ui and context 61

Framework Standard Apps Platform

Lungo HTML5, mobile, desk- iOS, Android JavaScript, top, TV CSS3 Lavaca HTML, mobile iOS, Android JavaScript, CSS Jo JavaScript mobile, desk- iOS, Black- top, Dashboard berry, Android, widgets WebOS Sproutcore HTML5, web, mobile iOS, Blackberry, JavaScript Android Sencha Touch HTML5 mobile iOS, Black- berry, Android, Kindle Fire

Table 2.4.: Comparison of HTML5 Mobile Development Frameworks

2.5.3 UI and Context – Discussion

Research offers several valuable and interesting approaches in terms of adapting UIs to various dimensions of context such as different devices, environmental factors and user characteristics. The majority of these approaches often remain at the level of changing screen colours or eliminating screen elements, but they don’t consider changing the whole structure and content of the UI. This however is necessary when adapting UIs to various business scenarios, or adapting complex UIs to different devices. During our analysis, we also encountered approaches that are able to fundamentally change the structure and content of a UI depending on the context, e.g., by (re)combining widgets. The weakness of those approaches is that they work according to a ﬁxed set of rules, and make assumptions on what is correct UI for a certain context. An approach with more ﬂexible rules is needed.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.6 background and related work - discussion 62

2.6 background and related work - discussion

Table 2.5 compares the work discussed in this chapter in terms of the following aspects: Do these approaches focus on the reuse of functionality, e.g., by searching for code needed to fulﬁll speciﬁc tasks as in [134]? Do they aim at the reuse of UI components as [41] ? Are UIs / applications adapted to certain context, either during run time or design time, as in [9]? Have the approaches been applied to web services such as in [42]?

Related Work Reuse Reuse Context Focus of Func- of UI Aware- on Web tional- ness Ser- ity vices McMillan Exemplar Code Y N N N Search [67] McMillan Searching Source Y N N N Code [65] Reiss Semantics Based Code Y N N N Search [88] Cottrell Small Scale Code Y N N N Reuse [16] Henninger Component Y N N N Repositories [41] Lemos CodeGenie [57] Y N N N Vassilakis E-government Y Y N Y Services [111] Feldmann Annotated Web Y Y N Y Services [29] Izquierdo Annotation Tool Y Y N Y UI Services [47] Spillner Dynvoker [97] Y Y N Y Paulheim Ontology Modu- Y Y N Y larisation of UI [82] Paulheim UI Component In- Y Y N Y tegration [83]

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.6 background and related work - discussion 63

Related Work Reuse Reuse Context Focus of Func- of UI Aware- on Web tional- ness Ser- ity vices Hoyer FAST [42] Y Y N Y Butter Context-aware UI N Y Y N Mobile [9] Ruiz UI Containers for Mo- N Y Y N bile Devices [61] Lange Dynamic Service Inte- Y Y Y Y gration [56] Zhang Pattern UI Genera- N Y Y N tion [133] Pietschmann CRUISe [86] Y Y Y Y Feng Heuristic UI Design N Y Y N [96] Kamisaka Operation Predic- N Y Y N tion [50] Hariri Business Adaptation N Y Y N [40] Zou ECommerce Apps Busi- Y Y Y N ness Processes [134]

Table 2.5.: Comparison of Related Work

The comparison reveals that the approaches in section 2.3.1 focus purely on the reuse of functionality, but do not take the reuse of UI, context-awareness or web services into account. The reuse of UI and a focus on services is part of the work in section 2.1.5. Section 2.5.2 contains approaches for which context- awareness and UI reuse form an important aspect. Our approach provides the reuse of functionality in cases where the UI components are bound to web services. However, this is not a prerequisite, the focus lies clearly on the reuse of UI. The approach adapts UIs to context during design time, thereby the topic of context-awareness plays an important role. The sample implementation later on discussed in this work is making use of web services, showing that the approach can be applied to SOA environments.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 2.6 background and related work - discussion 64

The modern application development process is supported by various APIs and API platforms, IDEs, Mashup tools, tools for code search and code reuse. Signif- icant improvements have been achieved on the functional side. UI development however hasn’t seen the same major improvements yet. In the web service space, various APIs and API platforms support the development process. However, there is a focus on the functionality of the code. The same level of support could not be detected for the development of user interfaces. Modern IDEs support the application development process to various degrees, from very simple IDEs like Java NetBeans, to more complex IDEs like Visual Studio or the SAP UI Designer. UI Components are offered by several of the investigated IDEs, but often remain on a basic, non-domain speciﬁc level. No guidance is provided to the developer in terms of which UI components belong to a certain UI. The investigation of code reuse approaches showed that there is a focus on the reuse of functionality, but not on the reuse of UI. Given the UI-intensive development of modern applications, the same amount of attention is required on the UI side as on the code side. Through UI patterns, the concept of UI reuse had already been introduced to UI development. In contrast to UI components, which provide reusable chunks of UI code, UI patterns are merely guidelines that require to be interpreted by an experienced UI developer. An approach which enables UI reuse for non-expert users is needed. Various approaches and APIs like Bootstrap assist with adapting UIs to context, such as differing platforms, environmental factors and user characteristics. Most of these approaches however lack the ability to perform complex structural changes to the UI, as it can be necessary when adapting UIs to business scenarios. The approaches that are capable of major UI adapations often operate according ot a ﬁxed set of rules and make assumptions on what components belong to a UI. There is no mechanism for changing rules if needed or the incremental build of a rules knowledge base. A need for an approach that supports UI development in SOA environments, fos- ters the productivity of UI development by reuse and assists with the adaptation of UIs to context is clearly visible.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 3 UIDEVELOPMENTKNOWLEDGE,CONCEPTSAND REPRESENTATION

As discussed in the previous chapter, modern IDEs and UI development approaches in research lack in support and guidance for the UI developer. The goal of this work is to provide more UI development support and guidance by automatically suggesting UIs. UI knowledge such as UIs and rules shall be stored in a Knowledge Base (KB) and made available for reuse. In order to at- tain this, a representation for UI artefacts is required. We show in the following sections how UI artefacts are represented in this work.

3.1 representing ui components

The core idea of our approach is to support UI developers in their daily tasks by suggesting user interface components to them during the development process. These components can be of different levels of granularity, ranging from simple textboxes with labels to entire user interfaces (see also Fig. 2.4 and the UI components shown in the Appendix ChapterA). The decision to use UI components was made when we initially investigated 45 versions of sales order screens in the SAP CRM system. The analysis showed that all screens could be composed of only nine different UI components. These components were variants of the components sales order header, sales order date section and sales order item section. The UI suggestions are based on context selected by the developer. Our approach derives suggestions for user interfaces from UIs created for similar contexts in the past. The suggested user interfaces consist of a number of UI widgets. These widgets might come with a speciﬁc service and mapping already linked to them. Where no service / mapping link is provided, the developer needs to discover a suitable service and link it with the UI components, which can be done by using traditional techniques. The UI developer can modify the UI proposals according to her needs, or reject the proposal and create a new UI from scratch. The changes / new UI will be made available to other UI developers on its completion.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 3.2 representing ui recommendation rules 66

UI components, context and recommendations are stored in a rule-based KB in our approach. Updates to the KB are triggered by any change in context or UI. The KB structure consists of artefact types and relationships linking them, as shown in the entity-relationship diagram, Fig. 3.1. The main artefacts are Rules (for UI recommendations). The rules consist of conditions (when does the rule apply) and conclusions (what should be recommended when the rule applies).

Forms the condion Forms the conclusion Rule 1..n 1..n Recommen- Context dation Is combined with 1 1 Layout Is part of Is combined 1 1 Business with Theme 1

Is part of Scenario Is combined 1 with 1 1 Binding Device 1

contains 1 Component Composition 1..n 1

Figure 3.1.: ER-Model of Rule Components

3.2 representing ui recommendation rules

UI recommendations in our approach are given based on rules. Rules lead to a conclusion based on one or multiple conditions. The nature of both rule conditions and conclusions is discussed below.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 3.2 representing ui recommendation rules 67

3.2.1 Rule Conditions

The left hand side of Fig. 3.1 shows artefacts which make up rule conditions. Devices (different consumption platforms, e.g., Blackberry, iPhone, Windows Desktop, etc.) and Business Scenarios (e.g., Sales Order Management, Quotation Management, Campaign Management for Business Customers, etc.) describe our Context 1. Sections 5.4.1 and 5.4.2 describe in detail how the context in this work was derived. These artefacts form the vocabulary used in the condition of a rule, e.g.: If device=“Apple iPhone” and screen resolution = 800x600(+/-20%) and scenario=“Sales Order Management-Standard Sales Order”, then...

3.2.2 Rule Conclusions

The conclusion of a rule is a UI recommendation for a given context. User interface suggestions in our approach are composed of UI Components (see section 3.1). In order to capture relevant aspects of UI components in a generic way, we represent them through four basic dimensions (see right-hand side of Fig. 3.1). We will illustrate these concepts by artefacts found in development frameworks such as Microsoft Visual Studio or Apple’s Cocoa. These dimensions are:

• Composition specifies which UI components are combined to form the structure of a UI (component). For instance, a screen for the scenario Sales Order Management - Standard Sales Order might be composed of the UI components Sales Order Header V1, Sales Order Date Section V3 and Sales Order Item List V1. There are basic UI components in each framework. The composition structure forms a tree with basic UI components as leaves, and the UI itself being the root. As an example, in the Visual Studio .NET Model View Controller (MVC) framework, we can find concepts similar to our Compo- sition when making use of views. Partial views (ascx.files)- representing UI components - are combined in complete views (aspx.files) to form a UI (see 3.2).

• Layout describes how the components are arranged on the screen, see Fig. 3.3. We distinguish horizontal layout, where components are placed

1 In this work, we have restricted our approach to two dimensions of context. The context could however be easily extended by other dimensions such as corporate identity or development platforms.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 3.2 representing ui recommendation rules 68

UI Element Header

Final UI

UI Element Date Section

UI Element Item Section

Figure 3.2.: Composition of UIs by combining UI elements

next to each other, and vertical layout, where components are positioned above and beneath each other. Vertical and horizontal layouts can be nested within the Composition, thereby allowing to model arbitrary combinations of horizontally and vertically ordered components. Layouts can be used to adapt a UI to different devices – e.g., a collapsible vertical layout may be suitable for mobile devices with small screen sizes, whereas a horizontal layout may be more suitable for wider desktop screens. The layout can be represented in ASP .NET as a view, at which partial views are displayed during runtime in a certain manner, e.g., horizontally next to each other.

• Theme refers to style sheets, which deﬁne the look-and-feel of UIs. Style sheets are a common method to adapt UIs to the look-and-feel of different operating systems (Windows, iOS, etc.) and to different corporate designs (e.g., Coca Cola vs. IBM). This is achieved by varying attributes like font size and style, colour scheme (e.g., red and black for Westpac, yellow and

[ Context-aware UI Component Reuse for Web Service Development Environments ] 3.2 representing ui recommendation rules 69

Ht ..,., Oate~ction ..m s 0 H"do< I S..~· V.JJ J - U.dar OGM AddNewltem o'l No V~j Saesc·::errli> sv~-~" 1 Optn C "'Actua l dates ""'"' Rnl Sj~.t'HS ,CI .\b Open 0 Co not ... iJse'!SialJS Do not print: Sok110

Elllll Sh)ll 0.110 11<1kl

C:rlor.l'!ro:r

Efrl*;-e Jell::r>be Ell f!t-'ell!>:e -·1 RE-l'fendl:e 0 o.t.Seetlon

0 ""''

Horizontal Vertical

Figure 3.3.: Examples for different Layouts

black for Commonwealth, blue and grey hues for Windows), background images, and even scripts. Stylesheets can be overlayed with other technologies like JQuery and JQuery Mobile to give screens an iOS-like appearance. Figure 3.4 illustrates how the same content looks when represented with style sheets for Westpac and Commonwealth Bank. In Visual Studio and other frameworks, themes are represented by CSS ﬁles.

• Binding links a UI to back-end web services, and describes how data should be transformed and exchanged. One UI might be used for different purposes, like accessing different back-end services, even without changing the UI itself. The flexible binding mechanism allows for changing the functionality in the background without changing the UI as such. An example is the creation of user interfaces for creating a sales order vs. UIs for changing a sales order. The UI may remain the same, whereas the web service the data is submitted to may change (for instance, from SalesOr- derERPCreateRequestConfirmation_In_V2 to SalesOrderERPUpdateRequest - Confirmation_In, see Fig. 3.5). The concept of Binding accordingly indicates which web service the UI element is bound to. The ASP .NET framework uses service references to make web service parameters available in the

[ Context-aware UI Component Reuse for Web Service Development Environments ] 3.2 representing ui recommendation rules 70

~-;;;;::;;;-~~ Q <;;,yoo• • Y

( :• llor,1•1tyou E-.:ti,Jiuki"N.'1 IU<.:lll.bnud l. Pm·tncrs ffiY OII~UUI'SUVIngs"? lew the su'llf Wc knu\\how. long t•un. aiii:D CIIID ------*'-·~ · vI Per.,onal ~>olulion.,, Husines., ~>olutioM. Planmng f ort:>morrow ~M nagirlg m'J business

;, "",; - u .., t;~, ,.,..,...... ,. , ~~· ; :'~ ''"• . '!;;;;,\ · ~

J ... ~ tu.. . Personotl pruduc.:ls. Busint>Ss prudu~:ls.

> ~ o ...... p.~...... ' "-""' ~~ Motle O

Online Banking– CW Bank Online Banking - Westpac

Figure 3.4.: Stylesheets for different Banks

framework. By writing a controller with getter and setter methods, UI ﬁelds in the view can be populated with data.

e Hlldlf e HotKif ... s..osoo. ...

--5Y!almSJ•1JS c;~SU1.15 0 0 ,..,_ ...... - thtt" ::Ji.U) ...... - Sodo liDI s..o liDI """ liDI ..... liDI ... """ ... """ """""""' .N """""""' "" Em! Em! -._.-..., -._._,'""""""' """"""""" """""""" 0 D•S.tton 0 D•S.ttM

0 tuu 0 """

Sa/esOrderERPCreateRequestConfirmation Sa/esOrderERPUpdateRequestConfirm ln_V2 ation_ln

Figure 3.5.: Sales Order UI bound to different Web Services

3.2.3 Data Structures for Rules

Fig. 3.6 shows a concrete example of how context is represented on the database level.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 3.2 representing ui recommendation rules 71

SizeX NULL 80 NULL 200

RuleID 82 133 Resolution Y NULL 240 NULL 1024

Value Mobile 139

Resolution X NULL 320 NULL 768 Condition Condition

Brand NULL RIM NULL Apple Attribute Device_Title Scenario

ID 86 93

Device Device Title Mobile BlackBerry 8310 Tablet iPad

ID -

Device -

Source NULL wurfl://blackberry8 310_ver1 NULL wurfl://apple_ipad _ver1

ID - Description NULL NULL NULL

Parent NULL 33 1 36

ID 1 8 36 45

Title Sales Standard From Value Rel. Cont Replenishment Order Business Scenario Scenario Business esentation of UI “Create Standard Sales Order Mobile” on the Database Level -

Parent ID 1 85 85

3 . 6 .: Repr

ID 85 139 140 DeviceID 1 1 Figure Case Case

Scenario ID 85 139

ID 86 121

[ Context-aware UI Component Reuse for Web Service Development Environments ] 3.2 representing ui recommendation rules 72

The context consists of a business scenario, e.g., scenario no. 85 (sales order) and a device, e.g., no.1, a generic mobile device. In the business scenario table, the hierarchical structure of scenarios becomes visible: Scenarios Rel. From Value Cont and Replenishment Order are subscenarios of the scenario with parent-id 85, Sales Order Management. The same structure can be seen in the device table, where e.g., the device mobile tablet is a sub-scenario of mobile. Each combination of business scenario and device is stored in the case table. Each dimension of context can enter as a condition for a rule, e.g., “IF device-title = Mobile, THEN apply rule 82”, or “IF scenario-id = 139 (Sales Order - Rel.From Value Cont), THEN apply rule 133”. Fig. 3.7 displays the representation of a user interface in the database.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 3.2 representing ui recommendation rules 73 Posion 0 1 2 ID 72

Component ID Composition

NULL Composition-Order Composi onID ID 76 72 77 72 78 1 72 2 3 Style Script

Theme Composi onID

Mobile Mobile Title ID 6 ThemeID

5 6 72 NULL NULL NULL NULL NULL NULL NULL NULL NULL BindingID

AconName Controller Name

Component Controller Name NULL NULL ViewName HeaderList SalesOrder DateSecon SalesOrder ItemList SalesOrder Icon Layout_colla psible.png esentation of UI “Create Standard Sales Order Mobile” on the Database Level Binding

NULL NULL NULL 7 LayoutID

3 . 7 .: Repr ViewName CollapsibleLay out Layout Title Create Sales Order SalesOrder Create Figure ID 5 Title Collapsible Vercal Layout Sales Order Header Sales Order Date Secon Complete Sales Order Item List Create Standard SO Mobile Name 2 3 49 1 ID ID 7

[ Context-aware UI Component Reuse for Web Service Development Environments ] 3.3 ui development knowledge, concepts and representation - discussion 74

The component table contains UI components of different granularity. The entire User Interface Create Standard Sales Order Mobile is saved in the component table under id 49 and consists of the components Sales Order Header, Sales Order Date Section Complete and Sales Order Item List. The components are represented each by a View and a Controller. UI number 49 is associated with the four dimensions Layout (Collapsible Vertical Layout), Binding (Create Sales Order), Theme (Mobile) and Composition (72). The Composition describes via the artefact Containment that the UI consists of the three named UI components, which are placed at positions 0,1 and 2, i.e., component Sales Order Header is placed at the top of the screen, component Sales Order Date Section Complete underneath it and the Sales Order Item List component occupies the bottom section.

3.3 ui development knowledge, concepts and representation - discussion

In this work, UIs are suggested to UI developers making use of rules. Context such as Devices and Business Scenarios act as a rule condition, the suggested UI is the rule conclusion. UI Components and Composition (defines which UI components belong to a specific UI), Layout (specifies how UI components are arranged on the screen, e.g., a vertical vs. a horizontal layout), Theme (defines the look and feel via a style sheet), Binding (the binding of a UI component to a web service) form the suggested UI. The rules data structure in our approach reflects the hierarchical nature of business scenarios and devices in the context.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 4 UIKNOWLEDGEACQUISITION

A central part of our approach is the reuse of UI artefacts. This reuse is enabled by a rule-based recommender system, which suggests user interfaces depending on the current context, as speciﬁed by the developer. The suggested UIs stem from previous development efforts. Chapter 3 discussed how UI artefacts and rules are represented in our work. This chapter shows how UI artefacts can be suggested to the UI developer with the help of the recommender system. The high-level architecture of the proposed recommender system is shown in Fig. 4.1. Parts and aspects of its usage are explained in this section, starting with the information used by the recommender system. Followed by how reuse rules are structured, how they are entered into the system, and how they evolve over time.

Hardware Software Users Community Producers UI Developers Domain Experts

Context UI Rules SO Mgmt., UIs Context iPhone 4 Component Platform Descriptions Composition

Business Scenario Layout Descriptions Binding

Theme

Recommender System

Figure 4.1.: Proposed Architecture of the Recommender System

[ Context-aware UI Component Reuse for Web Service Development Environments ] 4.1 context and ui repository in the ui recommender system 76

4.1 context and ui repository in the ui recommender system

The heart of the recommender system is a knowledge base which stores both contextual data, rules and UI-related data. The nature of context and UI data is explained in this section, Section 4.3 explains rules in more detail. The recommender system stores Context data for platforms and business scenarios. The Platform Descriptions database (see Fig. 4.1) contains data about the characteristics of different platforms, such as brand, model, screen sizes, keyboard type, etc. The platform-related characteristics are stored using a hierarchical structure, from more generic characteristics such as “Mobile” vs. “Desktop” to more speciﬁc ones such as “Apple iPhone 6” vs. “Apple iPhone 5s”. An example for such a device hierarchy is illustrated in Fig. 4.2.

Devices

Mobile Desktop

Multitouch PDA Handset Tablet

Blackberry WIN WebOs Symbian Mobile

Brand: RIM BlackBerry 9530 Size: 50x66mm Resolution: 360x480px Pointing method: touchscreen Keyboard type: qwerty

Figure 4.2.: Example of a Device Hierarchy

Likewise, business scenarios are stored in a hierarchical structure in the Busi- ness Scenario Descriptions database. An example for such a business scenario

[ Context-aware UI Component Reuse for Web Service Development Environments ] 4.2 investigation of sap crm user interfaces 77

hierarchy is “Sales Order Management” ⇒ “Quotation” ⇒ “Web Auction Quo- tation”. The UI repository stores different types of UI components, as outlined in Sec- tion 3:

• UI Components of different granularity, including – basic UI components such as text ﬁelds, labels, sliders – more complex generic composite UI components such as calendar pickers – composite UI components which are speciﬁc to a certain domain, such as a sales order management UIs or purchase order lists (examples for these types of UI components are visible in Fig. 2.4)

• Themes in the form of style sheets

• Layout information as views (e.g., a view representing a horizontal layout loops over an array of UI components and places them in a horizontal manner on the screen), and

• Composition, which combines UI Components to form a UI

• Binding, which links a UI component to a web service

Contextual knowledge can stem from different parties such as hardware and software producers, UI developers, domain experts or internet communities 2 . How these data sources are used in rules is explained in Section 4.3; how the UI knowledge is acquired follows in Section 4.4.

4.2 investigation of sap crm user interfaces

In the search for a way to create user interfaces more efﬁciently, existing real- life UIs were investigated. Could we detect common, rather coarse-grained UI components which would enable us to recreate the UIs faster than by developing them from scratch? Part of the analysis was the decomposition of the UIs into such common UI components. For the investigation, 115 screens from an SAP CRM 7.0 System were used that belong to the traditional SAP GUI. First, 61 UIs of the Sales Order Management

2 in our approach, we are making use of device characteristics stored in the WURFL [59] database, see Section 5.2.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 4.2 investigation of sap crm user interfaces 78

Scenario were compared in order to detect common UI components. As a result, each Sales Order UI was decomposed into 3 UI elements. In order to recreate 61 UIs, we needed 9 different sales order headers, 4 different date sections (some of the UIs required no date section at all), and only 2 different item sections. As an example, Fig. 4.3 shows Sales Order Management screen Quotation, which was dissected into 3 UI Elements Sales Header 4 (see Fig. 4.4), Sales Date Section 2 (Fig. 4.5) and Sales Item List 1 (Fig. 4.6).

Figure 4.3.: Sales Order UI Quotation

Figure 4.4.: UI Component Sales Header 4

Figure 4.5.: UI Component Sales Date Section 2

[ Context-aware UI Component Reuse for Web Service Development Environments ] 4.2 investigation of sap crm user interfaces 79

Figure 4.6.: UI Component Sales Item List 1

UI Component Sales Header 4 (Fig. 4.4) could furthermore be found on nu- merous of the other UI screens1 investigated, e.g.:

• Debit Memo Request

• Quotation

• Replenishment Order

• Standard Order

• Sales: Leased Object

The Replenishment Order screen shares the same header element and item list element with the Quotation, however, as can be seen in Fig. 4.7, it uses another date section (see Sales Date Section 2 in Fig. 4.8). Sales Date Section 2 could be detected on many other screens, such as

• CD Quotation

• LJ Quotation

• SUS Conﬁrmation

• SUS Order

In this manner, we compared all 115 SAP CRM UIs to each other, classiﬁed by business scenarios “Sales Order Management”, “Service Order Management” and “Contract Management”. AppendixA presents further examples of the SAP CRM UIs explored and the UI Elements derived. We analysed 30 Service Order Screens, which were split into 7 UI elements each, amongst which were 5 different header elements, 7 business partner elements, 1 iBase section, 4 date sections, 5 priority sections, 3 problem sections and 4 item list elements. For further information on the UIs and the elements, refer to AppendixA.

1 For a full list of all UIs sharing this header element, please refer to SectionA. 1.2 in the Appendix.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 4.3 rule specification 80

Figure 4.7.: Replenishment Order UI

Figure 4.8.: UI Component Sales Date Section 1

In Contract Management, our analysis discovered 7 different header elements, 4 date sections and 2 item list elements on overall 16 Contract Management UIs. Examples of Contract Management UIs and UI Elements detected can be found in SectionsA. 1.5 andA. 1.6 in the appendix. Overall, we investigated 115 SAP CRM UIs of medium to high complexity, which could be dissected into 57 coarse-grained UI components. The fact that a lot of common UI elements could be detected shows a potential for the reuse of UI components.

4.3 rule specification

A key point of the approach is the use of knowledge acquisition method Ripple Down Rules (RDR)[89] which has been successfully applied to other domains such as pathology reports, soccer simulations, duplicate invoices, but never before to the domain of user interface creation. RDR were developed in reply to the

[ Context-aware UI Component Reuse for Web Service Development Environments ] 4.3 rule specification 81

Rule 0: Rule 3: Rule 1: IF Business Scenario = “not defined IFBusiness Scenario = Sales Order IF Business Scenario = Sales Order “AND Management , Telesales AND Management AND Device = Mobile, except Device= “not defined”, Device = Mobile, PDA AND Pointing THEN Layout = 2 (Vertical), Binding = 45 THEN Layout = 2 (Vertical),Binding= 0 Method= Touch screen, (SalesOrderCreate), Composition = 67, (“”) Composition = 1, Theme = 455 THEN Composition = 68, Theme = 457 Theme = 455 (GeneralMobile) (GeneralMobile) (MobilePDA)

If not

Rule 2: Rule 5: IF Business Scenario = Sales Order IFBusiness Scenario = Sales Order Management AND Device = Desktop, except Management , Telesales AND THEN Layout = 1 (Horizontal), Binding = Device = Desktop, Mac AND 45 (SalesOrderCreate), Composition = Resolution=1440x900, 67, Theme = 434 (GeneralDesktop) THEN Theme = 435 (DesktopMac)

Figure 4.9.: Rules in our Approach, featuring four Dimensions in the Conclusion challenge of maintaining medium to large rule-based knowledge systems [89]. In the RDR framework, expert knowledge is acquired based on the current context and added incrementally [128]. We have decided to adopt this approach as it (i) provides a simple and easy approach to knowledge acquisition and maintenance [14]; (ii) allows for the incremental creation of new rules while processing example cases. For the specifications of rules, we make use of a Single Classification Ripple- Down Rules (SCRDR) approach which provides exactly one conclusion per context. This is combined with an approval process as used in Collaborative Ripple- Down Rules (CRDR)[89], and the possibility to actually change rule conclusions (in traditional RDR approaches, only exceptions to rules are allowed, rules can never be changed or deleted). A Rule in our approach specifies which UI components should be combined to form a screen for a given context. Each rule specifies a condition (the context), for which a conclusion (a partial UI suggestion) is derived. In our approach, rules are described in the following way. Conditions are based on two attributes, the business scenario (Sales Order Management, Supply Chain Management, etc.) and the platform (Desktop, Mobile, PDA, iPhone, etc.). The conclusion relates to a subset of the four dimensions described above: Layout, Submission, Composi- tion and Theme. The combination of the conclusions of the most applicable rules for all four dimensions results in the suggested user interface. Fig. 4.9 depicts a number of rules, some with partial conclusions, in the knowledge base. Rule 0 contains the default conclusion where the business scenario and the platform chosen are not defined. In our prototype, we do not suggest a specific UI for that case, but propose an empty UI screen with some default layout and theme. The knowledge base shows true (except) branches, which are

[ Context-aware UI Component Reuse for Web Service Development Environments ] 4.4 incremental ui knowledge acquisition 82

accessed in case the if-condition is fullfilled, and false (if not) branches, which are accessed otherwise, that is in case the if-condition is not fulfilled. Starting at the top node, the inference engine tests whether the next rule node is true or false. If a rule node is true, the engine proceeds with the child nodes of this rule node and tests if the children are false or true. The last rule node that evaluates to true is the conclusion given. This is done for each dimension individually. The overall conclusion is then the combination of all partial conclusions. To give an example in Fig. 4.9, a UI developer wants to create a UI for the context “Business Scenario = Sales Order Management , Telesales AND Device = Mobile, PDA AND Pointing Method= Touch screen”. The system finds a UI that was created for the context “Business Scenario = Sales Order Management AND Device = Mobile” (Rule 1). The developer modifies the UI suggested by Rule 1 by applying a new style sheet for PDAs (affects the theme) and adding further UI components (affects the composition). An exception to rule 1 is created which results in rule 3. In a second scenario, the developer wants to create a UI for the context “Business Scenario = Sales Order Management AND Device = Desktop”. Rule 1 is checked and evaluates to “false”. The system starts to check the rules down the “if not” path. Rule 2 evaluates to true, and the UI with the dimensions “Layout = 1 (Horizontal), Binding = 45 (SalesOrderCreate), Composition = 67, Theme = 434 (GeneralDesktop)” is suggested to the user.

4.4 incremental ui knowledge acquisition

In our approach, knowledge is added to the KB in the following situations:

(a) A new UI is created from scratch, for a given context.

(b) The recommder system suggests a UI for a given context, and the developer decides to modify it.

Case (a) triggers the creation of a new rule for a context that was already stored in the database, but for which no associated UI existed. The KB is extended with a new component entry, and, if new layouts, themes, or new web service bindings are used, these are stored in the respective databases. In case (b), the rule condition remains unchanged, but the conclusion changes. In our approach, such changes are not stored automatically: if an existing rule is modiﬁed, it is unclear if this change will improve the KB content. Therefore,

[ Context-aware UI Component Reuse for Web Service Development Environments ] 4.5 confidence score 83 an approval process is triggered, where a suitable approver (e.g., development manager) has to confirm or reject the change. Case (c) relates to a completely new context. Here, the condition and (likely) the conclusion of a rule are affected. This case arises whenever new devices are introduced to the platform database, new business scenarios are added, or combinations of devices and business scenarios are chosen for which no knowledge exists (a new case is created and accordingly a new condition and rule is specified). If the new context is an extension to an existing context, an exception to a rule is stored. Otherwise, a new rule is stored in the if not branch of the rule tree. After saving the UI in case (c), a difference list is presented to the user for every dimension of the UI, e.g., the UI developer is asked why the layout was changed, why the composition was changed, and a list of context-related differences is presented to her. The developer can flag the differences which were relevant for her decision to change the suggested UI. Relevant for a change in the layout might be , e.g., that the UI was created for a PDA as opposed to a generic mobile device. The context specified as relevant by the user will be saved by the system as a new rule condition. Our approach thus requires little user effort for maintaining the knowledge: Apart from specifying the rule conditions in a difference list, the user is not required to actively contribute to the rule base evolution – rules are created and stored by the system based on the users’ actions.

4.5 confidence score

For each UI suggestion, a value for the confidence is calculated. The confidence value serves as an indicator of how well the UI suggestion found by the system suits the context given. It is calculated as soon as the user has selected the context in the wizard, and is displayed together with the UI suggestion created by the approach. A confidence value of 100% indicates that a UI has been built in the past for exactly the same context. Confidence values lower than 100% show that a UI for a similar context has been found in the system. The higher the confidence value, the more similar is the context chosen to the context of the former case. Accordingly, the more suitable the UI suggestion might be for the new context chosen. In this work, the confidence serves merely as an indicator for the UI developer. In future validations of our approach however, the confidence score could be used to evaluate the fit of our UI suggestions to the context.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 4.6 evolution of rules 84

The confidence is first calculated separately for the four dimensions submission, layout, theme and composition. The overall confidence is the average confidence value over the four dimensions. The confidence is calculated in the following way: let case i be the case entered by the UI developer (called the Induction Case), and case j be the case stored in the system which is most similar to i (called the CornerStoneCase) , then X(i, j) represents the number of attributes which are equal between the cases i and j. Y(i,j) indicates the number of attributes that are defined in both cases, but differ between cases i and j. Z(i,j) is the number of attributes which are defined in one case, but do not exist in the other. Weighting Y(i,j) and Z(i,j) equally, confidence C(i,j) is then calculated for each dimension in the following way:

M(i, j) := X(i, j) + Y(i, j) + Z(i, j) (4.1)

X(i, j) C(i, j) := (4.2) M(i, j)

For instance, we have entered the case Sales Order Management, Telesales and Mobile, PDA, Blackberry, Blackberry 98420 and have found the case Service Order Management, Standard Service Order, Mobile, PDA. In this case, the difference list shows two device related attributes which are equal (Mobile, PDA ⇔ Mobile, PDA), i.e., X(i, j) is 2; two business-scenario related attributes which are different (Sales Order Management, Telesales ⇔ Service Order Management, Standard Service Order), i.e., Y(i,j) is 2; and two attributes which are defined in the induction case, but not in the cornerstone case (Blackberry, Blackberrry 98420). Accordingly, Z(i,j) is 2, and M(i, j) is 2+2+2 = 6. The system calculates a confidence of 2/6= 0.33, that is a confidence value of 33 %.

4.6 evolution of rules

Rules evolve over time: with every new change made to suggested UIs, with every new UI created from scratch and every new combination of context and UIs. We are using the following algorithm for creating and changing rules (here in Pseudocode): Case CornerstoneCase ( return Case for applicableRule )

[ Context-aware UI Component Reuse for Web Service Development Environments ] 4.7 ui knowledge acquisition - discussion 85

The case entered into the system, consisting of an Action, a business scenario and a device is the InductCase. The cornerstone case, that is the most similar case to the InductCase, is derived as case for the applicable rule: To derive the applicable rule and thereby the cornerstone case, we are using an SCRDR algorithm. The applicable rule is the deepest rule in a decision tree which evaluates to true for a given case. The exception rule refers to exceptions to an existing rule (case evaluates to true), the false rule refers to the false (if not) branches in the knowledge base.

4.7 ui knowledge acquisition - discussion

The reuse of UI artefacts being one of the central elements of our approach, we use a recommender system which suggests UIs to the developer based on a given context. The context consists of two dimensions, devices and business scenarios, which are stored in a hierarchical structure. This enables the creation of rules and suggestion of UIs on each level of the context-hierarchy. During our analysis of user interfaces, we investigated 115 SAP CRM UIs of medium to high complexity, which could be dissected into 57 coarse-grained UI components. The fact that a lot of common UI components could be detected on these real-life UIs showed the potential for the reuse of components, and thereby for an increase in UI development productivity. The recommender system is based on an incremental KB, which stores the context, UIs and rules. Rules are created automatically by the system based on the creation of new UIs and changes to existing UIs. The RDR approach, formerly applied to all kind of domains such as pathology reports and soccer simulations, was chosen to support the incremental knowledge acquisition based on context. In the recommender system, the conﬁdence score serves as a measure for the suitability of suggested UIs for the given context.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5 SYSTEMARCHITECTURE,IMPLEMENTATION& KNOWLEDGEBASECONTENT

The previous chapters illustrated how UI artefacts are represented in our approach, and how the recommender system, which is based on a knowledge base and the RDR approach, can forster the reuse of UIs. To enable the evaluation of the approach, which is discussed in the next chapter, we (i) developed two proof-of-concept prototypes, and (ii) ﬁlled the KBs with realistic content. Before presenting the details of the prototypes, called UISE and WST, we discuss the different possibilities to structure the KB.

5.1 deciding on a knowledge base rule paradigm

Having decided to use RDR for the reasons explained in Section 4.3, we had to investigate which type of RDR would be adequate for our approach. First we had to decide if we were facing a single or multiple classification problem. The creation of user interfaces is a complex task that may lead to multiple conclusions, particularly when several parties are contributing to a user interface design. In a community approach, user interface designers might contribute different proposals for a user interface for a chosen business scenario. The proposals might reflect the corporate identity of different companies, different ways to realise usability or simply reflect the personal taste of the UI designers. A Multiple Classification Ripple-Down Rules (MCRDR) approach, which allows for multiple conclusions, might be adequate for this scenario. On the other hand, multiple conclusions might lead to a chaotic conglomeration of differing user interfaces. The decision on which UI proposal is the right one for a certain context has to be made by the UI designer. Without clear UI guidelines and multiple UI developers contributing to a solution, the outcome can be applications lacking a consistent look and feel, with UIs differing significantly from each other. Furthermore, as the preview of every single UI proposal has to be calculated during runtime, the use of MCRDR for this approach might have a negative effect on the runtime performance of the system. In regards to a consistent look and feel of UIs and runtime performance, a SCRDR approach might

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.2 prototypical implementation of uise 87 be the better choice. As both approaches are valid, we decided to develop two implementations, one based on single conclusions, the other delivering multiple conclusions. In the ﬁrst prototype, UISE, we implemented an SCRDR approach which provides exactly one conclusion per context. This was combined with an approval process as used in CRDR [5], and the possibility to actually change rule conclusions (in traditional RDR approaches, only exceptions to rules are allowed, rules can never be changed or deleted). In the second prototype, WST [38], multiple widgets are suggested to the user for a given context. The main results described in [38] are summarized here for completeness. In the following, we describe the implementation of both prototypes that were built as a proof-of-concept of our approach, starting with UISE.

5.2 prototypical implementation of uise

The UISE prototype instantiates the approach for a Visual Studio .Net MVC environment. User interfaces are rendered with the help of JavaScript and the libraries JQuery and JQuery Mobile. These technologies were chosen as they support the adaptation of UIs to a large number of different platforms. The prototype is implemented as a rich Web application, using JSON as a data-interchange format. To fill the context side of the KB, we first integrated the Wurfl database [59] into our approach. Wurfl contains detailed technical descriptions of many devices and is updated on a regular basis. Second, we fed the KB with sample business scenarios derived from the SAP Business Suite CRM System via reverse- engineering. The details of the content elicitation are discussed in Section 5.4. The following components form the architecture:

• A front-end, the UISE wizard, which guides the UI developer through the application and which helps the user to enter the context and to deﬁne which conditions are going to enter a rule

• A back-end,which derives the UI proposals, calculates rules, and commu- nicates with the database and the frontend

• A database for persisting new rules, business scenarios, platforms, cases, and UI components

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.2 prototypical implementation of uise 88

• Web services which the UI components are bound to.

The APIs of our approach are shown in the following. We distinguish between a Reuse-API, which corresponds to the Recommender System and which provides everything needed for proposing a UI, and a Build-API, by which the knowledge base is built. The Reuse-API is described in table 5.1. The Build-API is presented in table 5.2.

Table 5.1.: Reuse-API Operation Name Input Output UI id View(component) UI FormCollection View(component) Component id View(component) CreateScenario FormCollection JSON (scenario.id), Scenario RenderComponent Component PartialView(view, component) or Par- tialView(“Elementary”, component) Editor - View (model)

Table 5.2.: Build-API Operation Name Input Output RippleDown FormCollection JSON (difference list, applicable rules, conﬁdence) Save FormCollection JSON (difference list, applicable rules, pendingForApproval )

The prototype’s functionality is split into two main procedures: recommend- ing UIs and acquiring knowledge. The recommendation works as follows. On the start of the prototype, the wizard guides the user through the application (see Figure 5.1 and Figure 5.2 ). The wizard displays all available devices and business scenarios which are derived from the device and business scenario repository. The context is entered into the wizard. On the server, RDR is triggered and a conclusion for the dimensions Lay- out, Binding, Composition and Theme are derived. A new user interface is created out of the named conclusions. The system checks if this user interface already

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.2 prototypical implementation of uise 89

Figure 5.1.: Choosing the Device in UISE exists in the component repository. If so, the name and description of the existing component is derived from the database. The component is rendered to an HTML string. A value for the conﬁdence, that is the suitability of the suggested UI for the given context, is calculated. The system determines the differences between the case which was entered into the system and the case which was found in the knowledge base. Components, HTML string, differences and applicable rules for all four dimensions and the conﬁdence value are sent back to the client as a JSON response. The recommendation starts with the user specifying the current context in a wizard. Using the hierarchies for the two context dimensions, the user selects from all available devices and business scenarios present in the repository. This is done with a set of dropdown boxes (see Figure 5.1) . The selected context information is sent back to the recommender system. As shown in Fig. 4.1, the system matches the context with the conditions of the available rules, selects the

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.2 prototypical implementation of uise 90

Context Selection UI Suggestion

Client

Derive rules Send Server derive data context Rule Composition Engine Platform Layout UI Descriptions

Binding Business Scenario Descriptions Theme

Rules

Figure 5.2.: Architecture of the Recommender System best fit, and returns a UI suggestion. Technically, the UI suggestion is stored and transmitted as a HTML string. If needed, the UI developer refines the suggested UI, deletes and adds elements, and possibly changes the Theme, Layout, or Binding. Figure 5.3 shows an example of a suggested Sales Order UI in the UISE prototype. Additional UI components can be dragged and dropped from the left hand side of the screen into the suggested UI. The application provides furthermore editing functionalities for the Binding to a web service (field “Controller” on the lower left hand side), the Layout (field “Layout” in the lower middle of the screen) and the Theme (field “Theme” on the lower right hand side). Storing the changes triggers the knowledge acquisition procedure, depicted in Fig. 5.4. For each dimension, the system calculates difference lists as described in section 4.4. These are shown to the user, who selects the dimensions which were relevant for her decision to modify the UI. The case repository is updated with the new case, and the new UI is stored in the component repository. New

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.3 classstructureforuise 91

Figure 5.3.: Suggested Create Sales Order UI in UISE and Editing Functionalities rules and conclusions are derived from the difference lists and stored into the database for all four dimensions.

5.3 class structure for uise

Figure 5.5 displays the class diagram of the UISE prototype. In the following, we will describe the classes and their attributes. We can distinguish between classes that belong to the condition, and classes that belong to the conclusion of a rule. Both sides are tied together by the Rule class.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.3 classstructureforuise 92

UI Modification Difference Lists

Save data Calculate difference lists store rules Composition Rule Layout Engine

Binding Rules

Theme Cases

Figure 5.4.: Recommender System: Knowledge Acquisition (top: User; bottom: System) 5.3.1 Classes forming the Rule Condition

The following classes belong to the rule Condition:

• Class Device is used for describing Devices and their attributes. Devices are ordered in a hierachy of devices (therefore attribute ParentID is required). Various attributes of the device can be maintained, i.e., the screen resolution, screen size, screen orientation (landscape, portrait), keyboard (qwerty/number), and the pointing method (touch screen/stylus). Furthermore, the class contains attributes for the operating system of the device, and the URL of the Device Image that will be displayed next to the device description in UISE.

• Scenario is a class for Business Scenarios. Business Scenarios in UISE are ordered in hierarchy of scenarios and subscenarios. Therefore, we are using attribute ParentID in this class.

• Class Case represents an RDR case with a speciﬁc combination of Device (DeviceID) and Business Scenario (ScenarioID). Attribute Action can be used to specify if a screen for a Create, Change, or Display action shall be created, e.g., for creating, changing or displaying sales orders.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.3 classstructureforuise 93

• Condition is the input into a rule. Multiple conditions can belong to a rule, Attribute (e.g., a scenario or a device), the Value of this attribute (e.g., 1 for Business Scenario 1 Sales Order Management), and a RuleID (e.g., 68) to show to which rule the condition belongs to.

• The KnowledgeBase class contains the RootruleID (root of a rule tree) for the four dimensions Layout, Theme, Binding and Composition.

• Each Rule is associated with a Conclusion. Following the RDR (Ripple- Down Rules) approach, a rule might be connected to an exception to the rule (ExceptRuleID) and an alternative rule that is checked if the current rule doesn’t hold true (FalseRuleID). The corner stone case (CornerstoneCa- seID) is the case that is added to the rule tree when none of rules contained in the knowledge base holds true for the new scenario and device chosen.

5.3.2 Classes forming the Rule Conclusion

Each Conclusion is associated with an ID, an author who created the conclusion, and, as a new conclusion might have to be approved by a development lead, a status. The status can be, e.g., “sent to approver”, “approval pending”, “approved”. The following classes belong to the conclusion:

• Class Submission represents the binding to a web service. In the MVC environment, a controller is written that represents the web service functionality (attribute ControllerName points to the controller, e.g., Sales Order Controller). The action that will be executed is given by the ActionName (e.g., CREATE, SUBMIT). Corresponding to the action performed, we can create a button with aButtonText (e.g., button “Create”, “Submit”).

• The Layout class speciﬁes in which way the UI components are arranged on the screen, e.g., in a horizontal or vertical manner. The ViewName indicates the view the layout is associated with, e.g., a view for a horizontal layout, a vertical layout, a collapsible vertical layout. The Icon is a small image of the layout that eases the selection of the layout on the UISE screen.

• The Component is a UI component, which can range from ﬁne-grained to coarse-grained components, up to entire UIs. Each component is associated with a Binding to a web service, a Theme (Stylesheet), a Composition (Com- positionID) and a Layout (LayoutID). The Title is what appears above the

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.3 classstructureforuise 94

component on the UISE screen. A description provides the UI developer with information what the UI component is used for. ViewName indicates the view the component is associated with, the ControllerID detects the controller. Attribute Name is the name under which the component can be selected, e.g., UI component Sales Order Date Section.

• A component can be hidden (class Hide), Labels on the screen can be changed (class Label) depending on the context. Both classes were not used in the current implementation of the prototype, but can be integrated into future versions of UISE.

• The Composition deﬁnes which UI components belong to a UI.

• The Containment deﬁnes combinations of compositions and components, and at which position of the screen the component is added (e.g., position 3 in a vertical layout means the component is added beneath the ﬁrst two components).

• The Theme is the style sheet that is applied to the UI component. The Title of the theme is the name under which the style sheet can be selected in the UISE prototype.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.3 classstructureforuise 95

«) ID CompositionID ComponentID Position Component Composition Containment Eigenschaften ILI~~IJ:l Navigationseigenscha… 'ffl'rm' J @ l~ rn rn 0 0 * I Conclusion 1 *

A Title Style Script Components

Theme 1'

@ Eigenschaften 'h~!Jn Navigationseigenscha… ~ rn rn Q "' 0..1 Conclusion Containments

Composition 1' Eigenschaften Navigationseigenscha… 1!1' -i' rn rn v :«) 0..1 * * ,0, 1 , 0, ,,0,, i«l «) ~ 1 * ID ComponentID Field Text Component Label

Eigenschaften itllfi'hlfi Navigationseigenscha… 'if () ·~ rn rn tl- «) ID RuleID Author Created Status Rule ID Title LayoutID ViewName ControllerName SubmissionID ThemeID CompositionID Description Name Hides Labels Composition Theme Submission Layout 1 * Conclusion Component () Eigenschaften i.tl:fiiJ:ltJIJ:i Navigationseigenscha… 'if Eigenschaften ilil'htJIJ:i'htJ'fi'h'hiJ:i Navigationseigenscha… @'ilf''if@'jiJ''if ~ rn rn ~ rn rn Q Q 1 * v * 0..1 ID ComponentID Field Component Hide Eigenschaften Navigationseigenscha… * 0..1 * lilfi'h .r I ~ rn rn [«) I Conclusion 0..1 Title ButtonText ControllerName ActionName ResponseCompon… ResponseCompon…

Submission 1' Diagram for the UISE prototype Eigenschaften 'h~ltl~:fi Navigationseigenscha… @ ~ rn rn "' I Conclusion Title ViewName Icon Components

Layout 1' Eigenschaften Navigationseigenscha… ~ rn 'ht~IJ:i rn "'I 5 . .: Class 0..1 A 0..1 @ @

>--- Figure 0..1 * 0..1 * ID FalseRuleID ExceptRuleID ConclusionID CornerstoneCaseID Conclusion Conditions ExceptRule FalseRule KnowledgeBases CornerstoneCase

~ 0..1 * Rule * 0..1 Eigenschaften ll~ltl'h~ Navigationseigenscha… 'ffl'liil'iil'Wiifiil' @ * 1 ID ParentID Title Description Children Parent ~ ~ rn []] Scenario

Eigenschaften Navigationseigenscha… ilf'jif v ~ IP:fi~'h 1 .;• []] rn 0..1

@ ID ScenarioID DeviceID Action Device Scenario Rules * 1 Case Eigenschaften Navigationseigenscha… * * ll~~~ ilf'jifll!l' ~ []] rn t«J '«] ~· 0..1 * ID ParentID Title Description SourceDeviceID Brand Image ResolutionX ResolutionY SizeX SizeY Keyboard ScreenOrientation PointingMethod OperatingSystem Browser Children Parent Device

Eigenschaften i.tltJIJ:iltl'hiJ:l~'h~~lfi~~'h~~ Navigationseigenscha… ill' 'if []] rn ID RootRuleID Title RootRule ID Attribute Value RuleID Rule KnowledgeBa… Condition -.Eigenschaften :]Navigationseigenscha… Eigenschaften ilil'htJ'tl Navigationseigenscha… ll!l' "' ¥ ¥ []] rn

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.4 knowledge base content elicitation for uise 96

5.4 knowledge base content elicitation for uise

In order to enable a realistic evaluation, we ﬁlled the context-related part of the KB with real-world content about devices and business scenarios.

5.4.1 Elicitation of the Device Hierarchy for UISE

In order to capture the characteristics of different devices such as Mac or Win- dows desktop, Apple iPhone, iPad, and different versions of mobile phones, we researched existing device databases. Our goal was to represent devices in a hierarchical way, enabling the user to choose between different levels of device speciﬁcation, ranging from rather generic device descriptions (e.g., mobile phone, Windows desktop) to very detailed descriptions on a brand- and model- based level (e.g., Nokia C5-00, Apple iPhone 4S ). Aiming at identifying a device hierarchy well suited for our approach, we analysed and compared the following device databases:

• MDBF

• Volantis

• UAprof

• WURFL

In the following section, we describe and compare the named device databases in detail.

5.4.1.1 MDBF

Mobile Device Browser File (MDBF) is an open source database that contains the capability deﬁnitions of over 400 mobile devices and browsers [13]. The data stored in MDBF was gathered from the WURFL device database (see below) and other sources. When used together with ASP.Net, the header information of the incoming requests is used to detect the mobile device or the browser that has sent the request. Information is exposed through the Request.Browser property1. MDBF deﬁnes 67 capabilities or properties of mobile devices and

1 For more information on the Request.Browser property, see [73].

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.4 knowledge base content elicitation for uise 97

browsers than can be used to render UIs according to the device / browser speciﬁcations. The capabilities range from screen size to cookie support. MDBF is part of the CodePlex project, and had its ﬁnal release in August 2010. Today, MDBF is not maintained any more. Fig. 5.6 displays the device hierarchy used for MDBF, showing an ID for the device (e.g., iPhone) and its parent (e.g., Apple) in the browser tag.

Figure 5.6.: Device Hierarchy used for MDBF

5.4.1.2 Volantis

Volantis is a Java-based mobile content delivery platform and development environment (Eclipse, WebSphere plugins). In February 2011, Volantis contained 8000 devices with over 850 attributes [112]. Volantis was updated on a regular basis as part of the Volantis Device Program. In February 2011, Volantis was purchased by mobile applications developer Antenna Software [117]. Volantis is a library of mobile UI widgets with abstract, device-independent UI descriptions (based on XHTML Device Independant Markup Extensions (XDIME)2). It contains a separate XML document for each device. We can distinguish the following types of XML documents used: • identiﬁcation.xml -speciﬁes regular expressions for identifying user agents from the header information (see Fig. 5.7)

2 For further information on XDIME, please refer to [119]

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.4 knowledge base content elicitation for uise 98

• deﬁnitions.xml -speciﬁes all available “policies” (capabilities / features) and their data types (see Fig. 5.8)

Figure 5.7.: Device Identiﬁcation used for Volantis

Figure 5.8.: Device Format used for Volantis

Fig. 5.9 shows the device hierarchy used by Volantis, going from coarse-grained device classes such as “Tablet” to a more ﬁne-grained device model level (e.g., “Nokia-E61i-OSS”).

5.4.1.3 WURFL

WURFL [59], the Wireless Universal Resource File by Luca Passani / ScientiaMo- bile, is a Device Description Repository (DDR) that stores the descriptions of

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.4 knowledge base content elicitation for uise 99

<:1:·/icc: nru·.-.::• "14blet•::- • ~'.o:·.lio.·o: W:1:11::- 'tlu)..i.4.-0S:S-BLufllo'~L'' :· .:.dev:.ca r.$.10e= •R'of.".1a-B61-0SS' ;. .:.dev:.ca r.$.10e= •R'of.".1a-tr73-0SS' i;. c.' C.cv icc:; <:I .'... ·~ io.·o::.

Figure 5.9.: Device Hierarchy used for Volantis

several thousand devices. WURFL is a framework that enables applications to map incoming HTTP requests to a description of the capability of the requesting device. The device descriptions are maintained in XML. Originally designed for mobile devices only (in the year of its creation 2001, the description “wireless” corresponded to today’s term “mobile”), WURFL is now storing data for “every HTTP-client worth recognizing” [59], including tablets and smartTVs. The data in WURFL is added by a number of approved “contributors”, which are typically representatives of big mobile companies or operators. Once an open source database, WURFL is now distributed to the community of WURFL adopters with a license. It offers an API for Java, PHP, databases (TeraWURFL) and ASP.net, and is available as a cloud solution. The cloud client can be used by hobbyists and micro companies for free. WURFL is hierarchically structured, containing information on properties that are grouped in feature groups, such as: • Product (model, version, release date, OS, browser, keyboard, pointing method, ...)

• Display (physical size, resolution, orientation) WURFL deﬁnes a fall-back for every device: Based on the observation that new device models are often using the same software as their predecessors, WURFL links devices to descriptions of “fall-back” devices, which are typically older models of the same manufacturer. The fall-back strategy can be used to make the repository more compact, and to reasonably predict the functionality of new devices. Programming APIs can traverse the device hierarchy and thereby make guesses about the capability of a device. “Generic” devices are devices at the top of a WURFL ﬁle. Typically characterized by the most basic features (e.g., small screens, only basic XHTML support), generic devices represent devices that couldn’t be recognized, and guarantee

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.4 knowledge base content elicitation for uise 100 that for every device at least a generic device can be found. They furthermore represent a termination point for all fall-back chains.

Fig. 5.10 shows a WURFL device description maintained in XML. As a minimum, the device hierarchy contains a user agent string, a device-id and a fall- back attribute, which can be used, as described above, to infer more information about the device by traversing the information of linked device descriptions.

Figure 5.10.: Device Hierarchy used for WURFL

5.4.1.4 UAProf

UAProf [53], short for “User Agent Proﬁle Speciﬁcation”, is a standard by the Open Mobile Alliance and based on the data provided by the WURFL project [59]. Maintained as XML-documents, UAProf describes the capability of devices and browsers, offering one document per device. The registry of UAProf documents is available at http://www.uaprof.com/. UAProfs are Resource Descrip- tion Framework (RDF)-based, which means that the document schema is extensible. In the community-driven approach, data about devices is contributed by various parties, e.g., for Global System for Mobile Communications (GSM) devices, it is provided by the vendors like Nokia and Samsung, whereas for Code Division Multiple Access (CDMA) / Binary Runtime Environment for Wireless (BREW) devices, it is more likely to be maintained by a telecommunications company (Ver-

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.4 knowledge base content elicitation for uise 101 izon, Sprint). The UAProf project-owners do not guarantee for the accuracy and correctness of the data. Users are however invited to check the data for errors and correct the device descriptions if needed. According to [59], UAProf can be classiﬁed as an industry standard for representing device capabilities. As this information is unlikely to be sent over the internet with every single request, the UAProf document is stored in a pub- licly accessible repository, and an UAProf URL is provided in the header of the HTTP-request of a mobile device. A typical UAProf document contains information about the hardware platform, software platform, browser user agent, network characteristics, and Wireless Application Protocol (WAP) characteristics, each with a predeﬁned collection of possible attributes [34]. Fig. 5.11 shows an example of a UAProf structure.

Figure 5.11.: Device Hierarchy used for UAProf

According to [34] and our own observations, there are certain drawbacks to the use of UAProfs:

• Not all devices have UAProfs and descriptions are not available for every device, e.g., UAProfs for Apple products were not available at the time of the creation of our prototype.

• Errors in the data or the schema of UAProfs can result in parsing failures.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.4 knowledge base content elicitation for uise 102

• Not all UAProfs that are advertised are actually available. According to UAProﬁle.com, around 20% of the links supplied by handsets are unavail- able.

• There is no industry-wide quality standard for the data in a UAProf.

• Data in the UAProf headers can be completely incorrect, e.g., it might be data for another device.

• Retrieving and parsing a UAProf document in real-time can be quite time- consuming, so that a signiﬁcant overhead is added to web requests. UAProfs have to be cached in a Device Description Repository, which has to be updated on a regular basis in order to capture device deprecation.

• The UAProf document might not contain the user agent of the device the documents refers to.

UAProf is furthermore not hierarchically structured, the device data is stored in separate documents without any references to similar devices/devices in the same device family. Due to the drawbacks described above, and to the missing hierarchical structure, UAProf was considered as not being applicable to our approach.

5.4.1.5 Elicitation of the Device Hierarchy for UISE - Discussion

The device database that we found most suitable for our approach was WURFL. The way its device hierarchy is structured, and the features provided such as fall-back devices made this database a good ﬁt. At the time of the creation of the prototype, WURFL was furthermore updated on a regular basis. Feeding our prototype with the latest device information was as simple as replacing the WURFL ﬁle with its updated version. Further device databases which weren’t taken into account for this analysis, but which shall be mentioned here, are DeviceAtlas [21], DetectRight [20] and Mo- bileAware [70].

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.4 knowledge base content elicitation for uise 103

5.4.2 Elicitation of the Business Scenario Hierarchy for UISE

Similar to the elicitation of a device hierarchy, we aimed at establishing a hierarchy of business scenarios. The user should have the option to deﬁne UIs for different levels of a business scenario hierarchy, starting at a generic level like the scenario Sales Order Management, and going to more ﬁne-grained levels like scenario Sales Order Management–Quotation–Web Auction Quotation . In contrast to the device hierarchies, we didn’t make use of an open source database, but derived a business scenario hierarchy directly from the SAP CRM 7.0 system. We explored transaction CRMD_ORDER 3 , which is a central application used in the CRM system for the creation, update and display of all kind of CRM sales orders, service orders, activities and contracts. Fig. 5.12 displays an extract of the resulting business scenario hierarchy in our approach. The entire business scenario hierarchy contains 115 SAP CRM scenarios on 4 different levels.

Business Scenario

Sales Order Service Order Contract Management Management Management

Internet Order Quotation Sales

Sls Order Standard Order Quot Order Quot. MorePriAct Order OnePriAct Amt all

Figure 5.12.: Business Scenario Hierarchy in UISE (Extract)

This structure is not ﬁxed, but can be extended by the user during runtime. New scenarios can be entered directly in the UI creation wizard, and existing scenarios can be enriched by adding further business scenario levels.

3 a transaction in the SAP system corresponds to an application or program. Transaction codes like CRMD_ORDER are used to navigate to the application.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.5 cross platform & context web services - wst 104

5.5 cross platform & context web services - wst

A second implementation of our approach was done in [38] as part of the Honors Thesis of Patrick de Guzman at UNSW. This work provides a service for UI developers, where, based on a context, UI widgets are recommended. In a community approach, UI developers can contribute UI widgets and add descriptive textual information. The widgets are furthermore categorised with contextual information. Context and textual information are used to make UI widgets searchable, enabling other users to search for them and reuse them.

In the following, we discuss the design that was used in this second implementation. We furthermore show the results of the evaluation.

5.5.1 Design for WST

The approach uses the elements which will be described in the following (see also the data model in Fig. 5.13). The majority of these elements are very similar to the ones used in the UISE prototype. New elements like the Creator or the Tag element were added in order to enable an easier and more precise search for widgets. The investigation of widgets that we found online led to the addition of element Template, which reflects the fact that widgets are often offered together with specific templates to display specific content (see a more detailed description below).

• Widget: The widget entity stores the attributes that describe a widget. Wid- gets correspond to UI components that are grouped in a hierarchical structure according to the “Hierarchy of UI Components” in Fig. 2.4.

• Composition: The Composition deﬁnes which UI widgets are combined to form a UI. The purpose of the composition is to allow for the reuse of UI widgets. Fig. 5.14 shows how a UI for a scheduling organiser on a mobile device is composed of a header section and a calendar component.

• Theme: The Theme refers to the look and feel of the UI. We can distinguish Themes that differ according to the operating system the widget had been created for, e.g., widgets for Macintosh desktop vs. widgets for Windows desktop. The Theme might also reﬂect different corporate identities such as the online shopping stores for Myer and David Jones.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.5 cross platform & context web services - wst 105

Figure 5.13.: Data Model for representing UI Widgets in [38]

• Template: Templates are features on a UI that are used to display a speciﬁc content. An example of a Theme with multiple Templates can be found in Fig. 5.15, which shows a hotel widget theme called “Ambassador”. It contains two templates, one for rooms & rates, another one for photo galleries.

• Device: Part of the context in this approach is the Device entity. It stores information and characteristics of different the consumption platforms, such as brand, model, resolution, operating system, etc. Devices are classiﬁed following a Device Hierarchy (see Fig. 5.16), starting on a generic level with descriptions like mobile or desktop, and going to a very speciﬁc level with device model name, display size, resolution and interaction mode.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.5 cross platform & context web services - wst 106

Figure 5.14.: Example of a Composition in [38]

Figure 5.15.: Example of Theme and various Templates in [38]

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.5 cross platform & context web services - wst 107

I s.u:~.u.,Ww.. n : I TIIW..'1 .,-'~ "' ) I .,.....,.,..,., l I "'·' ..... l r"-1 aou l

Bl:.,c-kb... ny I i'Poul o;,.a.,, ?.7 w. l>.i~ 4.. 2 .DCb ltor;.ob-..kc ~ '>J I CM~ :\..0,. tRJ lnr.l'r'lliCtit)n: T&!wl'lu ;r"'"'1 l.u~:u-.,jcm; ]Uud~n~~o."'.:; ).._

Figure 5.16.: Example of Device Hierarchy in [38]

• Business Scenario: Business Scenarios are, according to our approach, an essential description of a business problem. In [38], they are likewise stored in a hierarchical structure. Fig. 5.17 shows an example of such a hierarchy. A generic scenario like Travel Management can be speciﬁed on a more detailed level as Hotel Management.A Hotel Management scenario can be broken down into Room Details and Reservations.

• Programming Language: The Programming Language describes the languages the widget code is written in, e.g., Java, C, C++. This entity is part of the context.

• Creator: The Creator is the name of the UI developer who has created the widget and contributed the widget description into the database. By storing the Creator, widgets from a developer of interest can be searched for and identiﬁed by other users.

• Tag: A Tag is term or keyword that describes a widget, and can be used in a search for widgets. Multiple tags can be associated with a widget, and multiple widgets can use the same tag. As an example, a twitter timeline

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.5 cross platform & context web services - wst 108

lhr.:iu~ :'~ :kl'li:H~: ·

'I' ·;o:d SM.if;;;:u u .l

M(llt"l M!l ii :'<~!'>Ut'r t .

D~o·hj!~ • ~~·.liv~n J:'

Figure 5.17.: Example of Business Scenario Hierarchy in [38]

widget can be identiﬁed by the tags “twitter”, “timeline”, “social media” and “tweets”.

Fig. 5.18 shows a concrete example of how the different entities are stored in a database. Each table in the image represents one of the entities mentioned above. The context in the approach is represented by tables “Business Scenario”, “Device” and “Programming Language”. The hierachical structure in which business scenarios and devices are stored in is visible, e.g., business scenario Hotel Booking with ID=4 is linked to its parent business scenario Hotel via ParentID = 3.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.5 cross platform & context web services - wst 109 ' J~ :A•mi' 1 10 , : 11 ete Example of Data Store in Data Base in [ 38 ] lbt(.UW.:II)OlC: . ' ' "'• ' , ' ' A·e>x ,;,,,..., 5 . 18 .: Concr • ' Figure " • • .. , } ... · ~ ... · .. · . l · ~ ' .... C ':: " , . 1A " .... , , !"1 , n!ll Jf1!'to, .. S>J!I'I " ~:

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.5 cross platform & context web services - wst 110

5.5.2 System Architecture and Implementation for WST

Fig. 5.19 displays the architecture of the system, and the interaction of the system with its users. Developers contribute widgets via the API. They add descriptions to the widget, which will be stored in the entities described in Section 5.5.1. The more detailed the description, the easier the widget can be searched for. Users can be technical and non-technical users. They submit a search query to retrieve a widget via the widgets API. Searches can be performed by keyword, context and tags or creator of the widget. The API analyses which kind of search is intended, and submits the query to the search engine. The engine accesses a file-based indexed database to match the query. A list of recommended widgets is returned to the user. If the widgets suggested by the system do not match the user’s requirements, widgets can either be modified or created from scratch. Both modified and newly developed widgets can be contributed by the developer into the system, and are thereby made available to other users for reuse.

Figure 5.19.: System Architecture in [38]

The system was implemented using various technologies. Java was chosen for the implementation of the backend in order to make it compatible with related

[ Context-aware UI Component Reuse for Web Service Development Environments ] 5.6 system architecture and implementation - discussion 111 research projects that were using the same technology. For similar reasons, Post- greSQL was used for the database. The Apache Lucene software library provides the prototype with the ability to search for widgets. It enables a full text based search by indexing the database and retrieving indexed database entries for search queries. The Application Programmining Interfaces (APIs) of the system were implemented using a REST-based web-service. The REST-web service was chosen due to its higher accessibility using a standardised HTTP interface. In regards to the APIs, a Contribution API and a Search API can be distinguished. Developers can contribute widgets, programming languages, devices etc. via the Contribution API. In order to do so, a HTTP Post method can be used to send a JSON object. The Search API provides access to the data stored in the database. Through the REST API the data is exposed, and the user can identify all context data available. A composition resource identiﬁes the widgets used to form a composition. When a composition is posted, a JSON object containing an array of widgets is stored in the database, where the widgets in the array form a composite widget. Equally, when a theme is posted, the JSON object should contain an array of themes that are stored in the database.

5.6 system architecture and implementation - discussion

This chapter discussed the system architecture and implementation of our prototypes UISE and WST. For the implementation of UISE, we used .Net’s Visual Studio MVC framework. After an investigation of device databases, we chose a device database called “WURFL” to model the devices in our context. WURFL was selected as its hierarchical structure and features suited our approach best. The second context dimension, the business scenarios, was derived from a SAP CRM system via reverse engineering. The second implementation, WST ([38]), applies the approach to a widget search tool. Java was chosen for the implementation of the backend functionality, Post- greSQL for the database which stores various entities sucha s widgets, themes, templates. The Apache Lucene software library provides the search functionality. Widgets can be contributed through an API which is based on a REST-based web-service.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6 EVALUATION

Based on the two proof-of-concept prototypes described in the previous chapter, we conducted experiments simulating the development of UIs and the search for widgets. To evaluate the approach, we (i) developed two proof-of-concept prototypes, the recommender system and the widget search tool (see Chapter 5), and (ii) conducted experiments simulating the development of UIs and the search for widgets.

6.1 evaluation of uise

First we evaluated the UISE prototype. The business scenario hierarchy and device hierarchy used in the experiment were derived as described in Section 5.4. We wanted to investigate if an increase in productivity could actually be achieved through the reuse of UI components.

6.1.1 Evaluation Objectives and Settings - UISE

An important factor in any application of our approach is the amount of content and number of rules in the KB. On one end of the spectrum, the KB does not contain any UI components needed to create a user interface for a given context – all UI components have to be created from scratch first. In this situation, we hy- pothesise that our approach will not provide a benefit over conventional IDEs – it might even lead to a slightly increased effort. On the other end of the spectrum, all UI components required for the creation of a user interface are available in the KB. In this situation, we suspect that our approach is most helpful and leads to a significant increase in productivity. In all other situations, i.e., only some of the UI components required are available, whereas others have to be created in order to complete the UI, we expect that an increase in productivity is observable – depending on the portion of UI components available, the improvement may range from minor to significant.

112

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.1 evaluation of uise 113

For the evaluation herein, we decided to focus on the end of the spectrum where UI components reuse enabled by using our approach should be most clearly observable– i.e., when all UI components needed are already available, but no rules for the creation of UIs have been defined. In order to evaluate the added value of our approach in UI development productivity, we analysed 115 UIs from the Customer Relationship Management system SAP CRM 7.0, specifically from high-level business scenarios including “Sales Order Management”, “Service Order Management”, and “Contracts / Service Contract Management”. To facilitate the experiment, we reproduced the main screens for these highly complex UIs. In the first step, we identified the UI components out of which the user interfaces were composed. This was done by comparing different UIs with each other, to detect common elements and identical screen parts – e.g., header elements, item lists, data sections (see Section 4.2). The UI components identified thereby were added to the KB of our prototype UISE. Furthermore, the business scenarios we encountered in the CRM system were integrated into UISE via reverse engineering (see Section 5.4.2). After this boot-strapping step, we reached a reasonably rich UI base. All UI components, themes, layouts and bindings to web services required to create the UIs were available in the database – but no rules. By combining these elements to user interfaces during our experiment, new compositions, rules and new UI components would result. In the following step, the testing phase, we recreated the SAP CRM screens with UISE. For the experiment, we varied the business scenarios, but kept a fixed platform (a generic mobile platform). By doing so, we simulated a large- scale UI development effort. Given the source of the screens, the simulation is strongly based on real-world application. Due to the fact that we recreated the screens for given business scenarios, we knew what the correct result for each scenario looked like. However, we could not use this setup to realistically compare times taken for UI development. Instead, we counted the number of rules that had to be created during the recreation of all the 115 user interfaces with our approach. Only if the UI suggested by the tool already corresponded exactly to the desired UI, no changes were needed and accordingly no new rule was created.

Likewise, we observed how the number of compositions in the KB grew in the course of the experiment. Since the experiment only involved recreating UIs for an SAP system and a ﬁxed platform, the theme, layout and mapping were kept ﬁxed. An identical composition therefore indicated an identical UI. Less new rules and

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.1 evaluation of uise 114 less compositions thus mean less work for the developer. Therefore, both these metrics can be seen as an inverse measure of productivity.

6.1.2 Evaluation Results - UISE

Figure 6.1 shows the number of rules that had to be created for the selected UIs over time. Over the course of the experiment, we can see a slight decline of the rules curve: for creating 115 UIs, 107 rules were added. That means, out of all suggested UIs, 8 were a perfect match. A much more signiﬁcant decline however is observable in the composition curve: the 115 UIs were reproduced with only 48 different compositions. Improvements through the reuse of UI compositions were clearly present in the experiment.

140 UI Rules and Composions

120

100

80 without UISE

60 # Rules # Compositons

# rules/composions 40

0 1 11 21 31 41 51 61 71 81 91 101 111 # user interfaces

Figure 6.1.: Knowledge Base Size vs. Number of UIs

On a more detailed level, we also counted the number of changes needed to create a user interface. A user interface is suggested to the developer according to the context chosen. If the suggested UI corresponds already to the UI she

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.1 evaluation of uise 115

wanted to create, no changes are required. Otherwise suggested UI elements have to be replaced or eliminated, or new elements added. We counted each add / delete action as one change, thus replacements were counted as two changes. Fig. 6.2 shows the results of this investigation for each of the high-level business scenarios.

45.0

40.0

35.0

30.0

25.0 Service Orders 20.0

% Cases % Sales Orders

15.0 Contracts

10.0

5.0

0.0 0 1 2 3 4 5 6 7 8 10 12 # Changes

Figure 6.2.: Changes for Sales Order, Contract, and Service Order UIs

Depending on the speciﬁc scenario, Sales Order UIs consist of 38-71 simple UI elements like text boxes, labels and scroll-bars. Contracts require between 52 and 96 simple UI elements, and Service Orders between 54 and 108 simple UI elements. The number of changes that were needed to recreate Sales Order, Contract or Service Order UIs while using our prototype, UISE, are shown in Fig. 6.2. For all three scenarios, there were cases where zero changes were required – i.e., exact hits of the recommendation. For Sales Orders (see light grey columns in Fig. 6.2) up to 6 changes were needed in UISE, with an average value of 2.6 steps. Contracts (white columns) also required up to six steps; the average was at 3.6 steps. Service orders (dark grey columns) required up to 12 steps, with an average of 5.6 steps. Given the complexity of the target UIs, the number of changes required with UISE seems relatively minor.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.2 evaluation of wst 116

6.2 evaluation of wst

6.2.1 Goal of the Evaluation - WST

The approach was evaluated using a widget search tool. The goal of the evaluation was to examine the effectiveness of the tool in retrieving widgets that are relevant to the intention of the search. The search tool was compared against popular search engines such as Google or Bing. The work hypothesised that the widget search tool would deliver more precise results in the search for widgets than the conventional search engine Google.

6.2.2 Evaluation Environment - WST

The experiment was performed with a widget search tool implementing the approach described in the previous sections. The tool stored 50 widgets that could be retrieved via a search. The search results were compared to searches performed with Google. As the search with a conventional search engine could deliver hundreds of thousands of results, only the first 30 results were taken into account for the evaluation. When searching for a specific widget using Google, the word “widget” was added to the keywords in order to receive more relevant items. During the Experiment, the number of relevant items retrieved was compared to the total number of retrieved items. A measure of Precision was used, which is defined in the following way:

#relevant items retrieved Precision = (6.1) #retrieved items

6.2.3 Evaluation Search by Keywords - WST

Goal of the experiment was to evaluate the hypothesis by querying search tool and search engine with keywords and comparing the relevant number of search results retrieved. For the search, keywords retrieved from the proposed widget search tool database were entered. The test cases used in the experiment can be found in Tab. 6.1.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.2 evaluation of wst 117

Test Keyword Description Case 1 Facebook A high level search for any widgets related to Facebook 2 Facebook Follow A specific widget name Button 3 Schedule Class Terms that are used through several widgets, but want to retrieve widgets related to class scheduling 4 Zk Calendar A specific widget name 5 Calendar A description of a widget. To check if test case 5 still retrieves Zk Calendar as a top result 6 Facebook light A very specific type of template. Wid- theme gets that contain it shall be retrieved. 7 Glossy A type of theme available for widgets. Stored as Glossy black in the database. 8 Roomtype A type of template in a widget to display room type information 9 Gallery A template stored in the template table as Photo Gallery. To test if widgets can be retrieved just using keyword “gallery” 10 Java A description of a widget. Extracted from the tag table. 11 Follow A description of a widget. Extracted from the tag table. 12 Ipad A low level type of device 13 Desktop A high level type of device 14 Social Media A high level type of business scenario 15 Hotel A low level type of business scenario with specific widgets attached to it 16 JavaScript A programming language that describes the language the widget was developed in

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.2 evaluation of wst 118

Test Keyword Description Case 17 C A programming language that describes the language the widget was developed in

Table 6.1.: Test Cases for Experiment 1 in [38]

6.2.4 Experiment 1 Results - WST

Given that keywords were taken from the widget’s search tool database, results for every keyword entered into the REST- API could be derived as expected. In several cases such as in case 1, 3 and 10, the number of overall results matched exactly the number of relevant results (see Fig. 6.3). In those cases were also non- relevant results were delivered, the most relevant ones appeared on top of the result list. The experiments performed with the Google search engine showed that Google has the capability to find relevant widgets when searching by keywords. How- ever, it can be difficult to find widgets that are actually ready to use as intended by the search. Fig. 6.4 displays the results of the experiment in an overview. The precision measure was used to compare the number of relevant results to the overall number of search results (see Fig. 6.5). The graphic shows that the search results delivered by the widget search tool were much more precise than the search results delivered by the Google search engine.

6.2.5 Experiment 2 Results - WST

In the second experiment, the search for widgets was performed based on context. In accordance with experiment 1, keywords representing context were entered into the REST API. When searching for widgets by context in Google, keyword “widget” was added to the search. The experiment was based on the test cases shown in Tab. 6.2.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.2 evaluation of wst 119

Figure 6.3.: Results of Search by Keyword for Widget Search Tool in [38]

Context Test Keyword Description Case 1 Social Media High-level business scenario 2 Facebook Lower level business scenario for test case 1 Social Media Business Scenario 3 Facebook Follow Lover level business sce- Button nario for test case 2 Face- book 4 Travel High-level business scenario

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.2 evaluation of wst 120

Context Test Keyword Description Case 5 Flight Lower level business scenario for test case 4 Travel 6 Flight booking Lower level business scenario for test case 5 Flight 7 Education High-level business scenario. 8 Education Sched- Lower level business ule scenario for test case 7 Education 9 Assessment Sched- Lower level business ule scenario for test case 8 Education Schedule 10 Mobile High level device 11 Smartphone Lower level device for test case 10 Mobile 12 Iphone Lower level device for Device test case 11 Smartphone 13 Tablet Lower level device for test case 10 Mobile 14 Ipad Lower level device for test case 13 Tablet 15 Desktop High-level device 16 Microsoft Lower level device for case 15 Desktop 17 Windows XP Lower level device for case 16 Microsoft 18 Java Extracted from the programming language ta- Language ble

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.2 evaluation of wst 121

Context Test Keyword Description Case 19 JavaScript Extracted from the programming language table 20 Objective C Extracted from the programming language table 21 C++ Extracted from the programming language table

Table 6.2.: Test Cases for Experiment 2 in [38]

The ﬁrst search was performed using the widget search tool. As portrayed in Fig. 6.6, the search by context delivered an equal amount of relevant search results as overall search results retrieved. Due to the design of the widget search tool, which stores every widget together with its context, the tool is capable of returning all widgets associated with a certain context when queried by it. Searching by context on Google delivered different results. Releveant search results were returned in many test cases. In some cases however, no relevant search results could be retrieved for the search by context (see Fig. 6.7). As a conventional search engine, Google has not been designed for a search by context. It focuses on other factors instead, such as the popularity of pages on the web. The precision measure applied to the results of experiment 2 (see Fig. 6.8) results in a precision of 100% in all test cases for the widget search tool. The Google Search turned out to be not as precise, with a precision measure between 0% and 60%. The results of the experiement indicate that the widget search tool as a tool designed for the widget search by context has a higher capability to retrieve widgets by context than a conventional search engine like Google. Accordingly, the hypothesis holds true that the widget search tool is able to retrieve more widgets than a conventional search engine when searching by context such as business scenario, device or programming language.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.2 evaluation of wst 122

Result~ fm· !;Carch hy kcywm·d l'oa·

.l.~ .,.------

:;!) 1(1 hr;r--.----.---.----..-r--.----.-- -~ ')0:: ., - ~ ·,__::!: '(I ·~ ~ 15 § 1(1 i. 5 (I " .; 4 5 6 i ~ <) 10 11 12 1:l 14 15 16 17

Te\t < :a~

Figure 6.4.: Results of Search by Keyword for Google in [38]

6.2.6 Experiment 3 Results - WST

The third experiment was a keyword search performed with keywords that were not stored in the database. The goal of this negative search was to ensure that the widget search tool would not return any results for non-existent widgets. This experiment could be performed for keywords only, a negative test for search by context could not be conducted. The reason for that is that the only context that can be selected is that available in the widget search tool. Tab. 6.3 shows the test cases used in experiment 3.

Test Keyword Description Case II 1 Shopping High-level business scenario 2 Fashion Lower level business scenario for test case 1 Shopping 3 Online Shopping Lower level business scenario for test case 2 Fashion

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.3 evaluation - discussion 123

Test Keyword Description Case 4 Lifestyle High-level business scenario. 5 Restaurant Lower level business scenario for test case 4 Lifestyle 6 Restaurant Menu Lower level business scenario for test case 5 Restaurant 7 Blackberry Low-level smartphone device 8 Linux High-level desktop device 9 Windows Vista Low-level desktop device 10 Python Type of programming language 11 Ruby Type of programming language 12 Perl Type of programming language

Table 6.3.: Test Cases for Experiment 3 in [38]

As expected, the widget search tool did not retrieve any results for keywords that were not in the database. Accordingly, as Fig. 6.9 illustrates, there were no results returned for all test cases when searching with the widget search tool. In difference to the widget search tool, Google was able to retrieve relevant results for the test cases in experiment 3 (see Fig. 6.10). The precision measure chart for the negative search (see Fig. 6.11) illustrates that the conventional search engine was able to retrieve more results than the widget search tool. The test results indicate that the widget search tool relies on developers adding widgets, descriptions and context in order to work prop- erly. In experiment 3, the hypothesis fails as the Google search engine is able to retrieve more relevant widgets than the widget search tool.

6.3 evaluation - discussion

The results of the evaluation indicate that an increase in UI development productivity from UI reuse is possible. For the UISE prototype, 115 SAP CRM UIs were investigated. A signiﬁcant decrease in the number of compositions needed to recreate the UIs could be observed. Equally, the number of steps required to recreate the UIs compared to the number of steps used with conventional meth-

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.3 evaluation - discussion 124

!'n~dsion m cati urc for se arch by kl~yword

~ 8~<.• •" :<" 61)'~~ . .§- • •1 0'~~ . ·~ .."• ~~f)'~~ .

1 2 3 1 ::> 6 , .;:. 9 L•) 1! 12 13 11 13 I ·~· 17 T ea t \.a !'>e

Figure 6.5.: Precision Measure for Search by Keyword in [38] ods was signiﬁcantly less. The evaluation of the second implementation of our approach, WST, showed that the widget search tool delivered more precise search results than conventional search engines like Google in the search for widgets based on context, given that a sufﬁcient amount of UI widgets were already available in the widget search tool’s database.

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.3 evaluation - discussion 125

Rc~ ult~ of ~c:·an,; h by (.' Un tc:xt (or \'t"idgc:t Search Tool

Figure 6.6.: Results of Search by Context for Widget Search Tool in [38]

R e,.; ult uf sea rch by t.::un l c:x l f.,r Guug le

.. , . ).J

! :'•0 "3 .. ?.' 0 ~- ~·) e l!- !5 § 1o ) z

0' l,J l 2 ;, 4 5 ,.;, 7 "-~ ~> lli lJ lZ J :, 1~ 15 l6 17 U.1 19 20 ~J

' l~wl C :u1-

Figure 6.7.: Results of Search by Context for Google in [38]

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.3 evaluation - discussion 126

Figure 6.8.: Precision Measure for Search by Context in [38]

Figure 6.9.: Result of negative Search for Widget Search Tool in [38]

[ Context-aware UI Component Reuse for Web Service Development Environments ] 6.3 evaluation - discussion 127

Rc~ ult of nega tive ~carch for Got>gle

~r------

·I ·' :-;. 'J E~ I I 1:!

Figure 6.10.: Result of negative Search for Google in [38]

!'recision measure for negative search

., , ::;;I( ../ ' ~ " "'""-: 6.11 '\./ •)(•7> ., •) • ; •1 • 1:) • ' H ' T,' .,c,...,,'

Figure 6.11.: Precision Measure for negative Search in [38]

[ Context-aware UI Component Reuse for Web Service Development Environments ] 7 CONCLUSION

7.1 challenges

The investigation of current UI development approaches, IDEs and related work showed the following:

• Modern IDEs provide limited support for the adaptation of UIs to context. UI components are offered to the UI developer, however, the reuse of UI components is not a ﬁrst-class concept.

• Modern IDEs lack automation. There are no mechanisms suggesting user interfaces based on the context chosen. Accordingly, UI developers receive no guidance by IDEs on how to create a user interface for a certain context.

• Approaches for code reuse focus on the functionality of the code. The reuse of UIs and UI components is not supported.

• The concept of reuse has already been introduced into UI development in the form of UI patterns. However, UI patterns are merely guidelines that require UI development knowledge for their interpretation. UI components, reusable chunks of UI code, are needed to increase the productivity of UI development.

• The adaptation of UIs to context is supported by various approaches in research. The majority of these approaches remain on a level of adapting background colours and user menus, but do not cater for changes of the UI structure and content. This however would be required for the adaptation of UIs to business scenarios. Approaches allowing for fundamental structural UI changes operate based on a ﬁxed set of rules, assuming that the optimal UI for a certain context is known.

128

[ Context-aware UI Component Reuse for Web Service Development Environments ] 7.2 summary 129

7.2 summary

In this work, we presented a novel framework and a tool for reusing UI components in web service development environments. The approach has the following main characteristics. 1. It enables the automatic creation of UI proposals for web service-based applications in a given context. The suggestions stem from previous devel- opments.

2. The approach is based on ripple-down-rules (RDR), which allows for incremental acquisition of knowledge in a rule base. The creation of rules is performed semi-automatically, during development.

3. UI suggestions are matched to varying contexts by combining UI components, applying different style sheets, changing the layout, and selecting the binding of UI ﬁelds to web services. We implemented the approach in a prototype called UISE. Using the prototype, we simulated the development of 115 UIs from SAP’s CRM system. By doing so, we evaluated qualitatively if using our approach is likely to result in productivity gains. The results from the experiment indicate that productivity increase from UI reuse is possible, and our approach is a step in the right way. A second prototype, WST, applied the approach to widget search. The evaluation of WST showed that, given that a sufﬁcient amount of widgets is available in the WST database, the search for widgets by context in WST is more precise than the search with conventional search engines like Google.

7.3 future research

In the UISE implementation of our approach, we suggest one user interface to the UI developer for a speciﬁc context using the SCRDR approach. WST suggests multiple widgets based on the context chosen. An interesting research topic would be in that regard how multiple suggestions for either UIs or widgets could be presented to the UI developer in an efﬁcient way, e.g., by ranking the suggested user interfaces according to user ratings in a community approach. We plan to explore the topic of dependencies between different UI components in future work. How can we establish rules that allow for certain combinations of UI components only, e.g., tax-related components that have to be used together in a certain scenario for legal reasons? Likewise, our current approach

[ Context-aware UI Component Reuse for Web Service Development Environments ] 7.3 future research 130 does not consider the interaction between components, e.g., when a UI component receives input data from another component and processes this data on the same or another UI. How can we represent these dependencies and interactions in our approach? In the validation of this approach, context was based on the variation of business scenarios, whereas devices were held ﬁxed. An open question is if the variation of both business scenarios and devices would result in similar outcomes. We hope that this work will inspire future research, and come to a productive use.

[ Context-aware UI Component Reuse for Web Service Development Environments ] A APPENDIX

a.1 examples for sap crm uis and ui elements

This section shows screen shots of the real-life SAP CRM UIs that we used to derive UI patterns and develop our approach. We distinguish between Sales Order Management, Service Order Management and Contract Management UIs. The screen shots had been taken from a SAP CRM 7.0 system. a.1.1 Sales Order Management UIs

In the following, we show several examples of Sales Order Management UIs that were part of our analysis. Due to space restrictions, we decided not to show the entire list of screens. Overall, we investigated 61 different Sales Order Manage- ment screens of the SAP CRM 7.0 system.

Figure A.1.1.: Standard Sales Order in SAP CRM

131

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 132

Figure A.1.2.: Telesales Sales Order in SAP CRM

Figure A.1.3.: Quotation in SAP CRM

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 133

CriYte Web Auction Quoblt.

Net V~ k.J~ 0, CO .J.PJQUoL.atbn created .. I[ Furtller ~tatuses . J~ ~oyee Re~ponsible ~IT ~ ~- R"f"'n;nc~ { ' b!f:;.r~mce Dlh .r==:-

Date-;

C'dlb T'(PE From D~tQ Ruk! Our.~t Unit Con:nct !:tilt D

(Q]~m:_@ l(giD I ~ I ~~ !af /J Item No. Pro:luct Prod. ProJosal cua1titv SU1 Fist Reauested D Last Coofrme:l D DeMverv Grc-uo Da OrderQuanttv

Figure A.1.4.: Web Auction Quotation in SAP CRM

Create Replenishment Order § ~ Business Partner Cockp I IJ BLsrness Transac:10n I ~

EJdoO!s notexistf)oen Hetde· O'teniew

Header. ~eplenrshment Order 3ta:us (i:JOpen i!IJ _ =urthe'813tus es inl ~l 3olj-T) Part..~ ~ rlnP<::nnto> ·c~=:t

Jhi:l·T)ra~ ::)([.Reference Rerer:mceoate ~

Dates_/

D<~1eT(pE From To

ll,clu<~l Dor.es TU 0~.1 0.2010 08:37 TU 05.10.:i01 0 OB:31 Ac:uo.1 D~te !Ac1vi1i3s) ia

~ , .'\TP Item \lumber Procluc: Prod. Prop coal Quantity' SUn Fir:::! Requested D__ __cd Confrm~d D. .. Delivery GroJp Dot Order Quantiti

Figure A.1.5.: Replenishment Order in SAP CRM

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 134 a.1.2 Sales Order Management UI Elements

The following UI Elements could be derived from the SAP CRM screens shown above: sales header elements Sales Header Element 1 (seeA. 1.6) could be detected on the following screens:

• Product Sales • Loyalty Accrual • Loyalty Buy Points • Loyalty Redemption • Telesales

Figure A.1.6.: Sales Header Element 1

Sales Header Element 2 (seeA. 1.7) - which differs from Sales Header 1 by the ﬁelds Ship-To Party, Bill-To Party and Payer, and doesn’t contain a ﬁeld for the employee responsible, can be found on the following screens:

• Business to Business (B2B): Internet Sales • B2B: Recall Order • Business to Consumer (B2C): Internet Sales (Payer and Bill -To Party swapped) • Internet Sales Application (ISA): Loy BuyPt Order (Payer and Bill -To Party swapped) • ISA: Loy acc. Ordr (Payer and Bill -To Party swapped)

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 135

• ISA: Loy red. Ordr (Payer and Bill-To Party swapped) • ISA: ISA: Host Ordr • Order Service Recall

Figure A.1.7.: Sales Header Element 2

Sales Header Element 3 (seeA. 1.8) was identiﬁed on screens:

• B2B: Partner Shop • Business (BOB): Customer Shop

Figure A.1.8.: Sales Header Element 3

Sales Header Element 4 (seeA. 1.9) is part of screens:

• Allowed Channel • Collections and Disbursements (CD) Quotation • Credit Memo Request

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 136

• Debit Memo Request • Goods Supplier (GS) Standard Order • Internaltas Brazil • LJ Quotation • MOM ASN • MOM Invoice • MOM Standard Order • PP: Quotation • PP: Standard Order • PPSM • Quot. Internet Sales • Quotation • Quotation MorePrintA • Quotation NoActpro • Quotation OnePrintA • QuotationSZG • Rel. From Value Cont • Replenishment Order • Sales Order / CRM Bill • Sales: Leased Object • Sample Order • Sat. Sales Order • Service Fee Stimulate • Sls Order MorePriAct • Sls Order NoActPro • Sls Order OnePriAct • SPM Sell f. Stck. • Standard Order • Standard Order: Auct • Std. Order Brazil

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 137

• Std. Order India • Trade_Standard Order

II ::::d Ch•nnel ~F------~ Net Valle r--==--::o_-:o:::o""''-----,--l St.tu5 IJIJopon .1 FurthO< St>tu•os - I ~ I Sod· TO Party Shp-To Party Ext. Reference Reference Date

Figure A.1.9.: Sales Header Element 4

Sales Header Element 5 (seeA.1.10) could be detected on screen:

• ISA Collab. Showroom

~~lab . Showroom Net Vak.J e o,oo I I :;~~ flb open . 11 FuM erStatuses .1[ ~ ] Sold-To Party II '" ' SukJ.fi·unl P111ty I ShP·T o Party sa.To Party Elc!. Reference Reference Date

Figure A.1.10.: Sales Header Element 5

Sales Header Element 6 (seeA.1.11) is used for screens:

• Price Protection CMR • Ship-and-Debit CMR

Sales Header Element 7 (see A.1.12) could be detected on screen:

• RBK Quotation

The following screens contain Sales Header Element 8 (see A.1.13):

• Sales Order Template

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 138

t Header Prtce ProtectiOn CMR NetV

Figure A.1.11.: Sales Header Element 6

l Hct:~dcr -1 - I RBK Quotation Net v~ue o.oo ~ Status t New . 11 Ftlrther staMes · II~ I Ship· To PaJty 1 Empoyee Responsille I I Ext. Reference Rtferenc:e Oate

Figure A.1.12.: Sales Header Element 7

• Web Auction Quotation

The last header element that could be detected is Sales Header Element 9 (see A.1.14):

• SUS Conﬁrmation • SUS ERS Invoice 5030975 • SUS Invoice Request 5030976 • SUS Order 5030977

Header Sal;,s Order Terrplate I Net Vtus IJe Opon .I! RJrtl1er 5t>:uses . JI~ Errployee Responsl>le !t051i14 l doe~ no~ exi~~ Ext. Rete1ence l·r:====~:..:.:,l Reh!rence Date J

Figure A.1.13.: Sales Header Element 8

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 139

• SUS Ship.Notif. 5030 978

Header suscortkmatkn S03097' Net Value -3 ,)0 ·~ Statu~ IFIIn Prom< -II Fulthor Stahl«< - II~ I Soli-To Party 1 'o' Shi>-To PartY ,I vendor t!l' Ext ReferE-nce Reference Oate I J

Figure A.1.14.: Sales Header Element 9 sales date sections Sales Date Section Element 1 (see Fig.A.1.15) is part of the following screens:

• B2B: Internet Sales • B2B: Partner Shop • B2B: Recall Order • B2C: Internet Sales • Allowed Channel • BOB: Customer Shop • Credit Memo Request • Debit Memo Request • GS Standard Order • Internaltas Brazil • ISA: Loy BuyPt Ordr • ISA: Loy acc. Ordr • ISA: Loy red. Ordr • ISA Collab. Showroom • ISA: ISA: Host. Ord. • Loyalty Accrual • Loyalty Buy Points

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 140

• Loyalty Redemption • PP: Standard Order • PPSM • Price Protection CMR • Rel. From Value Cont • Replenishment Order • Sales Order / CRM Bill • Sample Order • Sat. Sales Order • Service Fee Simulate • Ship-and-Debit CMR • Sls Order MorePriAct • Sls Order NoActPro • Sls Order OnePriAct • Standard Order • Standard Order: Auct. • Std. Order Brazil • Std. Order India • Trade_Standard Order

Figure A.1.15.: Sales Date Section Element 1

Sales Date Section Element 2 (seeA. 1.16) was identiﬁed on screens:

• CD Quotation • LJ Quotation • PP: Quotation

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 141

• Quot. Internet Sales • Quotation • Quotation MorePrint A • Quotation NoActpro • Quotation OnePrintA • Quotation_SZG • RBK Quotation • SUS Conﬁrmation 5030974 • SUS Order 5030977

Figure A.1.16.: Sales Date Section Element 2

Sales Date Section Element 3 (seeA. 1.17) belongs to screen:

• Sales: Leased Object

Figure A.1.17.: Sales Date Section Element 3

Sales Date Section Element 4 (seeA. 1.18) is used on screen:

• Web Auction Quotation

The following screens have no date section:

• Product Telesales • MOM ASN

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 142

Oates

Date Ty!>e Fron Date IMe Our.~t Unt Coni:Jac:t Start Oate FR ~14.10.2011 00:00 Today'> O;te i1 Iii Coni:Jact End Datt SA 14.01.2011 oO:oo start Date+ \'al. Perod ,D i!l

Figure A.1.18.: Sales Date Section Element 4

• MOM Invoice • MOM Standard Order • Order Service Recall • Sales Order Template • SPM Sell f. Stock • SUS ERS Invoice 5030975 • SUS Invoice Request 5030976 • SUS Ship.Notif. 5030978 • Telesales sales item list elements Sales Item List Element 1 (seeA.1.19) was detected on screens:

• Product Telesales • B2B: Internet Sales • B2B: Partner Shop • B2B: Recall Order • B2C: Internet Sales • Allowed Channel • BOB: Customer Shop • CD Quotation • Credit Memo Request • Debit Memo Request • GS Standard Order • Internaltas Brazil • Loy BuyPt Ordr

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 143

• Loy. acc. Ordr • Loy. red. Ordr • ISA Collab. Showroom • ISA: ISA: Host Ord. • LJ Quotation • Loyalty Accrual • Loyalty Buy Points • Loyalty Redemption • MOM ASN • MOM Invoice • MOM Standard Order • Order Service Recall • PP: Quotation • PP: Standard Order • PPSM • Price Protection CMR • Quot. Internet Sales • Quotation • Quotation MorePrintA • Quotation NoActpro • Quotation OnePrintA • Quotation_SZG • RBK Quotation • Rel. From Value Cont • Replenishment Order • Sales Order / CRM Bill • Sales: Leased Object • Sample Order • Sat. Sales Order • Service Fee Simulate

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 144

• ShipandDebit CMR • Sls Order MorePriAct • Sls Order NoActPro • Sls Order OnePriAct • SPM Sell f. Stck. • Standard Order • Standard Order: Auct. • Std. Order Brazil • Std. Order India • SUS Conﬁrmation 5030974 • SUS ERS Invoice 5030975 • SUS Invoice Request 5030976 • SUS Order 5030977 • SUS Ship.Notif. 5030978 • Telesales • Trade_Standard Order • Web Acution Quot.

Figure A.1.19.: Sales Item List Element 1

Sales Item List Element 2 (seeA. 1.20) was part of screen:

• Sales Order Template

Figure A.1.20.: Sales Item List Element 2

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 145 a.1.3 Service Order Management UIs

In the following, we show several examples of Service Order Management UIs that were part of our analysis. Due to space restrictions, we decided not to show the entire list of screens. Overall, we investigated 30 different Service Order Management screens of the SAP CRM 7.0 system.

Figure A.1.21.: CD Service Order in SAP CRM

a.1.4 Service Order Management UI Elements service order header elements Service Order Header Element 1 (see A.1.28) was identiﬁed on screens:

• CD Service Order • FSL Service Order • ISA: Service Order • Lj Service Order • Order Quot MorePriAc

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 146

creMe FSL S#NV/ce Order

f.F:I r.:.:; l:tusme;s Ja'tn :r lockpr: I: us ess -.. rsacton fi]

I Fo:;- Er trv II r·e~r Jetol5 II Tr.~nmtor J>t.i I S9Mce J·oc9ss I "' '"""'()(d.. l St>tus l f'J ~F" . U}UF.elem Item; I 'urtherSt.rt:Jses - 1~ I Descnot~n L I

RP.fP.ril! n:-P. I Gol:l-T·> Part( .c::==J =-ri:>ri:y INcdum ·I ~P.I"VICP. F riphyP.P. firnu p .c::==J .·;n~Q('I')' _B,·cril L~ ·] 81>To i>.lrty r==J =x:.~.Et&ra n ce No. I I Clrdovee fiE~porSble ~ do-c::~ n:>t cKi.~t reference Date I I 1~.. ~ t Cor1p11~nr i J II• I ==i!JhjP. rt I ·I Procl.ct 10 ~ ~blc m Dcscn~t~l§!ilbh • ~[m R~Lt~l~ Slcr. TH 12..10.2011 OO:OC - utldy's Odlt: Ill RecLested End SO 10.10.ZOll OO:OC Start -t 3 Dav.s ill - I ~~ nn e~ ~'~ fr:>m ~ . II I

ltP.m lAnk I Proccct I Item l~u TJbe r QH1i liV I D rrP. m DtFonry .D De.mi~tion I I l i f~Open . 11 rurthe· ~:u'" · I~~EJ

Figure A.1.22.: FSL Service Order in SAP CRM

, Create I£4: Service Order

~ Ci7 Ru~lll-'...... Ptlrl rrH l.:t:

-1 j

Re""er~n ca t\lllrl-Tu PArl f ~ J: riuril ) ~i..rl ~ 1 :;eri ce Jnpbyee CroLp c====J CcteQort j\o.:rcu!: ~ ~I>TO ,.,.,. I I E).t.~fe ·e n :e IJ::>. [r------;1 3"np ayee fi.e~~:on sibe J!i~i_nQc~, :10t exi:~t Eeference· Cate -""• 1 t olrpc·n• n:I u II u ~ UbJHt P·ud 1: , m

P ud 1: 1 ll!-!ll tlll"llllf!l Qct c·n lfUOpe1 •lrl~ ~~~-,,

Figure A.1.23.: ISA Service Order in SAP CRM

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 147

Figure A.1.24.: Online Pricing in SAP CRM

Figure A.1.25.: Order Quotation MorePriAc in SAP CRM

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 148

Crtlilte SetVice Order

~usrm V>rt1a" tc-ckp• !Ju

-ast C1ay II !ten Oct: it; II r.m:n::ti01 Ootu I S~rvicc rroccx SHin! iJrdP.T I Sbtus Furcher st>tms .J[@J ~ I

_:jO'il:! 1 ~1cdi.Jm ·I I OtP.OO~ [Td::!JJO!lt!Lcll ·I =.xt.Rd

Produ:t J!em ~~um~~r I r.'lld lily nHuC...!lr!_r rv Ui SC1non I

Figure A.1.26.: Service Order MorePr in SAP CRM

Crellte Ptldulge Quotation

I .hst E1tr> I lte"Tl C

£'rimity ~t(_!;,Or')'__ ~·~~·~·"~J~'===== f)L~H(I-! fWI P. f'lo.

Rctcr::lncc ~~ Subjt!tl

Problem o ..criot L · I [ nolish :l~llifl QuJtitiJn •nld Frxn n- 13. lJ.2011 T•)(:ldy'S Jclti' El .. I I I QU:>tltl:>n •;,-~ -. FR n.o.c._:tc ~ ·5n't + RJntn:! e

• • ~ "'I ~ '------'

P·odu:t :ttemtlumter c==J t.,!uarttty .Item l'Lte~ory I I I Oes:·b:on [;ii"I~ Pre-em -IJ Futh" Ston:Js>; .JeiJII /-OJ[~

Figure A.1.27.: Package Quotation in SAP CRM

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 149

• Order Quot NotActPro • Order Quot OnePriAct • Order Quot. Amt all • Order Quotation • Package Quotation • Service ICSS • Service IC • Service Order • Service Order for WE 800002626 • Service Order MorePr 800002626 • Service Order NoActP 800002626 • Service Order OnePri 800002626 • Teleservice • Teleservice Test 8000026266 • XService Order 8000026267

Figure A.1.28.: Service Order Header Element 1

Service Order Header Element 2 (seeA. 1.29) is part of screens:

• Online Pricing • Parking Permit • Parking Permit w.DS • ParkPerm: ThirdParty • Web Request

Service Order Header Element 3 (seeA. 1.30) can be found on screens:

• Order Template

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 150

Figure A.1.29.: Service Order Header Element 2

Figure A.1.30.: Service Order Header Element 3

• RFC Template

The following screens contain Service Order Header Element 4 (seeA. 1.31):

• Park.Permit w/o Item • Web Requst w/o Item

Figure A.1.31.: Service Order Header Element 4

Service Order Header Element 5 (seeA. 1.32) belongs to screen:

• Request for Change

Figure A.1.32.: Service Order Header Element 5

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 151 service order business partner elements Service Order Business Partner Element 1 (seeA. 1.33) was identiﬁed on screens:

• FSL Service Order • ISA: Service Order • Lj Service Order • Order Quot MorePriAc • Order Quot NoActPro • Order Quot OnePriAct • Order Quot. Amt all • Order Quotation • Package Quotation • Service Order • Service Order for WE 800026262 • Service Order MorePr 800026263 • Service Order NoActP 800026264 • Service Order OnePri 800026265 • Teleservice • Teleservice Test 800026266 • XService Order 800026267

Figure A.1.33.: Service Order Business Partner Element 1

Service Order Business Partner Element 2 (seeA. 1.34) is part of screens:

• Online Pricing • Parking Permit • Parking Permit w.DS

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 152

• ParkPerm Third Party • Web Request

Figure A.1.34.: Service Order Business Partner Element 2

Service Order Business Partner Element 3 (seeA. 1.35) belongs to screen:

• Order Template

Figure A.1.35.: Service Order Business Partner Element 3

Service Order Business Partner Element 4 (seeA. 1.36) can be found on screens:

• Park.Permit w/o Item • PWeb Request w/o Item

Figure A.1.36.: Service Order Business Partner Element 4

The following screens contain Service Order Business Partner Element 5 (see A.1.37)

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 153

Figure A.1.37.: Service Order Business Partner Element 5

• Request for Change • RFC Template

Service Order Business Partner Element 6 (seeA. 1.38) was identiﬁed on screen:

• Service ICSS

Figure A.1.38.: Service Order Business Partner Element 6

Service Order Business Partner Element 7 (seeA. 1.39) is part of screen:

• Service IC

Figure A.1.39.: Service Order Business Partner Element 7

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 154 service order ibase section All service order screens investigated contain Service Order IBase Section 1 (seeA. 1.40):

• CD Service Order • FSL Service Order • ISA: Service Order • Lj Service Order • Online Pricing • Order Quot MorePriAc • Order Quot NoActPro • Order Quot OnePriAct • Order Quot. Amt all • Order Quotation • Order Template • Package Quotation • Park.Permit w/o Item • Parking Permit • Parking Permit w.DS • ParkPerm: Third Party • Request for Change • RFC Template • Service ICSS • Service IC • Service Order • Service Order for WE 800026262 • Service Order MorePr 800026263 • Service Order NoActP 800026264 • Service Order OnePri 800026265 • Teleservice • Teleservice Test 800026266

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 155

• Web Request • Web Requst w/o Item • XService Order 800026267

Figure A.1.40.: Service Order IBase Section 1 service order date section Service Order Date Section 1 (seeA. 1.41) was detected on screens:

• CD Service Order • FSL Service Order • Lj Service Order • Online Pricing • Park Permit w/o Item • Parking Permit • Parking Permit w.DS • ParkPerm: Third Party • Service -ICSS • Service Order • Service Order for WE 800002626 • Service Order MorePr 800002626 • Service Order NoActP 800002626 • Service Order OnePri 800002626 • Web Request w/o Item • XService Order 8000026267

We could derive Service Order Date Section 2 (seeA. 1.42) from the following screens:

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 156

1W 13.10-lGII 00:00 SO 16.10-lGII 00:00

Figure A.1.41.: Service Order Date Section 1

• Order Quot MorePriAc • Order Quot NotActPro • Order Quot OnePriAct • Order Quot. Amt all • Order Quotation • Package Quotation

TIII~IO.l:OII Tod>(S 0>11 il Rlll.04.2Gl2 Quobotl>n Start .. Aw~mt II • • • •

Figure A.1.42.: Service Order Date Section 1

Service Order Date Section 3 (seeA.1.43) is part of screens:

• Order Template • ORFC Template

Void Fol>m 1W 13.1~011 Todfl"s Doll II Yald To $41).10.2012 SIWOOOI II

Figure A.1.43.: Service Order Date Section 3

Service Order Date Section 4 (seeA.1.44) can be found on screens:

• Request for Change • Service IC

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 157

Figure A.1.44.: Service Order Date Section 4

• Teleservice • Teleservice Test 8000026266

No Date Section could be found on screen:

• ISA: Service Order service order header priority section Service Order Priority Sec- tion 1 (seeA. 1.45) was identiﬁed on screens:

• CD Service Order • Lj Service Order • Service Order • Service Order for WE 800002626 • Service Order MorePr 800002626 • Service Order NoActP 800002626 • Service Order OnePri 800002626 • XService Order 8000026267

Figure A.1.45.: Service Order Priority Section 1

The following screens contain Service Order Priority Section 2 (seeA. 1.46):

• FSL Service Order

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 158

• ISA: Service Order • Online Pricing • Park.Permit w/o Item • Parking Permit • Parking Permit w.DS • ParkPerm: Third Party • Web Request • Web Requst w/o Item

Figure A.1.46.: Service Order Priority Section 2

Service Order Priority Section 3 (seeA. 1.47) is part of screens:

• Order Quot MorePriAc • Order Quot NoActPro • Order Quot OnePriAct • Order Quot. Amt all • Order Quotation • Order Template • Package Quotation • Service -ICSS

Service Order Priority Section 4 (seeA. 1.48) can be detected on screens:

• Request for Change • RFC Template

Service Order Priority Section 5 (seeA. 1.49) was identiﬁed on screens:

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 159

""""tv Qo:ogory ect.w.. .- No. R!(O<..,COI»tt S..bl«t

Figure A.1.47.: Service Order Priority Section 3

Pnorty ~ • !!>t.IWifenct 110. Referonc;e~ SubtKI

Figure A.1.48.: Service Order Priority Section 4

• Service IC • Teleservice • Teleservice Test 8000026266

Pnorty Qtogory Ellt.Rtftrtntt Sul!lttt •

Figure A.1.49.: Service Order Priority Section 5

service order problem section The following screens contain Service Order Problem Section 1 (seeA.1.50):

• CD Service Order • FSL Service Order • Lj Service Order • Online Pricing

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 160

• Order Quot MorePriAc • Order Quot NoActPro • Order Quot OnePriAct • Order Quot. Amt all • Order Quotation • Order Template • Package Quotation • Park.Permit w/o Item • Parking Permit • Parking Permit w.DS • ParkPerm: Third Party • RFC Template • Service -ICSS • Service IC • Service Order • Service Order for WE 800002626 • Service Order MorePr 800002626 • Service Order NoActP 800002626 • Service Order OnePri 800002626 • Teleservice • Teleservice Test 8000026266 • Web Request • Web Requst w/o Item • XService Order 8000026267

Service Order Problem Section 2 (seeA. 1.51) belongs to screen:

• ISA: Service Order

Service Order Problem Section 3 (seeA. 1.52) was identiﬁed on screen:

• Request for Change

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 161

Figure A.1.50.: Service Order Problem Section 1

Figure A.1.51.: Service Order Problem Section 2

Figure A.1.52.: Service Order Problem Section 3

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 162 service order item section Service Order Item Section 1 (seeA. 1.53) was detected on screens:

• CD Service Order • FSL Service Order • ISA: Service Order • Lj Service Order • Order Quot MorePriAc • Order Quot NotActPro • Order Quot OnePriAct • Order Quot. Amt all • Order Quotation • Order Template • Package Quotation • Request Template • RFC Template • Service -ICSS • Service IC • Service Order • Service Order for WE 800026262 • Service Order MorePr 800026263 • Service Order NoActP 800026264 • Service Order OnePri 800026265 • Teleservice • Teleservice Test 800026266 • XService Order 800026267

We could derive Service Order Item Section 2 (seeA. 1.54) from the following screens:

• Online Pricing • Park.Permit w/o Item

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 163

Figure A.1.53.: Service Order Item Section 1

• Parking Permit • Park.Perm: Third Party

Figure A.1.54.: Service Order Item Section 2

Service Order Item Section 3 (seeA. 1.55) is part of screen:

• Parking Permit w.DS

Figure A.1.55.: Service Order Item Section 3

Service Order Item Section 4 (seeA. 1.56) belongs to screens:

• Web Request • Web Request w/o Item

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 164

Figure A.1.56.: Service Order Item Section 4 a.1.5 Contract Management UIs

In the following, we show several examples of Contract Management UIs that were part of our analysis. Due to space restrictions, we decided not to show the entire list of screens. Overall, we investigated 16 different Contract Management screens of the SAP CRM 7.0 system.

Figure A.1.57.: ECC Quantity Contract in SAP CRM

a.1.6 Contract Management UI Elements contract header elements Service Contract Header Element 1 (see A.1.63) was identiﬁed on screens:

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 165

I er-te ECC v~lu• Contrilct

LITI ~ Ru U\1>.;.: PilrtnPr .:'ntknt- R ~lf'lo'> • ~ ~ [CQ] ~ IB~ .§1 FPJf?l~ru~

;:;xr.Tr.tii V;:krF! o,oo ~ Status !P}Re!e1se lterru 1 ~1 Furth~r Sta:uses .. 1~ Sold-To P~rty Sh[t-To PartY b~' ,------, ~~ ext. Reference ~ 1.eference Date 1 t

~ Jate - ype rrom D;,te Rt..le Ourat Unt ::ontrcct Gtart Date Tlll3.1C.2011 OC:OO T:tday'' Date Ill Ill Cuullcl-l Ew.l O.A~ SA 13.10.2012 00;0(• Sldrl O

(Q]~~@J [§)~[OO)]ID(!Q I @E]oo:;) I ~ .!!£ Item No. ProdJCt Descripton Prod Let Ranoe Product :ateoorv Taroet vale CuT.. .

Figure A.1.58.: ECC Value Contract in SAP CRM

er-te Qu~ntity Contr~ct

.---~ Exp.Totil Valle ~----o:oo~ further StatuO!s : 1~ Sold-To Party Ship-To Party ;~ EXt. Reference RefErence Date ~

~ -ype =rom Date Rule Duot Unit I ~~~rcct Start Date rH 13.10.2011 00:00 Today's Date LJntrcct t:nd uate -:,A iJ.lU.'LUll uu:uu ~mt LJate - val. 1-1erod ~

[QJ~~@J I (§J(!]UDJ~ C'!GJ ~~ I ~ @!• Item No. 1-lro-juct uescnptJon target Quantlt)' Ia keleased Qty txp. total vaue :..:urr. 1-'!oduct Kiln

Figure A.1.59.: Quantity Contract in SAP CRM

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 166

CrNte Ship&Debit Contract

IIJ Ia: Susness Fartner CocKpit

51 ~&Debit. CuulrcLl Status

Scld-T~ Par:v

~.Reference

Dates

o~t@ Type «on To O;a:tl! Rule Dur.t Unt Conine': SOrt Date Contr.lc: End D01tc Hart DJtc 1 V

[QJ~~rn) l ~~~(OOJ ~ , ~~I [)Zj i! It2m No. Product Desatltion Prock.ct R.lrge JrOOuct categoy Tar~ et vaue Curr. ..

Figure A.1.60.: Ship and Debit Contract in SAP CRM

Creilte Sulncr. - Loose.Pub.

ITI ~ Busnass Partner Cockpit ~<,~_, e

Purchase Order Dlta ~ 1(!][9]

\'-- ---.~

Status Sold-To Pal't)l !;hip-TO Party Ext. Reference Reference Dc.te

~ Dates Date Type Pom Date Rule Contr.~ct Sg1: D;;~tc 13.10.2011 Tod.:t/ !; D;;~tc ~

Contract Enc Date 31.12.9999 31.12.9999 ~

[QJ~~ITQJ I :§J~[OOJ (OO] f.'im I ~~I ~ ~ Item No. Product Descrl;)tion Product Range Pr:xluct category Target valle curr...

• • ••

Figure A.1.61.: Subscr.-Loose.Pub in SAP CRM

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 167

Create Individu.l Contn.ct

P~yrmmt Fl)rrr

1 Exp.TotaiVale o,oo fl\Jil>ER,~Ie~,.~.~lte'e~ms~l ~l Further ;trt;us?~ .. j~ CuntJ

Tcrget Qua1tity Ta Released Qt-, Cxj:. Total VakJe Curr. . 'ro~uct 1'0n

'. '.

Figure A.1.62.: Individual Contract in SAP CRM

• Contract (Value / Qty) • Contract Quotation • Ctr. Quot. (Val / Qty) • Service Cont MorPriA • Service Cont NoActPr • Service Cont NoPriA • Service Contract • Service Contract ISU • Srv. Ctr. Template • UBB Service Contract • UBB Service Quot.

Contract Header Element 1 (seeA.1.64) was detected on screens:

• Customer Contract • Group Contract

Contract Header Element 2 (seeA.1.65) is part of screens:

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 168

Figure A.1.63.: Service Contract Header Element 1

Figure A.1.64.: Contract Header Element 1

• ECC Quantify Contrct • ECC Value Contrct • Mat.Rel. Value Cont. • Qlty Contract MorePr • Qlty Contract NoActP • Qlty Contract OnePri • Qnty / Val. Contr:Conf. • Quantity Contract • Quantity / Value Cont. • QuantityContract-NAV • Subcr. -Loose.Pub. • Value Contract Contract Header Element 3 (seeA. 1.66) can be found on screen: • Individual Contract Contract Header Element 4 (seeA. 1.67) was identiﬁed on screen: • Ship & Debit Contract

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 169

Figure A.1.65.: Contract Header Element 2

Figure A.1.66.: Contract Header Element 3 contract date sections Service Contract Date Section 1 (seeA. 1.68) is part of screens:

• Contract (Value / Qty) • Contract Quotation • Ctr. Quot. (Val / Qty) • Service Cont MorPriA • Service Cont NoActPr • Service Cont NoPriA • Service Contract • Srv. Ctr. Template

Figure A.1.67.: Contract Header Element 4

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 170

Dates

DiltQTyP'! From D~te RIMe Contr.lct St

Figure A.1.68.: Service Contract Date Section Element 1

Service Contract Date Section 2 (seeA.1.69) was identiﬁed on screen:

• Service QuotationISU

O;ates Date Type From Date Rule l Controct Stllft Dato TH 13.10.2011 Calculrte CONTSTART Date from ISORQCON • < • < • J

Figure A.1.69.: Service Contract Date Section Element 2

Service Contract Date Section 3 (seeA.1.70) can be found on screen:

• UBB Service Contract

Dates

Date Type From Date Rule Durat Un~ COmplttJon :11 :11 Reorganization :il :il

Figure A.1.70.: Service Contract Date Section Element 3

We derived Contract Date Section 1 (seeA.1.71) from the following screens:

• Custom Contract • Group Contract • Individual Contract

Contract Date Section 2 (see A.1.72) was identiﬁed on screens:

• ECC Quantity Contrct

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 171

Figure A.1.71.: Contract Date Section Element 1

• ECC Value Contrct • Mat.Rel. Value Cont. • Qlty Contract MorePr • Qlty Contract NoActP • Qlty Contract OnePri • Qnty / Val.Contr:Conf. • Quantity Contract • Quantity / Value Cont. • QuantityContract-NAV • Ship&Debit Contract • Value Contract

Figure A.1.72.: Contract Date Section Element 2

Contract Date Section 3 (seeA. 1.73) can be detected on screen:

• Subcr. -Loose.Pub.

Figure A.1.73.: Contract Date Section Element 3

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 172 contract item list elements Service Contract Item Section 1 (seeA.1.74) is part of screen:

• Contract (Value / Qty)

!;a Item No. Product SUn Itt

Figure A.1.74.: Service Contract Item Section Element 1

Service Contract Item Section 2 (seeA.1.75) belongs to screens:

• Contract Quotation • Ctr. Quot. (Val / Qty) • Service Cont MorPriA • Service Cont NoActPr • Service Cont OnePriA • Service Contract • Service Contract ISU • Service Quotation ISU • Srv. Ctr. Template

12 Item No. Product Quantity sun DescriPtiOn

Figure A.1.75.: Service Contract Item Section Element 2

Service Contract Item Section 3 (seeA.1.76) was identiﬁed on screens:

• UBB Service Contract • UBB Service Quot.

Contract Item Section 1 (see A.1.77) was detected on screens:

• Custom Contract

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 173

Figure A.1.76.: Service Contract Item Section Element 3

• Group Contract • Individual Contract • Quantity Contract

Figure A.1.77.: Contract Item Section Element 1

Contract Item Section 2 (seeA. 1.78) was identiﬁed on screens:

• ECC Quantity Contract • ECC Value Contract • Mat. Rel. Value Cont. • Qlty Contract MorePr • Qlty Contract NoActP • Qlty Contract OnePri • Quantity / Value Cont. • QuantityContract-NAV • Ship&Debit Contract • Subscr. -Loose.Pub.

Figure A.1.78.: Contract Item Section Element 2

Contract Item Section 3 (seeA. 1.79) is part of screen:

[ Context-aware UI Component Reuse for Web Service Development Environments ] A.1 examples for sap crm uis and ui elements 174

Figure A.1.79.: Contract Item Section Element 3

• Qnty / Val.Contr:Conf.

Contract Item Section 4 (seeA. 1.80) belongs to screen:

• Value Contract

Figure A.1.80.: Contract Item Section Element 4

a.1.7 Examples of CRM UIs and UI Elements - Discussion

The analysis and dissection of real-life SAP CRM UIs showed that many common, coarse-grained UI components could be detected on the CRM UI screens. This indicates a high potential for the reuse of UI components. As the SAP CRM system is based on best practises for common business processes, similar UIs and UI elements are likely to be found in comparable business software.

[ Context-aware UI Component Reuse for Web Service Development Environments ] BIBLIOGRAPHY

[1] C. Alexander. A pattern language towns buildings constructions. 1977.

[2] Jason Ankeny. Alcatel-lucent acquires api repository programmableweb, 29/06/ 2010. http://www.fiercemobileit.com/story/alcatel-lucent- acquires-api-repository-programmableweb/2010-06-29, accessed: 23/09/2014.

[3] Apigee. Api services, 2014. http://apigee.com/about/products/apis- and-edge, accessed: 23/09/2014.

[4] Udo Arend. User interface patterns - components for user interface, 19/11/ 2004. http://www.sapdesignguild.org/editions/edition8/ patterns.asp, accessed: 15/09/2014.

[5] Djamal Benslimane, Schahram Dustdar, and Amit Sheth. Services mashups: The new generation of web applications. IEEE Internet Com- puting, 12:13–15, 2008.

[6] Inc. Beyond Labs. pttrns, 2010-2014. http://www.pttrns.com/, accessed: 14/12/2014.

[7] Jan O. Borchers. A pattern approach to interaction design. In Designing Interactive Systems, pages 369–378, 2000. doi: 10.1145/347642.347795.

[8] Frank Buschmann, Kevlin Henney, and Douglas C. Schmidt. Pattern- oriented software architecture. 2007.

[9] Thomas Butter, Markus Aleksy, Philipp Bostan, and Martin Schader. Context-aware user interface framework for mobile applications. Dis- tributed Computing Systems Workshops, International Conference on, 0:39, 2007. ISSN 1545-0678. doi: http://doi.ieeecomputersociety.org/10.1109/ ICDCSW.2007.31.

[10] byteMyCode. byteMyCode, 1998-2014. http://www.bytemycode.com/, accessed: 03/12/2014.

175

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 176

[11] Erin Malone Christian Crumlish. Designing social interfaces, 2014. http://www.designingsocialinterfaces.com/patterns/Main_Page, accessed: 13/12/2014.

[12] Eric S. Chung, Jason I. Hong, James Lin, Madhu K. Prabaker, James A. Landay, and Alan L. Liu. Development and evaluation of emerging design patterns for ubiquitous computing. In Designing Interactive Systems, pages 233–242, 2004. doi: 10.1145/1013115.1013148.

[13] CodePlex. Mobile device browser ﬁle, 19/08/ 2011. http://mdbf. codeplex.com/, accessed: 15/09/2014.

[14] P. Compton, L. Peters, G. Edwards, and T.G. Lavers. Experience with Ripple-Down Rules. Knowledge-Based System Journal, 19(5):pp. 356–362, 2006.

[15] Eppleton IT Consulting. Dukescript, 2014. http://dukescript.com/, accessed: 29/10/2014.

[16] Rylan Cottrell, Robert J. Walker, and Jörg Denzinger. Semi-automating small-scale source code reuse via structural correspondence. In Proceed- ings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering, SIGSOFT ’08/FSE-16, pages 214–225, New York, NY, USA, 2008. ACM. ISBN 978-1-59593-995-1. doi: 10.1145/1453101.1453130. URL http://doi.acm.org/10.1145/1453101.1453130.

[17] Nathan Curtis. Components versus patterns, 09/01/ 2009. http://www. uie.com/articles/components_vs_patterns/, accessed: 06/11/2014.

[18] Keith Dawson. Spolsky’s softwaso q-and-a site, 16/09/ 2008. http://developers.slashdot.org/story/08/09/16/1910214/spolskys- software-q-and-a-site, accessed: 09/11/2014.

[19] UNITiD Interaction Designers. Android patterns, 2014. http:// androidpatterns.com/, accessed: 13/12/2014.

[20] Detectright. Device detectdet made easy, 2011. http://www.detectright. com/, accessed: 11/10/2014.

[21] DeviceAtlas. DeviceAtlas, 23/06/ 2014. https://deviceatlas.com/, accessed: 11/10/2014.

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 177

[22] Black Duck. Open HUB, 2014. http://code.openhub.net/, accessed: 03/12/2014.

[23] Eclipse. Web services overview, 2000, 2007. http://help.eclipse.org/ luna/index.jsp?topic=%2Forg.eclipse.jst.ws.doc.user%2Fconcepts% 2Fcws.html, accessed: 28/09/2014.

[24] Experts Exchange. Experts exchange - the network for technology profes- sionals, 2014. http://www.experts-exchange.com/, accessed: 03/12/2014.

[25] Stack Exchange. Technology, 2014. http://stackexchange.com/sites# technology, accessed: 10/11/2014.

[26] Stack Exchange. Stack exchange, 2014. http://cs.stackexchange.com, accessed: 03/12/2014.

[27] Stack Exchange. Stack overﬂow, 2014. http://stackoverflow.com, accessed: 03/12/2014.

[28] FedEx. FedEx web services, 1995-2014. http://www.fedex.com/ca_ english/businesstools/webservices/?, accessed: 23/09/2014.

[29] Marius Feldmann, Gerald Hubsch, Thomas Springer, and Alexander Schill. Improving task-driven software development approaches for creating service-based interactive applications by using annotated web services. In Proceedings of the 2009 Fifth International Conference on Next Generation Web Services Practices, NWESP ’09, pages 94–97, Washington, DC, USA, 2009. IEEE Computer Society. ISBN 978-0-7695-3821-1. doi: http://dx.doi.org/10.1109/NWeSP.2009.19. URL http://dx.doi.org/10. 1109/NWeSP.2009.19.

[30] William B. Frakes and Kyo Kang. Software reuse research: Status and future. IEEE Transactions on Software Engineering, 31:529–536, 2005. ISSN 0098-5589. doi: http://doi.ieeecomputersociety.org/10.1109/TSE.2005.85.

[31] Diana Frurip. lovely ui - a collection of mobile UI elements, 2014. http: //www.lovelyui.com/, accessed: 13/12/2014.

[32] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. De- sign patterns: elements of reusable object-oriented software. Pearson Education, 1994.

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 178

[33] Garnter. Hype cycle for context-aware computing. Technical report, Gart- ner, 23/07/ 2009.

[34] T. Glover and J. Davies. Integrating device independence and user pro- ﬁles on the web. BT Technology Journal, 23:239–248, 2005. ISSN 1358-3948. URL http://dx.doi.org/10.1007/s10550-005-0045-y. 10.1007/s10550- 005-0045-y.

[35] Google. Google code, 2014. code.google.com/, accessed: 03/12/2014.

[36] Aragon Consulting Group. Krugle, 2014. http://www.krugle.com/, accessed 03/12/2014.

[37] Network Working Group. Hypertext transfer protocol - HTTP 1.1, June 1999. http://www.ietf.org/rfc/rfc2616.txt, accessed: 15/09/2014.

[38] Patrick De Guzman. Cross platform & context web services. Master’s thesis, UNSW, 2013.

[39] Clayton Hamshar. Build html5 and javascript applications with dukescript, 02/10/ 2014. http://www.html5report.com/topics/html5/articles/ 390405-build-html5-javascript-applications-with-dukescript.htm, accessed: 04/11/2014.

[40] Anas Hariri, Dimitri Tabary, Sophie Lepreux, and Christophe Kolski. Con- text aware business adaptation toward user interface adaptation. Commu- nications of SIWN, 3:46–52, 2008.

[41] Scott Henninger. Supporting the construction and evolution of component repositories. In Proceedings of the 18th international conference on Software engineering, ICSE ’96, pages 279–288, Washington, DC, USA, 1996. IEEE Com- puter Society. ISBN 0-8186-7246-3. URL http://dl.acm.org/citation. cfm?id=227726.227776.

[42] Volker Hoyer, Till Janner, Christoph Schroth, Ivan Delchev, and Florian Urmetzer. FAST platform: A concept for user-centric, enterprise class mashups, 25/03/ 2009.

[43] IBM. IBM websphere help systems: Web services overview, 2000, 2005. http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index. jsp?topic=\%2Fcom.ibm.etools.webservice.doc\%2Fconcepts\%2Fcws. html, accessed: 15/09/2014.

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 179

[44] IBM. IBM websphere help systems: SO, 2000, 2005. http: //publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp? topic=%2Fcom.ibm.etools.webservice.doc%2Fconcepts%2Fcws.html, accessed: 15/09/2014.

[45] IBM. IBM websphere help systems: WSDL, 2000, 2005. http: //publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp? topic=%2Fcom.ibm.etools.webservice.doc%2Fconcepts%2Fcws.html, accessed: 15/09/2014.

[46] Infragistics. Quince, 2014. http://quince.infragistics.com/html/ AllPatterns.aspx, accessed: 14/12/2014.

[47] P. Izquierdo, J. Janeiro, G. Hubsch, T. Springer, and A. Schill. An annotation tool for enhancing the user interface generation process for services. In Microwave Telecommunication Technology, 2009. CriMiCo 2009. 19th Inter- national Crimean Conference, pages 372 –374, sept. 2009.

[48] Cory Janssen. Enterprent services, 2010-2014. http://www.techopedia. com/definition/25404/enterprise-services, accessed: 23/09/2014.

[49] JSON. Introducing json, 2013. http://json.org/, accessed: 22/09/2014.

[50] Daisuke Kamisaka, Shigeki Muarmatsu, and Hiroyuki Yokoyama. Oper- ation prediction for context-aware user interfaces of mobile phones. In Ninth Annual International Symposium on Applications and the Internet, pages 16–22. Ieee, 2009. ISBN 9781424447763.

[51] Dave Kerr. Wpf step by step: Getting started with wpf and expression blend, 20/08/ 2010. http://www.codeproject.com/Articles/99330/WPF- Step-by-Step-Getting-Started-with-WPF-and-Expr, accessed: 15/09/2014.

[52] Kerstin Klemisch, Ingo Weber, and Boualem Benatallah. Context-aware UI component reuse. In CAISE’13: International Conference on Advance Informa- tion Systems Engineering, 2013.

[53] Andre N. Klingsheim. UAPROF.com, 01/08/ 2010. http://www.uaprof. com/, accessed: 20/09/2010.

[54] S.A. Laakso. User interface design patterns, 16/09/ 2003. http://www.cs. helsinki.fi/u/salaakso/patterns/index.html, accessed: 15/09/2014.

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 180

[55] J. Lammi. UI pattern factory, 2009-2014. http://uipatternfactory.com, accessed: 15/09/2014.

[56] Tobias Lange. Dynamic Service Integration for Applications on heterogeneous Mobile Devices. Master thesis, TU Dresden, 2009.

[57] Otávio Augusto Lazzarini Lemos, Sushil Krishna Bajracharya, Joel Os- sher, Ricardo Santos Morla, Paulo Cesar Masiero, Pierre Baldi, and Cristina Videira Lopes. Codegenie: using test-cases to search and reuse source code. In Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering, ASE ’07, pages 525–526, New York, NY, USA, 2007. ACM. ISBN 978-1-59593-882-4. doi: 10.1145/1321631. 1321726. URL http://doi.acm.org/10.1145/1321631.1321726.

[58] Wrap Market LLC. Wrap bootstrap, 2014. wrapbootstrap.com, accessed: 03/12/2014.

[59] Steve Kamerman Luca Passani. WURFL, 2014. http://wurfl. sourceforge.net/, accessed: 15/09/2014.

[60] Alcatel Lucent. Lifecycle, 2014. , accessed: 24/09/2014.

[61] Francisco J. Martinez-Ruiz, Jean Vanderdonckt, and Jaime Munoz Arteaga. Context-aware generation of user interface containers for mobile devices, 2008.

[62] Mashery. Intel mashery api management, api gateways, services, 2014. http://www.mashery.com/, accessed: 23/09/2014.

[63] Neil McAllister. Mobile UIs: It’s developers vs. users, 19/01/ 2012. http://www.infoworld.com/d/application-development/mobile- uis-its-developers-vs-users-184472, accessed: 15/09/2014.

[64] Matthew McDermott. Debugging design time data in visual studio and expression blend, 11/02/ 2011. http://www.ableblue.com/blog/ archive/2011/02/11/debugging-design-time-data-in-visual-studio- and-expression-blend/, accessed: 14/09/2014.

[65] Collin McMillan. Searching, selecting, and synthesizing source code. In Proceedings of the 33rd International Conference on Software Engineering, ICSE ’11, pages 1124–1125, New York, NY, USA, 2011. ACM. ISBN 978-1-4503- 0445-0. doi: 10.1145/1985793.1986013. URL http://doi.acm.org/10.1145/ 1985793.1986013.

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 181

[66] Collin McMillan. Searching, selecting, and synthesizing source code. In ICSE ’11: 33rd International Conference on Software Engineering, 2011. ISBN 978-1-4503-0445-0. doi: 10.1145/1985793.1986013. URL http://doi.acm. org/10.1145/1985793.1986013.

[67] Collin McMillan, Mark Grechanik, Denys Poshyvanyk, Chen Fu, and Qing Xie. Exemplar: A source code search engine for ﬁnding highly relevant applications. IEEE Transactions on Software Engineering, 99(PrePrints), 2011. ISSN 0098-5589. doi: http://doi.ieeecomputersociety.org/10.1109/ TSE.2011.84.

[68] Meta. What experts-exchange think of stack overﬂow. http: //meta.stackexchange.com/questions/92683/what-experts-exchange- thinks-of-stack-overflow, accessed: 09/11/2014.

[69] Microsoft. Getting started with blend for visual studio 2013, 2014. http://msdn.microsoft.com/en-us/library/vstudio/jj171012.aspx, accessed: 14/09/2014.

[70] MobileAware. MobileAware, 29/09/ 2014. http://www.mobileaware.com/, accessed: 11/10/2014.

[71] Theresa Neil. Mobile design pattern gallery: Ui patterns for ios, android and more, 2012. mobiledesignpatterngallery.com, accessed: 13/12/2014.

[72] Theresa Neil. Mobile design pattern gallery, March 2012. www. mobiledesignpatterngallery.com, accessed: 20/09/2014.

[73] Microsoft Developer Network. Httprequest.browser property, 11/10/2014 2014. http://msdn.microsoft.com/en-us/library/system.web. httprequest.browser.aspx, accessed: 11/10/2014.

[74] Yahoo Developer Network. Yahoo design pattern library, 2014. https: //developer.yahoo.com/ypatterns/, accessed:13/12/2014.

[75] Donald A. Norman and Stephen W. Draper. User Centered System Design; New Perspectives on Human-Computer Interaction. L. Erlbaum Associates Inc., Hillsdale, NJ, USA, 1986. ISBN 0898597811.

[76] Interface Design Team of the University of Applied Sciences Potsdam. Interface design patterns, 2008. http://patternbrowser.org/, accessed: 13/12/2014.

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 182

[77] Stack Overﬂow. Questions, 2014. https://stackoverflow.com/questions, accessed: 09/11/2014.

[78] Stack Overﬂow. What is reputation? how do i earn it and lose it?, 2014. https://stackoverflow.com/help/whats-reputation, accessed: 09/11/2014.

[79] Stack Overﬂow. Users, 2014. https://stackoverflow.com/questions, accessed: 09/11/2014.

[80] Sergey Pakhandrin. Inspired ui - mobile apps design patterns (iPhone), 2011-2013. http://inspired-ui.com/, accessed: 13/12/2014.

[81] Thomas Park. Bootswatch - free themes for bootstrap, 2014. bootswatch. com, accessed: 04/12/2014.

[82] Heiko Paulheim. Ontology-based modularization of user interfaces. In Proceedings of the 1st ACM SIGCHI symposium on Engineering interactive computing systems, EICS ’09, pages 23–28, New York, NY, USA, 2009. ACM. ISBN 978-1-60558-600-7. doi: 10.1145/1570433.1570439. URL http://doi.acm.org/10.1145/1570433.1570439.

[83] Heiko Paulheim and Atila Erdogan. Seamless integration of heterogeneous UI components. In Proceedings of the 2nd ACM SIGCHI symposium on Engineering interactive computing systems, EICS ’10, pages 303–308, New York, NY, USA, 2010. ACM. ISBN 978-1-4503-0083-4. doi: 10.1145/1822018. 1822067. URL http://doi.acm.org/10.1145/1822018.1822067.

[84] Sunilkumar Peenikal. Mashups and the enterprise, 2009. http: //www.mphasis.com/pdfs/Mashups_and_the_Enterprise.pdf, accessed: 05/08/2012.

[85] Sarah Perez. iTunes App Store Now Has 1.2 Million Apps, Has Seen 75 Billion Downloads To Date, 02/06/ 2014. http: //techcrunch.com/2014/06/02/itunes-app-store-now-has-1-2- million-apps-has-seen-75-billion-downloads-to-date/, accessed: 28/09/2014.

[86] Stefan Pietschmann, Martin Voigt, Andreas Rümpel, and Klaus Meißner. CRUISe: Composition of rich user interface services. In ICWE’09: Intl. Conf. Web Engineering, volume Vol. 5648/2009, pages pp. 473–476. Springer Berlin / Heidelberg, 2009.

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 183

[87] Steven P. Reiss. Semantics-based code search. In ICSE ’09: 31st Interna- tional Conference on Software Engineering, 2009. ISBN 978-1-4244-3453-4. doi: 10.1109/ICSE.2009.5070525. URL http://dx.doi.org/10.1109/ICSE.2009. 5070525.

[88] Steven P. Reiss. Semantics-based code search. In Proceedings of the 31st Inter- national Conference on Software Engineering, ICSE ’09, pages 243–253, Wash- ington, DC, USA, 2009. IEEE Computer Society. ISBN 978-1-4244-3453-4. doi: 10.1109/ICSE.2009.5070525. URL http://dx.doi.org/10.1109/ICSE. 2009.5070525.

[89] Debbie Richards. Two decades of ripple down rules research. The Knowl- edge Engineering Review, 24:159–184, 2009.

[90] Alex Rodriguez. RESTful web services: The basics, 06/11/ 2008. http: //www.ibm.com/developerworks/webservices/library/ws-restful/, accessed: 14/09/2014.

[91] SAP. User interface styleguide: SAP business byDesign, 2012. http://www. sapdesignguild.org/resources/ByD_UI_Styleguide_2012_FP35.pdf, accessed: 20/09/2014.

[92] Ritu Saxena. 10 opensource HTML5 mobile app development framework, 16/01/ 2013. http://www.toolsjournal.com/mobile-articles/ item/1189-10-opensource-html5-mobile-app-development-frameworks, accessed: 21/09/2014.

[93] Christian Schormann. Expression blend for html, 13/09/ 2011. http:// electricbeach.org/?p=966, accessed: 14/09/2014.

[94] ServFace. Service annotations for user interface composition, 2010. http: //www.servface.org/, accessed: 18/12/2010.

[95] Mari Sheibley. Mobile patterns, 2013. http://www.mobile-patterns.com/, accessed: 13/12/2014.

[96] Feng shihong, Wan Jiancheng, Hou Jinkui, and Li Shunqing. Customiza- tion oriented heuristic user interface design. In Computer-Aided Industrial Design and Conceptual Design, 2006. CAIDCD ’06. 7th International Conference on, pages 1–4, Nov 2006. doi: 10.1109/CAIDCD.2006.329378.

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 184

[97] Josef Spillner, Marius Feldmann, Iris Braun, Thomas Springer, and Alexan- der Schill. Ad-hoc usage of web services with Dynvoker. In Proceedings of the 1st European Conference on Towards a Service-Based Internet, ServiceWave ’08, pages 208–219, Berlin, Heidelberg, 2008. Springer-Verlag. ISBN 978-3- 540-89896-2. doi: http://dx.doi.org/10.1007/978-3-540-89897-9_18. URL http://dx.doi.org/10.1007/978-3-540-89897-9_18.

[98] Josef Spillner, Marius Feldmann, Iris Braun, Thomas Springer, and Alexan- der Schill. Ad-hoc usage of web services with Dynvoker. In ServiceWave ’08, pages 208–219, 2008. ISBN 978-3-540-89896-2. doi: http://dx.doi.org/ 10.1007/978-3-540-89897-9_18. URL http://dx.doi.org/10.1007/978-3- 540-89897-9_18.

[99] J. Spool. The elements of a design pattern, 23/01/ 2006. http://www.uie. com/articles/elements_of_a_design_pattern/, accessed: 14/09/2014.

[100] Sun. Tutorial: Learning swing with the netbeans IDE, 2010. http://java. sun.com/docs/books/tutorial/uiswing/learn/netbeansbasics.html, accessed: 14/09/2014.

[101] The jQuery Foundation. jQuery, 2014. http://jquery.com/, accessed: 14/09/2014.

[102] Jenifer Tidwell. Common ground: a pattern language for human-computer interface design, 1999. http://www.mit.edu/~jtidwell/interaction_ patterns.html, accessed: 16/09/2014.

[103] Jenifer Tidwell. Designing Interfaces: Patterns for Effective Interaction Design. O’Reilly Media, 2005.

[104] TOGAF. Business scenarios, 2001. http://www.opengroup.org/ architecture/togaf7-doc/arch/p4/bus_scen/bus_scen.htm, accessed: 14/09/2014.

[105] Anders Toxboe. UI patterns - user interface design pattern library, 2014. http://ui-patterns.com/, accessed: 16/09/2014.

[106] Jaroslav Tulach. DukeScript, 29/09/ 2014. http://wiki.apidesign.org/ wiki/DukeScript, accessed 29/10/2014.

[107] Twilio. Twilio cloud communications - APIs for voice, VoIP and text messaging, 2012. http://www.twilio.com/, accessed: 12/07/2013.

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 185

[108] Twitter. Bootstrap. sleek, intuitive, and powerful front-end framework for faster and easier web development., 2014. http://getbootstrap.com/2.3. 2/, accessed: 28/10/2014.

[109] M. v. Welie. Patterns in interaction design, 2008. http://www.welie.com/ patterns/, accessed: 14/09/2014.

[110] Martijn van Welie. A pattern library for interaction design, 2008. http: //www.welie.com/, accessed: 14/12/2014.

[111] Costas Vassilakis, George Lepouras, and Constantin Halatsis. A knowledge-based approach for developing multi-channel e-government services. Electronic Commerce Research and Applications, Volume 6(Issue 1): pp. 113–124, Spring 2007.

[112] Petr Vlk. Volantis device database, February 2011. http:// www.volantis.com/files/Volantis_Device_Database_Overview.pdf, accessed: 14/12/2011.

[113]W 3C. Web services architecture, 11/02/ 2004. http://www.w3.org/TR/ws- arch/, accessed: 14/09/2014.

[114]w 3schools.com. Bootstrap 3 tutorial, 1999-2014. http://www.w3schools. com/bootstrap/, accessed: 02/11/2014.

[115] Gerd Waloszek. Introduction to user interface patterns at SAP, 20/11/ 2003. http://www.sapdesignguild.org/community/design/patterns_sap. asp, accessed: 14/09/2014.

[116] Michael Washington. Two ways to call lightswitch from a custom silverlight control, 21/05/ 2011. http://lightswitchhelpwebsite.com/ Blog/tabid/61/EntryId/26/Two-Ways-To-Call-LightSwitch-From-a- Custom-Silverlight-Control.aspx, accessed: 14/09/2014.

[117] Robin Wauters. Antenna acquires mobile internet software company Volantis, 07/02/ 2014. http://techcrunch.com/2011/02/07/antenna- acquires-mobile-internet-software-company-volantis/, accessed: 11/10/2014.

[118] U. A. Wenqian Xu. User interface styleguide for SAP Business ByDesign, 21/01/ 2009. https://wiki.wdf.sap.corp/wiki/display/ UIGuidelinesByD/Design+Principles, accessed: 14/08/2010.

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 186

[119] Wikipedia. XDIME, 13/05/ 2011. http://en.wikipedia.org/wiki/Xdime, accessed: 11/10/2014.

[120] Wikipedia. Application programming interface, 02/09/ 2014. http:// en.wikipedia.org/wiki/Application_programming_interface, accessed: 24/09/2014.

[121] Wikipedia. Application service provider, 07/07/ 2014. http: //en.wikipedia.org/wiki/Application_service_provider, accessed: 23/09/2014.

[122] Wikipedia. Bootstrap (front-end framework), 30/10/ 2014. http: //en.wikipedia.org/wiki/Bootstrap_(front-end_framework), accessed: 01/11/2014.

[123] Wikipedia. Experts-exchange, 29/10/ 2014. http://en.wikipedia.org/ wiki/Experts-Exchange, accessed: 09/11/2014.

[124] Wikipedia. List of platform-independent gui libraries, 16/08/ 2014. http://en.wikipedia.org/wiki/List_of_platform-independent_ GUI_libraries, accessed: 21/09/2014.

[125] Wikipedia. JSON, 20/09/ 2014. http://en.wikipedia.org/wiki/JSON, accessed: 22/09/2014.

[126] Wikipedia. Stack exchange, 07/11/ 2014. http://en.wikipedia.org/ wiki/Stack_Exchange, accessed: 10/11/2014.

[127] Wikipedia. Stack overﬂow, 08/11/ 2014. http://en.wikipedia.org/wiki/ Stack_Overflow, accessed: 08/11/2014.

[128] Wikipedia. Ripple-down rules, 14/07/ 2014. http://en.wikipedia.org/ wiki/Ripple-down_rules, accessed: 26/03/2015.

[129] Wikipedia. Visual component library, 28/07/ 2014. http://en.wikipedia. org/wiki/Visual_Component_Library, accessed: 14/09/2014.

[130] Xively. COSM beta is now xively!, 14/05/ 2013. http://blog.xively.com/ 2013/05/14/cosm-is-now-xively/, accessed: 28/09/2014.

[131] Yahoo. About the pattern library - what’s a pattern?, 2010. http://developer.yahoo.com/ypatterns/about/index.html, accessed: 14/09/2014.

[ Context-aware UI Component Reuse for Web Service Development Environments ] Bibliography 187

[132] Jin Yu. A UI-driven Approach to Facilitating Effective Development of Rich and Composite Web Applications. Doctorial thesis, Univ. of New South Wales, 2008.

[133] Lei Zhang, Bin Gong, and Shijun Liu. Pattern based user interface generation in pervasive computing. In Third International Conference on Pervasive Computing and Applications, volume 1, pages 48–53, Oct 2008.

[134] Ying Zou, Qi Zhang, and Xulin Zhao. Improving the usability of e- commerce applications using business processes. IEEE Trans. Software En- gineering, 2007.

[ Context-aware UI Component Reuse for Web Service Development Environments ]