visualization of tabular data on mobile...

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

ABSTRACT

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

PREFACE

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

Associate Professor Josef Hallberg at Lulea University of Technology for providing valu-

able 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 Caspar

v

LIST OF ABBREVIATIONS

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

CONTENTS

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

5.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.2.2 System components . . . . . . . . . . . . . . . . . . . . . . . . . . 41

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

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

5.10 State diagram of the Visualizing Wizard. . . . . . . . . . . . . . . . . . . 44

5.11 Class diagram of the Visualizing Wizard quiz. . . . . . . . . . . . . . . . 45

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

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.6 Test ratings from scenario 6 (Stock market, 10 columns) . . . . . . . . . 84


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

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

B.10 Test ratings from scenario 10 (Stock market, 7 columns) . . . . . . . . . 86

xiii

CHAPTER 1Introduction

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 dif-

ferent 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

2 Introduction

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 im-

plementing 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 de-

sign 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 implementa-

tion.

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

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 DelimitationsThis 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 structureThis 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.

CHAPTER 2Related 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 con-

tent. 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 com-

parison 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

6 Related work

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.

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 HCIThe 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 EnvironmentThe 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:

8 Related work

• 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 mo-

bile 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.

CHAPTER 3Theory 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

10 Theory and Methodology

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.

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.


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.


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.


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 scrol-

lable. 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


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.


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.

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

3.1.7 Others

Other solutions that can be found are for instance a combination of two or more ap-

proaches 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 solutionson 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 cat-

egorized 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.


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

compari-

son

3 2 Collapse

by rows

Kia Index Statistics Statistics 12 3 Click

Migrations-

verket

Authorities Statistics 5 5 Scroll

Citybuss

Pitea

Travel Timetable 5 4 Squish +

removing

Corren Magazine Sports 7 7 No ap-

proach

Allra Subscrip-

tions

Product

compari-

son

5 3 Squish +

collapse by

rows

Riksbanken Financial Product

informa-

tion

4 4 Squish

Lulea

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.


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 solu-

tions 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.


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.


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.


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.


Figure 3.12: The relationship between table solutions and number of columns for the 100 refer-

ence 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 con-

clusions. 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.


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

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 imple-

mentation. 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


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 di-

vided 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

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


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.

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.


The fuzzy logic systems architecture has four main parts which is described below and

displayed in figure 3.15 to give an overview of the system [14]:

• Fuzzification Module - Which handles the crisp system inputs and transforms it into

fuzzy sets and splits the input signal into five steps: Large positive (LP), Medium

positive (MP), Small (S), Medium negative (MN) and Large negative (LN).

• Knowledge Base - This store IF-THEN rules.

• Inference Engine - It provides fuzzy inference on the inputs and IF-THEN which

simulates the human reasoning process.

• Defuzzification Module - This takes the fuzzy set acquired by the inference engine

and transforms it into a crisp output.

Figure 3.15: The fuzzy logic systems architecture.

To describe the logic development of the hot water example above, five steps based on

the four main parts of the process are used [14]:

1. Define linguistic variables and terms - these are simple input and the output

variables, which for the hot water are: very cold, cold, warm, very warm and hot.

2. Construct membership functions for linguistic variables and terms - this

should represent the fuzzy set graphically and defines the degree of membership

to each element. Figure 3.16 displays the membership function for the hot wa-

ter with the five step input signal from the Fuzzification Module (Large positive

(LP), Medium positive (MP), Small (S), Medium negative (MN) and Large nega-

tive (LN)).

3.5. Fuzzy logic 31

Figure 3.16: The membership function.

3. Construct knowledge base rules - in this step all the rules are defined by first

creating a matrix to define actions based on what the water temperature currently

is and what the target temperature is. This is to build a set of rules into the

knowledge base. The matrix for the water example would be:

Table 3.2: A matrix with water temperatures vs the target temperature used to construct fuzzy

rules.

WaterTemp

/Target

Very Cold Cold Warm Hot Very Hot

Very Cold No change Heat Heat Heat Heat

Cold Cool No change Heat Heat Heat

Warm Cool Cool No change Heat Heat

Hot Cool Cool Cool No change Heat

Very Hot Cool Cool Cool Cool No change

Based on the expected outcomes depending on actual water temperature versus

the target temperature the set of knowledge based rules can be constructed, for

instance:

Table 3.3: Example of knowledge based fuzzy rules.

Rule

no.

Condition Action

1 IF temperature(Cold OR Very Cold) AND targetWarm THEN Heat

2 IF temperature=(Hot OR Very Hot) AND targetWarm THEN Cool

3 IF (temperature=Warm) AND (target=Warm) THEN No Change


4. Obtain fuzzy value - the fuzzy set operations AND and OR (Min and Max) perform

the evaluation of the rules. The combination of all evaluation results form a final

result which is a fuzzy value.

5. Perform defuzzification - this transforms the fuzzy value according to the mem-

bership function into a output value (Large positive (LP), Medium positive (MP),

Small (S), Medium negative (MN) and Large negative (LN)).

Figure 3.17: Defuzzification

Fuzzy logic systems are, as mentioned, good for imprecise and noisy input information

as long as it’s kept simple. For simple problems like adjusting the water temperature

it works well, but for more complex systems like mapping features of a table with a

responsive tabular solution it might be more complicated.

CHAPTER 4Results from user testings

The purpose of the user tests was to identify which table solutions were more preferable

in different scenarios by the user. A total of 8 test persons performed the user test and

the execution of the user test was the following:

1. The user was given a scenario/task and the tables associated with that scenario

with a specific type of data and number of columns.

2. The user had to go trough the 4 different responsive table solutions and solve the

”task” for each table.

3. The user made comments and opinions about the different approaches while going

through the tables.

4. When the user had gone through all the tables and solved the ”task”, the user had

to rank each table solution according to which the table preferred. The score was

between 1-4, where 1 was given to the most liked table solution and 4 to the least

liked.

5. The user had to repeat step 1-4 until all 10 scenarios were done.

The focus group consisted of 8 test persons. When all the test persons had been inter-

viewed a final score was calculated for each solution on each page. All test results, with

the exact score from each person can be read in appendix B.2. However, a summary

of a scenario’s total score per solution can be seen in table 4.1, where a low score indi-

cates the most preferred responsive table solution and is marked with bold font in the

table. Scenario 1 doesn’t have any ratings for scroll and click due to the tables being

too small with only 3 columns and it’s therefore meaningless to use the click and scroll

solution.

33

34 Results from user testings

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

Row collapse Squish Click Scroll

Scenario 1 (Product of-

fering, 3 columns)

11 13 - -

Scenario 2 (Product

comparison, 7 columns)

24 14 19 23

Scenario 3 (Stock mar-

ket, 5 columns)

22 10 26 22

Scenario 4 (Sports, 10

columns)

28 25 17 10


fering, 5 columns)

20 13 22 25

Scenario 6 (Stock mar-

ket, 10 columns)

29 25 11 15


fering, 7 columns)

22 22 20 16

Scenario 8 (Product

comparison, 5 columns)

28 8 19 25


columns)

17 11 27 25

Scenario 10 (Stock

market, 7 columns)

26 13 21 20

Apart from the ratings which was the main focus during the tests, there were also some

valuable comments and thoughts from the test persons. These can be read in appendix

B.3 and is also an important part that’s been taken into consideration when mapping

the different solutions.

CHAPTER 5Implementation and Solution

This chapter introduces the solution of the tool that’s been implemented based on the

findings from the research and the user test. It answers the questions from section 1.3

and describes the architecture and design of the solution. The tool built for this thesis

is a web system to help developers and designers deciding which responsive solution to

use is called the Visualizing Wizard.

5.1 Characteristic features of each table solutions

Based on the results from the user test and on the statistic analyze there are some main

characteristic features for each of the four chosen responsive table solution.

• Squish

– Squish makes the content very clear and easy to read.

– Squish makes it easier for beginners to understand the data at once.

– Squish makes the data cluttered and difficult to read when there are too many

columns.

– Try to avoid more than 7 columns. Too much data makes the table difficult

to read.

• Collapse by rows

– Collapse by rows is appealing and is fast to read.

– Collapse by rows is good when to read a specific data.

– Collapse by rows is not good for comparison and can not handle too much

data.

– Collapse by rows is cluttered when there are too many options.

– Don’t use too many columns nor rows.

• Scroll

– Scroll is good when one column is compared at a time.

– Scroll is pleasant to use on a mobile device.

– Scroll makes it difficult to remember all data when there are too many columns

35

36 Implementation and Solution

to scroll between.

• Click

– Click is good when comparing smaller amounts of data.

– Click makes it difficult to remember all data when there are too many columns

to click between.

5.2 The Visualization WizardThe main purpose of the Visualization Wizard is to help designers and developers with

which responsive table solution to implement on a website. A web system has been built

based on data from both the research and theory as well as from the user test. The

web system makes the user answer 8 questions about the intended table which generate

a suggested solution that matches the requirements of the table. The generated result

includes some recommendations and information about the given responsive table solu-

tion, but it also provides code to copy paste. The user can add their own table content

as input and then get a ready-to-use table with the suggested solution and the associated

source code.

The questions and answers used in the Wizard are based on observations and data from

the user test in chapter 4. They are supposed to cover different areas and types of content

in order for the system to generate a suitable result with a tabular solution. Table 5.1

provides the questions used for the quiz and the different answers associated with each

question. Apart from the four answers presented, there is one extra option for each

question with the value ”I don’t know/other”. Since it’s consistent throughout the quiz,

it’s not in table 5.1.

5.2. The Visualization Wizard 37

Table 5.1: Questions and answers used for identifying table solution.

ID Question Answer 1 Answer 2 Answer 3 Answer 4

Q1 Which category

best suits your

data?

Product

offering

Product

comparison

Sports Stock mar-

ket/statistics

Q2 How many

columns does

the intended

table have?

2-4 5-7 8-10 More than 10

Q3 How many

columns Must

be presented

in the mobile

solution?

2-4 5-7 8-10 More than 10

Q4 How many

rows does the

intended table

have?

2-4 5-7 8-10 More than 10

Q5 What type of

content will the

table mainly

contain?

Mostly text Mostly digits Mostly sym-

bols

A mixture of

two or more

options.

Q6 What type of

user does the

content of the

table mainly

target?

Beginners Persons with

arbitrary

knowledge of

the subject

Persons with

very good

knowledge of

the subject

Everyone

Q7 How much com-

parison will the

user most likely

do with the con-

tent?

Very much.

The purpose

of the table

is to compare

the content

Some com-

parison

Almost no

comparison

No compari-

son

Q8 If the user is

to compare

the contents

of the table:

how should

the content be

compared?

All or most

of the con-

tent should

be compared

at the same

time

The content

of several

columns

should be

compared si-

multaneously

The contents

of one col-

umn should

be compared

at a time

The contents

of a column

should be

compared at

a time


5.2.1 Design

The website has a simple design where the focus is the quiz and the suggested solutions.

The following images display the overall idea of how the web page is constructed. The

text is in Swedish since the company responsible for this thesis is mostly developing for

Swedish clients.

Figure 5.1: The start page of the Visualizing Wizard.


The question pages each contain one question and five options, where one option is ”I

don’t know/other”. Figure 5.2 displays how a question is presented with its answers.

Figure 5.2: One of the question pages with its answers.

When all eight questions are answered a result is generated with a recommended re-

sponsive table solution. The page includes information about the approach, some pros

and cons and also some valuable pointers on what to consider when implementing the

solution. It’s also possible for the user to enter data and get a produced table with the

suggested table solution with the associated code available for copy-paste.


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

It’s also possible to view the four different table solutions without taking the quiz. Those

pages look similar to the result pages, without the option to generate a customized table

directly in the browser.

Figure 5.4: A page with a responsive table solution.


5.2.2 System components

The components used for the implementation are all within the web system. It consists

of three main elements; the backend server, the web server and the application. Both the

frontend and the backend server are written in Golang and they communicate with each

other via different ports. The backend contains the quiz logic and receives the answers

from the frontend which it uses to generate a result. The backend sends back the result

to the frontend which displays it in the application for the user to see. A simple overview

of the system components in the web system is shown below in figure 5.5, figure 5.6 is

a bit more describing by displaying where the rule-based system fits in and figure 5.7

presents the different languages included.

Figure 5.5: System components of the Visualizing Wizard.

Figure 5.6: A more describing image of the system components including the rule-based system

in the Visualization Wizard.


Figure 5.7: A more describing image of the system components including programming lan-

guages in the Visualizing Wizard.

5.3 System architectureA more thorough review of the web system provides an understanding of how the system

works and is implemented. The main focus lies on the quiz part with the decision

algorithm that generates a result based on the answers provided by the user, but it also

has a small side track where the table solutions can be viewed without taking the test.

This section presents different diagrams of the system architecture to give a clearer view

of how the system is built. The first image, figure 5.8 shows the system architecture and

figure 5.9 is an activity diagram of the Visualizing Wizard, which gives a representation

and an overview of the work-flow during the use of the system.

5.3. System architecture 43

Figure 5.8: The system architecture.

Figure 5.9: Activity diagram of the Visualizing Wizard.

Another diagram associated with the system architecture is the state diagram in figure

5.10. It provides a more complete image of the different phases during the system’s

process with some of the important milestones or breakpoints of the system. One of the

important parts is when all the questions are answered and the answers are about to

be evaluated in the backend. A XMLHttpRequest (xhr) is created in order to set up a


connection to the backend server and send the answers via a HTTP POST request.

Figure 5.10: State diagram of the Visualizing Wizard.

A more detailed aspect of the system architecture is to view the different source code files

and see how they are linked. It can be difficult to get a full overview of all the functions

and variables in a large web system, but a downscaled attempt of class diagrams can

be seen in figure 5.11 and figure 5.12. The first image presents the files used for the

quiz part while the second shows the files used for the quiz-less solutions . The reason

they are separated in two different figures is because not everything could fit in the same

image. They still lack some detailed functions, variables and styles used in the web

system, however, these are all from plug-ins included from other open source projects.

The plug-ins and the table implementation are described in section 5.5. The methods

5.3. System architecture 45

in the backend and the frontend server aren’t printed in the diagrams either since it’s

mostly handlers to keep the application running.

Figure 5.11: Class diagram of the Visualizing Wizard quiz.


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

5.4. The rule-based system 47

5.4 The rule-based systemAs described in section 3.4, a rule-based system needs an appropriate number of rules

to the scope of the problem. The answers from table 5.1 have been mapped with differ-

ent paths to each responsive table solution to form these rules. Depending on what the

answers are, the result will differ and provide a specific approach. The mappings don’t

consider the ”I don’t know/other”-answer but focuses on the important aspects of each

table solution. Since squish is the most versatile approach according to the research in

section 3.2.1 and the user test in chapter 4, it will also act as a default solution when the

answers lead to an indecisive result.

The mappings outlines the rules and goals for the system and it implies that the sys-

tem uses backward chaining since the model looks for rules to help decide which table

solution to recommend. It reasons from the solutions back to the facts (answers) and

therefore focuses on the search, which can be compared to a depth-first search. Prolog is

a ruled-based system where the set of rules is defined and then pattern matched against

the answers. Prolog is also the language used to implement the rule based system in this

project.

The following figures display the mappings and are the set of rules in the Prolog decision/rule-

based model that will be further described in section 5.6.5. Each path in the mappings

indicates a IF path THEN statement. The mappings are based on the statical analysis,

the user tests and some of the best practices described in related work in chapter 2.


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


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


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


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


5.5 TablesAs mentioned in previous sections, there are some open source code used to implement

the different table solutions. Instead of reinventing the wheel and building solutions

that already exist from scratch, I decided to include these approaches in this project.

A more comprehensive description of the characteristics of the different table solutions

and more about how they were implemented is described in the next coming subsections

(5.5.1-4).

5.5.1 Squish

A software engineer named Gary Hepting (Github user: ghepting) has developed an open

source jQuery plug-in to make tabular data responsive.[16] His solution is a squish ap-

proach which reduces or increases the size of text and the cells in order to fit the size of

the browser. The plug-in can be downloaded from Github and then added to the web

project by including the relevant files in the HTML code. There are different files in the

plug-in but the one used in this web project is called jquery-responsiveTables.js in the

plug-in Github repository and is renamed to squish.js for this project to keep a better

track of the different plug-ins.

The initialization of the plug-in can be found in the Github repository and is defined as

the following:

<s c r i p t type=”text / j a v a s c r i p t”>

$ ( document ) . ready ( func t i on ( ) {$ ( ’ t ab l e . r e spons ive ’ ) . r e spons iveTab l e s ( ) ;

} ) ;

</s c r i p t >

After initializing the jquery-responsive-tables plug-in it’s time to implement a squish ta-

ble. A table is defined by using the HTML code below.

<t ab l e c l a s s=”r e spons i v e ” data−compress ion=”6” data−min=”8”

data−max=”16” ce l l padd ing =”.1em” c e l l s p a c i n g =”.2em”>

<tr>

<th> Heading 1 </th>



</tr>

<tr>

<td> Row 1 , Col 1 </td>


5.5. Tables 53


</tr>

<tr>




</tr>

</table>

The important part is the first row which is the markup of the table and handles the

configuration by setting different data attributes. It is that markup that sets how large or

how small the text and cells should be in the browser to match the size of the screen.

5.5.2 Collapse by rows

To implement a collapse by rows I found a responsive table method using display:block

and data attributes on CodePen, made by a web developer named Geoff Yuen.[17] It

doesn’t require JavaScript but is fully functional by using only HTML and CSS. The

styling in the CSS file defines how the table should look like when it’s presented on a

large screen (min-width: 680px) and when it’s presented on a smaller screen. When

displayed on a small screen, the table uses the collapse by rows approach.

By using display: block; on the table data and the CSS code below to define the

appearance of the tabular data on smaller screens, such as on mobile devices, it will

specify the collapse by rows approach.

. rwd−t ab l e th {d i sp l ay : none ;

}. rwd−t ab l e td {

d i sp l ay : b lock ;

}. rwd−t ab l e td : b e f o r e {

content : a t t r ( data−th ) ” : ” ;

font−weight : bold ;

width : 9em;

d i sp l ay : i n l i n e−block ;

}

Apart from the CSS styling, the table has to be implemented with data attributes in the

HTML document. This is done by specifying each header and then clarify which header

each table data (row) belongs to. An example is the following HTML code:


<t ab l e c l a s s=”rwd−t ab l e”>

<tr>

<th>Heading 1</th>

<th>Heading 2</th>

<th>Heading 3</th>

</tr>

<tr>

<td data−th=”Heading 1”>Row 1 , Col 1</td>



</tr>

<tr>




</tr>

</table>

5.5.3 Click

Filament Group is a design and frontend development studio, which has produced a

group of open source plug-ins. Their solutions for responsive tables, Tablesaw, can be

downloaded from Github.[18] The plug-in includes a variety of approaches, but the one

used for this project is called the swipe mode and that requires three separated files from

the Tablesaw repository. The CSS file, tablesaw.css, includes styling of the table and

the toggle-button used to change between columns while the two javascript/jquery files

include functions to handle the functionality of the swipe mode. When the relevant files

of the plug-in are included in the web project, it can be used for a table with a click

approach.

There are a few key elements that should be included in order to implement a click so-

lution. The first one is the declaration of the table that specifies that the table should

have the tablesaw class, and more specifically, the tablesaw-swipe class mode. Also that

it should include the minimap attribute which is the small dots that appears next to the

toggle buttons and shows which columns are currently being displayed.

<t ab l e c l a s s=”tablesaw tablesaw−swipe ” data−tablesaw−mode=”swipe ”

data−tablesaw−minimap>

The second important element is how the headings are included. The headings differ in

which attributes they use, since the first column should always be visible, the second

should be visible in the beginning and the rest of the columns should be hidden until

5.5. Tables 55

they are toggled. All columns except for the first changes attributes as they are toggled

by the click buttons since it also changes which columns are shown and which are hidden.

<thead>

<th c l a s s=” t i t l e tablesaw−swipe−c e l l p e r s i s t ” scope=”c o l ”

data−tablesaw−p r i o r i t y =” p e r s i s t ”>

<th scope=”c o l ” c l a s s>Heading 2</th>

<th scope=”c o l ” c l a s s=” tablesaw−swipe−c e l l h i d d e n”>

Heading 3</th>

<th scope=”c o l ” c l a s s=” tablesaw−swipe−c e l l h i d d e n”>

Heading 4</th>

<\thead>

The body of the table also has different attributes depending on which column each data

content is in. It does look similar as the headings, but with some changes on the first

data content.

<tbody>

<tr>

<td c l a s s=” t i t l e tablesaw−swipe−c e l l p e r s i s t ”>

Row 1 , Col 1</td>

<td c l a s s>Row 1 , Col 2</td>

<td scope=”c o l ” c l a s s=” tablesaw−swipe−c e l l h i d d e n”>

Row 1 , Col 3</td>

<td scope=”c o l ” c l a s s=” tablesaw−swipe−c e l l h i d d e n”>

Row 1 , Col 4</td>

</tr>

<\tbody>

5.5.4 Scroll

There are a lot of different approaches for a scroll solution. One of the simplest im-

plementations is to add overflow:hidden; in the CSS styling of the table. However,

majority of the scroll tables found during the research for this project did have a frozen

first column and therefore, the implementation for this web system also has a frozen first

column. A web developer named Paul O’Brien implemented a scroll approach with a

frozen first column on CodePen.[19] It includes a jQuery which clones the table and puts

the clone on top of the original table with an absolute positioning. The first column of

the clone is visible while the others are hidden at the same time as the original table has

scrollable columns. This creates an illusion that the first column is fixed while there are

actually two on top of each other. The jQuery looks like the following:


jQuery ( document ) . ready ( func t i on ( ) {jQuery ( ” . main−t ab l e ” ) . c l one ( t rue ) . appendTo( ’# table−s c r o l l ’ )

. addClass ( ’ c lone ’ ) ;

} ) ;

It appends a clone class on the main table which is defined in the CSS file and make the

cloned table worked as described above. A table with this scroll approach is implemented

by placing the original table in a div that allows scrolling while the clone is placed in a div

that doesn’t scroll. A setup of the scroll-table in the HTML document is presented below.

<div id=”table−s c r o l l ” c l a s s=”table−s c r o l l ”>

<div c l a s s=”table−wrap”>

<t ab l e c l a s s=”main−t ab l e”>

<thead>

<tr>

<th c l a s s=”f ixed−s i d e ” scope=”c o l”>Heading 1</th>

<th scope=”c o l”>Heading 2</th>

<th scope=”c o l”>Heading 3</th>

</tr>

</thead>

<tbody>

<tr>

<td c l a s s=”f ixed−s i d e ” >Row 1 , Col 1</td>

<td>Row 1 , Col 2</td>

<td>Row 1 , Col 3</td>

</tr>

</tbody>

</table>

</div>

</div>

5.6 FrameworksThis section describes and motivates the choices of frameworks used for the Visualization

Wizard. It also explains more how and where each framework has been used.

5.6.1 HTML

HTML is an inevitable technology to use when defining the structure of a web page. It’s

the foundation of this entire project and is the language used to specify the web content

5.6. Frameworks 57

and therefore also the tables. All the responsive table solutions have their markup in

HTML and by connecting (including) other files, such as CSS, Javascript etc., the table

can perform and appear as wanted.

5.6.2 CSS and Bootstrap

The styling of the website, but more importantly, the styling of the tables is done with

CSS and Bootstrap [20]. Bootstrap is easy to get started with and it’s used for the overall

structuring and placing of the content and also the setup of the navigation bar. CSS is

used to style the rest, such as table appearance, text, colors, margins and so on.

5.6.3 JavaScript

The behavior of the web page is programmed in JavaScript and it was chosen based on

that it’s very well documented and easy to learn [21]. For this project, JavaScript is

partly used to add interactivity on the website; to handle what happens when a button

is clicked and to add extra content on the page, but it’s also used to communicate with

the backend server. By creating a XMLHttpRequest and opening a POST connection

it’s possible to send a JSON object to the backend server and get the result back.

5.6.4 Golang

Go, or Golang, is an open source programming language created by Google [22]. It’s

chosen because it’s efficient and good to use for network communication. For this project

it’s used for the backend and the frontend server. The website is currently basic with a

focus on the quiz, but it’s relatively easy to implement new functionality and to integrate

a database to make the web system more dynamic.

The frontend is used to load the content of each page dynamically. Each page is a HTML

template that is loaded by Go, instead of a HTML document that is usually used. This

generates HTML output that is safe against code injections, which is desirable from a

security perspective [23]. The backend on the other hand is responsible for the logic of

the website, and usually also the part that adds or alter content in a database. It works

as the rest API and handles GET and POST requests and returns the requested data

to the frontend. However, for this project the backend mainly works as the quiz logic

handler that receives the answers from the quiz in the application and then generates a

result using Prolog rules described in the next subsection. The result is then sent back

to the web client as a JSON object.


5.6.5 Prolog

Prolog is a declarative programming language that is implemented using logical facts

instead of instructions [24]. It is also a language that is associated with AI due to its

pattern matching, automatic backtracking and tree-based data structuring mechanisms

that makes Prolog a flexible framework to work within AI [25]. It’s a rule-based frame-

work that in a way reminds of Drools, only more downscaled. Prolog is chosen for this

reason, to be used to handle the quiz logic in the Visualization Wizard. Since the map-

pings of the answers that leads to a specific solution in figure 5.13-5.16 technically are

the rules it became a clear choice to use a programming language where rules are set up

to generate a result. Drools would have been an alternative if the web system would’ve

been a bit more comprehensive, but for this extent Prolog is both easier to integrate with

Go and also easier to set up the rules with.

To integrate Prolog with the backend built in Golang I used an open source Prolog in-

terpreter in Go named Golog [26]. The logic was created in Prolog and then solved by a

Golog machine. An example of one rule that were set up based on the mappings is the

following:

getResultFromQuiz ( , , X, , , , Y, Z , squ i sh ):−(

X == ans1

;

X == ans2

) ,

Y \== ans4 ,

Z \== ans4

.

Golog takes the answers as input and pattern matches the different rules in order to

decide which result it’s equivalent to. It finds all the possible solutions in an efficient

way and is therefore a good approach for this project.

5.7. API 59

5.7 APIThere is only one API call for the Visualization Wizard and it handles a POST request

that also returns a result.

Table 5.2: REST API for generating a result.

Title Quiz Handler

Description Handles the answers and sends back a generated result.

URL /quizResult

Method POST

URL Params

Data Params {Q1 : [string]

Q2 : [string]

Q3 : [string]

Q4 : [string]

Q5 : [string]

Q6 : [string]

Q7 : [string]

Q8 : [string]

}Success Response Code: 200

Example Content:

{Result :

[

"squish"

]

}Error Response Code: 400

Content: { error : "bad input" }

CHAPTER 6Evaluation

Evaluation is an important part when developing a web system. How can we make sure

everything works as expected? For this particular system the main focus is the quiz and

which result it generates. One of the problems in 1.3 was to define which table solutions

are appropriate for different types of data and this will remain a dilemma since it depends

on various factors that can be difficult to specify. However, this thesis is a big step on

the way for some of the data categories. The research about finding the most common

solutions used today combined with the user test result provides a validation itself since

it gave valuable answers about which table solution is more appropriate than others when

it comes to certain data.

Based on the research and the user tests it can be established that for instance:

• Collapse by rows is not good for comparison tables and should be used for a small

amount of data.

• Squish is overall good for all types of data, as long as the number of columns exceeds

around 7.

• Click and scroll are similar but scroll isn’t preferable for product comparison. They

are however both good when no comparison or comparison of one column at a time

should be made.

The second main problem for this thesis was to find a way to use the information about

which solution is appropriate to use in what situation to help web developers and de-

signers in their process. A tool called Visualization Wizard has been developed in order

to meet this problem. It’s more a proof-of-concept, although it represents the thoughts

and feedback from the user tests as well as the important input from the research. The

following subsection describes the approach to evaluate the result from the Visualization

Wizard.

61

62 Evaluation

6.1 Black box testing/evaluationTo evaluate the web system, or more specifically, the quiz to make sure it works as ex-

pected a variant of black box test/evaluation was performed. The test scenario tables

implemented during chapter 4 combined with the test result in table 4.1 were used to

validate the quiz output. By letting the focus group used for the user tests answering the

questions from the Visualization Wizard according to the test scenario table content it

was possible to confirm the generated result with the winning approach for that specific

data.

In order to be able to answer the questions about the different tables and its content the

8 people in the focus group had to familiarize themselves a bit more about the actual

data. Each test person had to perform the quiz using the same data used for the user

tests to answer the questions about the tables. By using the focus group the evaluation

becomes more diverse and the system is examined from different perspectives. Table

6.1 displays the outcome of the evaluation where the answers are shortened into a two

letter representation. Squish is Sq, click is Cl, scroll is Sc and collapse by rows is CR.

The winning approach is the table solution with the lowest (winning) score from the user

testings in table 4.1.

6.1. Black box testing/evaluation 63

Table 6.1: Evaluation result.

Input data Winning

approach

U1 U2 U3 U4 U5 U6 U7 U8

Scenario 1 (Product offer-

ing, 3 columns)

Collapse

by rows

CR CR Sq CR CR Sq CR CR

Scenario 2 (Product com-

parison, 7 columns)

Squish Sq Sq Sq Sq Sq Sq Sq Sq

Scenario 3 (Stock market,

5 columns)



columns)

Scroll Sc Cl Sc Sc Cl Sc Sc Sc


ing, 5 columns)



10 columns)

Click Cl Sc Sc Cl Cl Sc Cl Cl


ing, 7 columns)

Scroll Cl Sc Sc Sc Sc Cl Sc Sc

Scenario 8 (Product com-

parison, 5 columns)

Squish Sq Sq Sq Sq Sq Sq Cl Sq


columns)

Squish Cl Sq Sq Sq Sc Sq Sq Sq


7 columns)

Squish Sq Sq Cl Sq Sq Sq Sq Sq

The evaluation for each scenario is also presented by using an accuracy percentage which

is calculated by taking the number of correct answers compared to the winning approach,

divided by the total number of user evaluations. The accuracy percentage for scenario 1

is therefore 6 correct answers divided by the total of 8 user evaluations. The result from

this calculation is displayed in table 6.2.

64 Evaluation

Table 6.2: Accuracy of the evaluation result in percentage.

Scenario Winning ap-

proach

Accuracy in

percentage

Scenario 1 (Product offering, 3 columns) Collapse by rows 75 %

Scenario 2 (Product comparison, 7 columns) Squish 100 %

Scenario 3 (Stock market, 5 columns) Squish 100 %

Scenario 4 (Sports, 10 columns) Scroll 75 %

Scenario 5 (Product offering, 5 columns) Squish 100 %

Scenario 6 (Stock market, 10 columns) Click 62.5 %

Scenario 7 (Product offering, 7 columns) Scroll 75 %

Scenario 8 (Product comparison, 5 columns) Squish 87.5 %

Scenario 9 (Sports, 5 columns) Squish 75 %

Scenario 10 (Stock market, 7 columns) Squish 87.5 %

The evaluation result is pretty straight forward. Most of the validations correspond to

the winning approach from the user test result in table 4.1 which implies that the quiz

could be accurate. There are 3 cases where the accuracy is 100%, 2 cases where result

differs with one ”wrong” answer compared to the winning approaches and 4 cases where

the evaluation results has two divergent answers. Scenario 6 had the lowest evaluation

result with three out of eight deviant outcomes, but the ”incorrect” answers are scroll

instead of click. Click and scroll are very similar solutions and even though it’s not the

correct answer according to the winning approach from the user test, I still think it’s an

arbitrary result.

The answers depend on how the quiz taker interprets the table content and how she or

he expects the table to be read. And that might not always be the full truth, since there

can be different aspects of the data that are not fully thought about. It’s therefore a

good idea to get familiarized with the data content and have a clear idea of how the

table should be perceived before taking the quiz. The evaluation is compared with the

winning approaches from the user tests, but that doesn’t mean the user test result reflects

the truth. It’s one part of the truth and it’s highly relevant to this project perspective.

However, the smallest change of data or content can alter the perception and therefore

the evaluation result as well as the user test results.

Overall, the validation turned out to have a good outcome when measured against the

results from the user test.

CHAPTER 7Discussion

The problem definition in section 1.3 was about finding which table solutions are appro-

priate for different types of data and to investigate a way of using this information to

help web developers and designers with deciding which approach to use. This chapter

discusses how these problems were solved and what I could’ve done differently. It’s also

about the problems I’ve encountered and potential alternative solutions. The following

subsections goes through each step of the process and discusses these aspects.

7.1 Finding appropriate table solutions for specific typesof data

To map which types of responsive table solutions were more suitable for a specific type

of data the following steps were taken:

1. Investigating 100 different websites and documenting one of its tables about the

table’s content, number of columns and its responsive approach.

2. Statistically analyzing the 100 tables to see which table solution is more common

in what scenario.

3. Weeding out types of solutions and data categories from the statistic analysis in

order to have a more narrow selection to continue the work with.

4. Planning and setting up tables used for user tests with different scenarios based on

the statistic analysis.

5. Performing the user tests on a total of 8 people.

6. Putting together the findings from the statistic analysis with the results and opin-

ions from the user tests to map different responsive table solutions with different

types of data.

I chose to continue the work using 4 different table approaches and 4 different data

categories with 4 ranges of amount of columns. This is because there were 4 main

table solutions and table categories that was found during the statistic analysis, and also

65

66 Discussion

because it seemed like a reasonable scope for this project. However, if I would’ve chosen

more types of table categories or more responsive table solutions the final result would

probably have differed. Maybe it would’ve provided a more precise mapping, or maybe

it would’ve confused everything.

7.1.1 Appropriate table solutions

The responsive table solutions I chose to continue the work with are similar to the best

practices and recommendations found in related work. The other approaches found are

either a combination of two or more solutions or no approach at all. If I would’ve chosen

more or different approaches for the further investigation, I think it would’ve created

more confusion than clarification in the end since many of the solutions are very similar.

If the user tests included more than four different tables for each scenario where some of

them are very alike, the users would have to endeavor to distinguish the small differences

instead of focusing on the overall differences between the approaches. Therefore, four

distinct table solutions seemed appropriate to use during this project.

7.1.2 Specific types of data

The categorization of each table during the investigation was made based on my own

observations. If other people would’ve categorized the same data it’s possible it would’ve

been other categories. Also, I tried to keep the variety of the categories general and

down to a minimum amount in order to make it easier to map the data with different

solutions further on. This however could have been done differently and would probably

give a another outcome. I could’ve used other general categories that would place some

tables in other groupings than now and that would give a new statistic result. After

going through 100 tables the perception changes over time and this can imply that the

determination of category varies depending on if it’s the categorization of table 1 or of

table 100. To limit this risk I went through the tables a couple of times to make sure I

chose a relevant category.

Therefore, I am satisfied with the categorization made during the investigation and I

think it gives a reasonable image of the data distribution. The types of data I chose

to continue the work with are based on the dominating categories after compiling and

analyzing all data. Afterwards I think it might have been more interesting to use product

information instead of sports since I believe it’s a more general category and maybe more

appealing to know how to display on a mobile device. However, sports is a good category

to use and instead of switching sports with product information I could’ve just added

more types of data for this project in order to get a wider spectrum. But that would also

require more time which was limited in this project.

7.1. Finding appropriate table solutions for specific types of data 67

7.1.3 The user test structure

To set up and plan a user test with the aim to get valuable information out of it was a bit

difficult. I had to decide what exactly I wanted to achieve by performing the user test,

and that was the easy part. I wanted to know which table solution the user preferred in

different scenarios with a specific type of data. But what type of scenarios is appropriate

to use and how could this be measured? I decided to base each scenario on real life cases

with data from real websites in order to give the test a more realistic approach and I used

data from websites found during the statistic analysis with the different table categories.

I implemented the 4 chosen table solutions for each of the 4 categories with 4 variations

of amount of columns and added different data for each scenario. For instance; product

offerings, 7 columns were about telephone subscriptions and had the same data in all 4

table approaches. I wanted to make sure the scenarios were relevant for the table purpose

as well as vary the types of data content for each scenario. Some people find it easier to

understand a certain type of data and by varying the content I could increase the chance

of the test person understanding and feeling calm while performing the test.

Since the goal with the test was to find out which table solution the test person preferred

I decided that a simple grading system would suffice. The user had to rate all table

solutions after each scenario accordingly and when all users had performed the user test

a final score would be calculated. The result would show which table solution the users

preferred in each scenario. Apart from the ratings, the user also gave valuable comments

which also were used when mapping specific features with table solutions.

The structure of the user test could have been different, but after consulting with a few

experts in UX and user tests we came to the conclusion that this approach would be

suitable for this type of problem. The user test was performed on a laptop in a browser

with the size of a mobile device and this is because it made it easier to record what was

happening and what the user said. It can be argued that not testing on a mobile phone

affected the experience since this project is about presenting tabular data on mobile

devices. Although that is true, the user tests did not aim to investigate the functionality

of the table solution as much as the overall approach. Therefore I made the decision that

the difference would be negligible, but it would however be interesting to see if the result

would differ if the user tests were performed on a mobile device instead.

7.1.4 Mapping table solutions with specific types of data

To finally answer the question of which type of data is more appropriate to present us-

ing which responsive tabular solution I had to combine the findings from the statistic

analysis with the result and opinions from the user tests, but also with some of the best

practices found in related work. This was one of the most difficult steps of the project. I

tried to form questions and answers based on comments, statistics and best practices and

68 Discussion

then backtrack each table solution with its characteristics to see which goes where. After

altering the mappings a couple of times I was finally satisfied, but this can be updated

and changed more times to become perfect.

Even though I have considered best practices, this can use more evaluation and tests in

order to cover more recommendations. More questions and answers can be added about

the actual content of the data, how much text it’s supposed to have and more about the

structure of the table. This can require more people’s point of views from different fields

to cover a wider scope and reduce the risk of missing important features.

7.2 Implementing the Visualization Wizard

The implementation of the final solution was pretty straightforward after all collecting

all the information during the research. I decided to build a basic web system that could

easily be upscaled if necessary. The web system includes both backend and frontend

server which might not be crucial for this project to work, but the intention is that it can

be further developed and perhaps integrated with something bigger. However, it’s good

to keep the logic separated from the graphical interface and that is the main reason for

the placing of the decision making in the backend server.

The decision to build the servers in Go is because I have worked with it a long time

ago and felt like I wanted to refresh my memory and also because it’s a nice language

to use for the API. There weren’t many requirements for the web system to work in a

certain way which meant it didn’t matter which languages I used to build the website.

The important part was to integrate some kind of decision making system.

7.2.1 The decision making

When researching about different approaches for a system to make decisions I found

some that were more interesting than others. I wanted to use a rule based system since

the mappings of the table solutions were based on rules. At first, Drools seemed like a

reasonable option since it was already a functioning system ready to be integrated, but it

turned out it was more suitable for larger business systems. The system I built is small

and Drools would require much more effort and data in order to work properly.

When reading up on Drools I found references to Prolog that stated the similarity be-

tween the rule based frameworks. Since I’ve worked with Prolog before it seemed like

a good option for this project. The problem was how to integrate Prolog with Golang

but after finding a basic plug-in for this I made it work. However, if I had more time

I would probably find a better way of merging both of the languages and implement a

better looking solution.

7.2. Implementing the Visualization Wizard 69

Prolog is a good approach for a rule based system because it’s efficient with its pattern

matching and it allows the developer to set rules without having to think of the logic. It

provides all possible outcomes by matching the input with the rules which is beneficial

in this project. Fuzzy logic can be a good approach, but I think that this problem is

a bit too complex to integrate it accordingly. I tried to set up a foundation of fuzzy

logic for this project, but the result wasn’t as hoped and I decided to focus on Prolog

instead.

7.2.2 Technical problems

During the implementation of the Visualization Wizard there were some difficulties

throughout the process. One dilemma I had was how to handle rule interferences when

more than one rule applies to the different facts. What should my conflict resolution

strategy be? I first thought that I could return all applicable results and present more

than one recommendation on the website. Since there are only four different solutions it

would perhaps be confusing if two or more recommendations were returned as a result.

Instead, I decided that the user would only get one table solution recommendation. The

approach now is that Prolog returns the first applicable result in the order they are set.

Another, perhaps better way of prioritizing the results is to add weights on each rule to

make sure the most suitable table solution is returned first. This would also require a

study of which order each table approach should have in the event of a conflict.

The implementation of the different table solutions was also a bit tricky at first since some

of the plug-ins lacked a clear documentation. I believe that the most difficult approach

to implement was scroll with a frozen first column. It took a while for me to grasp how

to keep the first column still while the others are scrollable. It was also sometimes a bit

frustrating to get the layout in the way I wanted it, but since the website design wasn’t

prioritized it was okay to keep some buttons imperfectly aligned for instance.

7.2.3 Security

This web system does not have any sensitive data sent back and forth, and security is

therefore not something that has been taken into consideration during the development

process. However, by using Golang templates it keeps the system safe from code injections

since it generating HTML output. There is no check on what data is sent to the API, but

the input data doesn’t alter or affect anything in the backend. The input data is used to

generate a result by pattern matching the input with the rules and if no rules apply the

returned result is ’uncertain’. If the system would integrate a database or similar then

it would be crucial to verify that the input matches the expected data.

70 Discussion

7.3 Evaluating the evaluationThe system was evaluated by comparing the Visualization Wizard quiz results with the

results from the user test, to see if both results matched. This was done by having the

focus group used during the user tests, answering the quiz questions for each user test

scenario. By using the focus group I got a wide scope and a decent perspective of how

the quiz actually works.

The result of the evaluation was corresponding to the winning approaches in the user

test. The evaluation could’ve been done in a different way to test more scenarios and

involve more people to test the system. However, an evaluation needs something to

evaluate against, something that confirms that the system works as expected and the

only values or similar available for this project was the user test results. I am satisfied

with the evaluation, especially its outcome, but it would’ve been interesting to involve

more people with different experiences of the implementation process. If this project is

going to be further developed it needs to be confirmed and evaluated from all steps of

the process of developing a web system including a responsive table solution.

CHAPTER 8Conclusions and future work

This thesis has resulted in a tool that allows the user to answer questions about her or his

intended table and then get a recommendation generated of which responsive table solu-

tion is appropriate to use in that situation on a mobile device. I have also concluded that

certain responsive table solutions are more suitable for specific types of data. The ini-

tial requirements for this project has been met and the result is the Visualization Wizard.

It is a starting point and something to use in order to expand and develop a full solution.

Some of the existing features can be improved as well as integrating new aspects and

technologies to get a better and more dynamic web tool. As previously mentioned, more

evaluation and analysis is needed to make sure that each rule corresponds to the ap-

propriate table solution. That requires a better conflict resolution strategy that returns

the table solution with the highest priority instead of the first applicable. To upscale

the scope of this project, it might be a good idea to add more types of data and maybe

eventually include more responsive table solutions.

One interesting technology that can be implemented in order to improve the entire system

and experience is artificial intelligence. An AI system can learn and adapt the generated

result based on if the user is satisfied or not. It could also make connections between

different table solutions and answers from the quiz based on how the website is used and

what the user answers in the quiz. This would result in a more dynamic system and

improve the result generating markedly.

71

APPENDIX AWebsites used during research

Table A.1: All websites with tables found during research.

Website Category

website

Category

table

Number

of columns

laptop

Number

of columns

mobile

Solution

Affarsvarlden Financial Stock mar-

ket

14 14 Scroll

Aftonbladet Magazine Sports 11 9 Squish +

removing

Alla Bolag Authorities Statistics 4 2 Click

Allra Subscrip-

tions

Product

compari-

son

5 2 Squish

+ Col-

lapse,by

rows

Allsvenskan Sports Sports 10 10 Squish

Alpresor Travel

agent

Product

offering

7 7 Squish

Apollo Travel

agent

Product

offering

6 1 Collapse

by rows

Arbetsformedlin-

gen

Authorities Statistics 3 3 Squish

ATG Online

betting

Sports 4 3 Squish

Avanza Stock mar-

ket

Stock mar-

ket

6 6 Scroll

73

74 Appendix A

Table A.2: All websites with tables found during research cont.

Website Category

website

Category

table

Number

of columns

laptop

Number

of columns

mobile

Solution

Betsson Online

betting

Online

betting

13 3 Removing

Biljetternu Event Product

offering

4 1 Collapse

by rows

Bloomberg Financial Stock mar-

ket

8 3 Squish +

removing

Bonava Housing Product

offering

7 1 Collapse

by rows

Brollopstorget Buy & Sell Product

offering

5 2 Removing

BT Magazine Sports 3 3 Squish

Cdon Electronics Product

informa-

tion

2 2 Squish

Citybuss Pitea Travel Timetable 5 4 Squish +

removing

Corren Magazine Sports 7 7 No ap-

proach

Di Magazine Stock mar-

ket

10 10 Scroll

DIF fotboll Sports Sports 4 1 Collapse

by rows

Domino Datalab Subscrip-

tions

Product

compari-

son

4 4 Squish

Dustin Home Electronics Product

informa-

tion

2 2 Squish

Elgiganten Electronics Product

compari-

son

4 3 Squish

+ Col-

lapse,by

rows

F-Secure Subscrip-

tions

Product

compari-

son

5 4 Squish +

Collapse

by rows

75


Website Category

website

Category

table

Number

of columns

laptop

Number

of columns

mobile

Solution

Finansportalen Stock mar-

ket

Stock mar-

ket

9 4 Squish +

removing

Flygbra Travel Product

offering

4 1 Collapse

by rows

Fondkollen Stock mar-

ket

Stock mar-

ket

7 2 Click

Fondmarknaden Stock mar-

ket

Stock mar-

ket

5 5 Squish

Forex Financial Product

offering

5 5 Squish

Fyndtorget Buy & Sell Product

offering

6 6 Squish

Golf.se Sports Sports 4 1 Collapse

by rows

Google cloud Subscrip-

tions

Product

compari-

son

3 3 Squish

GP Magazine Sports 8 7 Squish +

removing

Gymnasium.se Authorities Product

informa-

tion

3 3 Squish

Goteborgs uni-

versitet

School Product

offering

4 4 Scroll

Halebop Telephony Product

offering

6 6 Squish

Hammarby fot-

boll

Sports Sports 6 3 Squish +

removing

Handbollslands-

laget

Sports Statistics 4 1 Collapse

by rows

Handelsbanken Financial Product

compari-

son

4 3 Scroll

IBM Subscrip-

tions

Product

compari-

son

3 1 Collapse

by columns

76 Appendix A


Website Category

website

Category

table

Number

of columns

laptop

Number

of columns

mobile

Solution

Icabanken Financial Product

compari-

son

5 4 Squish

+ Col-

lapse,by

rows

IMDB Music/TV

/Movies

Leader

boards

3 1 Squish +

removing

Jamt-

land/Harjedalen

lanstrafik

Travel Timetable 6 6 Scroll

Jonkoping

lanstrafik

Travel Product

offering

7 2 Collapse

by rows

Kalmar

lanstrafik

Travel Product

offering

3 3 Squish

Kia Index Statistics Statistics 12 3 Click

Kiruna

lokaltrafik

Travel Product

offering

6 6 Squish

Komplett Electronics Product

informa-

tion

2 2 Squish

Kurser.se Event Product

informa-

tion

3 3 Squish

Livescore Sports Sports 5 4 Collapse

by rows

Lulea lanstrafik Travel Product

offering

6 6 Squish

Lulea tekniska

universitet

School Product

offering

5 2 Collapse

by rows

Lunds tekniska

hogskola

School Product

offering

12 12 Squish

McAfee Subscrip-

tions

Product

compari-

son

5 2 Click

Media Markt Electronics Product

informa-

tion

2 2 Squish

77


Website Category

website

Category

table

Number

of columns

laptop

Number

of columns

mobile

Solution

Migrationsverket Authorities Statistics 5 5 Scroll

Mobilabon-

nemang.se

Telephony Product

offering

8 1 Collapse

by rows

Morningstar Stock mar-

ket

Stock mar-

ket

8 8 No ap-

proach

Malardalens

lanstrafik

Travel Product

offering

4 4 Squish

NetOnNet Electronics Product

informa-

tion

2 2 Squish

Nettbuss Travel Product

offering

7 7 No ap-

proach

NHL Sports Sports 17 17 Scroll

Nordea Financial Product

compari-

son

3 2 Collapse

by rows

Nordnet Stock mar-

ket

Stock mar-

ket

11 11 Squish

Norwegian Travel Product

offering

6 2 Collapse

by rows

Odds365 Online

betting

Online

betting

5 4 Squish +

removing

Privata affarer Financial Stock mar-

ket

10 10 Scroll

Remember Financial Product

compari-

son

3 3 Squish

RidSport Sports Sports 6 6 Squish

Riksbanken Financial Product

informa-

tion

4 4 Squish

Rikshem Housing Product

offering

7 1 Collapse

by rows

SAS Travel Product

offering

13 13 Scroll

78 Appendix A


Website Category

website

Category

table

Number

of columns

laptop

Number

of columns

mobile

Solution

Showtic Event Product

offering

6 4 Squish +

removing

SJ Travel Timetable 5 4 Squish

SMHI Weather Weather 5 5 Squish

Sony Mobile Electronics Product

informa-

tion

3 1 Collapse

by rows

Statistiska cen-

tralbyran

Authorities Product

informa-

tion

5 5 Scroll

Sverige Topplis-

tan

Music/TV

/Movies

Leader

boards

6 6 Squish

SVT Music/TV

/Movies

Sports 11 11 Squish

Swedavia Travel Timetable 5 2 Collapse

by rows

Swedbank Financial Product

compari-

son

4 4 Squish

Ticket Travel

agent

Product

offering

5 3 Collapse

by rows

Ticketmaster Event Product

offering

4 2 Collapse

by rows

Tidningskungen Subscrip-

tions

Product

offering

5 1 Removing

TUI Travel

agent

Product

offering

6 1 Collapse

by rows

UL Travel Product

offering

3 3 Squish

Umea univer-

sitet

School Product

offering

2 2 Squish

Universitets- och

hogskoleradet

Authorities Statistics 7 7 Scroll

79


Website Category

website

Category

table

Number

of columns

laptop

Number

of columns

mobile

Solution

VA finans Financial Stock mar-

ket

9 9 Scroll

Vattenfall Subscrip-

tions

Product

compari-

son

3 3 Squish

Ving Travel

agent

Product

offering

6 1 Collapse

by rows

VK Magazine Sports 8 8 No ap-

proach

VLT Magazine Sports 9 8 Squish +

removing

Varmlandstrafik Travel Product

offering

6 6 Scroll

Vasttrafik Travel Timetable 10 10 Squish

Xtrafik Travel Product

offering

4 4 Squish

Yahoo finans Financial Stock mar-

ket

10 10 No ap-

proach

YR.no Weather Weather 5 5 Squish

Ostgotatrafiken Travel Product

offering

10 4 Click

APPENDIX BUser testing

B.1 Test scenarios

1. You are accompanied by your 19 year old brother into the town by bus. You are

going to travel 3 zones and your brother travels 4. You want to check out what the

trip costs for both of you separately. (Product offering, 3 columns).

2. You are going to buy a new tablet with a screen that should be at least 10” and that

is not too heavy. You want to compare different models. (Product comparison,

7 columns).

3. You are going to choose a fund with the lowest grade 4/5 stars and has a low cost.

You want to compare different funds. (Stock market, 5 columns).

4. You want to check out which team made the most goals and how many matches

the team AIK played. (Sports, 10 columns).

5. You want to go on a last minute trip somewhere from Stockholm around December.

You want to consider your options. (Product offering, 5 columns).

6. You want to know which share has grown and decreased the most in percentage

during the day and what the highest value of the Ericsson B share was during the

day. (Stock market, 10 columns).

7. 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.)

8. You are going to sign up for a dental insurance. You want to compare the different

types of insurances; protection, care and premium. (Product comparison, 5

columns).

9. You want to check out when Sevilla and Chester FC are playing their individual

match. (Sports, 5 columns).

10. You are going to choose a fund that has a top 10 ranking measured during both

3 and 5 years, and has an annual fee below 1.6%. You want to compare different

funds. (Stock market, 7 columns).

81

82 Appendix B

B.2 Test results

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

User Row collapse Squish Click Scroll

1 2 1 - -

2 1 2 - -

3 2 1 - -

4 1 2 - -

5 2 1 - -

6 1 2 - -

7 1 2 - -

8 1 2 - -

Total: 11 13 - -

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


1 4 2 1 3

2 2 1 4 3

3 1 4 2 3

4 2 1 4 3

5 4 2 1 3

6 3 1 4 2

7 4 2 1 3

8 4 1 2 3

Total: 24 14 19 23

B.2. Test results 83

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


1 2 1 3 4

2 3 2 4 1

3 2 1 3 4

4 2 1 4 3

5 3 2 4 1

6 2 1 4 3

7 4 1 2 3

8 4 1 2 3

Total: 22 10 26 22

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


1 4 3 1 2

2 4 2 3 1

3 3 4 2 1

4 4 3 2 1

5 3 4 2 1

6 3 4 2 1

7 4 1 3 2

8 3 4 2 1

Total: 28 25 17 10

84 Appendix B



1 4 3 1 2

2 1 2 4 3

3 1 2 4 3

4 3 1 2 4

5 4 1 3 2

6 2 1 4 3

7 2 1 3 4

8 3 2 1 4

Total: 20 13 22 25



1 3 4 1 2

2 3 4 2 1

3 4 3 1 2

4 4 3 2 1

5 4 2 1 3

6 3 4 2 1

7 4 2 1 3

8 4 3 1 2

Total: 29 25 11 15

B.2. Test results 85



1 4 3 2 1

2 2 4 3 1

3 1 4 3 2

4 4 3 2 1

5 4 2 1 3

6 2 1 4 3

7 2 1 4 3

8 3 4 1 2

Total: 22 22 20 16

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


1 4 1 2 3

2 4 1 2 3

3 4 1 3 2

4 2 1 3 4

5 4 1 2 3

6 4 1 2 3

7 4 1 2 3

8 2 1 3 4

Total: 28 8 19 25

86 Appendix B

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


1 2 1 3 4

2 1 2 4 3

3 2 1 4 3

4 1 2 3 4

5 2 1 4 3

6 4 1 3 2

7 4 1 2 3

8 1 2 4 3

Total: 17 11 27 25



1 4 1 3 2

2 4 1 2 3

3 1 2 4 3

4 2 1 4 3

5 4 1 3 2

6 3 4 2 1

7 4 2 1 3

8 4 1 2 3

Total: 26 13 21 20

B.3. Comments from user test 87

B.3 Comments from user test

User 1

• ”Collapse by rows is easy to read, but if I knew more about shares then scroll would

probably be good.” - Scenario 3 (Stock market, 5 columns)

• ”Click is good when there are fewer columns to keep track on, if there are too many

then it’s easy to forget the content.” - Scenario 5 (Product offering, 5 columns)

• ”If I already knew that I would want to buy shares from Ericsson then collapse by

rows would have been good, as long as I don’t want to compare it with other shares.”

- Scenario 6 (Stock market, 10 columns)

• ”Squish is nice when you want everything on the same screen, as long as the number

of columns doesn’t exceed 7.” - Scenario 10 (Stock market, 7 columns)

User 2

• ”Collapse by rows makes the reading go fast.” - Scenario 1 (Product offering, 3

columns)

• ”When you want to compare data you’d like everything gathered” - Scenario 2 (Prod-

uct comparison, 7 columns)

• ”Collapse by rows is clear when you want to read about a specific fund, but with

comparing you have to make a lot of scrolling up and down.” - Scenario 3 (Stock

market, 5 columns)

• ”It is difficult to remember what to look at when one column disappears during

click.” - Scenario 5 (Product offering, 5 columns)

User 3

• ”Squish is the easiest one since you get an overview straight away, but something

about the row collapse is appealing.” - Scenario 1 (Product offering, 3 columns)

• ”Collapse by rows isn’t good with comparisons” - Scenario 7 (Product offering, 7

columns)

• ”The squish table is too small and makes it difficult to read” - Scenario 10 (Stock

market, 7 columns)

User 4

• ”All of a sudden, the scroll is awesome.” - Scenario 4 (Sports, 10 columns)

• ”Squish is a bit overwhelming when there is too many decimals and numbers, but at

the same time it’s kind of easy to get all information at the same time, even though

it’s messy.” - Scenario 6 (Stock market, 10 columns)

• ”The table with collapse by rows is cluttered with too many cells.” - Scenario 7

(Product offering, 7 columns)

• ”It is nice with scroll on a phone screen.” - Scenario 7 (Product offering, 7 columns)

• ”Every time you’re not familiar with the content you feel like ’just give me every-

thing the squish does’.” - Scenario 8 (Product comparison, 5 columns)

User 5

• ”The collapse by rows is really good when I’m reading each row separately, but if I’m

88 Appendix B

comparing it gets harder to keep track of everything.” - Scenario 3 (Stock market,

5 columns)

• ”No, this is too much data for collapse by rows.” - Scenario 6 (Stock market, 10

columns)

• ”Squish gives a good overview.” - Scenario 10 (Stock market, 7 columns)

User 6

• ”Squish is more compact but I understand the row collapse faster.” - Scenario 1


• ”It depends on what you want to do. Comparing is better with scroll or click, but

collapse by rows is good if there is one specific share you want to check out.” -

Scenario 6 (Stock market, 10 columns)

• ”Collapse by rows is annoying since you have to scroll a lot up and down” - Scenario

10 (Stock market, 7 columns)

User 7

• ”When you have a lot of different options to choose from, squish makes it easier to

get an overview.” - Scenario 4 (Sports, 10 columns)

User 8

• ”If you have to zoom with squish to see clearer then you could just use the scroll

from the beginning.” - Scenario 4 (Sports, 10 columns)

• ”Collapse by row feels simple since all the information is right there.” - Scenario 5


• ”Squish makes is easy for comparison, easy to read, but the text is too small and

too much information displayed at the same time.” - Scenario 7 (Product offering,

7 columns)

APPENDIX CInstallation guide

A requirement to run The Visualization Wizard is to have Golang installed. Information

about how to get started with Go can be found on

https://golang.org/doc/install.

The setup for The Visualization Wizard are the following (in a terminal):

1. Download the project from

https://github.com/sophiacaspar/X7007E Visualizing-Wizard and open it it

a folder of your choice.

2. There are some plugins used for this project, these need to be added separately

in the GOPATH and can be done manually or automatic by using the following

commands.

(a) go get github.com/julienschmidt/httprouter

(b) go get github.com/rs/cors

(c) go get github.com/mndrix/golog

3. To build and run the web server, go into frontend -folder.

(a) Change variable ip in function startWebserver(input) in file

server frontend.go to your own IP address and port for the webserver or

use localhost.

(b) Run go build server frontend.go

(c) Run ./server frontend.go to start the webserver at your ip defined in a.

(d) It is also possible to skip step a-c and only run go run server frontend.go

since the webserver doesn’t require other files to run.

4. To build and run backend server, go into backend -folder.

(a) Change variable ip in function startBackend() in file server backend.go

to your own IP address or use localhost.

89

https://golang.org/doc/install

https://github.com/sophiacaspar/X7007E_Visualizing-Wizard

90

(b) Change variable ip in function getIP() in file getIP.js in frontend-folder

/frontend/static/js. NOTE: it is very important that both ip-variables

have the same ip-address.

(c) Run go build server backend.go

(d) Run ./server backend to start the backend at your ip defined in a.

(e) It is also possible to skip step a-c and only run go run server blackend.go

instead of building it first.

5. The Visualizing Wizard should now be up and running.

REFERENCES

[1] Moboom DevKit, “Responsive tables: Best practices and examples.”

http://trydevkit.com/blog-post/responsive-tables-best-practices-and

-examples/ee7961a6-a22e-610b-70d0-533c85cc59b6, 2014. [Online; accessed

19-January-2018].

[2] The Integrated Information Technology Services, “What are

some guidelines for table and listings for mobile apps?.”

https://itsupport.smu.edu.sg/hc/en-us/articles/203120704-What-are-some

-guidelines-for-table-and-listings-for-mobile-apps-, 2015. [Online; ac-

cessed 26-January-2018].

[3] Nielsen Norman Group, “Comparison tables for products, services, and features.”

https://www.nngroup.com/articles/comparison-tables/, 2017. [Online; ac-


[4] Nielsen Norman Group, “Mobile tables: Comparisons and other data tables.”

https://www.nngroup.com/articles/mobile-tables/, 2017. [Online; accessed

26-January-2018].

[5] M. Nazir and I. Iqbal and H. Shakir and A. Raza and H. Rasheed,

“Future of mobile human computer interaction research - a review.”

http://ieeexplore.ieee.org/document/7096904/, 2014.

[6] Interaction Design Foundation, “Designing for the

mobile environment – some simple guidelines.”

https://www.interaction-design.org/literature/article/designing-for

-the-mobile-environment-some-simple-guidelines, 2017. [Online; accessed

26-January-2018].

[7] J. Natoli, “5 Crucial Principles for Great Mobile Design.”

http://www.givegoodux.com/5-crucial-principles-great-mobile-design/,

2014.

[8] Merriam-Webster, “Definition of ’Table’.” https://www.merriam-webster.com/

dictionary/table, 2017. [Online; accessed 29-December-2017].

[9] Usability.gov, “Planning a Usability Test.” https://www.usability.gov/how-

to-and-tools/methods/planning-usability-testing.html, 2018. [Online; ac-

91

http://trydevkit.com/blog-post/responsive-tables-best-practices-and-examples/ee7961a6-a22e-610b-70d0-533c85cc59b6

http://trydevkit.com/blog-post/responsive-tables-best-practices-and-examples/ee7961a6-a22e-610b-70d0-533c85cc59b6

https://itsupport.smu.edu.sg/hc/en-us/articles/203120704-What-are-some-guidelines-for-table-and-listings-for-mobile-apps-

https://itsupport.smu.edu.sg/hc/en-us/articles/203120704-What-are-some-guidelines-for-table-and-listings-for-mobile-apps-

https://www.nngroup.com/articles/comparison-tables/

https://www.nngroup.com/articles/mobile-tables/

http://ieeexplore.ieee.org/document/7096904/

https://www.interaction-design.org/literature/article/designing-for-the-mobile-environment-some-simple-guidelines

https://www.interaction-design.org/literature/article/designing-for-the-mobile-environment-some-simple-guidelines

http://www.givegoodux.com/5-crucial-principles-great-mobile-design

https://www.merriam-webster.com/dictionary/table

https://www.merriam-webster.com/dictionary/table

https://www.usability.gov/how-to-and-tools/methods/planning-usability-testing.html

https://www.usability.gov/how-to-and-tools/methods/planning-usability-testing.html

92


[10] B. Konev, “COMP210: Artificial Intelligence. Lecture 13. Forward and backward

chaining.” http://www.theimpactinstitute.org/Teaching/CS4725/rbs.pdf,

2010.

[11] J. Freeman-Hargis, “Rule-Based Systems and Identification Trees.”

http://ai-depot.com/Tutorial/RuleBased.html, 2007.

[12] Red Hat Inc., “Drools.” https://www.drools.org, 2017. [Online; accessed 15-

December-2017].

[13] C. Berlioz, “Origin of the Rete Algorithm.”

https://www.sparklinglogic.com/rete-algorithm-demystified-part-1/,

2011.

[14] TutorialsPoint, “Artificial Intelligence - Fuzzy Logic Systems.”

https://www.tutorialspoint.com/artificial intelligence/

artificial intelligence fuzzy logic systems.htm, 2017. [Online; accessed

21-December-2017].

[15] MathWorks, “What Is Fuzzy Logic?.” https://se.mathworks.com/help/fuzzy/

what-is-fuzzy-logic.html?requestedDomain=true, 2018. [Online; accessed 22-

December-2017].

[16] G. Hepting, “jquery-responsive-tables.” https://github.com/ghepting/jquery-

responsive-tables, 2015.

[17] G. Yuen, “Responsive Table.” https://codepen.io/geoffyuen/pen/FCBEg, 2014.

[18] Filament Group, “Tablesaw.” https://github.com/filamentgroup/tablesaw,

2017.

[19] P. O’Brien, “Horizontal scrolling table with Fixed first column.”

https://codepen.io/paulobrien/pen/gWoVzN, 2017.

[20] Bootstrap v4.0, “Bootstrap.” http://getbootstrap.com, 2017.

[21] W3Schools, “JavaScript Tutorial.” https://www.w3schools.com/js/, 2017.

[22] Golang, “Golang documentation.” https://golang.org, 2017.

[23] Golang, “Package template.” https://golang.org/pkg/html/template/, 2017.

[24] P.Blackburn, J. Bos and K. Striegnitz, “Learn Prolog Now.”

http://www.learnprolognow.org/lpnpage.php?pagetype=htmlpageid=lpn-htmlli4,

2012.

[25] D. Wolf, Infoworld, “The 5 best programming languages for AI development.”

https://www.infoworld.com/article/3186599/artificial-intelligence/the-5-

best-programming-languages-for-ai-development.html, 2017.

[26] M. Hendricks, “Golog.” https://github.com/mndrix/golog, 2017.

http://www.theimpactinstitute.org/Teaching/CS4725/rbs.pdf

http://ai-depot.com/Tutorial/RuleBased.html

https://www.drools.org

https://www.sparklinglogic.com/rete-algorithm-demystified-part-1/

https://www.tutorialspoint.com/artificial_intelligence/artificial_intelligence_fuzzy_logic_systems.htm

https://www.tutorialspoint.com/artificial_intelligence/artificial_intelligence_fuzzy_logic_systems.htm

https://se.mathworks.com/help/fuzzy/what-is-fuzzy-logic.html?requestedDomain=true

https://se.mathworks.com/help/fuzzy/what-is-fuzzy-logic.html?requestedDomain=true

https://github.com/ghepting/jquery-responsive-tables

https://github.com/ghepting/jquery-responsive-tables

https://codepen.io/geoffyuen/pen/FCBEg

https://github.com/filamentgroup/tablesaw

https://codepen.io/paulobrien/pen/gWoVzN

http://getbootstrap.com

https://www.w3schools.com/js/

https://golang.org

https://golang.org/pkg/html/template/

http://www.learnprolognow.org/lpnpage.php?pagetype=html&pageid=lpn-htmlli4

https://www.infoworld.com/article/3186599/artificial-intelligence/the-5-best-programming-languages-for-ai-development.html

https://www.infoworld.com/article/3186599/artificial-intelligence/the-5-best-programming-languages-for-ai-development.html

https://github.com/mndrix/golog

visualization of tabular data on mobile...

Documents