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
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
A.3 All websites with tables found during research cont. . . . . . . . . . . . . 75
A.4 All websites with tables found during research cont. . . . . . . . . . . . . 76
A.5 All websites with tables found during research cont. . . . . . . . . . . . . 77
A.6 All websites with tables found during research cont. . . . . . . . . . . . . 78
A.7 All websites with tables found during research cont. . . . . . . . . . . . . 79
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.5 Test ratings from scenario 5 (Product offering, 5 columns) . . . . . . . . 84
B.6 Test ratings from scenario 6 (Stock market, 10 columns) . . . . . . . . . 84
B.7 Test ratings from scenario 7 (Product offering, 7 columns) . . . . . . . . 85
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.
12 Theory and Methodology
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. Mapping the most common table solutions for mobile devices 13
3.1.2 Collapse by rows
Collapse by rows means that each row splits up and forms its own column that places
in separate boxes on top of each other on the phone screen. A row collapse of figure 3.2
is demonstrated in figure 3.4. It is advantageous for tables that doesn’t contain large
datasets and with rows that isn’t supposed to be compared to another row in the table.
The solution is easy to read when a specific value is to be considered and it makes the
data very accessible and clear.
Figure 3.4: A table displayed on a mobile device using a collapse by row solution.
14 Theory and Methodology
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
3.1. Mapping the most common table solutions for mobile devices 15
of columns should be compared at the same time. When all content isn’t visible at the
same time, it can be difficult to remember other columns when the table data constantly
keeps scrolling back and forth.
Figure 3.6: A table displayed on a mobile device using a scroll solution.
3.1.5 Click
The click solution is very similar to the scroll approach. Some of the table content is
required to hide when the other content is visible due to the limited screen area on a
mobile device. In order to switch between the columns a button can be clicked to move
either left or right. And like the scroll solution, click also have the first column frozen to
increase readability and usability.
Too many columns to click through can be confusing if the purpose of the table is to
compare different columns with each other. The user could easily forget the data to
compare with while clicking left and right when parts of the content becomes hidden.
Figure 3.7 displays a click solution of figure 3.2 with a frozen first column. The left and
right buttons to toggle between the table’s columns is placed in the top right corner of
the phone.
16 Theory and Methodology
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.
18 Theory and Methodology
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. Statistic analysis of the most used table solutions on mobiledevices 19
3.2.1 Summary of the most used table solutions from research
As mentioned in the previous section, the number of tables used for this research is 100.
The data has been categorized into different categories and to simplify its distribution it
is presented in various charts below.
The first chart, figure 3.8, displays the distribution of the different responsive table 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.
20 Theory and Methodology
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.
3.2. Statistic analysis of the most used table solutions on mobiledevices 21
After evaluating the importance of website categories when finding patterns on when
to use which solution to what data, the next step is to evaluate the relevance of table
categories. Figure 3.10 displays a chart of the table category distribution and compared
to the website category distribution in figure 3.9 there’s a few less pies to keep track on.
The pies are also larger, which means it can be easier to draw conclusions when finding
patterns. The most common table categories are product offerings, product comparison,
sports and stock market.
Figure 3.10: The distribution of table categories for the 100 reference tables.
It is more relevant to use the table category distribution than the distribution for website
categories since it describes the content instead of the context. This thesis is about
mapping which responsive table solution is more appropriate to use for a specific type
of data and, therefore, it’s more important to study the content of the tables. The next
step is to investigate if there is any relationship between the table categories and the
table solutions. In figure 3.11 it can be seen that there are some solutions that are more
common for some table categories, but it’s not clear enough to draw any assumptions.
The data is overall scattered and there is not enough readings for some of the table
categories which makes it difficult for a conclusion about those.
22 Theory and Methodology
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.
3.2. Statistic analysis of the most used table solutions on mobiledevices 23
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.
24 Theory and Methodology
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
26 Theory and Methodology
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
28 Theory and Methodology
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.
30 Theory and Methodology
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
32 Theory and Methodology
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
Scenario 5 (Product of-
fering, 5 columns)
20 13 22 25
Scenario 6 (Stock mar-
ket, 10 columns)
29 25 11 15
Scenario 7 (Product of-
fering, 7 columns)
22 22 20 16
Scenario 8 (Product
comparison, 5 columns)
28 8 19 25
Scenario 9 (Sports, 5
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
38 Implementation and Solution
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.
5.2. The Visualization Wizard 39
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.
40 Implementation and Solution
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. The Visualization Wizard 41
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.
42 Implementation and Solution
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
44 Implementation and Solution
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.
46 Implementation and Solution
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.
48 Implementation and Solution
Figure 5.13: The mapping of the answers leading to a squish solution.
5.4. The rule-based system 49
Figure 5.14: The mapping of the answers leading to a row collapse solution.
50 Implementation and Solution
Figure 5.15: The mapping of the answers leading to a scroll solution.
5.4. The rule-based system 51
Figure 5.16: The mapping of the answers leading to a click solution.
52 Implementation and 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>
<th> Heading 2 </th>
<th> Heading 3 </th>
</tr>
<tr>
<td> Row 1 , Col 1 </td>
<td> Row 1 , Col 2 </td>
5.5. Tables 53
<td> Row 1 , Col 3 </td>
</tr>
<tr>
<td> Row 2 , Col 1 </td>
<td> Row 2 , Col 2 </td>
<td> Row 2 , Col 3 </td>
</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:
54 Implementation and Solution
<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>
<td data−th=”Heading 2”>Row 1 , Col 2</td>
<td data−th=”Heading 3”>Row 1 , Col 3</td>
</tr>
<tr>
<td data−th=”Heading 1”>Row 2 , Col 1</td>
<td data−th=”Heading 2”>Row 2 , Col 2</td>
<td data−th=”Heading 3”>Row 2 , Col 3</td>
</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:
56 Implementation and Solution
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.
58 Implementation and Solution
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)
Squish Sq Sq Sq Sq Sq Sq Sq Sq
Scenario 4 (Sports, 10
columns)
Scroll Sc Cl Sc Sc Cl Sc Sc Sc
Scenario 5 (Product offer-
ing, 5 columns)
Squish Sq Sq Sq Sq Sq Sq Sq Sq
Scenario 6 (Stock market,
10 columns)
Click Cl Sc Sc Cl Cl Sc Cl Cl
Scenario 7 (Product offer-
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
Scenario 9 (Sports, 5
columns)
Squish Cl Sq Sq Sq Sc Sq Sq Sq
Scenario 10 (Stock market,
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
Table A.3: All websites with tables found during research cont.
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
Table A.4: All websites with tables found during research cont.
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
Table A.5: All websites with tables found during research cont.
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
Table A.6: All websites with tables found during research cont.
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
Table A.7: All websites with tables found during research cont.
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)
User Row collapse Squish Click Scroll
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)
User Row collapse Squish Click Scroll
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)
User Row collapse Squish Click Scroll
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
Table B.5: Test ratings from scenario 5 (Product offering, 5 columns)
User Row collapse Squish Click Scroll
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
Table B.6: Test ratings from scenario 6 (Stock market, 10 columns)
User Row collapse Squish Click Scroll
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
Table B.7: Test ratings from scenario 7 (Product offering, 7 columns)
User Row collapse Squish Click Scroll
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)
User Row collapse Squish Click Scroll
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)
User Row collapse Squish Click Scroll
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
Table B.10: Test ratings from scenario 10 (Stock market, 7 columns)
User Row collapse Squish Click Scroll
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
(Product offering, 3 columns)
• ”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
(Product offering, 5 columns)
• ”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
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-
cessed 26-January-2018].
[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
92
cessed 03-January-2018].
[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.