Designing "Landing Page" for Websites Based on the User Experience: Review, Analysis, and Interpretation

*Luiza Fabisiak and Barbara Jagielska*

## **Abstract**

The primary web design method is user experience-based "landing page" web design. It enables you to expand the reach of a particular company, institution, or application. It aims to present́the most relevant information on the owner's website. A simple approach, such as split A/B testing, can provide reliable data because it includes an appropriate set of alternatives. This article provides an overview, analysis, and interpretation of the results obtained. It presents good and bad practices of existing landing pages. The approach showed optimal solutions in aggregate, segmented, and individual site users.

**Keywords:** UX, user experience, landing page, Adobe creative suit, website, webpage, A/B tests, CTA, dark patterns

## **1. Introduction**

Nowadays, when creating a brand, or a product, one should take proper care of its advertising and kind of image. You need to clearly define the vision - what the product will be associated with, whether it is good enough and whether there will be demand for it. In the online world, achieving such a goal is much simpler than in the past - you can set up a website to present your offer. However, there are challenges involved competition is even more significant than ever. You need to be original and, at the same time, follow current trends and outlined guidelines. It is necessary to exist and prove that life with our product will turn out to be simpler, more functional, and easier to use. A landing page was created to understand our clients and know their needs to encourage them to buy or make a specific profit. This page contains all critical information about the potential customer while offering relevant product information. Creating a catchy landing page requires a wealth of knowledge in the fields of user experience, web architecture, marketing, and analysis of the data collected by the owner. This study aims to analyze and interpret the perception of website landing page prototypes and their templates created with Adobe software by users of different age groups based on user experience.

## **2. Overview of methodologies and techniques for creating a landing page based on user experience**

A landing page, otherwise known as a landing page, allows you to expand the reach of a particular company, institution, or application. Its purpose is to present the most relevant information on the owner's website. Users are redirected to a landing page when they click on a link, advertisement, newsletter, or even online shopping. Thus, it is a page to which one is redirected - usually from other portals. However, one can also be redirected within a given system, site, or application - for example, to another tab, such as purchasing or signing up for a mailing list. Profit is the key word - a landing page is supposed to provide profit - in the form of financial, more observers, more demand for a particular product, or simply visitors to the site [1].

A landing page is directly related to concepts such as Google Ads, Google Analytics, or at least the user experience itself - its task is to gather information from users or, more specifically, to motivate them to perform the actions on the page. For example, registering on a website, signing up for a newsletter, or purchasing a specific product or service [2]. The task of a landing page is to attract as many users as possible to act. For this reason, tools such as Google Ads and Google Analytics are needed to control, and analyze users' data, track their movements inside the site and advertise to get them to the landing page. Google Ads and Google Analytics are undoubtedly some of the more critical user experience tools - with them, you can improve the content found on portals or web vortals.

A landing page has several essential elements that must be present on it. Among the most critical components of a properly executed landing page are:


Like any website, a landing page should also be fast, mobile-friendly, and secure [3]. The landing page can be divided into:


A landing page is an excellent tool for market research, competition, and analysis [4].

## **2.1 Methodologies for creating and elements of UX-oriented landing pages**

Google Ads and Google Analytics play a significant role in landing page design. Thanks to them, the portal owner, or UX designer, can create the ideal marketing persona or document for the prospects who use a given site. Thanks to these tools, we can find out who is interested in the content appearing on a page. We can find out, for example - where the person is from, their age, education, or employment. Of course, these are not the only supporting tools. Based on this information, an experienced UX designer can determine a prospect's motivations and concerns. What influences their decisions, what their typical day looks like, or what goal they want to achieve by using the service are additional information that can infer from this information [5].

#### *2.1.1 CTA, or call to action*

A vital landing page element is the so-called CTA button or calls to action button. It is usually located in a prominent place in the very center of the site. It should stand out from other elements. This button is supposed to convey clear and precise information what will happen when the user clicks on it? The information should be short, concise, striking, and simple in its message.

#### *2.1.2 Graphic interface and typography of the landing page*

The essence of most websites, including landing pages, is their design. The characteristic elements of a landing page, for example, are the CTA mentioned in Section 2.1.1. However, a call to action is not the only element of a landing page.

Limited text is a must. Fineness and detail are by no means advisable when designing such a page. What matters is the quick transmission of the essential information. Usually, it is the first seconds of the reception of a given site that determines the attraction of the viewer's attention [6].

The text is naturally connected with the font, size, type, or placement. Typography is an essential aspect of a landing page. The placement of typography depends mainly on the background and the page's image. In addition, it is a good idea to vary the size of fonts for headings and buttons versus the page content itself. Line spacing is also crucial, as well as line width - the maximum width is about 70 characters, corresponding to the width of A4-sized text [7]. The text must also contrast well so that it is easy to read. At most, the site should have two fonts - for example, headlines and text. It is also good practice to choose "standard" fonts - ones that the user has probably seen before (e.g., Helvetica or Arial).

Testimonials or customer logos are an exciting element that may or may not appear on our landing page. Testimonials are short videos usually containing a customer's opinion about our product. In it, he expresses his experience with it. They help and encourage a potential future observer of our site to make a purchase. Logos of known or existing customers, on the other hand, will inspire confidence that our product is made reliably and that someone is already using it. Any certificates, awards, or prizes in competitions can also be an additional asset [8]. Another confidence-inspiring element can be to show your contact information, such as your phone number, email, or business address.

## *2.1.3 Dark patterns*

Dark patterns are deliberate practices that various companies or institutions use to achieve certain benefits, usually marketing or financial [9]. While these practices are legally legal, they are hardly ethical solutions. Therefore, it is quite a risky user experience practice.

These are online behaviors designed to manipulate viewers into doing something they **do not** necessarily want to do, such as joining an unsolicited newsletter to access a particular website or read an article.

Dark patterns can include, for example, bait and switch, forced disclosure, roach motel, forced continuity, friend spam, misdirection, sneak into the basket, confirm shaming, trick questions, privacy Zuckering, triggering fear, and disguised advertisements [10]. In **Figure 1**, you can see a typical example of a dark bait and switch pattern. This is one of the more commonly used dark patterns. It deceives the viewer by displaying several links, buttons, or redirection options on a given area of the website. In this situation, the user is often misled and does not necessarily click on the link they wanted. Clicking on another can, for example, download an unwanted program or, as in the example below, update your computer system.

Dark patterning is very controversial among the design community or web architects. Undoubtedly, they can bring a lot of benefits to a given site. However, it can also harm it. Viewers can easily be discouraged by such practices and thus abandon visiting a particular site. Equally, many corporations use them for their profits, but many abandon them for the sake of ethics and certain unwritten norms [12].

## **2.2 Examples of good and bad practices in landing page design**

A landing page is also a website, so creating it should be guided by existing design principles. The fundamental rules are user experience, **esthetics**, Gestalt principles, limited color palette, fit for mobile devices, security, and typography [13]. However, the landing page has a couple of elements that need special attention - these are what distinguish it from other tabs on a given website.

**Figure 1.** *Example of recipient deception, bait, and switch [11].*

*Designing "Landing Page" for Websites Based on the User Experience… DOI: http://dx.doi.org/10.5772/intechopen.109240*

#### *2.2.1 Good practices*

One of the correct practices is a *header that precisely indicates the value* - the button should be above the fold. This element should be the most visible element on the page.

Another important aspect is the **form** - how long it should be and whether it collects only the most relevant user information. For example - an irrelevant piece of information will be the user's ownership of animals if you have a stock market website. From the perspective of meeting a business objective, you need to make sure that it is of sufficient length and that it does not also collect sensitive data from the recipient. Many users may become discouraged and not visit the site in question. The collection of sensitive data must be justified and explained [14].

**Simple design** is undoubtedly a trend in recent years in the design of all kinds of web pages. However, designing a landing page also has another use - it focuses only on its most crucial element - conversion, i.e., acquiring contact and then profit (e.g., selling a product, joining a mailing list). Distracting the viewer with an overly creative and colorful page is not advisable [15].

From a marketing perspective, page load time is essential for a landing page. According to a Google study, only 15% of respondents met the goal of loading a page in no more than 5 seconds [16]. This is an essential factor as it affects the final audience.

Another good practice in landing page design is a **graphic** or **video** showcasing our site's product. This is a very modern trend that can become a factor in attracting even more watchers. Interest in the product is one aspect, but if it is shown in an attractive, interesting, creative way - it will attract more takers. Recently, a very commonly used scheme is videos that stretch across the entire screen resolution, but you must remember to optimize these videos. They can slow down a given page a lot [**14**]. Often an adequately selected graphic is called a **"**hero shot.**"** If the photo, the graphic, supports the message, the intention of the page, and fits the offer - it means that it was chosen correctly [**8**].

Critical practice is **customer feedback** - very often, we check the observations and ratings of others on a product. Their insights can warn against a potentially unsuccessful purchase or encourage us to make a good investment. It's worth posting them somewhere in the middle or end of our landing page - an essential and good practice but not the most important one from a marketing perspective [17].

**Concise and understandable** is the key to a well-executed landing page. The page should convey as little content as possible, which at the same time will be overflowing with helpful information. It is worth operating with the so-called **"**language of benefits**"** - what the user will gain by owning the product and what conveniences accompany the purchase. The creation of a personal document allowed the creation of more targeted content by understanding consumer needs [**18**].

#### *2.2.2 Malpractices*

**Placing navigation at the top of our website can discourage the user** - he will quickly change our site to another one. Any buttons should be in the center of our subpage. The lack of user interaction makes our landing page just an ordinary website. Conversion is a critical element of a landing page and should not forget - it is not only an unfair practice but also considerable negligence.

**Complicated design** only distracts the potential user. The recipient will most often abandon the use of our site without reading the information on it.

If the page takes **too long to load**, it will easily discourage a prospective buyer from doing anything. If the page does not load quickly, the recipient may assume that the services offered by the owner will not be of very high quality either, or perhaps will not reach him. It is, therefore, worth optimizing this page.

A **mismatched ad** on the landing page will confuse any viewer. The user needs to know that they have come to the right place. Hence the ad must contain the same message. Raising doubts in observers is not advisable [17].

## **3. Landing page prototypes**

They made four pairs of prototype landing pages to test users' general knowledge of web design and user experience. In each of the five pairs of landing page prototypes, you can see the differences between versions A and B. For simplicity, version A is at the top of a given pair - version B at the bottom. The prototypes were made so that in some of the pairs, the differences were already apparent when first looking at them. In others, the differences are only apparent on closer inspection. The prototypes presented were also arranged the same way in the survey - as the first set varies the most. Thanks to this procedure, it was also possible to differentiate the approach of the respondents - whether they focused their attention on the general, the whole, or the details of the pairs of prototypes. A pair of prototypes that differed little would define the respondents' approach to focusing only on the details. The landing page prototypes differed in typography, color scheme, overall visual aspect, as well as on the quality of the selected images, and a modern approach in design such as neomorphism, in which 2D or 3D elements take on a background color giving the impression of being very uniform, even merged.

During the creation of the prototypes, followed both good and bad design practices to determine whether the average web user can perceive these differences and has a basic knowledge of web design, in this case, landing pages.

The prototype presented is "Veggie's," whose differences are immediately apparent the A version has less opacity and has only one typographic font. The elements do not generally contrast as well as in the B version. Version B additionally uses two font types for the informational text and a standard font for the logo and the button with the CTA. In addition, the A version logo washes out the background color is taken from the darkest point of the background photo, whereas in the B version, the white color contrasts with the photo. It enhances the logo, and it is more readable.

Therefore, version B is the correct version regarding user experience and design principles (**Figure 2**).

The next pair of prototypes show the hotel accommodation search service "hotelandresortspa.eu". The main difference in this pair is the color scheme of the two versions - the first is dominated by purple-blue, while the second is pink. In both versions, they are **esthetically** pleasing and match the background photo. According to design rules, however, the color scheme should relate to the background photo - so in theory, users should lean towards version A (**Figure 3**).

However, many users subconsciously choose solutions that feature contrast, characteristic of design trends in the past. Thus, it can conclude that both are done correctly in this pair of prototypes, but one is more in line with today's standards. However, it is likely that both, with a larger sample of users, would be considered correct - depending on the user's age, i.e., the likely seniority of Internet use and their preference for site design (**Figure 4**).

The final prototype is a prototype in which current web design principles create versions A and version B. Version B uses neomorphic elements - elements that merge colorfully with the background elements modeled on 3D graphics (**Figure 5**).

*Designing "Landing Page" for Websites Based on the User Experience… DOI: http://dx.doi.org/10.5772/intechopen.109240*

**Figure 2.** *First pair of prototypes.*

**Figure 3.** *Second pair of prototypes.*

**Figure 4.** *Third pair of prototypes.*

**Figure 5.** *Fourth Third pair of prototypes.*

*Designing "Landing Page" for Websites Based on the User Experience… DOI: http://dx.doi.org/10.5772/intechopen.109240*

On the other hand, Version A is a more conservative version, probably appealing to a larger audience in general. Version B is the version for younger users who may have been exposed to the trend of neomorphism in many applications - it is nothing new or revelatory for them. It is more natural. It is worth noting that in the pairs of prototypes produced, it is impossible to determine which version is prettier clearly this is a very subjective evaluation of each user. However, one can be guided by current design trends and user experience principles in such a way that one can determine which version is better and more functional. Also, notably, it included no dark pattern in the manufactured prototypes. Research on the manufactured prototypes is presented in the following subsection of the paper.

## **4. A/B testing analysis of the created landing page prototypes and surveys**

Performed A/B testing of the created prototypes and surveys for testing. The purpose of A/B testing was to test the knowledge of the basic principles of website creation websites - in this case, landing pages - of users of different age groups and their personal preferences. The survey involved 451 users, including both men and women.

#### **4.1 A/B tests**

The user was allowed to make a single choice in the choice tests between two versions of the prototypes - versions A and B (**Figure 6**).

**Figure 6.** *Query in the test.*

The command "Choose the version of the site that you think is better" has been specially constructed - so that the user does not suggest only one factor but the whole and complete site. Not necessarily just the appearance but also the functionality or a more modern approach to design. It assigned the command to each of the five pairs of prototypes.

## **4.2 Survey construction**

The survey for A/B testing consisted of seven questions. Each question in the survey was mandatory and had clear answer guidelines - only one answer was always possible. The survey did not contain open-ended questions. It avoided answers that were not detailed enough or answers that were not relevant to the topic of the work.

The first question was a gender question, in which one could choose the "Female" and "Male" answers.

In addition, users were divided into four age groups:


The next question asked about the frequency of Internet use. The question was asked in the form of a linear scale, from 1 to 5, where 1 - very rarely and 5 - very often. The amount of time spent, such as the answer "5 hours a day," was unnecessary in this question. What mattered was the user's subjective assessment, which made it clear whether they had daily contact with websites.

The next question was, "Do you often pay attention to the appearance of websites?" The answers were:



Responses to this question in a later survey made it possible to divide users into those who pay more attention to the details of the sites, the esthetics, and those who are not influenced by the site's appearance—also tested familiarity with the concept of

**Figure 7.** *Survey query for A/B testing.*

a "landing page" during the survey execution. The next question was about this term not everyone may have been familiar with it (**Figure 7**).

The next question in the survey was, "When performing A/B tests, did you pay attention to page details?" Possible answers to mark were:


Since users can be divided here into visual and more interested, this is a fundamental question for the survey. This is because some users may not have noticed any differences between the A and B versions despite the specially selected order of prototypes in the A/B tests. Others, on the other hand, may have looked all too closely for some hidden content on the site after the first pair of prototypes without focusing on the site.

The last question was about performing A/B tests in the past. This question was strictly informational and did not change the subjective feelings about a particular pair of user prototypes. One can only assume that a user who had once performed such tests would approach the task more generally because he knew what to expect when performing the test.

## **5. Analysis and interpretation of the results of A/B tests of surveys**

Simplified in work where the analysis and interpretation of data, A/B testing, and a survey through a single form via Google. This allowed us to see correlations between users' choices regarding their age, gender, or frequency of Internet use. The form was divided into the A/B tests and the survey. Completed the form by 451 people, including 180 men (39.9%) and 271 women (60,1%). 85 participants (18.8%) were aged 10–22, 148 participants (32.8%) were aged 23–30, 111 (24.6%) were aged 31–45, and 107 participants (23.7%) were over 46 years old. For the question "Do you often use the Internet?", where 1 is very rarely and 5 is very often, the number of respondents was as follows: 1–3 respondents (0.7%), 2–7 respondents (1.6%), 3–29 respondents (6.4%), 4–61 respondents (13.5%), 5–351 respondents (77.8%) (**Figure 8**).

#### **Figure 8.**

*Survey results relative to the frequency of Internet use.*

About 67.6%, or 305 of those filling out the form, pay attention to the functionality of the site, not the look of it. In contrast, as many as 17.7%, or 80 respondents, believe that the website's appearance is the most important thing. 11.3%, or 51 respondents, focus only partially on the website's appearance. The rest, or 15 people (3.3%), do not focus on web design (**Figure 9**).

Of all respondents, as many as 55.2%, which equals 249 recipients, knew what a landing page was. The rest, 44.8%, 202 recipients, did not know the term (**Figure 10**).

Before choosing version A or version B, A/B testing of landing page prototypes was looked at by 274 people. They paid attention, for example, to the size of the fonts, their type, and the color scheme of the prototypes. 37.9% of the respondents, or 171 people, looked at the prototypes more holistically. However, they noted differences between the A and B versions. Only six individuals (1.3%) did not pay particular attention to the differences between the A and B versions.

Of those surveyed, as many as 241 had already performed A/B tests in the past (53.4%). The remaining 210 (46.6%) performed such tests for the first time (**Figure 11**).

For each pair of prototypes, the results were as follows:

• "Veggie's" - A version 11.5% (52 respondents), B version 88.5% (399 respondents) (**Figure 12**)

**Figure 9.**

*Survey results relative to paying attention to website design.*

*Designing "Landing Page" for Websites Based on the User Experience… DOI: http://dx.doi.org/10.5772/intechopen.109240*

**Figure 10.** *Survey results on familiarity with the landing page concept.*

**Figure 11.** *Survey results on prior performance of A/B tests.*

**Figure 12.** *A/B test results for a pair of prototypes "Veggie's".*

### *Updates on Software Usability*

The results by gender are as follows: For prototype one, 34 women chose version A (12.5% women), and as many as 237 women chose version B (87.5% women), whereas 18 men chose version A (10% men), while version B was chosen by 162 (90% men). This means that the results for the first pair of prototypes were very similar in percentage terms. There is no significant difference in gender with the first pair of prototypes.

• "hotelandresortspa.eu" - Version A 64.5% (291 respondents), version B 35.5% (160 respondents) (**Figure 13**)

In this pair of prototypes, as many as 168 women chose version A (62% women) and 103 version B (38% women). Men chose very similarly in percentage terms - 123 chose version A (68.3% of men) and 57 version B (31.7% of men).

• "homeDESIGN" - version A 86.5% (390 respondents), version B 13.5% (61 respondents) (**Figure 14**)

**Figure 13.** *A/B test results for a pair of prototypes "music.com".*

**Figure 14.** *A/B test results for a pair of prototypes "homeDESIGN".*

*Designing "Landing Page" for Websites Based on the User Experience… DOI: http://dx.doi.org/10.5772/intechopen.109240*

In this pair of prototypes, there are slight differences in the choice between versions A and B regarding gender. As many as 227 women (83.8% women) chose version A, whereas 44 women (16.2% women) chose version B. 163 men (90.6% of men) chose version A, while the rest (9.4% of men) - 17 men - chose version B.

• "music.com"- A version 31% (140 respondents), B version 69% (311 respondents) (**Figure 15**)

In the last pair of prototypes, there were also no significant differences in the choice between the sexes. Women chose as follows: Version A by 83 women (30.6% of women), Version B by 188 women (69.4% of women). Among men, the results were as follows: 57 men chose version A (31.7% of men), while version B was chosen by 123 men (68.3% of men).

Because of the respondent's answers, the conclusion is that they prefer the appearance of prototypes that conform to generally accepted design principles 36 regardless of gender. The differences in the choices of the different versions were insignificant in the survey.

In the entire survey, a total of only 10 people very rarely or rarely (responses with values of 1 and 2) used the Internet. These included two men and eight women. All users, except for one woman in the 31–45 age category, were over 46 years old (**Figure 16**).

In **Figure 16**, we can see that three people chose "I pay moderate attention to the site's appearance," Four chose "I pay attention to the site's appearance, but more to its functionality," and the rest chose "No, I don't pay attention to it at all." In the first two pairs of prototypes by a majority (9 out of 10 votes), these people chose version B - the correct version in terms of user experience. In the third and fourth pairs of prototypes between versions A and B, the scores were 5 for both versions. In the fifth pair of prototypes, there were 4 A, and 6 B responses - the correct version here was B.

For the question "Did you pay attention to the details of the pages when doing A/B testing?" Six respondents did not pay particular attention to the differences in the prototypes. All of these people, except one in the 10–22 age group, were older than 46. Only three of them knew what a landing page was, including the person in the youngest age group.

**Figure 15.** *A/B test results for a pair of prototypes.*

#### **Figure 16.**

*Distribution of responses for very infrequent and infrequent use of the Internet in terms of paying attention to the appearance of websites.*

In the question "Do you often pay attention to the appearance of websites?" many as 15 respondents do not pay attention. Only one of these people knew what a landing page was. These people also answered the frequency of Internet use - each gave a different answer from 1 to 5, in the same question, seven users. Interestingly - as many as 7 of these people answered, "I looked carefully before choosing the version they looked at before choosing version A or B, e.g., the size of the fonts and their type, color scheme, etc.". This indicates that they probably pay attention to the appearance of websites daily, however.

Additionally, in the question: Paying attention in the prototype to the details between versions A/B - 159 women (58.6% of all women) and 115 men (62.8% of all men) said they looked at the site closely before choosing the better version.

In contrast, in the general question: The appearance of websites - 49 women (18% of all women) and 31 men (17% of all men) believe that the look of a website is most important.

In addition, I calculated the mean and median for the Internet frequency rubric on a scale of 1 to 5. The mean was 4.66, while the median was 5. Thus, most users have constant contact with websites.

## **6. Conclusion**

The paper presents an analysis and interpretation of the perception of website landing page prototypes and their templates created with Adobe software by users of different age groups based on user experience. The analysis presented shows that, depending on age, users have different preferences about the appearance of the websites in question. It is due to contact only with the latest design trends of younger people. Most likely, users have not all been exposed to other web design principles. From a young age, users are present with more **esthetically** pleasing websites. On the other hand, it**'**s somewhat of a novelty for older users.

*Designing "Landing Page" for Websites Based on the User Experience… DOI: http://dx.doi.org/10.5772/intechopen.109240*

Due to the respondents**'** responses, the conclusion emerges that they mostly prefer the appearance of prototypes that conform to generally accepted design principles. The experiment shows that gender has little influence on this. It does, however, have the age and frequency of Internet use. Most users prefer when a site is **esthetically** pleasing but functional. Proved that in the age group over 46, the responses differed the most from generally accepted design principles relative to other age groups. The differences were up to 22%. Very often, in the 31–45 age group, the answers differed from those of the 10–22 and 23–30 age groups. These groups have been in contact with the Internet since childhood or teenage years. The differences here were also up to 20%. However, the responses of the 46+ age group differed the most on average in the five pairs of prototypes to other age groups.

The appearance of websites has changed dramatically over the years. Over time, sites have evolved both functionally and **esthetically**. Their main idea and concept have changed. Nowadays, content should no longer only be understandable to the user but also compressed to a minimum. They aim to convey the most relevant information with as little text as possible. This analysis can also help create and design landing pages to avoid bad practices while using good ones. Creating a correct landing page for any user, regardless of age, is difficult. Therefore, this work can serve as an educational resource for those beginning to design UX-compliant websites.

## **Author details**

Luiza Fabisiak\* and Barbara Jagielska West Pomeranian University of Technology in Szczecin, Szczecin, Poland

\*Address all correspondence to: lfabisiak@zut.edu.pl

© 2022 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

## **References**

[1] Ash T, Page R, Ginty M. Landing Page Optimization. Indianapolis: John Wiley & Sons; 2012. p. s.4

[2] Detante. 2022. [Internet] Available from: https://delante.pl/definicje/ landing-page/. [Accessed: 17-05-2022]

[3] Wix Blog. 2022. [Internet] Available from: https://pl.wix.com/blog/ artykul/tworzenie-landing-pages?utm\_ source=google&utm\_medium=cpc& utm\_campaign= 14050035777^13386288 5908&experiment\_id=^^536052956 531^^\_DSA&gclid=CjwKCAjwj42UB hAAEiwACIhADgEjBrBsVbIdEvomx jvN\_UNcGdHA3gnsgTaAkcsVIIobTPZ0 PKcUhoCBOsQAvD\_BwE#viewer-9blrs. [Accessed: 12.01.2022]

[4] Prodesigner. 2022. [Internet]. Available from: https://prodesigner.pl/ co-to-jest-landing-page/. [Accessed: 17-12-2021]

[5] Marczak. 2022. [Internet]. Available from: https://marczak.me/efektywnylanding-page/#mcetoc\_1d5c0ebdr3. [Accessed: 08-06-2022]

[6] Landingi. 2018. [Internet] Available from: https://landingi.com/pl/blog/ 4-techniki-optymalizacji-landingpage-potencjalnie-szkodzace-konwersji/. [Accessed: 17-05-2022]

[7] Raidboxes. 2019. [Internet] Available from: https://raidboxes.io/pl/blog/ webdesign-development/typographiegrundlagen-webfonts-tipps/. [Accessed: 24-04-2019]

[8] Damianrams. 2019. [Internet]. Available from: https://www. damianrams.pl/landing-page/#8\_ dobrych\_praktyk\_w\_tworzeniu\_ landing\_page. [Accessed: 12-02-2019] [9] Koduje. 2022. [Internet] Available from: https://www.koduje.pl/dostepnematerialy/dark-patterny-na-kodu-je. [Accessed: 23-05-2022]

[10] RekinySukcesu. 2022. [Internet] Available from: https://www. rekinysukcesu.pl/blog/internet/darkpatterns-czyli-ryzykowna-praktyka-ux. [Accessed: 20-07-2022]

[11] Netsolution. 2021. [Internet] Available from: https://www.netsolutions.com/ insights/dark-patterns-in-ux-disadvantage s/. [Accessed: 09-07-2021]

[12] Gray CM, Kou Y, Battles B, Hoggatt J, Toombs AL. The dark (patterns) side of UX design. In CHI 2018 - Extended Abstracts of the 2018 CHI Conference on Human factors in Computing Systems: Engage with CII (Conference on Human Factors in Computing Systems - Proceedings; Vol. 2018 - April). Association for Computing Machinery. DOI: 10.1145/3173574.3174108

[13] Gupta S, Kumaraguru P. Emerging Phishing Trends and Effectiveness of the Anti-Phishing Landing Page. Birmingham, IEEE; 2014. p. s. 39

[14] Marczak. 2021. [Internet] Available from: https://marczak.me/efektywnylanding-page/#mcetoc\_1d5c0rjic7. [Accessed: 08-06-2021]

[15] Gofman A. Consumer driven multivariate landing page optimization: Overview, issues, and outlook. Transactions on Internet Research. 2007. p. 2. Available from: http://tir.ipsitransac tions.org/2007/July/Paper%2003.pdf. [Accessed: 15-12-2022]

[16] Unbounce. 2021 [Internet] Available from: https://unbounce.com/pagespeed-report/. [Accessed: 17-05-2022]

*Designing "Landing Page" for Websites Based on the User Experience… DOI: http://dx.doi.org/10.5772/intechopen.109240*

[17] Ash T, Page R, Ginty M. Landing Page Optimization. Indianapolis: John Wiley & Sons; 2012. p. s.31

[18] Landingi. 2022. [Internet] Available from: https://landingi.com/ pl/tworzenie/landing-page/. [Accessed: 17-05-2022]

## **Chapter 3**

## Managing Quantities and Units of Measurement in Code Bases

*Steve McKeever*

## **Abstract**

Quantities in engineering and the physical sciences are expressed as units of measurement (UoM). If a software system fails to maintain the algebraic attributes of a system's UoM information correctly when evaluating expressions then disastrous problems can arise. However, it is perhaps the more mundane unit mismatches and lack of interoperability that over time incurs a greater cost. Global and existential challenges, from infectious diseases to environmental breakdown, require highquality data. Ensuring software systems support quantities explicitly is becoming less of a luxury and more of a necessity. While there are technical solutions that allow units of measurement to be specified at both the model and code level, a detailed assessment of their strengths and weaknesses has only recently been undertaken. This chapter provides both a formal introduction to managing quantities and a practical comparison of existing techniques so that software users can judge the robustness of their systems with regards to units of measurement.

**Keywords:** units of measurement, quantities, dimension checking, unit conversion, libraries, component based checking

## **1. Introduction**

With ubiquitous digitalisation, and removal of humans in the loop, the need to faithfully represent and manipulate quantities in physical systems is ever increasing [1]. Popular programming languages allow developers to describe how to evaluate numeric expressions but not how to detect inappropriate actions on quantities. Consequently there have been infamous examples, such as the Mars Climate Orbiter [2], where units of measurement (UoM) conversion omissions led to catastrophic outcomes.

Humans have used local units of measurement since the days of early trade, enhanced over time to fulfil the accuracy and interoperable needs of science and technology. In the 19th century, James Clerk Maxwell [3] introduced the concept of a system of quantities with a corresponding system of units. This generalisation allowed scientists working with different measurement systems to communicate more easily, as unit names (such as inch or metre) are treated as numeric variables and can be interchanged through multiplication.

#### *Updates on Software Usability*

There are many ways in which manipulating physical quantities in a digital system can be made more robust. Thereby enabling the developer to depend on an automated validator, rather than trust, to ensure UoM are handled correctly. The software engineering benefits of embracing quantity checking and automatic conversion support is beyond dispute. It is clear from the various known UoM failures that one size does not fit all. However, a general lack of awareness has ensured that developers often reinvent the wheel or forego any kind of checking. From a correctness perspective, the optimal solution would be to natively support quantities as this allows for efficient unit conversion and static checking. However none of the mainstream languages provide such support, nor is that level of rigour always required. A software library might seem to confer the desired functionality of adding a unit type to one's preferred language but they are inconvenient in practice, adding an extra layer to one's code base, and incur a performance cost. All popular programming languages have a multitude of freely available quantity libraries but we argue that these are best suited to applications in which UoM checking is required at run-time. Component based checking and black-box testing are two lightweight methods of providing a degree of robustness while sacrificing completeness. Component checking will only validate the interfaces between components, while testing will ensure known examples of methods dealing with quantities perform correctly. Neither are comprehensive.

Implicit in our presentation is that the various approaches have compromises. For users who need a degree of robustness when using quantities in their code bases, this discussion is very important. An approach that initially might seem suitable for a given project, could be too costly in terms of speed, too cumbersome in terms of use or too risky by creating an unnecessary dependency on some library. In Section 2 we discuss early attempts to incorporate UoM checking into programming languages, and recent attempts to incorporate quantities into modelling languages. In Section 3 we introduce a very simple assignment language to show how the various aspects of quantities are defined and validated. In Section 4 we discuss the various approaches to providing quantity support in programming environments, highlighting their strengths and weaknesses. We summarise the results of our comparative study in Section 5, providing suggestions for developers as to which method to choose depending on their requirements, along with enabling software users to access pertinent aspects of an implementation that claims UoM support.

## **2. Background**

Dimensions are physical quantities that can be measured, while units are arbitrary labels that correspond to a given dimension to make it relative. For example a dimension is length, whereas a metre is a relative unit that describes length. Units of measure can be defined in the most generic form as either *base quantities* or *derived quantities*. The base quantities are the basic building blocks, and the derived quantities are built from these. For instance, the base quantity for time is second and that for length is metre in the International System of Units (SI), also known as the metric system. The SI system of measurement is based on seven base quantities for length, mass, time, electric current, temperature, quantity, and brightness [4]. Velocity, (metre/second or metre second<sup>1</sup> ), is a derived quantity made from the two base quantities. Rather than representing UoM as a tree structure, a normal form exists which makes storage and comparison a lot easier. Any system of units can be derived from the base units as a product of powers of those base units: base*<sup>e</sup>*<sup>1</sup> base*<sup>e</sup>*<sup>2</sup> *:::* base*en* , where the exponents *e*1,*:::*,*en* are rational numbers. Thus an SI unit can be represented as a 7-tuple ð Þ *e*1, *:::*, *e*<sup>7</sup> where *ei* denotes the *i*-th base unit; or in our case *e*<sup>1</sup> denotes length, *e*<sup>2</sup> mass, *e*<sup>3</sup> time and so on.

Adding units to conventional programming languages originates in the 1970s [5] and early 80s with proposals to extend Fortran [6] and then Pascal [7]. However these efforts were heavily syntax based and required modifications to the underlying languages, reducing backwards compatibility and thus uptake. Ada's abstraction facilities, namely operator overloading and type parameterisation, allowed for a more versatile approach [8] to labelling variables with UoM features. With the appearance of practical object oriented programming languages, such as C++ and Java, developers began to implement UoM either by means of a class hierarchy of units and their derived forms, or via the Quantity pattern [9]. This has led to a veritable explosion in the number of UoM libraries available for all popular programming languages based on this pattern [10].

Software development typically begins at a more abstract level through diagrams and rules that focus on the conceptual model that is to be implemented. Extensions to the Unified Modelling Language (UML) have been proposed to support quantities. SysML, for instance, is defined as an extension of a subset of UML to support systems engineering activities and has extensive support for quantities<sup>1</sup> . Unit checking and conversion can be undertaken before code is generated, either through a compilation workflow that leverages Object Constraint Language (OCL) expressions [11] or staged computation [12]. Unless the workflow has been created specifically, declaring quantities in a system specification language offers no guarantee that the UoM information is supported in the eventual implementation. The aim of this chapter is to discuss the various ways in which quantity information can be transferred into software and errors detected either at compile-time or run-time. Motivated by a prior critique of UoM libraries and a survey of scientific coders [13], we assess various approaches based on their ease of use, execution speed, numeric accuracy, ease of integration and coverage of unit error detection capabilities.

We lack a definitive understanding of how frequently quantity errors occur in practice. Anecdotally we can infer that it is not negligible from experiments described in the literature. When applied to a repository of CellML models, a validation tool [14] found that 60% of the descriptions that were invalid had dimensionally inconsistent units. A spreadsheet checker [15] was applied to 22 published scientific spreadsheets and detected 3, nearly 14%, with errors. Ore [16] applied his lightweight C++ unit inconsistency tool to 213 open-source systems, finding inconsistencies in 11% of them. It must be noted that these figures are gleaned from post development studies and are not representative of a quantity adhering software discipline. Thus, it seems important to ensure UoM information existing in software models is supported in derived implementations.

## **3. Validating quantities**

Performing calculations in relation to quantities, dimensions and units is subtle and can easily lead to mistakes. We shall begin by looking at a very simple language of declarations and assignments so that we can untangle the various aspects involved in

<sup>1</sup> https://sysml.org

**Figure 1.** *Rules for evaluating expressions.*

managing quantities correctly. A program will consist of a sequence of UoM variable declarations, *uv*, followed by a sequence of assignment statements, *ustmt*. Unit arithmetic expressions, *uexp*, impose syntactic restrictions so that their soundness can be inferred using the algebra of quantities.

> *ustmt* ≔ *uv* ≔ *uexp uexp* ≔ *uv* ∣ *uexp*<sup>1</sup> þ *uexp*<sup>2</sup> ∣ *r* � *uexp* ∣ *uexp*<sup>1</sup> � *uexp*<sup>2</sup>

By creating a separate syntax for unit expressions we can distinguish between scalar values, such as *r*, and *unitless quantities* in which all the dimensions are zero, such as moisture content. Consider a simple program to calculate Newton's second law of motion: begin

```
f : float;
  m : float of 5.7;
  a : float of 3.2;
  ...
  f:=m*a
end
```
We can use the evaluate function, E of **Figure 1**, with an environment consisting of values for m and a to calculate f:

$$\begin{array}{rcl} \mathcal{E}[[\mathfrak{m} \ast \mathfrak{a}]]\_{\{\mathfrak{m}\mapsto \mathfrak{5}, \mathfrak{I}, \mathfrak{a} \mapsto \mathfrak{3}, \mathfrak{2}\}} &=& \mathcal{E}[[\mathfrak{m}]]\_{\{\mathfrak{m} \mapsto \mathfrak{5}, \mathfrak{I}, \mathfrak{a} \mapsto \mathfrak{3}, \mathfrak{2}\}} \times \mathcal{E}[[\mathfrak{a}]]\_{\{\mathfrak{m} \mapsto \mathfrak{5}, \mathfrak{I}, \mathfrak{a} \mapsto \mathfrak{3}, \mathfrak{2}\}} \\ &=& (\{\mathfrak{m} \mapsto \mathfrak{5}.\mathfrak{I}, \mathfrak{a} \mapsto \mathfrak{3}.\mathfrak{2}\} \text{ \(\mathfrak{m} \mapsto \mathfrak{5}.\mathfrak{I}, \ \mathfrak{a} \mapsto \mathfrak{3}.\mathfrak{2}\)} \text{ \(\mathfrak{a}\)}) \\ &=& \mathbf{5}.\mathbf{7} \times \mathbf{3}.\mathbf{2} \end{array}$$

As is the case in nearly all programming languages, users have to assume that the mass (m) is given in kilograms, and the acceleration (a) is given in metres per second per second for the assignment to be correct. The reminder of this section explores the various aspects involved in handling quantities correctly, and how these aspects can be automated.

## **3.1 Dimensions**

A dimensional analysis needs to ensure that (1) two physical quantities can only be equated if they have the same dimensions; (2) two physical quantities can only be added if they have the same dimensions (known as the *Principle of Dimensional Homogeneity*); (3) the dimensions of the multiplication of two quantities is given by the addition of the dimensions of the two quantities. If we only consider the three

*Managing Quantities and Units of Measurement in Code Bases DOI: http://dx.doi.org/10.5772/intechopen.108014*

**Figure 2.** *Dimensional analysis rules for expressions.*

common dimensions of length, mass and time then we can capture the rules for addition and multiplication.

$$\begin{aligned} \left(l\_1, m\_1, t\_1\right) &\stackrel{\cdot}{+} \left(l\_2, m\_2, t\_2\right) &=& \left(l\_1, m\_1, t\_1\right), \text{ if } \ l\_1 = l\_2 \land m\_1 = m\_2 \land t\_1 = t\_2\\ \left(l\_1, m\_1, t\_1\right) &\stackrel{\cdot}{\times} \left(l\_2, m\_2, t\_2\right) &=& \left(l\_1 + l\_2, m\_1 + m\_2, t\_1 + t\_2\right) \end{aligned}$$

This allows us to rewrite the rules of **Figure 1** by replacing the addition and multiplication operators to create a dimensional checker, shown in **Figure 2**. Scalar multiplication does not affect the dimensions of a quantity. The dimension of mass, m, is described as (0,1,0), while acceleration is length � time�<sup>2</sup> , or (1,0,-2) as a tuple. Our dimensional checker will compute with dimensions and attempt to ensure all assignments are correct. Consider our example program:

begin

f : float of (1,1,-2); m : float of (0,1,0); a : float of (1,0,-2); ... f:=m\*a end

Checking would proceed as follows:

DE½ � ½ � <sup>m</sup> � <sup>a</sup> f g <sup>m</sup>↦ð Þ 0,1,0 , a↦ð Þ 1,0,�<sup>2</sup> <sup>¼</sup> DE½ � ½ � <sup>m</sup> f g <sup>m</sup>↦ð Þ 0,1,0 , a↦ð Þ 1,0,�<sup>2</sup> �^ DE½ � ½ � <sup>a</sup> f g <sup>m</sup>↦ð Þ 0,1,0 , a↦ð Þ 1,0,�<sup>2</sup> ¼ ð Þ f g m↦ð Þ 0,1,0 , a↦ð Þ 1,0,�2 m �^ ð Þ f g m↦ð Þ 0,1,0 , a↦ð Þ 1,0,�2 a ¼ ð Þ 0,1,0 �^ ð Þ 1,0,�2 ¼ ð Þ 1,1,�2

and as this dimension matches f we know that the assignment is correct. Most UoM checkers adopt this approach, extending the checking into the statements and function calls of typical programming language constructs. For instance, all branches of conditionals and case statements must have the same dimensions, while comparison operators can only operate on quantities of the same dimension. If the dimensions of all variables are known at compile-time then this process can be undertaken before the program runs.

### **3.2 Kinds of quantities**

Two values that share the same UoM might not represent the same *kinds of quantities* (KOQ) [17]. For example, torque is a rotational force which causes an object to

rotate about an axis while work is the result of a force acting over some distance. Surface tension can be described as newtons per meter or kilogram per second squared, and even though they equate, they represent different quantities.

We have recently developed a simple set of rules for arithmetic and function calls that allow quantities to be named and handled *safely* [18]. This is not as straightforward as preserving the names of quantities throughout the program text. Multiplication will generate a new quantity so it is very likely that information is lost in intermediate stages of a calculation. Moreover, not all quantity variables in a program will have a name such as Torque or Work. Some might denote an entity such as length that could be in metres or yards, while another might be a variable used to store some temporary value. Neither of these need to be named. Using an algebraic data type, we define named quantities as:

type quantname ¼ Named of string j No name

We can now define the rules for adding and multiplying named quantities. In both cases we assume that the unit expression is dimensionally correct, our concern is to define how named quantities conduct themselves. The operator ⋄ takes two named quantities and states the conditions under which they can be summed: *two named quantities can be added together only if they represent the same entity*, if one quantity is named but the other is not then it is necessary for the result to be named, and if both are unnamed then the result will be too:


Our comparison rules cast upwards from Noname to Named, so as to assume a named quantity whenever possible. This is required to ensure named quantities behave correctly. For multiplication the rules are simpler. The operator Δ takes in two named quantities and defines how they behave over the multiplication operator. As *multiplication sums the dimensions of the two operands, the value will be different to either and so the result will always be* \_Δ\_ = Noname. The rules for named quantity analysis of expressions are given in **Figure 3**.

Multiplication will generate a new quantity so it is very likely that information is lost in intermediate stages of a calculation. We propose that functions, whose return KOQ are known, are used to regain information when calculations use multiplication.

**Figure 3.** *Named quantity rules for unit expression.* *Managing Quantities and Units of Measurement in Code Bases DOI: http://dx.doi.org/10.5772/intechopen.108014*

In this manner a discipline of programming with quantities is suggested Nonetheless, we can exemplify how our approach behaves on a simple incorrect assignment where we try to add a value of torque to one of work:

```
begin
  sumt : float of Named Torque;
  t : float of Named Torque;
  w : float of Named of Work;
  ...
  sumt : = t + w
end
```
Checking would start as follows:


and as we cannot proceed, we deduce that the assignment is unsafe. None of the current methodologies for managing quantities perform this kind of quantity checking.

#### **3.3 Systems of Units**

Dimension analysis would be sufficient if only one unit system, such as the SI system, was required. In such cases the base units of metre, gram and second could be implicit in implementations. There are, however, two further complications. A system of units provides a set of base units but they can be extended with prefixes. For instance, the SI system allows lengths to be described in terms of the base unit metre and prefixes, such as kilo- and centi-. While the Imperial system has the base unit feet on which an inch and a yard are constructed. Consequently we need to consider normalising values within a system of units and allow dimensionally faithful expressions to evaluate correctly with different units of measurement, as shown in **Figure 4**.

#### *3.3.1 Normalising within a system of units*

We can extend our tuple for dimensions to include prefixes. They are used to avoid very large or very small numeric values. Speed is typically shown in kilometres per hour, which we could represent in our 3-tuple as ((kilometre,1),(gram,0),(hour,-1)). This approach simplifies normalisation. A kilometre can be converted into metres by multiplying the value by a 1000, and an hour is 3600 seconds. Consider the dimensionally correct assignment below where the mass, m, is given in grams:

### begin

```
f : float of ((metre,1),(kilogram,1),(second,-2));
  m : float of ((metre,0),(gram,1),(second,0));
  a : float of ((metre,1),(gram,0),(second,-2));
  ...
  f:=m*a
end
```
A UoM analysis would reveal that force, f, is expected in Newtons so the value for m needs to be divided by 1000, f:= (m/1000)\*a. It is straightforward to normalise within a given system of units by aligning the prefixes. However, we also need to take the exponent into account. For example, the density of iron is 7.86 *g/cm3* , and can be converted into *kg/m<sup>3</sup>* as follows:

$$\begin{aligned} &7.86 \times (\mathcal{C} \text{ (gram, kilogram)}) \times (\mathcal{C} \text{ (centimeter, metre)})^{-3} \\ &= 7.86 \times 0.001 \times 0.01^{-3} \\ &= 7860 \text{ kg/}m^3 \end{aligned}$$

where we assume the existence of a function C that takes in two prefixes and returns the conversion factor.

## *3.3.2 Converting between two Systems of Units*

A second issue is that of converting in-between two systems of units. This can be achieved by extending the function C to convert between known systems, such as from yards to metres and visa-versa. Consider a similar example to the Mars climate orbiter error, here we want to calculate momentum, where p is mass times velocity, in Newton seconds, or *m*�*Kg*�*s -1*. However our mass is in pounds:

begin

```
p : float of ((metre,1),(kilogram,1),(second,-1));
  m : float of ((metre,0),(pound,1),(second,0));
  v : float of ((metre,1),(gram,0),(second,-1));
  ...
  p:=m*v
end
```
The function conversion, C ð Þ pound, kilogram , yields 0.45 so we need to modify the assignment so that the result will be correct, namely p := 0.45\*m\*v.

A naive unit conversion algorithm will convert the right hand side's units to the left hand side's for each sub-expression when performing addition or multiplication, but this is rarely the most efficient. The algorithm described by Cooper [14] is applied at compile-time. It choose the least number of conversions by generating all possible valid UoM conversions from a given expression, and selecting the one with the fewest conversions. Finally, many non-SI units continue to be used in the scientific, technical, and commercial literature. Some units are deeply rooted in history and culture.

**Figure 4.**

*Conversion within and in-between systems of units.*

We use the term week rather than 168 hours. These also need to be supported through conversion functions.

## **3.4 Levels of measurement**

A further aspect is that of the operations that might be applicable to a given quantity. To a physicist or applied mathematician, it is taken for granted that a quantity is used in the same manner as a unit-independent value, and that all arithmetic and comparative operators can be applied to it. However this is often not the case. For instance, what operations apply to a person's IQ? It does not makes sense to multiply scales of intelligence or personality traits.

Stevens [19] identified four categories of scale that places limits on the type of measurement that can be used to construct valid terms:


Currently no system employs levels of measurement checking, such that only meaningful operations are applied to certain quantities. We suspect that this is due to even less awareness of scale levels and an assumption that quantity checking is only necessary for ratio scales. Hall [20] has developed a UML class diagram that captures the inheritance relationship between the four levels, enabling operations to be restricted to the most general of a pair of operands. As discussed with the ordinal scale, there is a pragmatic context that needs to be considered when using levels of measurement.

## **3.5 Summary of quantity checking**

Through the use of an illustrative expression language we have shown how to ensure programs correctly manipulate the dimensions, the named quantities and the UoM of values. In doing so we have raised two important issues relating to the implementation of quantities: at what point checking and conversions can occur, and how extensive the coverage will be. If all UoM variables are annotated, or their annotations inferred, then both dimension checking and unit conversions can be undertaken by the compiler. This means that programs with UoM errors will be detected early, before the system is put in place, creating a strongly UoM typed language. Moreover, the code can be optimised so as to have the least number of conversions, reducing rounding errors, and increasing the accuracy of its calculations. The technique can be extended to include assertions on allowable unit conversions. If UoM are only known at run-time, or their design is embedded within the host language, then dimension checking and unit conversions will be undertaken at run-time. Programs will still manipulate UoM correctly but with a performance penalty and errors will only be detected once running. One must also consider the annotation burden, [21] found subjects choose a correct UoM annotation only 51% of the time and take an average of 136 seconds to make a single correct annotation.

## **4. Implementing quantities**

Many constructs in Software Models can be directly translated into code. A UML class diagram can be used to build the class structure of an object oriented implementation. The situation for UoM annotations is more complex. UoM values are neither primitive nor reference types in modern object oriented terminology. As described in Section 3, they require an advanced checker to ensure variables and method calls are handled soundly by the compiler.

In this Section we shall look at the four practical methods that support unit checking of code basis. All implementation options are affected by the following three concerns [13]: *lack of awareness*, *cumbersome implementations* and *lack of support* from the given software eco-system. Software rarely lives in a vacuum so even if it has been designed and developed with one of these methods, associated components are unlikely to support UoM, such as legacy libraries, databases and spreadsheets. Nonetheless as sources of data are migrated to quantity aware formats, the software must be able to follow suit.

#### **4.1 Native language support**

Adding unit checking to conventional imperative, object-oriented and even functional languages using syntactic sugaring is beyond the algorithmic scope of their underlying type checkers. The pioneering foundational work of Wand and O'Keefe [22] demonstrated how the simply-typed lambda calculus could be extended with dimensions. Milner's polymorphic type inference algorithm [23] is symbolic, so in order to include UoM variable resolution one has to provide an equational solver based on the theory of Abelian groups [24]. A programming language with native support will include additional syntax for UoM and an enhanced static analyser that calculates or infers the validity of annotations. When UoM annotations are validated prior to compilation, errors can be detected early and generated arithmetic code can minimise the number of conversions, mitigating round-off errors.

The only language in the 20 most popular programming languages [25] that supports units of measurement is Apple's Swift language [26]. Microsoft's F# [27] is a general purpose functional language with a full implementation of UoM, including

unit variables that the static checker will seek to determine at compile-time [24]. This property permits valid UoM programmes to be written in which not all the quantity variables are annotated, thereby reducing the annotation burden and allowing greater reusability. However, large software projects rarely use either Swift or F#.

## *4.1.1 C++ boost library*

C++ is still very popular [25] and has a de facto UoM extension that exploits the template meta-programming feature<sup>2</sup> . Consequently BoostUnits is more than just a library as it supports a staged computation model, similar to MixGen [12], which has the benefit of providing a language extension while still supporting backwards compatibility. C++ is quite unique in terms of being a popular programming language that supports this adaptable compilation strategy. Dimensional analysis is treated as a generic compile-time meta-programming problem, and delivers features and performance comparable to native language support. As no run-time penalty is incurred, BoostUnits supports UoM checking in performance-critical code. However, the survey [28] found both usability and accuracy issues with the use of this library.

## *4.1.2 Unit of measurement validators*

Creating a new compiler feature for an existing language is contentious, non-trivial and likely to become outmoded. An alternative static approach is to define UoM through comments or attributes and to build a tool that attempts to perform as much scrutiny as possible. Such a validator checks at compile-time for unit violations without adding a new syntax or changing the run-time behaviour of the code. **Figure 5** shows an example of the Unit of Measurement Validator for C# [29]. The Osprey [30]

### **Figure 5.**

*Example of unit of measurement validator for C#.*

<sup>2</sup> https://github.com/boostorg/units

system is a C front end that automatically checks for all potential quantity errors. UoM are annotated with a \$ and are modelled as types, reducing dimensional analysis to type checking, with Gaussian elimination to resolve unspecified UoM variable exponents. Simiarly [31] allows one to express relationships between the units of function parameters and return values. Ensuring the validity of unit conversions can be specified. PUnits [32] is a Java front end, or pluggable type system, that has many additional features. It can be used in three modes: checking the correctness of a program, solving UoM type variables, and annotating a program with units. This last feature is the most novel and allows human inspection which is useful since having a valid typing does not guarantee that the inferred specification expresses design intent, and allows KOQs to be expressed. These approaches are lightweight and scalable but they need to be supported for users to feel that they are credible. Alas few of these tools have lifespans outside of their original research project.

#### *4.1.3 Domain-specific languages (DSLs) with quantities*

DSLs are languages specialised to a particular application domain. They are often written in a mark-up language such as XML or JSON which facilitates their use with general purpose languages as they can be easily parsed. They might have originally been designed for the purpose of curation, such as CellML and SMBL where the intention was to build biological repositories of computational models. A model will include the constants, variables and equations denoting a particular biological system. Thus, translating them into a programming language with the aid of a differential equation solver means that they can be readily simulated [33]. If the DSL contains UoM declarations then separately analysing source files can be undertaken before they are uploaded to a repository and translated into the run-time system [14]. Quantity checking coverage might be limited to the application domain but one can easily make the argument that this is where the vulnerabilities would lie.

#### **4.2 Static or dynamic library support**

Adding a feature to an existing programming language is usually undertaken by developing a library which implements the desired behaviour. It is written in terms of the language, using advanced abstraction methods such as classes and generics, and delivers a well-defined interface. There are many UoM libraries for all modern programming languages [34]. The basic idea behind dimensional analysis, as shown in Section 3.1, is relatively straightforward and familiar to scientific coders. However, *"making a physical quantity library is easy but making a good one is hard"* [35]. The reasons behind this lie in the subtleties of implementation: providing non-standard UoM, offering many new operators, supporting conversions, creating helpful error messages, while being efficient. These aspects are far harder to code and maintain than a faithful implementation of the Quantity pattern [9, 36].

Experience has shown that quantity libraries add an extra layer to an existing application through boilerplate code that is rarely idiomatic to the host language. The Quantity pattern ensures that values are hard-wired to have a single floating point representation, requiring further conversions to other internal formats and accuracy issues. Poor error messages are also a frequent complaint. Certain modern languages, such as Ruby, provide a special syntax for adding features to the language which exploit duck typing, enabling lightweight libraries to be built. The main conclusion is that for adoption to occur, UoM must be included in such a way that they are almost as easy to use as standard arithmetic types [13].

The standard technique for implementing the Quantity pattern is through exploiting overriding, making UoM checking a run-time activity. However UoM can be implemented through static overloading, or Java generic instantiations, ensuring compile-time checking. An example of both styles is shown in [13]. Merging the two techniques would double the amount of notation required and significantly add to the burden of adoption. Languages such as Python or Ruby are dynamically typed by definition, so quantity checking will occur at run-time regardless of how UoM are defined. Run-time support is a key reason why there are so many libraries for these two languages when typically one would assume quantities require high-performance executables. From a user survey of UoM libraries: *"In our product line, our users may very well have one file whose units are 'kg <sup>m</sup>*<sup>3</sup>*', another whose units are 'g*\_*cc'and a third whose units are 'degrees Celsius'. We therefore need to be able to operate on units at runtime, not compile-time"* [28].

An additional limitation of libraries versus a native language or a pluggable type solution is that variables of a Quantity class can be reassigned at run-time. The 7 tuple that represents dimensions can be modified such that a kilometre could become a newton. Dimensional homogeneity and conversion errors can be caught by a library implementation but to avoid such programming style errors necessitates discipline. A dimensionally aware static checker ensures that all instances of a quantity declaration have the same dimensions. Errors caused by this violation were found to account for 75% of inconsistencies in the study of 5.9 M lines of code [37].

Implementing UoM through a data type or a class requires values to be boxed at run-time, incurring both speed and memory penalties. Native language solutions can perform the checking at compile-time so that generated executables contain no further UoM annotations and values are represented by primitive types. For scientific applications that perform many calculations, such as matrix multiplications, this unnecessary performance overhead is unacceptable. A UoM library might seem attractive and undemanding initially, but the subtle burden that they inflict will often increase the complexity of a project.

#### **4.3 Component or Interface description support**

Encapsulating implementation details, interfaces are a collection of the externally visible entities and function signatures of a component. They are used by the compiler to ensure access is handled correctly. Libraries, native language support and pluggable type systems usually require all quantity variable and function declarations to have UoM annotations, while component or interface based approaches only require certain functions to be annotated. This drastically reduces the annotation burden, supports legacy code but at the expense of robustness.

A component based approach seeks to add UoM information to the interface in order to enforce unit consistency when composing components and thereby reduce dimensional mismatch errors. There is some anecdotal evidence in the many quotes of [28] to support this approach. Damevski [38] hypothesises that UoM libraries are too restricting by requiring complete coverage, incurring an annotation or migration burden. His technique performs dimensional analysis on component interfaces at runtime, and if the calling parameters are compatible with the arguments dimensions then unit conversions occur. Consider the C++ class Earth [38]:

```
class Earth {.
    void setCircumference(in Metre circumference);
    Metre getCircumference();
```
}

It assigns and queries the earth's circumference using Metre internally but can be called with Kilometre and the return value bound to a variable of, say, type Mile. Unlike libraries, within the class Earth no further annotations are required, nor will internal declarations be checked. This is a dynamic component based approach, units are converted at run-time.

Another lightweight methodology was presented by Ore [16] which performs an initial pass to build a table mapping attributes in C++ shared libraries to UoM. The shared libraries have been specifically enhanced to include UoM annotations. The table is used to disseminate UoM information into a source program and detect errors at compile-time. The algorithm successfully exploits dimensional analysis rules for arithmetic operators within components [39]. This is an example of a static component based approach, and through this process of static UoM propagation checking, manages to perform a greater coverage than Damevski's run-time method.

A component based discipline means that the consequences of local unit mistakes are underestimated. The analysis of local assignment expressions will not occur in Damevski's scheme and will be limited in Ore's. On the other hand, checking at the component level allows diverse teams to collaborate even if their domain specific environments or choice of quantity systems were, to some extent, dissimilar. More importantly, either a static or dynamic component implementation would have been effective at correcting the Mars Climate Orbiter error.

## **4.4 Black-box testing**

The last method that we will look at for checking quantities are managed correctly is known as black box automated testing. This method is usually applied to detect incorrect or missing methods, initialisation errors, interface errors and errors in data structures. By extrapolating use cases from the requirements specification to create unit tests, which are then systematically applied to the program, errors can be discovered before the code is put into operation. In the case of UoM tests, the resulting testing will not be comprehensive. Unit testing will focus on the correct initialisation of variables, the UoM correctness of assignments and method calls. This approach is also considered lightweight as no annotations are required in the program, however creating sufficient unit tests by hand is tedious. Efforts to generate unit tests from UML descriptions automatically [40–43], either through behavioural diagrams or with rule based approaches, are seen to be costly and non-trivial in practice [44].

Modern agile software development practices rely heavily on manually developing tests for enabling refactoring but also to support test driven development (TTD). Unit testing for UoM errors does not require any extra tool support, and will not alter any other parts of the system as shown in **Figure 6**, where we show the testing required for a simple UoM based addition function. If t is true then both arguments are in kilometres, alternatively the second argument is in miles and converted accordingly. The two test cases capture this intention. Many developers would argue that time spent becoming familiar with a UoM library, and updating their programs accordingly, might be better spend writing unit tests: *"I could use the same time to write tests and that would really find and prevent errors and at the same time not introduce a crazy complicated library every other developer in my team would have to deal with."* [28].

*Managing Quantities and Units of Measurement in Code Bases DOI: http://dx.doi.org/10.5772/intechopen.108014*

#### **Figure 6.**

*Java code and JUnit test case for simple addition of two kilometres, or kilometre and mile distances [45].*

However, the UoM knowledge will be localised to each particular unit so the slight implementation cost comes at the expense of potentially average checking.

## **5. Conclusions**

Recent initiatives such as the FAIR data principles [46] emphasis machineactionability of scientific data. With greater interoperability, industrial use of computational simulations and penetration of digitalisation through cyber-physical systems; there is an urgency to faithfully represent key properties of physical systems in code bases [1, 47].

We have endeavoured to provide the necessary background for software users to choose the most appropriate method for enabling quantity checking in code bases. Alas native language support is not available for popular programming languages. This situation is unlikely to change as it would require new language definitions and expensive compiler rewrites, with an important criteria of ensuring backwards compatibility with existing code. Validators solve some of these issues but require assurances that tool support will be maintained. DSL checkers are very effective for their given domain but lack generality. It is clear that even the best libraries currently cause significant performance issues while not being relevant for most developers. However some of the dynamic libraries include a lightweight syntax that makes UoM annotations significantly easier. A strength of component based techniques is that they can be undertaken at either compile-time or run-time with little overhead. They cede UoM checking completeness for a low annotation burden and ease of adoption. Approaches based on manual blackbox testing frameworks offer many of the benefits of static component based techniques without requiring extra syntax. The drawback is that the UoM information will be implanted within the unit tests and not as a form of documentation within programs.

Annotating quantities in code bases is costly for developers [21] but relatively durable to software evolution. Refactoring does not change the external behaviour of the software, it will rarely require quantity annotation modifications unless there are changes to the core data structures. Techniques that manage UoM at compile-time, such as native language support or static lightweight solutions, allow unit conversions to be undertaken before code is created and values to be represented in unboxed form, thus resulting in better accuracy and efficiency.

The pros and cons of UoM techniques are listed in **Table 1** using features that are relevant to users. Native language or pluggable type based techniques offer many benefits, such as an equational UoM checker that is capable of resolving UoM type


#### **Table 1.**

*Contrasting alternative methods of implementing units of measurement in software projects, extended from [45].*

variables, and unit conversion optimisation to improve run-time behaviour. Static component and black box based testing provide some of the benefits of static UoM libraries with less coverage but greater versatility. This is in tune with contemporary software development methods that favours lightweight techniques which integrate into existing digital platforms.

Software users who require a degree of robustness have had little say over how much validation was undertaken on their code to ensure UoM are handled correctly. This chapter aims to inform users and developers of the various options that exist to check that quantities are handled properly, along with the implications of these choices with regards to their software eco-system. The needs of a reactive and responsive on-line application, with assorted UoM input, are very different to a fully quantity specified stand-alone safety critical application. Nonetheless softwareintensive systems are prevalent in our daily lives, with complex functionality and strong interconnection. The need to ensure quantity values behave correctly are greater than ever before.

## **Author details**

Steve McKeever Department of Informatics and Media, Uppsala University, Sweden

\*Address all correspondence to: steve.mckeever@im.uu.se

© 2022 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

*Managing Quantities and Units of Measurement in Code Bases DOI: http://dx.doi.org/10.5772/intechopen.108014*

## **References**

[1] Hanisch R et al. Stop squandering data: Make units of measurement machine-readable. Nature. 2022;**605**: 222-224

[2] Arthur Stephenson, Lia LaPiana, Daniel Mulville, Frank Bauer Peter Rutledge, David Folta, Greg Dukeman, Robert Sackheim, and Peter Norvig. Mars Climate Orbiter Mishap Investigation Board Phase 1 Report, 1999. NASA Headquarters, Washington D.C., USA: NASA Press Release; [Last Accessed: May 19, 2022]

[3] James Clerk Maxwell. A Treatise on Electricity and Magnetism [Microform] / by James Clerk Maxwell. Oxford: Clarendon Press; 1873

[4] NIST. International System of Units (SI): Base and Derived. 2015. [Last Accessed: May 19, 2022]

[5] Karr M, Loveman DB. Incorporation of units into programming languages. Communications of the ACM. 1978; **21**(5):385-391

[6] Gehani N. Units of measure as a data attribute. Computer Languages. 1977; **2**(3):93-111

[7] Dreiheller A, Mohr B, Moerschbacher M. Programming pascal with physical units. SIGPLAN Notes. 1986;**21**(12):114-123

[8] Hilfinger PN. An Ada package for dimensional analysis. ACM Transactions on Programming Languages and Systems. 1988;**10**(2):189-203

[9] Fowler M. Analysis Patterns: Reusable Objects Models. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc.; 1997

[10] McKeever S, Paçaci G, Bennich-Björkman O. Quantity checking through unit of measurement libraries, current status and future directions. In: Model-Driven Engineering and Software Development, MODELS WARD. Portugal: SciTePress; 2019

[11] Mayerhofer T, Wimmer M, Vallecillo A. Adding uncertainty and units to quantity types in software models. In: Software Language Engineering, SLE 2016. NY, USA: ACM; 2016. pp. 118-131

[12] Allen E, Chase D, Luchangco V, Maessen J-W, Steele GL Jr. Objectoriented units of measurement. In: Proceedings of Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA '04. NY, USA: ACM; 2004. pp. 384-403

[13] McKeever S, Bennich-Björkman O, Salah O-A. Unit of measurement libraries, their popularity and suitability. Software: Practice and Experience. 2020; **51**(4):711-734

[14] Cooper J, McKeever S. A modeldriven approach to automatic conversion of physical units. Software: Practice and Experience. 2008;**38**(4):337-359

[15] Antoniu T, Steckler PA, Krishnamurthi S, Neuwirth E, Felleisen M. Validating the unit correctness of spreadsheet programs. In: Proceedings of Software Engineering, ICSE '04. Washington, DC, USA: IEEE Computer Society; 2004. pp. 439-448

[16] Ore J-P, Detweiler C, Elbaum S. Lightweight detection of physical unit inconsistencies without program annotations. In: Proceedings of International Symposium on Software Testing and Analysis, ISSTA 2017. NY, USA: ACM; 2017. pp. 341-351

[17] Marcus Foster and Sean Tregeagle. Physical-Type Correctness in Scientific Python, CoRR, arXiv; 2018

[18] McKeever S. Discerning quantities from units of measurement. In: Proceedings of the 10th International Conference on Model-Driven Engineering and Software Development - MODELSWARD. Portugal: INSTICC, SciTePress; 2022. pp. 105-115

[19] Stevens SS. On the theory of scales of measurement. Science. 1946;**103**(2684): 677-680

[20] Hall B. The problem with 'dimensionless quantities'. In: Proceedings of the 10th International Conference on Model-Driven Engineering and Software Development - MODELSWARD. Portugal: INSTICC, SciTePress; 2022. pp. 116-125

[21] Ore J-P, Elbaum S, Detweiler C, Karkazis L. Assessing the type annotation burden. In: Automated Software Engineering, ASE 2018. NY, USA: ACM; 2018. pp. 190-201

[22] Wand M, O'Keefe P. Automatic dimensional inference. In: Computational Logic - Essays in Honor of Alan Robinson. Cambridge Massachusetts, USA: MIT Press; 1991. pp. 479-483

[23] Milner R. A theory of type polymorphism in programming. Journal of Computer and System Sciences. 1978; **17**:348-375

[24] Kennedy A. Dimension types. In: Sannella D, editor. Programming Languages and Systems—ESOP'94. Vol. 788. Edinburgh, U.K.: Springer; 1994. pp. 348-362

[25] TIOBE. The Importance of Being Earnest Index. 2022. Available from: https://www.tiobe.com/tiobe-index/ [Last Accessed: July 6]

[26] Apple. Swift open source. 2022. [Last Accessed: May 19, 2022]

[27] Microsoft. F# software foundation, 2020. [Last Accessed: May 19, 2022]

[28] Salah O-A, McKeever S. Lack of adoption of units of measurement libraries: Survey and anecdotes. In: Proceedings of Software Engineering in Practice, ICSE-SEIP '20. NY, USA: ACM; 2020

[29] Dieterichs Henning. Units of Measurement Validator for C#. [Last Accessed: May 19 2022]

[30] Jiang L, Zhendong S. Osprey: A practical type system for validating dimensional unit correctness of C programs. In: Proceedings of the 28th International Conference on Software Engineering, ICSE '06. New York, NY, USA: ACM; 2006. pp. 262-271

[31] Hills M, Feng C, Grigore R. A rewriting logic approach to static checking of units of measurement in C. Electronic Notes in Theoretical Computer Science. 2012;**290**:51-67

[32] Xiang T, Luo JY, Dietl W. Precise inference of expressive units of measurement types. Proceedings of the ACM on Programming Languages. 2020; **4**:1-28. (OOPSLA)

[33] Garny A, Nickerson D, Cooper J, dos Santos RW, Miller A, McKeever S, et al. Cellml and associated tools and techniques. Philosophical Transactions of the Royal Society, A: Mathematical, Physical and Engineering Sciences. 2008; **366**:3017-3043

[34] Bennich-Björkman O, McKeever S. The Next 700 Unit of Measurement Checkers. In Proceedings of Software Language Engineering, SLE 2018. NY,

*Managing Quantities and Units of Measurement in Code Bases DOI: http://dx.doi.org/10.5772/intechopen.108014*

USA: Association for Computing Machinery; 2018. pp. 121-132

[35] Bekolay T. A comprehensive look at representing physical quantities in python. Scientific Computing with Python. Proceedings of the 11th ACM SIGPLAN International Conference on Software Language Engineering. 2013. pp. 121-132

[36] Krisper M, Iber J, Rauter T, Kreiner C. Physical quantity: Towards a pattern language for quantities and units in physical calculations. In: Proceedings of Pattern Languages of Programs, EuroPLoP '17. NY, USA: ACM; 2017. p. 9:1–9:20

[37] Ore J-P, Elbaum S, Detweiler C. Dimensional inconsistencies in code and ROS messages: A study of 5.9m lines of code. In: 2017 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS). Manhattan, NY, USA: IEEE; 2017. pp. 712-718

[38] Damevski K. Expressing measurement units in interfaces for scientific component software. In: Proceedings of Component-Based High Performance Computing, CBHPC '09. NY, USA: ACM; 2009. p. 13:1–13:8

[39] Ore J-P, Detweiler C, Elbaum S. Phriky-units: A lightweight, annotationfree physical unit inconsistency detection tool. In: Software Testing and Analysis, ISSTA 2017. NY, USA: Association for Computing Machinery; 2017. pp. 352-355

[40] Alessandra Cavarra, Charles Crichton, Jim Davies, Alan Hartman, Thierry Jeron, and Laurent Mounier. Using UML for Automatic Test Generation. Proceedings of ISSTA. NY, USA: ACM SIGSOFT International Symposium on Software Testing and Analysis; 2002

[41] Hartmann J, Vieira M, Foster H, Ruder A. A UML-based approach to system testing. Innovations in Systems and Software Engineering. 2005;**1**:12-24

[42] Ali S, Hemmati H, Holt NE, Arisholm E, Briand LC. Model transformations as a strategy to automate model-based testing-a tool and industrial case studies. In: Simula Research Laboratory, Technical Report (2010-01). Norway: Technical Report, Simula Research Laboratory and University of Oslo; 2010. pp. 1-28

[43] Mussa M, Ouchani S, Sammane W, Hamou-Lhadj A. A Survey of Model-Driven Testing Techniques. Proceedings - International Conference on Quality Software. QSIC. 2009. Manhattan, NY, USA: IEEE; pp. 167-172

[44] Kasurinen J, Taipale O, Smolander K. Software test automation in practice: Empirical observations. Advances in Software Engineering. 2010;**2010**:01

[45] McKeever S. From quantities in software models to implementation. In: Proceedings of the 9th International Conference on Model-Driven Engineering and Software Development - MODELSWARD. Portugal: INSTICC, SciTePres; 2021. pp. 199-206

[46] Wilkinson MD, Dumontier M, Aalbersberg IJJ, Appleton G, Axton M, Baak A, et al. The fair guiding principles for scientific data management and stewardship. Scientific Data. 2016;**3**:1-9

[47] Selic B. Beyond mere logic: A vision of modeling languages for the 21st century. In: Pervasive and Embedded Computing and Communication Systems (PECCS). Portugal: SciTePress; 2015. p. IS09
