Visualization of tabular data on mobile devices

(1)

Visualization of tabular data on mobile devices

Sophia Caspár

Computer Science and Engineering, master's level 2018

Luleå University of Technology

Department of Computer Science, Electrical and Space Engineering

(2)

(3)

A

^BSTRACT

This thesis evaluates various ways of displaying tabular data on mobile devices using different responsive table solutions. It also presents a tool to help web developers and designers in the process of choosing and implementing a suitable table approach. The proposed solution for this thesis is a web system called The Visualizing Wizard that allows the user to answer some questions about the intended table and then get a recommended responsive table solution generated based on the answers. The system uses a rule-based approach via Prolog to match the answers to a set of rules and provide an appropriate result. In order to determine which table solutions are more appropriate to use for which type of data a statistical analysis and user tests were performed. The statistical analysis contains an investigation to identify the most common table approaches and data types used on various websites. The result indicates that solutions such as ”squish”,

”collapse by rows”, ”click” and ”scroll” are most common. The most common table categories are product comparison, product offerings, sports and stock market/statistics.

This information was used to implement and establish user tests to collect feedback and opinions. The data and statistics gathered from the user tests were mapped into sets of rules to answer the question of which responsive table solution is more appropriate to use for which type of data. This serves as the foundation for The Visualizing Wizard.

iii

(4)

(5)

P

^REFACE

I would like to thank my supervisors for their guidance and support during this project.

Associate Professor Josef Hallberg at Lule˚a University of Technology for providing valuable feedback and resources. Thanks to Tobian Haire at Forefront Consulting in Stock- holm for giving me this opportunity and helping me form the basis of this thesis. My greatest gratitude and thanks are to my supervisor and mentor, Lina Holmgren at Fore- front Consulting, who has given me great advices and helped me throughout the project with good insights and knowledge about UX and project planning.

I would also like to thank everyone at Forefront Consulting for being patient and sup- portive and for always answering any questions I might have or pointing me in the right direction.

Sophia Casp´ar

v

(6)

(7)

L

^{IST OF}

A

BBREVIATIONS

Abbreviation Description

UX User Experience

RWD Responsive Web Design

API Application Programming Interface AI Artificial Intelligence

BRMS Business Rule Management System HCI Human-Computer Interaction

vii

(8)

(9)

C

^ONTENTS

Chapter 1 – Introduction 1

1.1 Background . . . . 1

1.2 Motivation . . . . 1

1.3 Problem definition . . . . 2

1.4 Delimitations . . . . 3

1.5 Thesis structure . . . . 3

Chapter 2 – Related work 5 2.1 Responsive tables: Best practices . . . . 5

2.1.1 Best practices for comparison tables . . . . 6

2.1.2 Comparisons and other data tables . . . . 7

2.2 Guidelines for Mobile HCI . . . . 7

2.3 Designing for the Mobile Environment . . . . 7

Chapter 3 – Theory and Methodology 9 3.1 Mapping the most common table solutions for mobile devices . . . . 11

3.1.1 Squish . . . . 12

3.1.2 Collapse by rows . . . . 13

3.1.3 Collapse by columns . . . . 14

3.1.4 Scroll . . . . 14

3.1.5 Click . . . . 15

3.1.6 Cutting/removing . . . . 16

3.1.7 Others . . . . 17

3.2 Statistic analysis of the most used table solutions on mobile devices . . . 17

3.2.1 Summary of the most used table solutions from research . . . . . 19

3.2.2 Motivation of further solution investigation . . . . 24

3.3 Usability test plan . . . . 25

3.3.1 Planning . . . . 25

3.3.2 Setup . . . . 26

3.4 Rule based system . . . . 27

3.4.1 Drools . . . . 28

3.5 Fuzzy logic . . . . 29

Chapter 4 – Results from user testings 33 Chapter 5 – Implementation and Solution 35 5.1 Characteristic features of each table solutions . . . . 35

5.2 The Visualization Wizard . . . . 36

(10)

5.3 System architecture . . . . 42

5.4 The rule-based system . . . . 47

5.5 Tables . . . . 52

5.5.1 Squish . . . . 52

5.5.2 Collapse by rows . . . . 53

5.5.3 Click . . . . 54

5.5.4 Scroll . . . . 55

5.6 Frameworks . . . . 56

5.6.1 HTML . . . . 56

5.6.2 CSS and Bootstrap . . . . 57

5.6.3 JavaScript . . . . 57

5.6.4 Golang . . . . 57

5.6.5 Prolog . . . . 58

5.7 API . . . . 59

Chapter 6 – Evaluation 61 6.1 Black box testing/evaluation . . . . 62

Chapter 7 – Discussion 65 7.1 Finding appropriate table solutions for specific types of data . . . . 65

7.1.1 Appropriate table solutions . . . . 66

7.1.2 Specific types of data . . . . 66

7.1.3 The user test structure . . . . 67

7.1.4 Mapping table solutions with specific types of data . . . . 67

7.2 Implementing the Visualization Wizard . . . . 68

7.2.1 The decision making . . . . 68

7.2.2 Technical problems . . . . 69

7.2.3 Security . . . . 69

7.3 Evaluating the evaluation . . . . 70

Chapter 8 – Conclusions and future work 71 Appendix A – Websites used during research 73 Appendix B – User testing 81 B.1 Test scenarios . . . . 81

B.2 Test results . . . . 82

B.3 Comments from user test . . . . 87

Appendix C – Installation guide 89

x

(11)

List of Figures

3.1 The methodology of the thesis process. . . . 10

3.2 A table displayed on a desktop screen. . . . . 11

3.3 A table displayed on a mobile device using a squish solution. . . . 12

3.4 A table displayed on a mobile device using a collapse by row solution. . . 13

3.5 A table displayed on a mobile device using a collapse by columns solution. 14 3.6 A table displayed on a mobile device using a scroll solution. . . . . 15

3.7 A table displayed on a mobile device using a click solution. . . . 16

3.8 The distribution of table solutions for the 100 reference tables. . . . 19

3.9 The distribution of website categories for the 100 reference tables. . . . . 20

3.10 The distribution of table categories for the 100 reference tables. . . . 21

3.11 The relationship between table categories and table solutions for the 100 reference tables. . . . 22

3.12 The relationship between table solutions and number of columns for the 100 reference tables. . . . . 23

3.13 The relationship between table solutions and grouped number of columns for the 100 reference tables. . . . 23

3.14 The process of the user test. . . . 25

3.15 The fuzzy logic systems architecture. . . . 30

3.16 The membership function. . . . 31

3.17 Defuzzification . . . . 32

5.1 The start page of the Visualizing Wizard. . . . 38

5.2 One of the question pages with its answers. . . . 39

5.3 A generated result with a suggested solution based on the answers from the quiz. . . . 40

5.4 A page with a responsive table solution. . . . . 40

5.5 System components of the Visualizing Wizard. . . . 41

5.6 A more describing image of the system components including the rule- based system in the Visualization Wizard. . . . 41

5.7 A more describing image of the system components including programming languages in the Visualizing Wizard. . . . 42

5.8 The system architecture. . . . 43

5.9 Activity diagram of the Visualizing Wizard. . . . 43 xi

(12)

5.12 Class diagram of the pre-made solutions for the Visualizing Wizard. . . . 46

5.13 The mapping of the answers leading to a squish solution. . . . 48

5.14 The mapping of the answers leading to a row collapse solution. . . . 49

5.15 The mapping of the answers leading to a scroll solution. . . . 50

5.16 The mapping of the answers leading to a click solution. . . . 51

xii

(13)

List of Tables

3.1 A selection of websites with tables found during research. . . . 18

3.2 A matrix with water temperatures vs the target temperature used to con- struct fuzzy rules. . . . 31

3.3 Example of knowledge based fuzzy rules. . . . 31

4.1 The total score for each table solution per test scenario. . . . 34

5.1 Questions and answers used for identifying table solution. . . . 37

5.2 REST API for generating a result. . . . . 59

6.1 Evaluation result. . . . 63

6.2 Accuracy of the evaluation result in percentage. . . . 64

A.1 All websites with tables found during research. . . . 73

A.2 All websites with tables found during research cont. . . . 74

B.1 Test ratings from scenario 1 (Product offering, 3 columns) . . . . 82

B.2 Test ratings from scenario 2 (Product comparison, 7 columns) . . . . 82

B.3 Test ratings from scenario 3 (Stock market, 5 columns) . . . . 83

B.4 Test ratings from scenario 4 (Sports, 10 columns) . . . . 83

B.8 Test ratings from scenario 8 (Product comparison, 5 columns) . . . . 85

B.9 Test ratings from scenario 9 (Sports, 5 columns) . . . . 86

xiii

(14)

(15)

C

^HAPTER

1 Introduction

A responsive design framework is crucial when developing modern web systems. The content needs to fit and be readable on a variety of screen sizes and resolutions like phone-, tablet- and laptop displays, and a wide variety of possible solutions exist. One of the more complex elements to make responsive is data tables, as smaller screens make it difficult to display tabular data while keeping the content readable and easy to use. This project aims to alleviate this problem by offering content-specific responsive guidelines that can be used throughout the implementation process.

1.1 Background

There are a lot of different approaches when it comes to displaying tables on small screens, such as on mobile devices, where some are better than others. New or altered solutions are developed all the time in different programming languages and with new techniques and using current technologies. This might be confusing when trying to decide which solution to approach when developing web pages that should include tables of some sort.

It is relatively easy to find examples and tutorials online of how to implement the different existing responsive tabular solutions and also to find documentation about new techniques. There is, however, not that many guides or information about when to use what type of table representation.

The work aims to collect already existing table approaches and examine possible solutions for different types of data. By using the collected data and combining it with results from user tests, a tool can be produced to help web developers to implement their tables.

1.2 Motivation

It can be difficult to decide what type of table implementation to use for mobile devices to keep a decent readability. This thesis can simplify the process of developing and de-

1

(16)

signing web pages that contain tables and can therefore be a helpful tool. The work is important for companies that would like a more effective and standardized way of implementing responsive table solutions. It is important to have something relevant to rely on when making decisions about tabular representations. Something that represents the thoughts and opinions from users and is based on best practices.

A tool to help both developers and UX-designers decide on how to implement and design a responsive table solution would be beneficial for a company with focus on web development. If there are guidelines and best practices on when and how to use which tabular representation it would save the developers and designers time from doing the same research over and over again. The main impact for this thesis is therefore economi- cal and customer satisfaction through improved user experience. The time the company could save by using the tool also means they could save money on development. Time and money that could be used on other important parts of the web system implementation.

1.3 Problem definition

The major problem to be solved in this project is how to present tables on mobile devices.

How can tabular data be visualized with good readability on small devices, such as mobile phones? Tabular data that is readable on larger screens may end up being cluttered and too small to read on smaller devices. It can therefore be necessary to visualize tabular data in other ways for mobile devices, and this thesis investigates different methodologies and approaches for this in order to make recommendations for different types of tabular data representations.

In some cases, rows and columns are squeezed together to make the whole table fit a small area and in other cases, columns and rows are simply removed for the table to be displayed on mobile devices. There are a lot of different approaches to address this problem, a lot of different ways to present tabular data on small screens but even more questions about when to use which solution on what data.

What responsive table solutions are appropriate for different types of data? And how can this information be used to help developers and designers deciding which approach to use? This thesis investigates and proposes guidelines for developers on different im- plementations and what responsive table solution to use in an implementation.

One objective for this problem is to examine if there are some tabular solutions that are more common to use on mobile devices. Patterns in when a specific implementation is used for a specific type of data can be found by researching a variety of web pages and mapping its responsive solutions for tables. Another objective is to investigate which

(17)

1.4. Delimitations 3 tabular solutions are more preferable in different scenarios on mobile devices. To do this, user tests should be performed to collect valuable input and opinions about various table solutions and their functionality. It’s important to take advantage of users’ point of view to determine best practices for visualizing tabular data on mobile devices.

Based on the investigations above, a tool to help decide on which table solution to use should be developed. The tool should be a web system where the user answers a couple of questions about the tabular data to be implemented and then gets a result generated.

The result should be a responsive table solution with some helpful guidelines on how the user could visualize tabular data on mobile devices.

1.4 Delimitations

This thesis describes an attempt of building a tool to assist with the designing and development process of a responsive web system including tabular data. In order to build a complete system that covers all possible types of data and aspects of table solutions, it would require a lot of more work and time. There was simply not enough time to evaluate all different areas and therefore I made the decision to limit the number of table approaches and types of data to a reasonable amount to focus on. The choice of approaches and types of data was based on research presented in section 3.2 in this thesis.

Covering more responsive table solutions would most likely provide a more accurate result. Also, the graphical user interface had a lower priority since it was more important to focus on the functionality rather than the design of buttons for instance.

1.5 Thesis structure

This thesis starts by describing some related work in chapter 2 and continues by resolving theory and methodology behind the project in chapter 3. Some of the findings from the theory are investigated by performing user tests and this is explained and disputed in chapter 4 along with the summarized user test result. Based on the discoveries from the theory and user tests, a web system is developed to solve the problems from section 1.3.

The implementation of this system and everything about it is described in chapter 5, and in the chapter after, 6, the result is evaluated. A discussion of improvements and about the result can be read in chapter 7 and after that follows the conclusion and suggestions about future work in chapter 8. An appendix and a reference section is also included at the end of this report.

(18)

(19)

C

^HAPTER

2 Related work

There is not that much research about when to use which kind of table solution, nor about any tool or similar to help with the process of implementing a table that can be presented in an appropriate way on a mobile device. There is however some related work that in a way can be associated with this thesis work and these are described in this section.

2.1 Responsive tables: Best practices

It can be difficult to implement tabular data with responsive web design in order to keep the table readable on a smaller screen, such as a mobile device. The web development platform DevKit recommends asking yourself two important questions before beginning with the development [1]:

1. What information needs to be displayed?

2. Is it necessary to compare rows and columns?

The article also states that it’s not a good idea to hide/remove some content based on which device is used and it denotes that the right table solution depends on the content. But exactly which solution is appropriate for which type content is not further investigated. There are however some recommendations of which table solutions DevKit considers to be the best approaches.

• Chris Coyier’s Responsive Table - a responsive tabular solution that transforms each row into a block of content and allows access to all data without scrolling.

• Horizontal Scroll Table - an approach that is better for row and column comparison and that allows the user to scroll horizontally to view all data.

• Frozen Column - the table solution freezes a column and keeps the other columns scrollable horizontally. Some advantages with this solution is that it doesn’t break responsive layouts, it doesn’t unnecessary hide data and also still is good for com-

5

(20)

paring rows.

• Column Display Menu - a solution that lets the user compare data by controlling which data are displayed by a drop-down menu.

• FooTable - this solution hides the columns that doesn’t fit the screen and adds a

’+’ sign to let the user expand that row to see the rest of the data.

• Flip Scroll - the orientation changes in this table solution which means the column labels becomes row labels on the left. The row’s data is displayed horizontally using scroll.

• Tap to View - a thumbnail of the table is displayed that the user can click on and get the full version of the table.

DevKit believes that all of the above responsive table solutions are good options, but recommends Chris Coyier’s basic table for most types of data. The Integrated Informa- tion Technology Services (IITS) has also listed some guidelines for tables and listings for mobile devices [2].

• Avoid using dark grid-lines and vertical dividers.

• Use left align for text and right align for numbers.

• Don’t overload the screen.

• Arrange the data in an alternative way if there is too much information to fit on a single screen.

• Use maximum three rows in each data cell when no headers are used. Use smaller and/or lighter font for less important details.

• Separate the summary rows from the other rows in the table when using grouped rows.

• For tables with visual indicators, choose visual indicators that are immediately rec- ognizable; avoid gratuitous icon use.

2.1.1 Best practices for comparison tables

One of the leading voice in UX, Nielsen Norman Group has published a lot of articles about how to implement websites from a UX perspective. One article is about what the best practices are when building comparison tables [3].

• Don’t use more than 5 columns for comparison. If it’s absolutely necessary then add other mechanisms such as filters so that the user can narrow down their options.

• Be consistent with the content, for instance, if one object is missing from a column then the table becomes useless.

• Enable scanning for differences. It makes it easier for users to compare data.

• Use sticky column headers to help the users to keep track what each column is.

• Use meaningful attributes that the user cares about.

(21)

2.2. Guidelines for Mobile HCI 7

• Give users control over which attributes to compare, and in what order.

2.1.2 Comparisons and other data tables

Nielsen Norman Group also have an article about how to fit a large amount of data on a small screen without having to limit the number of rows of columns [4].

• Columns Large Enough to Be Legible - the number of columns that fit on mobile screen without scrolling or similar depends on the width of those columns.

The data need to be legible without requiring the user to zoom in.

• Rotating the Phone Is a Last Resort - implement a table that doesn’t require the user to rotate the phone.

• Stick Column Headers in Place - if the headers are frozen it helps the user to keep track of the data.

• Clearly Indicate if Horizontal Scrolling Is Needed - add arrows that instructs the user if the table needs scrolling.

• Stick the Left Column in Place - if the user must scroll horizontally to see all data, it’s good to lock the first column, which is usually the labels.

• Let Users Select the Data to View - the users might not want to see all the content and by allowing them to select which content to display then it can increase the experience.

2.2 Guidelines for Mobile HCI

The article Future of Mobile Human Computer Interaction Research - A Review written by M. Nazir, I. Iqbal, H. Shakir, A. Raza and H. Rasheed offer some guidelines for designing a mobile device interface [5]. Two of the guidelines associated with designs for mobile device interfaces are:

• Using shortcuts - keep the design simple and try to reduce the number of inter- actions in order to increase the user experience.

• User friendly feedback - Give easy and understandable error messages or alarms to the user while operating the mobile phone.

The article states that it’s difficult to develop guidelines for designing mobile devices since mobile devices have fewer resources to utilize as compared to desktops.

2.3 Designing for the Mobile Environment

The Interaction Design Foundation has listed some guidelines and principles to design for the mobile environment [6]. The basic considerations for the mobile web according to them are:

(22)

• Small screens

• Keep navigation simple

• Keep content to a minimum

• Reduce inputs required from users

• Reminder: mobile connections are not stable

• Continuous integrated experience

The considerations relevant for tables in this case are small screens, simple navigation and keep the content to a minimum, and they are about the following:

• Small screens - Since there are a large variety of screen sizes it’s a good idea to focus on a ”mobile first” approach where you start designing for a small mobile device first and then increase the complexity from there.

• Keep navigation simple - It can be difficult to navigate on small screens such as mobile devices and it’s a good idea to for instance, try to minimize the levels of navigation involved, prioritize navigation based on the way users use it and ensure that the labeling is clear and concise for navigation.

• Keep content to a minimum - It’s important to respect the small screen space and keep it simple by not adding too much content. Don’t write too much, keep the descriptions short and to the point.

A UX Evangelist and writer named Joe Natoli also lists 5 crucial principles of great mobile design in an article [7]. These are similar to the guidelines above but more describing.

• Design the parts to be consistent with the whole. - Keep in mind that the implementation is part of a bigger family. It shouldn’t be confusing to switch between a mobile device and a desktop environment.

• Make opportunities to interact obvious and visible. - Keep key navigation elements visible, otherwise it’s difficult for the user to interact with something they can’t find.

• Aim for single-trial learning. - If the user knows how to operate the website on the first try it’s likely that she will get a better experience. It will increase the effectiveness, efficiency and satisfaction.

• Give people the ability to predict the result of their actions. - People don’t want to be surprised by what happens when an action is made and it’s a good idea to keep the work flow logical.

• Anticipate the user’s questions — and answer them real-time. - Make sure the user knows what’s happening. If the user writes a document she can see that text is added to the white paper, but if she clicks save she can’t really know where the data is. A message that says ”your text has been saved” is a good confirmation.

(23)

C

^HAPTER

3 Theory and Methodology

This chapter describes the methods and theories that have to be evaluated in order to solve the problem of this thesis. It explains the steps taken before implementing the actual solution and includes important aspects to consider when designing a tool to help developers and designers choose a responsive tabular solution. Figure 3.1 shows the process of the entire thesis work.

9

(24)

Figure 3.1: The methodology of the thesis process.

The process is basically divided into four main parts; research, user testing and selection of frameworks and approaches, implementation and evaluation. All parts are based on each other. The user test and selection of frameworks and approaches depends on the findings from all of the research and the user test also lays as the foundation of the implementation of the solution. All parts leading up to the web system is crucial to the final result which is evaluated and discussed at the end.

(25)

3.1. Mapping the most common table solutions for mobile devices 11

3.1 Mapping the most common table solutions for mo- bile devices

A table is defined as a systematic arrangement of data, usually in rows and columns for ready reference [8]. In HTML a table is mainly defined by using the <table> tag and each new row are defined with <tr> (table row). The data entries, or the content, which forms the columns in the table is defined by using the <td> (table data) tag. It is however also possible to create tables by using a various numbers of <div> tags and defining the design in CSS, but this thesis focuses on tables defined by <table>.

The following sections describes some of the most common approaches for responsive tables that have been found during research for this thesis. The tables look very similar when presented in a browser on a laptop or a desktop screen. It is when the same table is displayed in a browser on a mobile device with a smaller screen that the layout can differ from each other.

Figure 3.2: A table displayed on a desktop screen.

(26)

3.1.1 Squish

Squish is a solution that keeps the original layout on mobile devices, only reduces the size of it to fit the smaller screen. Figure 3.3 displays a squish representation of figure 3.2. This is a very common approach as it’s almost identical to the original table and is therefore easy for the users to read from. Although, if the table contains too many columns it can be difficult for the user to interpret the table data. A large set of columns forces the content to scale down to fit everything on the same screen and this means reducing the text size as much as needed. Therefore, squish is more favorable with a fewer number of columns.

Figure 3.3: A table displayed on a mobile device using a squish solution.

(27)

3.1. Mapping the most common table solutions for mobile devices 13

3.1.2 Collapse by rows

Collapse by rows means that each row splits up and forms its own column that places in separate boxes on top of each other on the phone screen. A row collapse of figure 3.2 is demonstrated in figure 3.4. It is advantageous for tables that doesn’t contain large datasets and with rows that isn’t supposed to be compared to another row in the table.

The solution is easy to read when a specific value is to be considered and it makes the data very accessible and clear.

Figure 3.4: A table displayed on a mobile device using a collapse by row solution.

(28)

3.1.3 Collapse by columns

Collapse by columns works in the same way as collapse by rows with one difference, it splits the table by columns instead of rows. When the table is displayed on a mobile device each column places itself in separate boxes on top of each other. Depending on whether the table is column or row oriented the solution should be accordingly. However, collapse by row is a more common approach.

Figure 3.5: A table displayed on a mobile device using a collapse by columns solution.

3.1.4 Scroll

When a table is displayed on a mobile device where the responsive table solution scroll is used, some of the content is at first hidden. The content that doesn’t fit the smaller screen, also known as the table overflow, can be viewed by scrolling horizontal back and forth. A scroll approach can either be to scroll the entire table backwards and forwards or the table can have the first column frozen and have the rest of the columns scrollable. If a column freezes it will stay fixated on the same location no matter how much the user is scrolling, it can for instance be advantageous when the headlines are placed in the first column. Figure 3.6 is a scroll solution of figure 3.2 with its first column frozen.

The scroll approach can be handy for lookup and comparison, although not when a lot

(29)

3.1. Mapping the most common table solutions for mobile devices 15 of columns should be compared at the same time. When all content isn’t visible at the same time, it can be difficult to remember other columns when the table data constantly keeps scrolling back and forth.

Figure 3.6: A table displayed on a mobile device using a scroll solution.

3.1.5 Click

The click solution is very similar to the scroll approach. Some of the table content is required to hide when the other content is visible due to the limited screen area on a mobile device. In order to switch between the columns a button can be clicked to move either left or right. And like the scroll solution, click also have the first column frozen to increase readability and usability.

Too many columns to click through can be confusing if the purpose of the table is to compare different columns with each other. The user could easily forget the data to compare with while clicking left and right when parts of the content becomes hidden.

Figure 3.7 displays a click solution of figure 3.2 with a frozen first column. The left and right buttons to toggle between the table’s columns is placed in the top right corner of the phone.

(30)

Figure 3.7: A table displayed on a mobile device using a click solution.

3.1.6 Cutting/removing

Another common approach that requires more understanding of the content is to simply remove some columns to make a better fit on the screen of a mobile device. In some cases, not all data is important enough to keep directly in the table and it is therefore taken out when the size of the screen becomes smaller. An example of this can be in sports tables where the table on a desktop browser might both display the score from one game and the goal difference from the same match. On a phone screen the same table could have removed the goal difference column if the creators feel like it is unnecessary or superfluous. The developers and designers chose which columns are most important to present in the table on a mobile device and removes the others. The information in the cut out columns can often be found in other places on the website however.

(31)

3.2. Statistic analysis of the most used table solutions on mobile

devices 17

3.1.7 Others

Other solutions that can be found are for instance a combination of two or more approaches or that there is no responsive solution at all. If the website looks exactly the same on a desktop screen as on a phone screen, it could indicate that there is a mobile application to compensate for the lack of responsive design for the website. To combine two or more solutions is an approach that fuses the best parts of each used solution and forms a new one. It can for instance be a row collapse combined with squish where each row collapses and puts its first column as a header and the rest of the columns squish together underneath. Each new row formation are placed as separate boxes on top of each other. Another example where two solutions are combined is when both squish and removing of some columns are used at the same time. By removing various numbers of columns it becomes easier to fit the table on the mobile screen.

3.2 Statistic analysis of the most used table solutions on mobile devices

In order to know which responsive table solution is more suitable for a specific type of data, some research had to be done about finding tables on various number of websites and analyze its content, structure and approach for mobile devices. Each table was categorized according to how many columns the table had on both a laptop screen and on a phone screen, what type of website the table were used on and what type of solution the table had on a mobile device. The tables were also categorized based on what type of data the table actually contained since there are cases where the classification of the website didn’t match the type of the data. An example of this is when newspaper web pages hold sports tables in which it would be misguided to categorize the table as news when it’s really sport results.

A total of 100 different tables were evaluated during the research, majority from Swedish companies or authorities. The websites used to find the tables, were chosen randomly and without any ulterior motive. I tried to make a diverse selection with representatives from different industries that are of common interest for regular people. The total number of 100 was selected because it seemed like an appropriate amount in order to cover a large scope of different types of websites and tables. The findings from the gathering gives an idea of how the reality might look like. However, it’s not the entire truth, since the chosen tables are just a fraction of the tables used on the Internet. A full list of the websites that were used to find the most used solution for mobile devices can be found in appendix A. The following table contains information about a few of the tables found during research.

(32)

Table 3.1: A selection of websites with tables found during research.

Website Category

website

Category table

Number of columns laptop

Number of columns mobile

Solution

SAS Travel Product

offering

13 13 Scroll

Ticket Travel

agent

Product offering

5 3 Collapse

by rows Halebop Telephony Product

offering

6 6 Squish

Nordea Financial Product comparison

3 2 Collapse

by rows

Kia Index Statistics Statistics 12 3 Click

Migrations- verket

Authorities Statistics 5 5 Scroll

Citybuss Pite˚a

Travel Timetable 5 4 Squish +

removing

Corren Magazine Sports 7 7 No ap-

proach

Allra Subscrip-

tions

Product comparison

5 3 Squish +

collapse by rows Riksbanken Financial Product

information

4 4 Squish

Lule˚a tekniska universitet

School Product offering

5 2 Collapse

by rows

A summary of all the findings from the gathering of data about the different tables is presented in charts in the following section.

(33)

devices 19

3.2.1 Summary of the most used table solutions from research

As mentioned in the previous section, the number of tables used for this research is 100.

The data has been categorized into different categories and to simplify its distribution it is presented in various charts below.

The first chart, figure 3.8, displays the distribution of the different responsive table solutions found during research. The most common approaches for mobile devices according to the aggregated data is the squish solution, collapse by rows and scroll. An explanation of what the different types of solutions means can be read under section 3.1.

Figure 3.8: The distribution of table solutions for the 100 reference tables.

(34)

One of the categorizations of the tables were according to the type of web page the table were on. If, for instance, the website is an online magazine but the table contains data from the stock market, then the categorization in this case would be magazine. The distribution can be seen in figure 3.9 and a conclusion of the chart is that there might be too many categories to obtain any patterns for when which solution is more preferable to what data. Also that the website category perhaps isn’t that relevant when finding patterns.

Figure 3.9: The distribution of website categories for the 100 reference tables.

(35)

devices 21

After evaluating the importance of website categories when finding patterns on when to use which solution to what data, the next step is to evaluate the relevance of table categories. Figure 3.10 displays a chart of the table category distribution and compared to the website category distribution in figure 3.9 there’s a few less pies to keep track on.

The pies are also larger, which means it can be easier to draw conclusions when finding patterns. The most common table categories are product offerings, product comparison, sports and stock market.

Figure 3.10: The distribution of table categories for the 100 reference tables.

It is more relevant to use the table category distribution than the distribution for website categories since it describes the content instead of the context. This thesis is about mapping which responsive table solution is more appropriate to use for a specific type of data and, therefore, it’s more important to study the content of the tables. The next step is to investigate if there is any relationship between the table categories and the table solutions. In figure 3.11 it can be seen that there are some solutions that are more common for some table categories, but it’s not clear enough to draw any assumptions.

The data is overall scattered and there is not enough readings for some of the table categories which makes it difficult for a conclusion about those.

(36)

Figure 3.11: The relationship between table categories and table solutions for the 100 reference tables.

Another factor that can be interesting to take into consideration is the relationship between the table solution and how many columns a table had on the larger screen before it was displayed on a mobile device. Figure 3.12 presents the relationship for the tables with different amount of columns. Of all the 100 tables used for this research, the majority has a maximum of 3-6 columns. Again, there is no clear pattern on which solution that is more preferable to a table with a specific number or columns.

(37)

devices 23

Figure 3.12: The relationship between table solutions and number of columns for the 100 reference tables.

Figure 3.13 is a simplified plot of figure 3.12. The difference is that the columns are grouped together with column intervals instead, to hopefully make it easier to draw conclusions. Since squish and collapse by rows are two of the most commonly used solutions of the 100 inspected tables they are bound to be the larger parts of the bars.

Figure 3.13: The relationship between table solutions and grouped number of columns for the 100 reference tables.

(38)

3.2.2 Motivation of further solution investigation

Based on the data from the gathering of tables and on the result from the graphs, there are a few solutions and factors that should be further investigated. It would be too ex- tensive to continue the work with all of the different categories and solutions during the short amount of time available for this thesis. The selected solutions and factors will be used for user testings in order to evaluate the different approaches from a user’s point of view. The responsive table solutions that should be further investigated are based on figure 3.8 and are the following:

• Squish

• Collapse by rows

• Scroll

• Click

The first three approaches represents almost 3/4 of the total amount of solutions found during this research and are therefore indisputable to continue the work with. However, the fourth most common solution according to the chart is squish + removing, but since squish already is one of the selected approaches it is more relevant to study click. Also, removing requires more knowledge of the content in order to decide which data is more important than other. Therefore the four responsive table solutions chosen to continue the work with are squish, collapse by rows, scroll and click. The table categories chosen for further investigations are based on figure 3.10 and are the four most common that’s been found during this research:

• Product offering

• Product comparison

• Sports

• Stock market

Finally, there had to be some limitations on the number of columns to use for the upcom- ing analysis. For this part it’s important to get an even spread of the numbers to be able to compare the results later on. The selection of which columns to use is partly based on figure 3.12 to get an approximately even distribution, but also because it’s supposed to cover a variety of number of columns. The chosen amount of columns to use for further investigations are the following:

• 3 columns

• 5 columns

• 7 columns

• 10 columns

(39)

3.3. Usability test plan 25

3.3 Usability test plan

The findings from section 3.2 is a good start on reaching some kind of conclusion on when a specific table solution is appropriate to use when presenting a table on a small screen, such as on a mobile device. But the collected data isn’t enough. It’s important to consider users’ experience and opinions when evaluating and analyzing the possibilities for a relevant recommendation of table solutions. The following subsections describe how the user tests were planned and executed and image 3.14 gives an overview of the process.

Figure 3.14: The process of the user test.

3.3.1 Planning

The user test was planned to ensure a valuable outcome with relevant input to the implementation. To have some relevant input to base the final implementation of. According to a UX resource site called Usability.org there are 10 planning elements to be considered before performing a user test [9]:

• Scope - what is being tested?

• Purpose - determine the concerns, questions and goals for the test.

• Schedule and location - determine when and where the test should happen.

• Session - describe the length of the tests and what’s going to happen during that

(40)

time.

• Equipment - describe which type of equipment to use during the test.

• Participants - describe how many and what type of participants should participate in the tests.

• Scenarios - decide on how many and what type of tasks to be performed during the test.

• Subjective metrics - decide which questions to be asked before, after and during each session about the feelings and satisfaction about the system to be tested.

• Quantitative metrics - decide which quantitative data to be measured during the test.

• Roles - decide which roles the people in the team to perform the test should have.

The scope of this user test is the different table solutions with a variety of table categories and the number of columns. This is to identify which table solutions are more preferable in different scenarios by the user. A session was planned to last about 30-45 minutes where the test person goes through different scenarios and analyzes the table solutions.

Since the test is about visualizing tables with different size constraints, it was decided to use a laptop environment but with a browser size to simulate the area of a phone. In that way it’s easier for the observer to follow the steps in a better way as well as record the screen and voice of the test person to have something to go back to later for references.

The experience level of the participants was not considered important for the selection of participants, as long as they had some basic experience about navigating a website, which can be assumed most people have today, they were accepted. The objective was to get input from everyday Internet users to get their opinions about how good different table solutions are. The user test required a focus group for a qualitative study which meant that around 6-10 persons would therefore be a good amount to interview. A quality study was to prefer instead of a quantitative study since I wanted more than metrics as a result. The following section, setup, describes more about the scope and about the scenarios and the different metrics.

3.3.2 Setup

A test website was created based on the motivations from section 3.2.2. Pages are divided according to table categories and the number of columns and contain all four table solutions with the same data, only in different orders. For instance, one page is product offering with 5 columns, and on that page there are one squish table, one collapse by rows table, one scroll table and one click table. All of them including the same data set presented in different orders. Each page also presents the different tables in a random order so that no page has the same lineup as another. By randomizing the order of the data and the order of the tables, the user becomes more active during the tests. The data

(41)

3.4. Rule based system 27 sets are different for each page to adapt to the table category and number of columns.

This is to make the user tests more realistic to real-life scenarios and easy to understand.

By having the four different table categories it also increases the chance that the user is familiar with the content.

After setting up the test environment, test scenarios, or smaller tasks, were created to match the different pages. The test scenarios were used to give the user a purpose and goal while searching through the tables instead of just looking aimlessly at them. The UX resource site Usability.gov recommends around 8-10 scenarios to be included in a user test [9] and based on that 10 scenarios were chosen for this user test. Scenarios with different table categories and number of columns in order to get the largest range possible. All test scenarios can be found in appendix B.1 but one of them is presented below as an example.

You are going to buy a new cellphone subscription and wants a minimum of 6GB surf data per month. You want to consider your options and to know the price.

- Product offering, 7 columns.

3.4 Rule based system

One of the outcomes of this thesis is the Visualizing Wizard, which guides developers to select the appropriate table. The Visualizing Wizard is based on a rule based system. A rule based system is a relatively simple model based on a set of rules and facts as well as an inference engine [10]. It basically consists of if-then statements that specifies how the system should perform. Given a number of rules, there are two ways to use them in order to generate some kind of result.

• Forward chaining: a data driven approach that applies rules given the facts. Rules represent which actions to take when a specific fact occur.

• Backward chaining: a goal driven approach which looks for rules to help answer a question or statement. It reasons from goals back to facts which, means that backwards chaining focuses on the search.

Which chaining to use depends on the problem and on the rules. Backwards chaining might be better to use when a clear hypothesis or path is set while forward is better when the hypothesis is less precise [10]. Overall, rule-based systems are beneficial for smaller problems where the rules can be written in the if-then form. If the system has too many rules it can be less efficient and it can be difficult to maintain.

With some problems (often larger) there might be more than one rule that applies to the different facts and in those cases a conflict resolution strategy can be used to eliminate all but one rule. One of the simpler strategies is to use the first applicable rule and therefore

(42)

be careful when placing the rules in the wanted order of selection. It can also be done by using a priority queue with different weights for the different rules. Another approach is to simply choose a random rule that applies to the facts which provides unpredictability and can be advantageous in games. However, randomness is not that good to use when control of the system is desirable. Which conflict resolution strategy to use is determined depending on the problem and preferences, some might work better for a specific type of problem while others are preferable in other situations.

Apart from a conflict resolution strategy, there are some requirements that are necessary when creating a rule-based system for a given problem. They have been briefly mentioned above but are good to be clarified [11]:

1. An initial working memory that is defined by a set of facts.

2. An appropriate number of rules within the scope of the problem.

3. A condition that terminates the rule-based system by stating that a solution has been found or doesn’t exist.

The rule-based system could be considered as a simple form of artificial intelligence and can be a good approach when developing a tool with a numerous of rules like this thesis focuses on.

3.4.1 Drools

A technique/system that can be relevant for this type of project is the business rule management system (BRMS) Drools. It is built upon a rule based system and includes a forward and backward chaining inference based rule engine [12]. It allows companies to set up rules for a large web system and it provides a reliable evaluation of business rules and complex event processing. Drools can be a good system to integrate in a web project when it’s desirable to create an expert system that emulates humans’ capability to make decisions, like AI.

Drools uses the Rete algorithm which removes the need for constant calculations and rather uses pattern-matching to pair rules with facts [13]. By storing partial matches, the system avoids having to re-evaluate all the facts each time something changes in the working memory. This allows the rules to be evaluated much faster since the system only calculates the changes.

Instead of using a lot of different IF-THEN statements, Drools use a framework that provides the same benefits of configuration, readability and also keeps it simple. A setback for Drools in this project is that it’s made to be used in business systems and the scale of the work for this thesis might be more limited.

(43)

3.5. Fuzzy logic 29

3.5 Fuzzy logic

Another concept that was evaluated and taken into consideration before implementing the Visualization Wizard was Fuzzy logic. Fuzzy logic is a concept which can provide a truth value anywhere between 0 and 1. It is similar to humans’ way of decision making since it contains all the possible answers between YES and NO. Instead of the computer producing the more conventional logic block output True or False (1 or 0) which is equiva- lent to humans’ YES or NO, the computer has a range of possible outputs that resembles human reasoning. These can be a variety of different YES and NO compositions, for instance [14]:

• Certainly YES

• Possible YES

• Can’t say

• Possible NO

• Certainly NO

Compared to rule-based systems, fuzzy logic deals with fuzzy consequents and fuzzy pre- decessors which can be beneficial when developing an AI system. It helps deal with the uncertainty in the system and even though it doesn’t provide precise interpretation it provides acceptable reasoning.

Consider some simple examples of when fuzzy logic can be implemented and mapped with everyday life inputs and outputs [15]:

• With the input on how good your service was at a restaurant, fuzzy logic system can give an output of how much tip is appropriate to give.

• With the input on how hot water you want, fuzzy logic system can adjust the temperature to the right setting.

• Fuzzy logic system can help focus the camera lens if it has information about how far away the subject is from the camera.

• With input about how fast a car is going and how hard the motor is working, fuzzy logic system can help shift gears.

Fuzzy logic is flexible and conceptually easy to understand and use since it reminds of the way humans think and communicate and also because the mathematical concepts behind its reasoning are fairly simple. Fuzzy logic can handle imprecise data because it builds its understanding into the process instead of attaching it onto the end. These are a few of the general observations about why to use fuzzy logic [15]. However, if the fuzzy logic system gets too complicated it won’t be as understandable and also, there is no systematic approach when designing a system with fuzzy logic.