IMPLEMENTING UI LIBRARY IN FINTECH APPLICATIONS
An Evaluation of the Effectiveness
Emil Hallberg
Master of Science Programme in Interaction Technology and Design, 300 credits Degree Project in Interaction Technology and Design, 30 credits
Spring 2021 Examiner: Ola Ringdahl
Supervisor: Paul Townend
External Supervisor: Christoffer Lundmark
Implementing new technology into a complex software developing en- vironment comes with many challenges in terms of code, user inter- face design, and developer experience. It is well-established that the pressing demand for security and regulations within financial technol- ogy makes it even more essential to implement new technologies with care and minimised risks. This work aims to determine the effectiveness of such implementations. Specifically, it evaluates the effectiveness of implementing a UI library in a FinTech application to find the most suit- able approach. In this context, a UI library defines as a robust set of user interface components available in one place and a FinTech applica- tion as an application in financial technology with complex developing infrastructure.
In order to successfully evaluate the effectiveness of implementing a UI library in a FinTech application, a thorough literature survey was performed to identify decisive factors relating to code quality, user in- terface, and developer experience. In a case study in which a FinTech company served as an example, a solution consisting of their product and UI library was developed. The solution was tested by collecting data from code evaluation, questionnaires, and interviews. The result shows that the solution has higher code quality, fulfils the FinTech UI requirements, and perceived as an improvement of the development in- frastructure.
On this basis, the utilised methodology and the recognised factors in this work should be taken into account to identify the most suitable approach when implementing a UI library in a FinTech application.
I want to extend my sincere appreciation to my supervisor Paul Townend, which has con- tributed valuable knowledge and guidance during this work.
I also want to extend my gratitude to Nasdaq, which welcomed me with open arms and allowing me to apply my skills and knowledge to your company. Mainly thanks to my supervisors Christoffer Lundmark and P˚al Forsberg, which helped me throughout the work and provided me with excellent insight and expertise within the FinTech area. Thanks to everyone who participated in the interviews and answered the questionnaire.
Finally, I would like to thank my friends and family for providing valuable feedback.
1 Introduction 1
1.1 Background 2
1.2 Aims & Objectives 2
1.3 Outline 3
2 Literature Survey 4
2.1 Distributed Systems 4
2.1.1 Modern Distributed Systems 4
2.2 FinTech 5
2.2.1 Difference Between FinTech and Other Distributed Systems 5
2.2.2 Requirements 6
2.3 User Interface (UI) 6
2.3.1 Domain Specific UI Requirements 6
2.3.2 UI in FinTech 7
2.4 Frontend Development 7
2.4.1 UI Frameworks 7
2.4.2 UI Component 8
2.4.3 UI Library 8
2.5 Working with Code 9
2.5.1 Refactoring 9
2.5.2 Rewriting 9
2.5.3 Design Patterns 9
2.6 Evaluating Code 10
2.6.1 Cohesion 10
2.6.2 Coupling 10
2.6.3 Readability 11
2.7 Developer Experience 11
2.7.1 Cognition 11
2.7.3 Contribution 11
2.8 Evaluation Framework in Software Engineering 12
2.8.1 Important Metrics for Implementing UI Library 12
2.8.2 Methods for Obtaining Metrics 12
2.8.3 Different Ways of Evaluating Developer Experience 13 2.8.4 Evaluation of the Effectiveness of Implementing a UI Library in
FinTech 13
2.9 Research Challenges 14
3 Solution Design 15
3.1 Proposal 15
3.2 Criteria for Success 15
3.2.1 High Code Quality 15
3.2.2 Efficient UI Design 16
3.2.3 Good DX 16
3.3 Company Case Study 16
3.3.1 Clearing Platform (CP) 16
3.3.2 Risk Domain of CP 16
3.3.3 User Interface Library (UIF) 17
3.3.4 Company Style Guide 17
3.4 High-Level Architecture 18
3.5 Methodology 19
3.5.1 Design 20
3.5.2 Build 21
3.5.3 Test 23
3.6 Limitations 23
4 Implementation 24
4.1 Low-Level Architecture 24
4.2 Created Components 25
4.2.1 Page Component 25
4.2.2 Help Component 26
4.3 Implementation of Selected Pages 28
4.3.1 Reverse Credit Stress Test Page 28
4.3.3 Monitoring Overview Page 31
4.3.4 Monitoring Tree Component 32
4.3.5 Haircut Backtest Page 33
4.3.6 Haircut Backtest Search Form 35
5 Testing 37
5.1 Evaluating Code 37
5.1.1 Testing Cohesion for a React.js Component 37
5.1.2 Testing Coupling for a React.js Component 38
5.1.3 Testing Readability for a React.js Component 38
5.2 Evaluating UI Design 39
5.3 Assessing Developer Experience 40
5.3.1 Cognition Category 40
5.3.2 Affection Category 41
5.3.3 Contribution Category 41
5.3.4 Preferences Category 41
6 Results 43
6.1 Code Quality Results 43
6.2 UI Questionnaire Results 46
6.2.1 Data Visualisation Category Results 46
6.2.2 Human Language Category Results 47
6.2.3 Brand Identity Category Results 47
6.3 Interviews with Developers 47
6.3.1 Cognition Category Results 48
6.3.2 Affection Category Results 48
6.3.3 Contribution Category Results 49
6.3.4 Preference Category Results 49
7 Evaluation 51
7.1 Effectiveness of Code Cohesion, Coupling, and Readability 51 7.2 Difference Between FinTech and Other Applications in Terms of UI 52
7.3 Assessing Developer Experience for UI Libraries 52
7.4 Effectiveness of Implementing a UI Library in FinTech Applications 53
8.1 Aims & Objectives 56
8.2 Lessons Learned 57
8.2.1 Achievements 57
8.2.2 Personal Reflection 57
8.2.3 Problems Encountered 58
8.3 Future Work 58
8.3.1 Automatic Testing of Code Quality Metrics for React.js Components 59 8.3.2 Applying FinTech UI requirements in Other Areas 59 8.3.3 Altering the Developer Experience in Large Organisations 59
8.4 Summary 59
References 60
A UI Feedback Questionnaire 62
B Interview with Developers 66
1 Introduction
Implementing new technology into a complex software developing environment comes with many challenges, significantly within financial technology (FinTech), where the need for se- curity and high-availability [15] makes it essential to implement new technologies with care and minimised risks. It is also essential for FinTech to emit a sense of trust and credibility via the user interface (UI) and user experience (UX) to create a lasting relationship with the end-users1.
The UI is how a user and a computer system interact. The purpose of the interaction is to enable effective communication for a user that operates the system, while the system simul- taneously provides feedback that helps the user decision-making process. In the seventies, Douglas Engelbart at Xerox PARC developed the first UI, and at first, it was intended mainly for research at universities [16]. It was not until the eighties when Apple introduced Lisa, the first computer with a UI designed for personal use, that the UI was considered more of a commercial product than before. As we today rely upon digital services to perform every- day tasks such as socialising, banking, or transportation, the UI is even more essential for software developing companies to maintain competitive advantage, enhance engagement, customer acquisition, and customer retention2.
Along with the increased popularity of UI frameworks in software engineering, the need for cohesive and reusable UI components across platforms has risen [12]. Components are the building blocks for UI and can be buttons, input fields, text, icons, amongst others [1];
often designed using company or product style guides to create a unitary and coherent UI.
Recently, design systems such as Google’s Material Design, Airbnb Design and Shopify’s Polaris have created UI component libraries3. Meaning, the components are available in one place, with documentation, examples, and code for developers to extract and use. The UI library helps the developers, but it also helps establish brand-familiarity and enhanced UX for the end-users and aids designers enable consistent design and a digital product to scale effectively without rework of design assets. Substantially, it helps to standardise UI, UX and development across multiple products and teams.
However, developers tend to adapt and interpret new implementations differently, leading to inconsistent usage and affecting the code quality and readability [22]. One of the most crucial factors in software development is the human factor, both in terms of quality and per- formance [2]. The increasing number of software developers and development teams doing distributed software development, indicates that the human factor is becoming even more critical. The developer experience concept tries to better understand these human factors by apprehending how developers perceive the developing infrastructure and feel about their work and contribution [2]. Assessment of the developer experience and decisive factors
1https://djangostars.com/blog/five-tips-ui-ux-development-fintech-products/
2https://www.toptal.com/designers/ui/touch-the-world-is-our-interface
3https://medium.com/sketch-app-sources/why-should-you-build-a-ui-component-library-854656b91a96
in complex software developing environments can minimise the risk of using unnecessary resources and improve productivity [22].
Implementing new technologies comes with lots of challenges, and various factors need consideration. An important consideration is understanding how code cohesion, coupling, and readability contribute to successfully implementing new technologies. This work will explore methods for evaluating the effectiveness of implementing a UI library in FinTech applications.
1.1 Background
This work cooperates with Nasdaq, an American multinational financial services corpora- tion that owns and operates the Nasdaq stock market in the United States and eight European Stock Exchanges. Today Nasdaq has over 4000 employees and offices all over the world.
In 2019 Nasdaq Technology acquired the financial technology company Cinnober located in Ume˚a4. Cinnober specialised in trading and clearing technology, serving exchanges and clearinghouses globally. Some of the world’s most demanding financial marketplaces use their multi-asset class solutions to deliver mission-critical business processes.
In order to maintain the brand identity, companies continually review their products to align them to the company brand. Usually, within software development, with the help of a UI library. However, to better understand how the implementation affects the product and de- velopers, companies need to evaluate the effectiveness of implementing new technologies, such as UI libraries, on existing applications.
1.2 Aims & Objectives
While respecting decisive factors in a complex software developing environment, the aims of this work are:
A1. Investigate how to identify the most suitable approach for implementing a UI library on a FinTech application.
A2. Investigate the correlation between decisive factors when implementing a UI library on a FinTech application.
In order to achieve the presented aims, the objectives are to explore methods for evaluating the effectiveness of implementing a UI library in a FinTech application. These include the following:
O1. Develop a methodology to evaluate the effectiveness of implementing a UI library in FinTech applications.
O2. Develop a methodology to evaluate how code cohesion, coupling, and readability is affected when implementing a UI library.
4https://www.nasdaq.com/about/press-center/nasdaq-acquire-cinnober
O3. Determine if there are any differences between FinTech and other applications in terms of UI.
O4. Develop a methodology to determine how the developer experience affect the pro- gramming outcome when implementing a UI library.
1.3 Outline
The rest of this work structures as follows. Chapter 2 presents a thorough literature survey to understand the topic better and justify the solution design decisions. Chapter 3 intro- duces a company case study in which the collaborating company serves as an example and by using one of their product and UI library, a solution is proposed. Chapter 4 presents a more detailed description of meaningful choices made during the implementation. Chapter 5 explains how to test the solution with a survey-based approach, including interviews and feedback questionnaires with developers. Chapter 6 presents the results of the performed tests. Chapter 7 evaluates the collected data while respecting the aims and objectives of this work. Finally, the work is summarised in Chapter 8 by discussing aims and objectives, lessons learned and future work.
2 Literature Survey
In this chapter, a thorough literature survey justifying the decisions made for the solution design is presented. Important areas within the scope of this work and how they relate to each other are highlighted.
2.1 Distributed Systems
The rise of powerful microprocessors and high-speed computer networks meant that a con- siderable amount of data could transfer between systems at a great rate. Along with these opportunities, the cost and size of, now networked, computers decreased, leading to that many computers can be connected whilst geographically dispersed, thus said to form a dis- tributed system [23].
Nowadays, a distributed system defines as a collection of autonomous computing elements that appear as a single coherent system for its users. The key features are that all computing elements can behave independently and that the users believe that they are dealing with one system to make the autonomous elements collaborate. Furthermore, a distributed system must be open, which means that its elements can easily integrate with other systems. Also, while considering the system’s size, a distributed system must be scalable, which means that more users and resources should not affect its performance.
2.1.1 Modern Distributed Systems
A modern distributed system consists of various nodes that work together to achieve a mu- tual goal by interacting with each other. A node often has a dedicated task and area of responsibility within the system [23]. However, as mentioned in Section 2.1, the node must have the ability to act independently and can not be relying upon one another. By working together, the system can hopefully plan its information and resources efficiently, and if one node fails, it will not affect the system’s availability.
Because there was no standard way of communicating between the systems, service-oriented architecture (SOA) emerged. SOA is a software design that provides reusable software com- ponents via service interfaces [17], usually designed to enable quick incorporation into new applications without creating supplementary integrations each time1. Like the nodes, each service is assigned a dedicated task and embodies all the data and code needed to perform it.
This task is often part of the application’s business logic and can, for example, check a cus- tomer’s credit or calculate a monthly loan payment. Also, by making the services loosely coupled, each service can be used with limited knowledge concerning the underlying func- tionality’s implementation.
1https://www.ibm.com/cloud/learn/soa
However, modern distributed systems come with many challenges, such as latency, message passing, performance, usability, and many different locations. A significant domain within distributed systems is FinTech.
2.2 FinTech
At first, FinTech, an abbreviation of financial and technology, was used to highlight in- novative technologies associated with the finance industry. In the seventies, it appeared in scientific literature and was used to describe banking expertise combined with modern tech- nologies. Nowadays, FinTech refers to technologies aiming to improve and automate the use and delivery of traditional financial services [15]. By taking advantage of specialised software and algorithms used on computers, FinTech helps business owners and consumers organise their financial operations and processes better. In FinTech, there are two cate- gories; sustainable and disruptive [15]. Sustainable FinTechs refers to established financial services, which aim to protect their market position by using technologies. Disruptive Fin- Techs aim to challenge these by offering innovative ways to operate and monitor financial activities with new services and products.
With the emergence of digital finance and the pressing demands of security and regulations in banking and financial services, the traditional actors’ faced a significant transformation.
However, the finance industry is considered a keen adaptor to new technologies [15]. Lead- ing to exchanges, clearinghouses, and trading facilities has become the backbone of today’s globally connected financial markets [20]. Even though this promises significant benefits for society, as its lowering costs and broadens access [14], new challenges and concerns arise. Within finance, regarding rules and regulations and within technology, requiring sys- tems with high security and availability.
2.2.1 Difference Between FinTech and Other Distributed Systems
Unlike other distributed systems, FinTech comes with many challenges such as regulation, technology integration, security and privacy, and risk management.
Financial products and services, both provided by traditional financial actors and emerging FinTech, is unlike other distributed systems, belonging to the world’s most densely reg- ulated sectors2. In general, the same regulations may not apply to FinTech as traditional financial services. When developing a FinTech system, this needs consideration [11].
Technology integration identifies the challenge of integrating new technologies on legacy systems. Even though traditional financial actors are considered early adopters of new tech- nologies [15], they are unlikely to change their dependable and functioning systems. In particular, disruptive FinTech is usually based on new technologies and how to integrate these with existing legacy systems within finance is challenging and of great importance in providing a seamless consumer service [9].
Security and privacy imply the significance of how to handle critical and sensitive data. The nature of the data usually handled in FinTech applications is often significant and delicate, both for companies and users. Hence, to minimise the risk of security and privacy breaches,
2https://www.investopedia.com/terms/f/fintech.asp
it is essential to take appropriate means to protect sensitive consumer data from unauthorised access when developing FinTech systems [11].
Living up to these demanding security and regulations comes with many challenges in se- curity and privacy, and multiple requirements need consideration.
2.2.2 Requirements
The emerging technologies within FinTech have supplemented the offerings of financial ser- vices. However, this also brought various challenges from a technical perspective, including security and privacy concerns [11].
Complex FinTech-infrastructures such as clearing and settlement systems often interacts with the financial markets to retrieve sensitive information about trades, users, and corporate data [10]. Therefore, security is of great importance to ensure the privacy and protection of data.
Financial products and services belong to the world’s most densely regulated sectors3. Due to the immense number of geographically dispersed external systems connected in the fi- nancial markets [10], the systems have to conform to local laws and regulations to prevent impropriety.
Additionally, the FinTech system has to emit a sense of trust and credibility to establish a lasting relationship with the consumers. In software design, a sense of trust builds by giving the user the impression that the software is dependable to get the task done. Similarly, credibility forms by giving feedback to the user when performing tasks. Consequently, the user interface is of great importance.
2.3 User Interface (UI)
The user interface (UI) is how users and computer systems interact. It is where the system’s functionality connects with the end-users [21]. Often, via direct manipulation of visual components with pointing devices or senses like touch, gestures, or voice [16]. As men- tioned in Chapter 1, the UI was not considered much of a commercial product until the eighties. Today, as the product and services complexity increases and users demand more in terms of user-friendliness [21], it indicates that the UI is one of the most important factors to consider in software development. A helpful UI helps the user interact with the system naturally and intuitively, which means that the design should satisfy the users’ needs, capa- bilities, and limitations [21] to help in the decision-making process. Additionally, different systems have different users, and therefore the design must reflect the domain in which the system lies.
2.3.1 Domain Specific UI Requirements
To create an intuitive UI, the domain in which the system lies needs consideration. Different domains have various requirements, and the design needs to be reflected by the system’s domain [7].
3https://www.investopedia.com/terms/f/fintech.asp
Systems designed without considering the tasks domain tend to increase the user’s cognitive load by making them work the interface instead of focusing on the intended task [7]. In other words; allowing the user to utilise their skills efficiently. In such a design, the elements need a natural association with the specific domain’s terminology and concepts. As seen, FinTech is particularly important in this regard due to its enhanced trust and privacy concerns.
2.3.2 UI in FinTech
When designing for FinTech, it is essential to let the user focus on the operations and pro- cesses the system allows them to perform. Therefore, the UI design often focuses on; data visualisation, human language, and the service or product’s brand identity4.
The first one, data visualisation, relates to the significant amount of data, which the Fin- Tech systems often handle; it is essential to visualise it in a relevant way to the user to prevent misinterpretation and impropriety. The security and privacy concerns in FinTech introduced in Section 2.2.2 requires the design to visualise the data carefully in order to prevent exposing sensitive and misleading data.
The second one, human language, refers to the financial terminology often used when pre- senting the data; it is vital to use understandable terminology and provide further expla- nations. A system oversaturated with niche jargon can intimidate the user, damaging the service’s trust and credibility. As stated in Section 2.2.2, FinTech needs to conform to local laws and regulations; in this regard, using the correct language is of great importance.
The third one, the service or product’s brand identity, relates to how the design is per- ceived and experienced by the end-users; a straightforward and inviting design enhances the user engagement and increases the product value. Also, it contributes to strengthening the psychological bond between the user and the product. In Section 2.2.1, the challenge of integrating new technology in legacy FinTech systems was discussed; in this regard, partic- ularly in terms of UI, it is essential to consider how the design is affected to maintain the brand familiarity.
To successfully design an intuitive and valuable UI, the domain in which the system lies need consideration. Additionally, it is essential to understand how to implement the design without affecting it and its usability through frontend development.
2.4 Frontend Development
The term frontend development is usually used to describe the developing activities related to developing and implementing UI and integrating the system’s fundamental functionality.
In this work, the focus is on the frontend development of web-based applications.
2.4.1 UI Frameworks
In recent years, web browser technologies like HTML5, CSS3 and JavaScript have matured, making it possible to replace native desktop applications with web-based counterparts [6];
this implies that the application runs on multiple platforms with less effort and eases the
4https://adamfard.com/blog/fintech-ux-trends
development process. Along with this progression, and while also moving towards a more digitised market, a more out-of-the-box solution is necessary to ensure cross-browser com- patibility and speed up application comprehension and development [6]. To solve this, several companies created frameworks by abstracting complex and large operations by us- ing the capabilities of JavaScript or other well-established web programming languages [1], making these solutions accessible and reusable.
Recently, with the increasing number of viable UI frameworks, the choice is of great im- portance, and numerous factors require consideration [25]. Table 1 presents a comparison of UI frameworks concerning capabilities such as code style, documentation, and industry adaptation. When choosing between technologies, which continuously update with new features and changes and also have active developing communities, the choice tends to be influenced by personal preferences and experiences. Therefore, this comparison’s capabili- ties compare based on findings in the framework’s documentation, community forums, and blogs.
Table 1 UI Framework Comparative Analysis
Capabilities React.js Vue Svelte
Developer Productivity High High Normal
Learning Curve Low Normal Normal
Community Support Good Good Growing
Code Style Good Good Fair
Industry Adoption High High Low
Flexibility High High Medium
Performance Good Good Best
Low Memory Footprint Good Good Best
Conceptual Integrity Yes Yes No
2.4.2 UI Component
In software development, generally, a component is seen as a part of the software or system.
In this case, a UI component relates to the systems’ visual parts and can be buttons, input fields, text, and icons, amongst others [1]; often designed using company or product style guides to create a unitary and coherent UI. Components act as building blocks and are usually designed and developed to consider reusability and scalability.
2.4.3 UI Library
To enable reusability and scalability and facilitate the usage of the components, they are often gathered and made available in one place, called UI library, with documentation and examples for developers to utilise. As mentioned in Chapter 1, it helps to standardise UI, UX, and development across multiple products and teams and contributes to creating a brand-familiarity.
Studies indicate that reusing UI components increases productivity [12] and when imple- menting new technologies onto existing solutions, the usage must be consistent not to affect the code quality and readability. Therefore, it is relevant to identify appropriate methods for working with both existing and new code.
2.5 Working with Code
When applying new technologies to existing solutions, some well-known programming methods such as refactoring, rewriting, and design patterns are needed.
2.5.1 Refactoring
In software development, refactoring refers to modifying and changing code structure with- out altering its observable behaviour [5]. Over the years, the term usually refers to when developers clean up their code. Recently, refactoring considers applying small behaviour- preserving steps and accumulates into one more extensive modification; this means that the program does not spend much time in a broken state and that the refactor could stop at any given time.
While developing to achieve short-term aims without fully understanding the code infras- tructure, developers modify the structure to fit their needs, making the code decay. Refac- toring contributes to preventing this decay; it makes the code more understandable and readable, finds bugs, and often improves the speed of the software [5]. When working with refactoring, some methods are encapsulation, moving features, organising data, simplifying conditional logic.
Refactoring also helps prepare the software for new features. However, refactoring should not be confused with rewriting since it does not include adding new features or functionality [3].
2.5.2 Rewriting
Like refactoring, rewriting also involves working with the existing code and finding ways to improve the design. However, rewriting also includes the opportunity to choose new tech- nologies and modify functionality. When rewriting, one often uses dependency-breaking techniques such as definition completion, parameter adaptation, and breakout-method [4], meaning that the code is in a broken state. Therefore, rewriting is considered a more risky and time-consuming method when working with code. Reasons to rewrite are tangled code, outdated code, or movement towards a different framework [3].
Deciding between refactoring or rewriting depends on numerous factors; in some cases, the most suitable option is to ignore the alteration [3]. However, if a change is necessary, consider if the code is comprehensible, the value it brings, and the timeline. It is also helpful to consider which design patterns to use.
2.5.3 Design Patterns
In software development, design patterns refer to well-established models to use when de- signing or implementing new features. In this work, the focus is on three design patterns within web-based frontend frameworks.
Stateless components, also called functional components, are one of these design patterns.
A component’s state is data fetched or imported to it; a stateless component does not do this and always renders the same thing. It is desirable to use stateless components since it
prompts reusability5.
Another design pattern is conditional rendering. It allows the developer to determine when parts of the components should be rendered based on the current state or data conditions.
The hook design pattern introduction allows developers to create reusable functions by ex- tracting the component’s logic without changing its hierarchy6.
It is relevant to use appropriate methods when implementing new technologies; it is also necessary to evaluate the code to determine the work’s effectiveness.
2.6 Evaluating Code
Evaluating code helps determine whether the implementation or modification’s effective- ness is successful regarding code quality metrics such as cohesion, coupling, and readabil- ity.
2.6.1 Cohesion
Code cohesion measures to which degree the implemented responsibilities inside the same abstract component [18] belong together by assessing shared variables [19].
Typically, cohesion classifies on a high to low scale, where high is preferable; since it promotes the single responsibilities principle, meaning that a component should only have one responsibility [19]. Opposite, low cohesion usually associates with unwanted flaws such as difficulties maintaining, testing, reusing, or even understanding.
Cohesion usually contrasts by code coupling, and high cohesion often associates with low coupling and vice versa.
2.6.2 Coupling
Code coupling is to which degree of the interdependence between software components; by examing the number of dependencies and methods invoked by components, code coupling acts as a measurement of how closely connected two components are [19].
Like cohesion, coupling also classifies in a high to low scale, where low is preferable; since it indicates less dependency, coordination, and information flow between components. In contrast, a high coupling can lead to undesirable traits such as information hiding, impro- priety and unexpected side-effects.
As mentioned above, cohesion usually contrasts by coupling. In software design, low cou- pling combined with high cohesion is desirable and usually indicates readable and under- standable code.
5https://www.uxpin.com/studio/blog/react-design-patterns/
6https://reactjs.org/docs/hooks-intro.html#motivation
2.6.3 Readability
By studying factors such as consistency between source code and comments, identifiers’
specificity, textual coherence, amongst others [19] code readability describes to which de- gree the code is comprehensible to the reader, meaning that it logically communicates its intention to the reader. A high-readability is preferable since it cultivates the understanding of the code [19].
When working and evaluating code in software development, the human factor is one of the most crucial. Consequently, it is of great interest to examine. Not only to minimise the risk of using unnecessary resources but to improve productivity [22].
2.7 Developer Experience
A developer within software engineering faces numerous demands regarding skills and qualities, both from a technical and social perspective [13]. Based on familiar concepts such as UX, customer experience, and brand experience, Developer Experience (DX) has emerged to understand how human factors affect software engineering quality [2]. UX typically considers the circumstances of using a system, whilst DX considers software de- velopment context. DX consists of all related activities that a developer can encounter dur- ing their involvement in developing software, including development processes, modelling methods, and other structuring tasks [13].
In general, a developer’s mood influences the programming outcome and feelings such as happiness tend to increase productivity [13]. A great DX is likely to improve productivity and team performance by making it easier to adopt new workflows and procure the most value with minimum effort. In contrast, an inferior DX is likely to affect both the code and software quality. The DX concept tries to define how developers experience and feel about their work and contribution by examining: cognition, affection, and contribution [2].
2.7.1 Cognition
Cognition describes how developers perceive the development infrastructure, including con- crete interactions with development tools and software processes [2]. A positive experience of perceiving these contributes to better DX.
2.7.2 Affect
Affection describes factors that influence how developers feel about their work. It explains how social factors such as respect and belonging provides a sense of security and how attachment to persons, teams or even habits contributes to the DX [2]. Positive feelings towards the work are likely to contribute to a better DX.
2.7.3 Contribution
Another factor in assessing DX is how developers recognise the value of their work [2].
If a developer sees the value in their contribution, the sense of purpose, motivation, and commitment will likely increase, thus positively impact the DX.
Implementing technologies like UI libraries on existing FinTech solutions comes with many challenges in code, UI, and DX. A suitable way to evaluate the effectiveness of these is to create an evaluation framework respecting the existing system’s complexity, the need for intuitive UI’s, and good DX.
2.8 Evaluation Framework in Software Engineering
In software engineering, evaluating and choosing the appropriate technologies and method- ologies is essential to prevent technical debt and unnecessary resource usage. An evaluation framework consists of many criteria relevant to the context and aids in choosing a suitable approach by comparing several methodologies according to desired aims [8].
2.8.1 Important Metrics for Implementing UI Library
In FinTech, as introduced in 2.2, the UI is of great importance. Trust and credibility are key factors, and the design has to be unambiguous to enhance user engagement. When implementing a new set of UI components on an existing system, it is important to consider how these affect the UX, functionality and design.
UI libraries consist of a robust set of components available to use. These components are usually well tested, have high cohesion, low coupling and good readability. However, the challenge when implementing these components is how to assemble them without affecting the quality.
As presented in 2.5, code cohesion, coupling, and readability are dependable indicators of the implementation’s quality in software development. High cohesion, combined with low coupling, often implies good readability and maintainability. This combination usually correlates with a high quality of the software.
2.8.2 Methods for Obtaining Metrics
It is possible to measure the metrics mentioned in Section 2.8.1 by implementing a UI library designed with FinTech requirements in mind on an existing FinTech application. By identifying a suitable part of the system to work with, it is possible to understand how to assemble the UI components and implement them using refactoring and rewriting methods.
Consequently, it is possible to evaluate if the implementation affected the code in terms of cohesion, coupling, and readability by comparing the changes.
Since the cohesion metric prompts the single responsibility principle, the cohesion in mod- ern UI frameworks and components determines by assessing its responsibilities and number of shared properties. For instance, a component receiving properties that turns out to be un- used or is responsible for calculating two independent values indicates low cohesion.
Determining the level of coupling is made by examining the number of dependencies. For example, a component required to change another component to change itself indicates a high coupling. In other words, changing one part of the system should not affect the rest.
High cohesion and low coupling often indicate good readability; however, it is possible to determine the readability by the consistency between source code and comments, the
specificity of the identifiers, textual coherence, and comments readability [19]. Another indicator of readability is determining how readers other than the author self comprehend and perceive the code.
As mentioned in Chapter 1, developers tend to adapt and interpret new technologies differ- ently. When choosing how to assemble the UI library components, the choice tends to be influenced by personal preferences and experiences. Therefore, it is vital to determine how the implementation is perceived and experienced by developers destined to work with it and how these affect the implementation.
2.8.3 Different Ways of Evaluating Developer Experience
One way to evaluate the DX is by interviewing developers destined to work with the new implementation. Doing an interview makes it possible to understand how they perceive and recognise the developing environment, infrastructure, and proposed solution. The purpose of the interview is to identify which human factors there are and how they affect the im- plementation of new technologies. Additionally, to classify decisive factors in a complex development environment; by questioning the development process, conditions, and tools.
Another way of evaluating the DX is by performing an observational-based survey, in which the developers are observed in their natural working environment. This way, it is possible to apprehend how they work with the current system and get a sense of how they feel and experience it.
2.8.4 Evaluation of the Effectiveness of Implementing a UI Library in FinTech Effectiveness is the degree to which something successfully produces the desired result;
in this case, to which degree the implementation of a UI library on an existing FinTech application is successful.
The suggested interviews can help understand if the developers comprehend the proposed implementation and are likely to adapt. The interviews can also help indicate the solution’s quality and how the developers think about design when implementing.
In FinTech, it is vital to meet the requirements introduced in 2.2 and 2.3. Therefore, it is necessary to consider all decisive factors presented above and how they affect each other in a complex developing environment. By studying the implementation’s code and assessing how it is perceived and experienced by the people destined to work with it, it is possible to propose an evaluation framework that acts as a guide for evaluating the effectiveness of implementing a UI library in FinTech applications. An evaluation framework also aids in choosing and comparing several methodologies according to desired aims [8].
Moreover, it is relevant to identify relevant research challenges based on the discussed lit- erature to successfully determine the extent to which a UI library’s implementation is satis- factory.
2.9 Research Challenges
Chapter 1 presented several research challenges aiming to investigate how to identify the most suitable approach for implementing a UI library on a FinTech application and also in- vestigate the correlation between decisive factors to minimise the risks of using unnecessary resources.
The first challenge is developing a methodology to evaluate implementing a UI library on an existing FinTech application based on discussions in 2.2, 2.5, 2.6, and 2.8.
The second challenge is developing a methodology to evaluate how code cohesion, coupling and readability is affected when implementing a UI library based on discussions in 2.5, 2.6, and 2.8. In [19], the authors evaluated the effectiveness of refactoring code by comparing many changes before and after it is made. The work concluded that refactorings did not have the desired impact on code quality as the developer believed, indicating that code tends to be influenced by personal preferences. Additionally, [18] presents that developers tend not to choose a better solution even though they are aware of it.
The third challenge is identifying the differences between FinTech and other applications in UI based on discussions in 2.3 and 2.8. In [7], the authors highlight the importance of designing the UI based on what tasks the user needs to perform and considering the domain in which the system lies. Strengthen by the work of [11], in which the authors presents how emerging FinTech bestows new challenges, both within finance but also from a technical perspective.
The fourth challenge is developing a methodology to assess the DX when implementing UI libraries based on discussions in 2.7 and 2.8. In [2], the authors attempt to define DX based on familiar concepts such as user experience, customer experience, and brand familiarity.
The work does not describe how the developer experience affects the development process.
However, in [22], the authors identify the human factor as one of the essential factors in the development process and conclude that by considering it, productivity increases.
The discussion above indicated that implementing new technologies within domain-specific areas and complex developing environments comes with many challenges. Therefore, it is relevant to study how the implementation affects the design, code quality, and DX to minimise the risks of using unnecessary resources and improve productivity.
3 Solution Design
This chapter presents a solution design for the identified research challenges and the criteria for success. It sets the work scope, presents the methodology used to develop and test the solution, and discusses its limitations.
3.1 Proposal
Section 2.9 presented several research challenges relating to FinTech, UI, and DX. A solu- tion that implements a UI library in an existing FinTech application is proposed to address these subjects.
As discussed in Section 2.2, FinTech applications usually come with a complex developing environment due to the pressing demands on regulations and security. Using an existing FinTech application for this solution design makes it possible to examine the proposed de- cisive factors in a complex development environment and infrastructure and determine its effectiveness.
Regarding the UI, using an existing application with already established brand-familiarity and a trustworthy relationship with several consumers makes it possible to evaluate how the implementation affects the UI and UX.
Concerning the DX, the proposed solution makes it possible to assess how the developers operate and work on the existing application and how they experience implementing new technologies in their familiar developing environment and infrastructure.
3.2 Criteria for Success
In terms of the discussions in Chapter 2, the effectiveness of implementing a UI library in FinTech combines factors such as code quality, UI design, and DX to determine to which degree the implementation satisfy the desired goals. A solution satisfying high code quality, efficient UI design, and good DX is considered a success.
3.2.1 High Code Quality
Evaluating code helps determine whether the implementation’s effectiveness is successful concerning code quality metrics such as cohesion, coupling, and readability. The focus is on how the modification differs from the source code and how refactoring and rewriting methods affect the quality. In terms of this solution, high code quality means the solution should have high cohesion, low coupling, and good readability.
3.2.2 Efficient UI Design
The UI plays an integral part in establishing a trustworthy relationship with the consumers, and exchanging a familiar product UI with a new UI may affect this. Therefore, the focus is on determining to which degree the new UI design is efficient. In terms of this solution, efficient UI design means the solution should satisfy FinTech UI requirements presented in Section 2.3.2: data visualisation, human language, and product brand identity.
3.2.3 Good DX
DX relates to all activities a developer encounter during their work and tries to comprehend how human factors affect software engineering quality. In this solution, good DX means that people destined to work with the solution should perceive it as manageable and experience it as an improvement of the development infrastructure and environment.
Acknowledging the number of factors needing consideration and the work’s character relat- ing to FinTech, UI libraries, and developer experience, a suitable methodology to use is a company case study.
3.3 Company Case Study
Case studies attempt to understand and explain phenomenons or test theories in complicated environments with little control over the variables, using a wide diversity of data collecting methods, such as literature studies, interviews, or on-site observations. This work tries to comprehend how decisive factors in a complex development environment affect the imple- mentation of new technologies, and therefore a case study is a suitable scientific method.
As mentioned in Section 1.1, this work collaborates with a FinTech company, and for this case study, they serve as an example. The company has a variety of products in FinTech and consequently has many complex developing environments. One of these products is the Clearing Platform.
3.3.1 Clearing Platform (CP)
The Clearing Platform provides central counterparty clearinghouses with cost-efficient, high-velocity clearing, settlement and risk management capabilities for safe, efficient and reliable operations. The CP is a modular solution based on a distributed and service-oriented architecture and manages a broad range of assets classes, both on-exchange and OTS traded, supporting the implementation of various size and complexity, including multi-model, - currency, and -market organisations. One of these assets handles risk functionality, from now on referred to as the Risk domain.
3.3.2 Risk Domain of CP
The Risk domain of CP provides the functionality required to measure and manage risk in both cash and derivatives instruments, helping to ensure that risk breaches and violations do not go undetected. Some of the key features within the Risk domain is comprehensive risk and collateral management, real-time position keeping and allocations, and root cause
analysis for limit braches.
A domain, such as Risk, contains a UI to interact with its consumers. This work includes working with the Risk UI, a web application built with React.js and styled with CSS. This work focuses on refactoring and rewriting the Risk UI, meaning that the system’s underlying functionality and logic are untouched.
Even though the Risk UI holds a modern web-based UI, it is necessary to establish a brand- familiarity amongst other company products’. In other words, implement the User Interface Library.
3.3.3 User Interface Library (UIF)
UIF is a UI library consisting of several UI components created for the company’s products.
UIF builds on existing best practices in frontend development and UX design. It aims to provide a robust set of base-level components and create solutions for broader use cases that modern web applications need.
The UI components’ design is based on the company’s branding guidelines and builds on React.js and styles with styled-components. UIF is made accessible for company develop- ers via Storybook.js, a JavaScript framework making it possible to display UI components with use cases, examples of code and documentation. The UIF library is divided into five categories presented in Table 2.
Table 2 User Interface Library Categories Category Description
Layout Components used for distributing and aligning other components.
Icons Components used for indicating system functionality such as navigation and actions.
Forms Components used for handling user input in various ways.
Charts Components used for visualising data in charts such as area, bar, pie, his- togram, amongst others.
Lab Components that are not thoroughly tested in production yet.
Others All other components not fitting the categories mentioned above.
To ensure brand identity, UIF uses the Company Style Guide, a document providing guide- lines for how the company brand should present, both from a visual and language perspec- tive.
3.3.4 Company Style Guide
A style guide aims to ensure that multiple contributors create designs and content clearly and coherently. In this case, the Company Style Guide provides guiding when creating new designs and developing UI’s that should reflect the company brand. For this work, the Company Style Guide aids in taking decisions regarding the UI when assembling UIF components or when UIF can not provide components with the required features.
As mentioned in Section 3.3.2, this work concentrates on the Risk domain of the CP product.
Therefore it is relevant to set the scope by reviewing the domain and its views.
3.4 High-Level Architecture
To clarify this work’s scope, Figure 1 presents the CP products’ high-level architecture. The product consists of external APIs and a user interface. The user interface consists of several micro UI’s and each of these communicates with its corresponding API to provide different clearing capabilities.
This work includes the following parts: Risk UI, User Interface Framework, and Develop- ers; everything else is considered out of scope.
Figure 1: High-Level Architecture
However, the Risk UI consists of several different pages with different purposes and func- tionality. By reading the CP code base, all the defined pages are found in the URL schema.
Visiting each page shows that the layout is considerably similar and beneficially groups into the categories presented in Table 3.
Table 3 Layout Categories of Risk UI Pages Category Description
Table Consists of a table displaying data based on search and filter values. The table itself also holds various commonly used actions such as export, reset, column selection.
List Consists of a list with expandable rows containing selectable items for a more detailed view.
Overview Consists of several boxes containing different data and components.
Others Pages not fitting above mentioned categories.
One page from each layout category is selected for UIF implementation and used as proof of concept for the case study to limit this work’s scope. Table 4 presents the selected pages and their category. The pages are arbitrarily named. For example, ”Haircut Backtest” refers to the methodology used when evaluating trading strategies backtests.
Table 4 Selected Pages for UIF Implementation Category Selected Page
Table Reverse Credit Stress Test List Monitoring All Channels Overview Monitoring Overview Others Haircut Backtest
As discussed in Section 3.3.2, the focus of this work is implementing UIF on the Risk UI using refactoring and rewriting methods and to do this; an iterative methodology is utilised.
3.5 Methodology
The implementation of UIF in these pages is made by utilising an iterative methodology named Design-Build-Test (DBT). In this case, this is a suitable method because the method aids in iteratively enhancing software engineering capabilities and represents a more sys- tematic and efficient approach when working with code [24]. Figure 2 presents the iterative process of DBT and how this work applies to it.
Figure 2: Design-Build-Test Iteration
For instance, to be able to replace a current component in the Risk UI. An equivalent com- ponent in UIF needs to be identified, exchanged using refactoring or rewriting methods, and examined to determine whether the logic and functionality are affected. In this case, DBT is a suitable process because if a component breaks during the iteration, the method allows us to iterate the exchange again. As shown in Figure 2, the process consists of three phases named Design, Build, and Test and to ensure reproducibility, the following sections explain what to do in each phase.
3.5.1 Design
As presented in Figure 2, the design phase consists of the targets and current design; in this case, UIF and the Risk UI. This phase aims to frame the problem by selecting a Risk UI component and identify its corresponding component in UIF. In this situation, corre- sponding means that both the selected and identified components provide similar logic and functionality. For example, how a selected and identified button component should provide disabling logic and on click functionality.
To aid in identifying the corresponding component, the company provides mock-ups, which resembles the Risk UI using UIF components for each selected page presented in Table 4.
For example, one iteration of the design phase selects a button component from the Risk UI and identifies its corresponding component in UIF using the provided mock-up.
If there is no corresponding component, a new component is created based on the given design in the mock-up by assembling the new component using existing UIF components.
However, if the mock-up prompts extra functionality not provided by the UIF components.
A new component is designed using the Company Style Guide mentioned in Section 3.3.4 and created in the build phase.
3.5.2 Build
As presented in Figure 2, the build phase consists of generating alternatives based on the framed problem. In this case, either refactoring or rewriting methods is used to convert the selected component. Which method to utilise depends on whether the design phase identified corresponding components in both UIF and the Risk UI. Each refactoring and rewriting method utilised during the build phase is documented and used when evaluating the code.
If the selected and identified component is corresponding, a suitable method to use would be refactoring. For example, if the corresponding components named their disabling property differently, the ”Rename Parameter” refactoring method is suitable. Table 5 lists some refactoring methods and explain when and how to use them. More methods are available in [5].
Table 5 Refactoring Methods
Method Problem Solution
Extract Method Fragments of code doing the same thing.
Move code to separate function and replace the code with a call to this method.
Extract Variable Code contains an expres- sion that is hard to under- stand.
Place expression in a vari- able and replace the expres- sion.
Inline Method Method body is more obvi- ous than the method itself.
Replace method call with method body.
Remove Assignments to Parameters
Some value is assigned to a parameter inside method’s body.
Use a local variable instead of a parameter.
However, an important consideration is that the design phase may not find a correspond- ing component; a suitable method would then be rewriting. For example, if the selected component provides functionality not provided by a single UIF component, the ”Break Out Method” rewriting method is suitable to accommodate UIF assembling. Table 6 lists some rewriting methods and explain when and how to use them. More methods are available in [4].
Table 6 Rewriting Methods
Method Problem Solution
Break Out Method Component has multiple re- sponsibilities resulting in long and complex code.
Extract code into smaller methods or classes.
Pull Up Feature Methods in child compo- nents does the same thing.
Make methods do the same thing and move to parent component.
Push Down Dependency Component handles prob- lematic dependencies for child component.
Move dependencies to child component.
Parameterise Method Method creates object within method body.
Pass object as parameter.
In some cases, it is necessary to use refactoring and rewriting methods to exchange a se- lected component successfully. For instance, if the selected component consists of an input field and a button and that UIF does not provide a component consisting of these but pro- vides an input field component and a button component. The input field can use rewriting methods and button refactoring, or vice versa.
As mentioned in Section 3.5.1, new components are designed if the mock-ups prompt ad- ditional features. When creating these, the code quality metrics mentioned in Section 2.6 needs consideration. For example, Figure 3 shows code creating a component that triggers a modal; this requires using the UIF button and modal component.
1 const SomeComponent = () => {
2 const [open, isOpen] = useState(false)
3 return (
4 <Container>
5 <Button onClick={() => isOpen(v => !v)}>
6 Open Modal
7 </Button>
8 <Modal open={open}>
9 Modal Content
10 </Modal>
11 </Container>
12 )
13 } 14
Figure 3: Example of Created Component during Build Phase
In this case, cohesion is considered by placing these in the same component, coupling by limiting the number of components the button affects, and readability by providing the context of how the modal is triggered.
3.5.3 Test
As presented in Figure 2, the test phase consists of evaluating the generated alternative. In this case, evaluating whether replacing the selected component with the identified compo- nent affected the underlying logic and functionality by setting up a user story. For example, a clicked upon button should trigger the same action before and after replacing the compo- nent.
If the evaluation shows that no underlying functionality or logic is affected, replacing the component is considered a success. However, if the evaluation shows that the component lacks functionality or changes logic, the DBT cycle is repeated.
3.6 Limitations
The presented solution comes with some limitations. Since the solution only focuses on one business domain, the solution is limited in missing out on other functionality that may affect the UIF implementation. Even though the pages have similar layouts, the functionality and purpose differ. Selecting only one page from each category for the case study limits the solution by possibly missing out on using different UIF components.
The suggested agile methodology also comes with some challenges. In the design phase, the provided mock-up’s may lack or have additional design suggestions or requests, making it harder to identify the corresponding UIF component. The same goes for the build phase;
if the mock-up’s lacks or have additional functionality, the building requires more time and resources when implementing.
4 Implementation
This chapter presents the implementation made based on the solution design. It gives a more detailed description of meaningful choices made during the implementation and provides examples of code and UI. The components mentioned in this chapter are arbitrarily named;
for instance, the ”Reverse Credit Stress Test Page” allows the user to trigger a reverse credit stress test and search amongst existing test.
4.1 Low-Level Architecture
Section 3.4 presented a high-level architecture to set the scope for this work. To provide more context of the relevant parts used in the implementation, Figure 4 presents a low-level architecture.
Figure 4: Low-Level Architecture
The Risk UI consists of the Main Page, which consists of five different components: Nav, Head, Help, Tabs and the Risk Switch. Table 7 presents a brief explanation of what they provide. Each page in the Risk Switch uses the Page Component, a reusable component providing a consistent page layout with expandable areas.
Table 7 Explanation of Main Page Components Component Description
Nav Provides navigation for the system in the form of a sidebar with links.
Head Provides a header for each page based on URL.
Help Provides contextual help for each page based on URL.
Tabs Provides a panel of tabs based on URL.
Risk Switch Show different pages depending on URL.
During the implementation and DBT iteration, there were some components that UIF did not provide and some features not existing in the system but opted for in the provided mock- up’s, resulting in creating new components.
4.2 Created Components
This section aims to provide a more detailed description of new components created during the implementation.
4.2.1 Page Component
The Page component did not exist before the implementation but existed in the provided mock-up’s. The component considers all the different layouts for the selected pages and provides a consistent page layout with expandable areas.
The component is created as a functional compound component, meaning that the compo- nent provides functionality by utilising other components; in this case, using other compo- nents such as the Top, Left, Right, Bottom, Quick Action and Main component. Each of these components represents an area within the page, see Figure 5, and a page can consist of one or several areas.
Figure 5: Page Component Areas
A compound component, such as the Page component, provides contextual help of using other components by grouping them and by providing context, the readability improves.
Because it is possible to use each component belonging to the compound in any other cir- cumstances and none of them is dependent on one another, both low cohesion and high coupling is maintained. For instance, the code presented in Figure 6 exemplifies how the Reverse Credit Stress Test Page uses the Page component.
1 <Page>
2 <Page.Top>
3 <StressTestSearchForm />
4 </Page.Top>
5 <Page.Main>
6 <ReverseCreditStressTestTable>
7 <TriggerReverseCreditStressTestButton />
8 </ReverseCreditStressTestTable>
9 </Page.Main>
10 </Page>
Figure 6: Example Utilising the Page Component
The code in Figure 6 shows that the Reverse Credit Stress Test Page only uses the Top and Main area. Also known as the Table layout as presented in Table 3, without using other components belonging to the compound.
4.2.2 Help Component
A feature requested in the provided mock-up’s were contextual page help. The component aims to provide help in a short descriptive paragraph and a list of its attributes, which means adding a button accessible on every page that opens a side drawer containing the text. The information displayed in the drawer is stored in a page object containing a title, text, and a list of attributes. These page objects are stored amongst all other pages in a data object and fetched by providing the getHelp-function with the active page id; in other words,
performing a key lookup. A key lookup only searches for the given key, meaning the search does not have to search the entire page object to find the correct data. Figure 7 presents an example of the page and data object, and the getHelp-function.
1 const reverseCreditStressTest = { 2 title: "Reverse Credit Stress Test"
3 text: "The goal of the Reverse Credit Stress Test is to find..."
4 attributes: [
5 {id: 1, label: "Silo", value: "The silo to calculate in."}
6 ]
7 } 8
9 const data = {
10 reverseCreditStressTest, 11 monitoringOverview, 12 haircutBacktest, 13 }
14
15 export const getHelp = (pageId) => data[pageId]
Figure 7: Contextual Help Object
The provided mock-up used existing UIF components to create the design, making it pos- sible to create this component by assembling them. The newly created Help component consists of the Help Button component and the Help Drawer component, see Figure 8.
1 const HelpButton = () => { 2 const dispatch = useDispatch() 3
4 return (
5 <CircleButton onClick={() => dispatch(isOpen(true))}>
6 <FontAwesomeIcon iconClassName="fa-question-circle" />
7 </CircleButton>
8 )
9 } 10
11 const HelpDrawer = () => {
12 const dispatch = useDispatch()
13 const { open } = useSelector(state => state.help) 14 const { page } = useActivePage()
15 const text = getHelp(page.id)
16 const body = text ? createBody(text) : empty 17
18 return (
19 <Drawer isOpen={open}>
20 <DrawerHeader toggle={() => dispatch(isOpen(!open))}>
21 Page Help
22 </DrawerHeader>
23 <DrawerBody>
24 {body}
25 </DrawerBody>
26 <DrawerFooter>
27 <Button onClick={toogle}>
28 Close
29 </Button>
30 </DrawerFooter>
31 </Drawer>
32 )
33 }
Figure 8: Help Component in Code
The code in Figure 8 shows that the Help Button triggers the Help Drawer to open or close, and the Help Drawer fetches data based on the URL and renders it.
4.3 Implementation of Selected Pages
In terms of this solution, one page has different purposes, layouts and provides various functionality. For instance, the Reverse Credit Stress Test Page allows the user to trigger a reverse credit stress test and search amongst existing test.
4.3.1 Reverse Credit Stress Test Page
The Reverse Credit Stress Test Page was one of the pages selected for the UIF implementa- tion. Figure 9 presents the difference regarding the UI before and after the implementation.
(a) Before
(b) After
Figure 9: Reverse Credit Stress Test Page UI Comparison
The Reverse Credit Stress Test Page belongs to the Table layout category presented in Table 3, meaning that the layout consists of a table displaying data based on search and filter values. In Figure 9 (a) all the user functionality is placed above the table. Compared to Figure 9 (b) where all functionality related to user input is placed in the top area of the Page component, allowing the user to minimise the area and focus on the displayed data.
Concerning the code, the page consists of the Stress Test Search Form and the Reverse Credit Stress Test Table. The Stress Test Search Form consists of several input fields, but- tons for submitting, clearing, saving, and quick search. The Reverse Credit Stress Test Table displays data based on the search criteria provided in the Stress Test Search Form.
