On Web Services UI In User Interface Generation in Standalone ...

On Web Services UI In User Interface Generation in Standalone Applications Martin Tomasek

Tomas Cerny

Dept. of Computer Science, FEE Czech Technical University in Prague Technicka 2 Prague, Czech Republic

Dept. of Computer Science, FEE Czech Technical University in Prague Technicka 2 Prague, Czech Republic

[email protected]

[email protected]

ABSTRACT Every production-level software application is like a living organism that changes and evolves throughout its lifecycle. Most of the changes related to application data impact the User Interface (UI). Usually, the change propagation to UI relates to input validations, data consistency as well as the UI behavior. In the case that UI involves data transfer from web services then the provided data format must correlate. This paper presents an approach that involves Model-Driven Development (MDD) to generate platform-independent definitions and provides these definitions to clients through web services. These definitions are generated based on templates, data types, annotations, security and application context using code-inspection. This approach decreases the effort involved in the development phase as well as in maintenance. Next, it prevents data inconsistencies and it makes it possible to specify the client’s UI at runtime by the server. We consider the message format, input validation rules, type safety and then evaluate the proposed solution through a prototype and present its abilities, advantages and limitations from the UI perspective. Furthermore, we perform usability tests to determine suitability of the proposed approach for practical usage.

CCS Concepts •Software and its engineering → Object oriented development; Maintaining software;

Keywords User interfaces, web services, UI generated based model

1.

INTRODUCTION

User Interfaces act as the gateway software application. They allow users to display and manage data, control processes, derive reports and access the information that they Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected].

RACS ’15, October 09-12, 2015, Prague, Czech Republic c 2015 ACM. ISBN 978-1-4503-3738-0/15/10. . . $15.00

DOI: http://dx.doi.org/10.1145/2811411.2811537

need. The UI should reflect the purpose of applications and provide users the ability to control the application. In order to increase efficiency and usability it must provide a proper feedback on user actions. Contemporary applications aim to separate the technology that is used to generate the UI and technology to process a particular request. The preferred concept is to divide the application to web services [12] as a processor and a thick client as UI representation. The thick client can involve various technologies, such as Java, AngularJS [2], HTML5 [14], etc. Usually, we need to represent the actual application state at the client-side. The state can be captured by a visual object that holds the particular state information, its representation usually consists of application data as well as information reflecting the particular field, their types, etc. However, the object that deals with the representation does not generate the UI presentation. Developers manually describe a particular UI. Unfortunately, designing a particular UI is a time-consuming and error-prone process [5]. For instance, the time that is allocated to UI design is around 50% [5] of the overall development time. The application requirements and possibly the application data model may change during the development lifecycle and all the changes must propagate to be reflected in the UI. Moreover, we have to consider application security and access rights because each user may have different rights and thus some actions are restricted to certain users only. To increase usability each user is presented with a UI that reflects his access rights and concrete purpose of his goal. This implies that often we need to describe multiple distinct UI presentations for these varying situations, which further extends the involved efforts and the level of duplication. If there was a way to generate parts of UIs based on the data model, the process could be automated and server-side changes would be immediately reflected by the client-side. Such automation would also mitigate inconsistency and human errors. So far we have described just one perspective and we did not take into account the involved client-server communication. The server-side usually considers public and private web resources, underneath there are object-oriented classes responsible for business validation or a dedicated persistence layer responsible for maintaining data. Each web resource has a unique location accessible through a URL and either consumes or produces a concrete instance of data. The message accepted by producers and consumers usually expects a standard format, such as JSON or XML [12]. However, in order to make the client application aware of the server

provided data, the client must follow the data structures defined by the server. Thus the client application must create equivalent projections of the data structures. The client application then synchronizes the data, following the structures separately defined by both sides. The business validation applies on data provided to the server followed by passing the actual data to the persistence layer for storage. The main problem we depict here is the client-server data synchronization that must consider separately defined data models that must correlate. Consequently, wrong models on either side may lead to information loss or to integrity issues. When the model changes at the server-side it must change also at the client-side, which most likely impacts the UI presentation of the data. In this paper we consider an alternative approach to generate client-sides. The main problem we consider in contemporary approaches is the model synchronization, the clientserver model correlation and reflection of all server model changes at the client-side. At the same time, we aim to avoid the need to design multiple slightly different UI presentations for users with different access rights. We address these issues by exposing the UI definition model at the server-side for clients in a machine-readable format, so that they interpret the model content to derive the UI presentation for data elements. Having the server-side responsible for providing the UI definition model makes the client-side unaware and loosely coupled from particular data structures involved in the UI presentation. This brings the flexibility to automatically adjust to changes at the server-side. Furthermore, the approach reduces possible typological errors and avoids inconsistency. Moreover, we extend the UI definition model for data elements with rules for user input validation and show their integration to the client-side application at a case study. This paper is organized as follows: The following chapter describes the related work, our proposed solution is described next, aft er that is a chapter evaluating our approach, and the paper ends with conclusion.

2.

RELATED WORK

There exist various concepts that address the introduced issues and we discuss them in this section. We divide the section to two subsections. Firstly, the generation of UIs secondly, the data representation for clients, including the data transmission.

2.1

Generating User Interface

There exists a significant amount of work in the area of Model-Driven Development (MDD) [4, 19]. The rationale is to design models from which the UI can be generated based on model descriptions and their information. The main advantage is that the generated UI is always up to date and reflects all changes made to the model. The model transformation can consist of multiple strategies, which can take into account input validations or even access rights. This means that the effect the efforts to provide various UIs for different goals and users reduce as duplication can be reduced. It also brings beneficial abstraction to manipulate the data definitions and to see their relations. Furthermore, novel technology can be supported simply by adding new transformation rules, while reusing the model. On the other hand there are multiple issues with the MDD approach, for instance we would need to generate from the model not only the client-

side, but also the server-side to keep them in correlation. This might become impractical as many developers prefer to make changes in the code rather than in the model [9], which consequently disallows future model-to-code transformations since all manual changes be would erased. Thus having solely the client-side generated from the model is impractical as we only delegate the issue from client-server correlation to model-server correlation. Next, the MDD is usually executing the transformation at the compile time [9], which might be a difficulty for context-aware systems that consist of large amount of application states that might be dependent and formi exponential growth of states that as a result occupy disk space, even though they are just hypothetical. This may further impact the UI description transmission as multiple states might require transmission to the client-side [8]. Another idea considers code-inspection and consequent transformation [4, 16]. Compared to MDD the information is captured in code, and the model is generated ad-hoc at the code-inspection. Therefore, this can take the advantage of runtime transformation. The framework called AspectFaces [1] generates UI based on code-inspection models and involves Aspect-Oriented Programming (AOP) [18] for the transformation. It considers all the enterprise standards and information from the code; the transformation is templatebased, which allows for influencing of the transformation result. The code-inspection idea is based on metaprogramming and gives the program the ability to describe itself and deduce what properties the program components have, which fits in with the UI derivation since most of these information is used in the UI. Another idea, which is used in this approach, combines metaprogramming and declarative programming [13]. Declarative metaprogramming is used to configure generative programming [10] with the concept introduced in [13] that uses a SmallTalk Open Unification Language as part of the transformation syntax-tree, such as XML, to combine logical facts.

2.2

Data Representation for Clients

So far we have not discussed the way the client application presents the UI to users. For instance, the AspectFaces extend the server-side UI representation, the Java ServerFaces (JSF) component tree that renders view to clients with webbrowsers as HTML fragments. The presentation is assembled during the rendering of JSF phase. However, our aim is to build UIs on the client-side which are independent of particular technology. Another framework, called MetaWidget [16, 17], is used to generate UI and it has an extension to generate UI on the client-side. MetaWidget comes with the idea that inspection is set up based on application, then specific elements are used for the UI assembly. Next, it is possible to use the standard REST [12] protocol to transfer data between the client and server for Angular JS technology. The idea introduced in [6, 7] suggests dividing and untangling various elements involved in the UI assembly, so that their transmission size can reduce, and independent decisions on client-based caching can be made to optimize the transmission.

3.

PROPOSED SOLUTION

This section presents our proposed solution. We use the

model derived from code-inspection to generate the UI. Therefore we divide the consequent text into three subsections. The first section explains the UI generation. The second shows the way it is processed at the client-side. Finally, we describe the integration of the ideas from the previous subsections. We demonstrate the prototype application created based on the proposed architecture.

3.1

Code-based, Model-driven UI Generation

The UI that is generated based on the model, which is derived from code brings multiple advantages. The actual information captured by coexisting code at the server-side are reused, which as result avoids typographical error and reduces issues with type safe variables and consistency issues between the model and UI. However, we need to propagate the derived model to the client-side. The abstract UI representation is derived at the server-side and then provided to clients, which we mention later. We use the AspectFaces approach and thus apply code- inspection to objects that are subjects of visualization in the UI, and for these objects we derive the abstract UI definition. The result is a platformindependent UI representation, which is provided to clients in a machine-readable way through web services. Our goal is that the generated UI reflects the actual state of the model as well as the application context, security and possibly other custom conditions provided by developers. Our approach is to provide presentation for data elements such as forms, tables, lists, reports, etc. The generation process has 3 phases and takes as the input a reference to data that are presented in the given UI in the given context. Phase 1 applies code-inspection to the data references; this together with the application context determines the ad-hoc model that is used for the transformation. The codeinspection takes place at runtime but since the result does not change, caching can apply for performance optimization. The phase 2 is invoked during phase 1 and applies the transformation. It maps the model properties to it’s UI representation, such as widgets. Again, the decisions are made based on data properties as well as the application context. Each widget is described through a template and specifies the component type, behavior and settings. Phase 2 resolves the property representations and through their integration produces the complete UI component. Phase 3 customizes the generated components. This last phase is optional, and is intended for customization of the UI. Next we look at these phases in closer detail. The UI presentation is generated based on the visual objects. Phase 1 audits each field of the object and based on the field type it starts the transformation process with the goal to find an appropriate component template to use. The transformation rules used in the transformation are part of phase 2. They query the inspected field properties and based on the queried clause they determine whether to use a particular template. The transformation rules are described through an XML-based Domain-Specific Language (DSL). Developers can adjust and define custom rules to reflect the actual needs. The transformation rules are aware of field properties but also have the ability to consider runtime application context, such as access rights, geo-location, user input validation failure rate, etc. The result of the field transformation is the selection of the most suitable template and its content resolution towards the data field and the application context. Phase 2 determines the content for all visual ob-

"widgetType": "TEXTFIELD", "id": "login", "label": "Login", "classType": false , "readOnly": false , "visible": true, "layout": { "layoutDefinition": "ONECOLUMNLAYOUT", "layoutOrientation": "AXISY", "labelPosstion": "BEFORE" }, "rules": [ { "validationType": "REQUIRED", "value": "true" }, { "validationType": "MAXLENGTH", "value": "255" } ], "options": null

Listing 1: Sample Abstract UI description provided by server

ject fields using a particular layout specification. The layout specifies individual field composition at page, window or a panel. At this point the suitable abstract UI presentation is resolved. However exists one more transformation, which converts the abstract UI presentation description to objects, which could be used in the final phase to customize the components. These objects can be modified or extended to influence the final definition. At this point we generated the platform-independent definition of the given visual object. Listing 1 shows an example. In the example there is a single component type, component identification, settings, and general information about layout and validations rules. The layout only describes that there should be a single column layout applied in the interpretation, which should have the orientation based on the axis X. The concrete layout implementation is determined upon interpretation at the client-side. The same applies for user input validation rules and for the interpretation and representation of the component at the client-side.

3.2

Interpreting the Abstract UI by Clients

So far, we have discussed the server-side responsibilities. This section shows the interpretation of the abstract UI at the client-side. The server provides the platform-independent abstract UI description in a machine-readable format, such as JSON [12]. The content can be interpreted on various platforms using native components, which further improves the usability for the end users. Thus the single description provided by the server can have multiple interpretations and possibly slightly different results reflecting the client-side platform. As described in the previous subsection the component definition is represented through an object, which means that we know the object structure and we can work with it even if the visual object or resource has been modified.

When a client aims to derive a UI presentation for a particular data element the abstract UI description is requested from the server-side. The response it gets provides contextaware UI description, from which is revived the UI for the particular data. Our preliminary prototype interpreter is a Java-based application that uses Java Swing framework. It process the abstract UI definition, however, the interpreter can be written in any other programming language. We describe the prototype later in more detail, and explain the interpretation. The client-side application issues a request to the server-side and based on the response it derives the concrete presentation using native components, such as input fields, combo boxes, radio buttons, etc., An example of code is shown in Listing 2. This code retrieves an abstract UI description from the server. The description can be the example given by Listing 1, although it shows only a single field from a more complex visual object. The example in Listing 2 builds a form and interprets fields. For instance, a JTextField template is selected for the Listing 1 example, with label “Login”. It also sets up layout, which means that the label is positioned before the input text and the text field positioned at the right hand-side of the label. In Swing, the border layout is used, although this is specific the Swing. Additional settings are also processed, such as input validations. The validation in the example requires at least one character in the input text field. In addition, there could be specified custom skin of generated components, such as colors, sizes, fonts, etc. The timing, of a particular UI assembly happens upon user action that intends to select and display a particular data element. Then a request is made to the server-side for the particular data presentation and data values. The received abstract UI is locally integrated with the concrete presentation and data values are populated to the resulting component. The matching bases on field name in the hierarchy, which mean that it can recognize, for example: person.name, person.pet.name, etc., in the object graph. When users terminate the interaction with the particular component, the data values are sent back to the server to create, update or delete the particular data instance. Specification of this action can be described in a global XML configuration that describes the locations of resources with definitions, data values and endpoints to accept objects to commit data changes, etc. Next, let us consider the client-side process of the UI assembly. Consider the example in Listing 2. First of all a builder is initiated. Developers specify the identification of the intended page/window UI fragment that is to be assembled. Next, the parameter identifies the connection resource to use, finally, other parameters are provided. The connection resource is specified through the XML configuration. In this file can found be all the necessary information such as resources, parameters, authorization, etc. The expression language is used to specify variables that should be resolved at runtime. The above interaction in the UI assembly is displayed in Fig. 1. First, the client requests an abstract UI description. Based on this request is created the description is created involving the model and code-inspection, transformation and the combination phase. The client-side builds the UI based on the description and then requests the particular data values. The server finds the data to display, provides them back

AFSwinxFormBuilder formBuilder = AFSwinx. getInstance().getFormBuilder(); formBuilder.initBuilder("personForm", connectionResource , "personFormConnection", parameters); AFSwinxForm form = formBuilder.buildComponent();

Listing 2: Sample of UI assembly at the client-side

Figure 1: UI assembly client-server interaction

to client and the client displays them in the assembled UI. The component is embedded to the UI in the application. When the interaction terminates the client asks the server to process the data values and the server commits a particular action.

4.

EVALUATION

We implemented a prototype that uses the proposed concept, although it has a few restrictions. Arrays and collections are not supported as the data field types, however, we support all the non-primitive data types, such as those provided by various persistence or validation frameworks [3, 11], which can be integrated with this approach. The JSON messages are supported, although only a limited amount of layouts are provided. For the evaluation, we consider an application which is used to manage people’s absences at work. This application has a server-side with a database using standard Java Persistence API [3, 11] and REST API [12], which is used to obtain the abstract UI definition and data. The client-side has a login form with security control on the server-side. The client-side provides seven views, which are used to control the application. To generate input components and tables we use solely the proposed approach, although buttons in menus and buttons which control the application flow are created at the client-side manually. Notice that in Listing 2, only 3 lines of code are necessary to assemble the data UI presentation. In the end it is about 23 lines of code to generate the UI data presentation or to submit the data back to the server. On the server-side there must exist a corresponding mapping and a component definition. These mappings

Fields

Server (ms)

Client (ms)

Total (ms)

2

9,9+0 ∆

5,9+0,5 ∆

16,3 ∆

13

25,7+2,5 ∆

30,3+1,8 ∆

60,3 ∆

Table 1: Measurement results - time to create abstract UI/assemble the UI (in ms with ∆)

4.1.1

Test Setup and Scenarios

We prepared client and server sides for the test users. Participants completed only prepared tasks and they did not need to install the environment, setting application server etc. The reason for this was that we did not want to test users about their knowledge and skills about Java EE. Each participant received the user guide, which was designed to introduce the approach to developers. Each participant was advised of the server and client side architecture. A RESTClient able to call remote, server-provided service API and display output is available as a library at the client-side Each participant was asked to complete following tasks: • Read the user guide and examine the client and server side.

Figure 2: Example of generated view.

and definitions are reusable. We decided to separate the definition resource from the data resource. The reason is that when the developer wants to integrate this approach to an already existing application the change of public or private API is complex and this can provide smooth integration. Furthermore, distinct caching strategies may apply. Next, we consider the performance. We divide the measurement into two parts, the client part and the server part. We ignore the time needed for the transfer of data from the client to server. The object which is considered, has 13 fields, the second measurement has an object with 2 fields. The measurement results are provided in Table 1. The server column has a number indicating the time consumed by abstract UI description derivation plus customization. The client column has a number indicating the assembly from the abstract UI description plus filling data to generated fields. The measurement was repeated 30 times and the average times of overall composition took lite more that 60ms for the 13-fields sample and about 16ms for the 2-field sample. The resulting times are promising for the requirements of production applications. An example of generated form is shown in Figure 2. The example demonstrates form use with a few read-only and editable elements. A two-column layout is applied. The combo box uses values specified during the 3rd phase, which shows a component customization.

4.1

Usability Test

There is another important aspect of this proposed solution, which is the end user that will create the view. It is hard to decide whether our concept is right and whether it is usable. In the early development phase of our prototype, when it had enought functionality to test [15], we performed qualitative usability tests with 7 persons. The prototype was able to build UI and send it back to the server. First of all, we defined the target group. Each member of our group is a software developer who works primarily in Java and who knows web services and who is open to new approaches in UI generation. We wanted to verify whether users are able to understand the process and whether they are able to generate UI with our new approach.

• Create a web service source on the server-side, which retrieves an abstract UI description of the Country entity. Demonstrate functionality using REST-Client. • Create a blank form or other components on the clientside, so that it is derived based on the abstract UI description from the previous point. • Fill in the created form with data from the server. • Create a blank form, which submits data back to the server and this action will create the new country object. Perform this action. • Create a table that receives abstract UI description from the server and fills in this table with all the values with country entities and verify that the new instance from the previous point was created. • Change the property of the table, so that this table changes it’s size dynamically. • Create a form that can update county with ID 3. • Create a form that can delete country with ID 3. • Create a blank form that is built based on country abstract UI description and change the check box component to a drop down menu componnet for the field called active.

4.1.2

Usability Test Evaluation

We wanted to test whether users are capable of working with the designed concept. We did not find a blocker in this test, but we had to help two persons from our test group with the problems related to documentation. Each participant completed the test, however, we found platform specific issues. The main issue is that our tables and forms extend from JPanel class, which has many methods and it is hard to determine which methods to use as many are inherited. The solution could use abstraction. Based on our observation during the lasts tests we identified another issue. Users spent more than 5 minutes reading template definitions, which are used to transform input object to the platform-independent abstract UI description. Future research will be made to determine whether XML template specification is the appropriate option and whether the maintenance efforts are optimal. Another issue was related to functionality, which we hoped would be beneficial for users, but it was not. Considered components have a small amount of logic, when the

data value endpoint is not specified then the component is empty and it does not need data. In case the component should be filled with data then it is only necessary to specify a resource that provides the data. Users had a little confusion as they always created a blank form and added the data resource and they searched for a method that would populate it with data. Since they did not find any such method they tested the outcome and it worked with no extra efforts, although this process should be more intuitive. The usability tests were successful, as they identified several issues which can be addressed in our future work, although the main goal of this test was accomplished. The concept is suitable and end users are able to use it.

5.

CONCLUSION

In this paper we present an alternative approach to assemble UIs at the client-side for situations when all data are stored at the server. We considered the use of a codeinspection approach and MDD to generate a platform independent UI description that is transformed to the UI. We demonstrated this concept on prototype based on Swing framework and provided information about performance. The advantages of the approach is that it is possible to reflect all changes made at the server-side automatically at the client without manual work, avoiding human errors and inconsistencies. We performed usability tests, which proved the suitability of the concept for the end users and provided feedback on how developers work with this concept. However, the approach only considers the derivation for data presentations, actions and navigation are left to developers. The approach brings the benefits of platformindependent UI description provided in a machine-readable format from the server to native clients, which allows for deriving UI using native components to increase user comfort and integrate native features. In future work we like to focus on Mobile and JavaScript applications using the same concept we presented in this paper. After that, we would like to explore the possibility to improve readability of templates using DSLs.

6.

ACKNOWLEDGMENTS

This work was supported by the Grant Agency of the Czech Technical University in Prague, grant No. SGS14/201/OHK3/3T/13

7.

REFERENCES

[1] AspectFaces, 2015. http://AspectFaces.com. [2] Phonecat tutorial app, 2015. https://docs.angularjs.org/tutorial. [3] E. Bernard. JSR 303: Bean validation, November 2009. [4] T. Cerny, K. Cemus, M. J. Donahoo, and E. Song. Aspect-driven, data-reflective and context-aware user interfaces design. SIGAPP Appl. Comput. Rev., 13(4):53–66, Dec. 2013. [5] T. Cerny, V. Chalupa, and M. Donahoo. Towards smart user interface design. In Information Science and Applications (ICISA), 2012 International Conference on, pages 1–6, May 2012. [6] T. Cerny and M. Donahoo. On separation of platform-independent particles in user interfaces. Cluster Computing, pages 1–14, 2015.

[7] T. Cerny and M. Donahoo. Separating out platform-independent particles of user interfaces. In K. J. Kim, editor, Information Science and Applications, volume 339 of Lecture Notes in Electrical Engineering, pages 941–948. Springer Berlin Heidelberg, 2015. [8] T. Cerny, L. Matl, K. Cemus, and M. Donahoo. Evaluation of separated concerns in web-based delivery of user interfaces. In K. J. Kim, editor, Information Science and Applications, volume 339 of Lecture Notes in Electrical Engineering, pages 933–940. Springer Berlin Heidelberg, 2015. [9] T. Cerny and E. Song. Model-driven rich form generation. In INFORMATION-An International Interdisciplinary Journal, pages 2695–2714, July 2012. [10] K. Czarnecki and U. W. Eisenecker. Components and generative programming (invited paper). In Proceedings of the 7th European software engineering conference held jointly with the 7th ACM SIGSOFT international symposium on Foundations of software engineering, ESEC/FSE-7, pages 2–19, London, UK, UK, 1999. Springer-Verlag. [11] L. DeMichiel. JSR 317: JavaTM persistence API, version 2.0, November 2009. [12] T. Fredrich. RESTful Service Best Practices Recommendations for Creating Web Services, 2015. http://www.restapitutorial.com/media /RESTful Best Practices-v1 1.pdf.

[13] S. Goderis and W. De Meuter. Generating user interfaces by means of declarative meta programming. In ECOOP02 Workshop on Generative Programming, 2002. [14] B. R. Hickson I. and collective. Html 5.1 w3c working draft 17 march 2015, 2015. [15] S. in the Master of Technical and S. C. Programl. Usability testing: Developing useful and usable products, 2002. [16] R. KENNARD. MetaWidget documentation, 2015. http://metawidget.sourceforge.net/documentation.php. [17] R. Kennard and J. Leaney. Towards a general purpose architecture for UI generation. Journal of Systems and Software, 83(10):1896 – 1906, 2010. [18] G. Kiczales, J. Irwin, J. Lamping, J.-M. Loingtier, C. V. Lopes, C. Maeda, and A. Mendhekar. Aspect-oriented programming. In IECOOP’97-Object-Oriented Programming, 11th European Conference, volume 1241, pages 220–242. Springer, June 1997. [19] M. Macik, T. Cerny, and P. Slavik. Context-sensitive, cross-platform user interface generation. Journal on Multimodal User Interfaces, 8(2):217–229, 2014.