applications

Usability of distributed data sources for modern Web

Academic year 2018-2019

Master of Science in Computer Science Engineering

Master's dissertation submitted in order to obtain the academic degree of

Counsellors: Dr. ir. Miel Vander Sande, Ir. Ruben Taelman, Ir. Pieter HeyvaertSupervisor: Prof. dr. ir. Ruben Verborgh

Student number: 01404382

Isa Sebrechts

Preface

I found out that starting your thesis in a field where you have no previous experience is as

challenging as it sounds, but sometimes related interests and curiosity are all you need to get

started. I would like to thank my counsellors Miel Vander Sande, Ruben Taelman and Pieter

Heyvaert for their patience and advice. Even though my communication was often sparse,

questions were always quickly resolved and feedback promptly given.

Additionally, I want to thank everyone who participated in the user tests, and apologize to

them and all who read this thesis for inciting you to become hyper-aware of the UX strategies

your social media uses while it loads.

Isa Sebrechts, Ghent, May 2019

Copyright notice

“The author gives permission to make this master dissertation available for consultation and to

copy parts of this master dissertation for personal use. In all cases of other use, the copyright

terms have to be respected, in particular with regard to the obligation to state explicitly the

source when quoting results from this master dissertation.”

Isa Sebrechts, Ghent, May 2019

Usability of Distributed Data Sources

for Modern Web Applicationsby

Isa SEBRECHTS

Master’s dissertation submitted in order to obtain the academic degree of

Master of Science in Computer Science Engineering

Academic yaar 2018–2019

Supervisor: Prof. Dr. Ir. R. VERBORGH

Counsellors: Dr. Ir. M. VANDER SANDE, Ir. R. TAELMAN, Ir. P. HEYVAERT

Faculty of Engineering and Architecture

Ghent University

Department of Electronics and Information Systems

Chair: Prof. Dr. Ir. K. DEBOSSCHERE

Abstract

This paper researches how to minimize the negative effect of using distributed data sources on

the usability of modern web applications; more specifically the effect of varying load times on the

usability of social media feeds. Qualitative user testing was performed to assess the performance

of three UX strategies, i.e. using content placeholders, using spinners, and displaying content

in-order. Results show that usability is highly dependent on the distribution of delays. If less

than half of the data pods in the network are delayed, content placeholders can be used to

ensure sufficient usability. A hybrid strategy which should cover most distributions is proposed.

Additionally, if the content allows it, reordering the feed advised.

Keywords

usability, user experience, UX, distributed data sources, distributed social media

Usability of Distributed Data Sourcesin Modern Web Applications

Isa Sebrechts

Supervisor(s): prof. dr. ir. Ruben Verborgh, dr. ir. Miel Vander Sande, ir. Ruben Taelman, ir. Pieter Heyvaert

Abstract—This paper researches how to minimize the negative effect of

using distributed data sources on the usability of modern web applications;

more specifically the effect of varying load times on the usability of social

media feeds. Qualitative user testing was performed to assess the perfor-

mance of three UX strategies, i.e. using content placeholders, using spin-

ners, and displaying content in-order. Results show that usability is highly

dependent on the distribution of delays. If less than half of the data pods

in the network are delayed, the content placeholders can be used to ensure

sufficient usability. A hybrid strategy which should cover most distribu-

tions is proposed. Additionally, if the content allows it, reordering the feed

advised.

Keywords—usability, user experience, UX, distributed data sources, dis-

tributed social media

I. INTRODUCTION

THE persistent scandals, privacy breeches and monopolies

in mainstream social media have incited users to start look-

ing for more flexible and privacy-oriented alternatives. Dis-

tributed social media networks provide an alternative by focus-

ing on true data ownership and interoperability between net-

works [1]. True data ownership can be provided by having each

user in the network host their data on a personal data pod, prefer-

able on their private, self-maintained server [2]. However, de-

velopers are expressing doubts that this fully distributed archi-

tecture can provide sufficient guarantees regarding the user ex-

perience. In practice, no fully distributed social media platforms

with a significant user base exist yet [3], and we are thus unable

to derive the usability of distributed data sources for social me-

dia applications from the usability proven by existing applica-

tions. Qualitative research into the effects of using distributed

data sources in the design of social media applications is neces-

sary to advance their development.

II. UX STRATEGIES

The main difference between UX design for distributed data

sources and traditional UX design is that for distributed data

sources in-order arrival of posts cannot be guaranteed. This is

due to varying load times, which depend on the server where

the data resides. Thus, traditional UX strategies are not guaran-

teed to work for distributed applications and have to be tested as

well. The strategies presented hereafter are based on traditional

UX design, and aim at keeping the perceived performance high.

Figure 1 shows a schematic overview of the three strategies.

Content Placeholders, also called Skeleton screens, aim to

create the lay-out of a web page before the actual content is

ready. Images and blocks of text are temporarily represented by

gray boxes with similar dimensions, which are then gradually

replaced by the actual content when it becomes available [4].

A second approach to optimizing the perceived loading time

is through progress indicators and feedback messages [5]. A

Fig. 1. A schematic representation of the three different UX strategies investi-

gated during the user test.

splash screen is shown with a spinner or progress bar, indicat-

ing the percentage of posts already loaded. Only once all posts

(in this batch) have loaded will the app show the feed. Before

content placeholders became popular, this was one of the most

commonly used strategies. It has however been criticized for

drawing the user’s attention to the act of waiting [6].

In-Order Rendering of posts is self-evident for centralized

social media feeds. For a distributed social media feed, this

poses a bigger challenge. The previous strategies consisted of

either showing each post as soon as it loaded, or letting the user

wait until all posts have arrived. In-order rendering proposes a

compromise between the two, by displaying the posts for which

all previous posts have been loaded and displayed as well.

III. RESEARCH QUESTION AND HYPOTHESES

A. Research Question

How can a good user experience be ensured when using dis-

tributed data sources in the design of modern web applications?

In this research question, we define the quality of the user expe-

rience as the subjective usability, i.e. whether the user perceived

the application to be usable or not.

B. Hypotheses

To reach an answer to the research question, the following

three statements are hypothesized.

Hypothesis 1: Variable load times have negative effects on

the subjective usability.

Hypothesis 2: By using the spinner strategy to mask varying

load times, the subjective usability of a modern web application

which uses distributed data sources can be improved.

Hypothesis 3: If the amount of delayed pods is small com-

pared to the amount of fast pods (≤ 20%), the use of placehold-

ers can ensure a good user experience.

IV. EXPERIMENT

A. Testing Platform

To observe in a qualitative manner how the users perceive the

usability of the app, a testing platform was built that simulates a

data pod-driven social media feed by adding artificial delays to

the data. As most currently popular social media platforms (e.g.

Facebook, Instagram, Reddit, Twitter) use some form of feed

as their main feature, the feed was deemed representative for a

generic social media app, and results can thus be generalized.

The feeds shown during the tests have been populated with data

from Reddit, and are a combination of pictures with captions,

comments and replies to those comments.

The testing platform consists primarily of a ReactJS1 front-

end, responsible for the user interface and user interaction. The

test controller, responsible for selecting and executing the cor-

rect scenarios, is also a part of the front-end. All data resides

in a single LowDB2 database and is served through a NodeJS3

server.

Although the testing application uses only a single server, the

use of data pods can be simulated. First of all, the structure

of the data is adapted to resemble the data as if it were stored

on data pods. To achieve this, all data created by one person

should be stored in the same place (i.e. this person’s data pod).

All other information related to this data created by other users,

such as comments on this user’s post, should only be available as

links to other user’s pods. A schematic representation is shown

in Figure 2.

Secondly, a delay value is associated with each data pod to

simulate varying load times. The distribution of these delays

should cover a representative subset of data pod configurations.

To represent different categories of pods, we introduce the terms

fast pods, delayed pods and heavily delayed pods. A fast pod is

assumed to have negligible delay, and has thus a delay value

of 0. We define delayed pods as pods having a delay up to 5

seconds, normally distributed around 3 seconds. To achieve this,

we sample a delay d as min(ds, 5) with ds ∼ N (3,1). Similarly,

a collection of heavily delayed pods is sampled from N (5,2),

with a cut-off at 8 seconds. Figure 3 shows the distribution of

the delays, generated for a data set with 3217 distinct data pods.

B. User Tests

Before the test starts the user has to fill out a questionnaire

about their background, which can be used to provide context

for the results. Questions are asked about gender, age, social me-

dia use, online privacy, patience and technological background.

The test itself consists of the test person judging a set of sce-

narios, where each scenario is defined by a delay configuration

and a UX strategy. The non-delayed scenario is always shown

first to give the users the opportunity to become familiar with

the application. The order of the other scenarios is randomized.

1https://reactjs.org/2https://github.com/typicode/lowdb3https://nodejs.org/

Fig. 2. Schematic representation of the data pod structure assumed in the testing

application.

Fig. 3. Histogram showing distributions for delayed (∼ N (3,1)) and heavily

delayed data pods (∼ N (5,2)), with N = 3217 data pods.

Two randomly picked scenarios from this set are added to the

end of the list, to verify the consistency of the user’s answers.

Each user tester is thus judging 16 scenarios, which takes be-

tween 15 and 45 minutes depending on the test person.

During every scenario the user is asked to select a topic and

find at least one post they like and one comment they agree with

in the feed. Afterwards the user can choose to end this sce-

nario and is then asked to assess how quickly the page loaded,

whether or not this was acceptable for them, and to what degree

they enjoyed using the app. Comments given during the test are

recorded.

V. RESULTS

While the main aim of the user testing is to gather in-depth

feedback on the app’s usability, the users were also asked to

judge the acceptability of the initial delay and their satisfaction

while using the app on a 5-step scale. The average outcomes for

each scenario are listed in Table I.

A. UX strategy comparison per delay configuration

For all delay configurations the placeholder strategy receives

the highest score for acceptability of the initial waiting time, as

shown in bold in Table I. These results are as expected. Either

the user starts scrolling through the feed immediately until the

first loaded post is encountered. In this case the waiting time

will be equal to the delay of the fastest post in the batch. If

the user instead waits at the top of the feed until the first post

placeholders spinners in-order

Data pod delay distribution acc sat acc sat acc sat

100% fast 5 4.75

80% fast, 10% delayed, 10% heavily delayed 4.42 4.32

50% fast, 50% delayed 4.37 4.11 3.78 3.89 4.11 3.67

20% fast, 50% delayed, 30% heavily delayed 3.63 3.47 3.21 3.63 3.40 3.65

100% delayed 3.74 3.63 3.74 4.00 3.32 3.63

100% heavily delayed 3.37 3.53 3.05 3.63 2.89 3.58

TABLE I

AVERAGE ACCEPTABILITY [OF INITIAL DELAY] (ACC) AND SATISFACTION [DURING USE] (SAT) FOR ALL SCENARIOS. THE NUMERIC VALUES

CORRESPOND TO TEXTUAL ANSWERS IN THE FOLLOWING MANNER: 1 - NOT AT ALL, 2 - NO, 3 - UNSURE, 4 - YES, 5 - VERY MUCH. ONLY SCENARIOS

WITH AN AVERAGE SCORE OF 4 OR HIGHER ON BOTH CRITERIA ARE ON AVERAGE SEEN AS USABLE BY ALL USER TESTERS.

appears, the waiting time will be equal to the delay of the pod

containing the first post on the feed. For the spinner and in-order

strategy this waiting time is equal to respectively the delay of the

slowest pod in the batch, and the delay of the pod containing the

first post. Hence the initial delay for placeholders will always be

the shortest, and the results confirm that it also feels the fastest.

However, the satisfaction scores show that placeholders lack

in other aspects. As long as the percentage of fast pods in the

network is higher than 50%, the test results show that users are

satisfied to very satisfied with the app. Users can quickly start

reading posts and comments, while the annoyance of having a

part of the posts and comments still loading and popping up

is kept to a minimum. When the amount of fast pods drops

to 20% or lower, the satisfaction decreases significantly for the

placeholder strategy, while the scores for spinners and in-order

remain almost constant. The lack of chronology and stutter-

ing completion of the feed and comment sections are the main

causes for this decrease in satisfaction. Neither of these issues

are present in the other two strategies. This also explains why

the satisfaction scores for the spinner and in-order strategy vary

significantly less than for placeholders.

B. Possible Mitigations

B.1 Derived hybrid strategy

From the results of the user tests an improved UX strategy

can be derived, based on the needs which users reported or im-

plied. One aspect all users agreed upon is the need for con-

sistency in waiting times. Because of the intrinsic properties of

distributed data sources this consistency cannot be guaranteed in

itself. However, the app can behave in certain ways to give the

appearance of consistency. The proposed strategy would have a

short fixed waiting time at the start of every load, while show-

ing a progress bar or other loading indicator. Network analysis

should be done to determine the fixed waiting time to ensure that

at least 50% of pods can respond within this time period. Af-

terward the feed is displayed with placeholders for the remain-

ing posts and comments. This guarantees the shortest possible

waiting time while providing a proper UX, without needing to

change the order of the feed. The proposed strategy was neither

implemented nor tested within this thesis.

B.2 Relaxing the order of the feed

In the usual social media feed, posts and comments are either

ordered chronologically, or ordered based on a certain measure-

ment of popularity. For most types of content, as long as unseen

posts are shown before the others and the comment tree struc-

ture is preserved, posts and comments can be reordered without

being really noticeable to the users. For these cases it would

be an option to have a greedy UX strategy, in which the posts

and comments residing on the fastest pods are shown highest on

the feed or comment section. While there is no doubt that this

would result in a smooth UX, developers should be mindful of

the possible social implications this kind of strategy would have.

VI. CONCLUSIONS

When using distributed data sources in the design of modern

web applications, the quality of the user experience can be im-

proved by firstly giving the appearance of consistency in wait-

ing times, and secondly by providing consistency in lay-out of

the user interface. For up to 50% noticeably delayed pods, a

placeholder strategy can guarantee a sufficiently high perceived

usability. For a higher percentage of delayed pods, a hybrid

strategy combining spinners with placeholders could provide a

solution. In defining the UX strategy, a trade-off has to be made

between the app feeling fast (content showing up on arrival) and

the UX feeling intuitive (content shown at once or progressively

from top to bottom).

If the type of content shown in the feed is suitable for it, de-

velopers can decide to exchange the sorted order of the content

in the feed for increased speed and usability by reordering posts

and comments on speed of the pod they reside on instead of cre-

ation time or popularity.

REFERENCES

[1] Fediverse, “Fediverse, diversity is strength,” 2019.[2] The Solid Project, “What is solid?,” 2017.[3] Ames Bielenberg, Lara Helm, Anthony Gentilucci, Dan Stefanescu, and

Honggang Zhang, “The growth of Diaspora - A decentralized online socialnetwork in the wild,” in Proceedings - IEEE INFOCOM. mar 2012, pp.13–18, IEEE.

[4] W Danielson, “Building skeleton screens with css custom properties,” 2017.[5] R Morey, “What is perceived performance and why you need to optimize

it,” 2018.[6] L Wroblewski, “Mobile design details: Avoid the spinner,” 2013.

i

Contents

1 Introduction 1

2 Distributed Social Media 3

2.1 The Fediverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Diaspora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Mastodon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Solid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 UX Design 8

3.1 Centralized vs. Distributed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.1 Content Placeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.2 Spinners with Progress Indication . . . . . . . . . . . . . . . . . . . . . . 10

3.2.3 In-order Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Research Question & Hypotheses 12

4.1 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Experiment 14

5.1 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2.1 Testing Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2.2 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2.3 User Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

ii

5.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.3.1 Performance of UX Strategies . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.3.2 UX strategy comparison per delay configuration . . . . . . . . . . . . . . 28

6 Discussion 29

7 Conclusions 31

8 Future Work 32

A User test results grouped by UX strategy 33

B User test results grouped by delay configuration 37

iii

List of Figures

1.1 Number of social media users worldwide (in billions), graph from Statista [1] . . . 1

2.1 The Diaspora user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 The Mastodon user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 A schematic representation of the three different strategies discussed in sec-

tion 3.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Skeleton screen examples from currently popular applications [2] . . . . . . . . . 10

5.1 A comparison of the Instapod feed with currently popular social media feeds. . . 15

5.2 Schematic representation of the data pod structure assumed in the testing appli-

cation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.3 Placeholder implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.4 Spinner implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.5 Histogram showing distributions for delayed (∼ N (3, 1)) and heavily delayed data

pods (∼ N (5, 2)), with N = 3217 data pods. . . . . . . . . . . . . . . . . . . . . . 20

5.6 Questionnaire with background questions to be filled out by the test person before

starting the test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.7 Questions to be answered by the test person after interacting with a scenario. . . 24

5.8 Chart showing the average acceptability of initial delay and satisfaction during

use for all scenarios. The numeric values on the y-axis correspond to textual

answers in the following manner: 1 - Not at all, 2 - No, 3 - Unsure, 4 - Yes, 5 -

Very much. Only scenarios with an average score of 4 or higher on both criteria

are on average seen as usable by all user testers. . . . . . . . . . . . . . . . . . . 25

iv

A.1 Bubble chart of the test results for the base case scenario. X marks the average

within each row. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

A.2 Bubble charts for placeholder scenarios. X marks the average. . . . . . . . . . . . 34

A.3 Bubble charts for spinner scenarios. X marks the average. . . . . . . . . . . . . . 35

A.4 Bubble charts for in-order scenarios. X marks the average. . . . . . . . . . . . . . 36

B.1 Bubble charts for the scenarios with 50% fast pods and 50% delayed pods. X

marks the average. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

B.2 Bubble charts for the scenarios with 20% fast pods, 50% delayed pods and 30%

heavily delayed pods. X marks the average. . . . . . . . . . . . . . . . . . . . . . 39

B.3 Bubble charts for the scenarios with 100% delayed pods. X marks the average. . 40

B.4 Bubble charts for the scenarios with 100% heavily delayed pods. X marks the

average. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

B.5 Bubble charts for 100% and 80% fast pods with placeholder strategy. X marks

the average. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

v

List of Tables

5.1 Overview of all scenarios used during user testing . . . . . . . . . . . . . . . . . . 21

5.2 Average acceptability [of initial delay] (acc) and satisfaction [during use] (sat) for

all scenarios. The numeric values correspond to textual answers in the following

manner: 1 - Not at all, 2 - No, 3 - Unsure, 4 - Yes, 5 - Very much. Only scenarios

with an average score of 4 or higher on both criteria are on average seen as usable

by all user testers. The maximal acceptability and satisfaction for each scenario

is shown in bold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1

Chapter 1

Introduction

Social media is abundantly present in modern society. The number of social media users has

doubled in the past ten years, and is projected to keep growing, as shown in Figure 1.1. With

over 2.7 billion social media users world wide, the amount of data being generated and collected

is immense and valuable.

Figure 1.1: Number of social media users worldwide (in billions), graph from Statista [1]

The Facebook-Cambridge Analytica data scandal in early 2018 was the start of online privacy

awareness for a large fraction of the mainstream social media users [3]. Cambridge Analytica,

a former British political consulting company specialized in data mining and data analysis, had

harvested personal data from 87 million Facebook users [4] and used it to influence political

campaigns such as the US 2016 elections [5] and the Brexit referendum. While users start to

become aware of their need for online privacy, breaking all ties with industry giants such as

Facebook is not particularly easy. The company has become a monopoly for social media appli-

2

cations, acquiring competitors such as Instagram and WhatsApp [6]. In October 2018 Google

announced the shutdown of social media network Google+, due to low usage and challenges

involved in maintaining a successful product that meets consumers expectations [7]. Their user

base might have been small in comparison to Facebook or Twitter, but at least 7 million people

saw their social network crumble. The user base received the option to download their personal

data, files and pictures, but there was no way to move the community and network to a different

platform. The API and application itself were shut down completely in April 2019.

To counter these tendencies of vendor lock-in, privacy breeches and monopolies, alternatives

have popped up. Since 2011, Distributed Social Media (DSM) applications have been created

and have gained significant traction, focusing on interoperability between platforms to avoid this

vendor lock-in. Tim Berners Lee, the inventor of the Web, has an even more radical opinion on

decentralization, which looks beyond only social networks. He claims that the World Wide Web

as it exists today will evolve into the Semantic Web, based on Linked Data principles [8]. The

Solid project provides a set of conventions and tools for this decentralized Web, with a focus on

true data ownership, modular design and reusing existing data.

While the first Solid apps are being developed, application developers have also started

voicing their concerns about the usability of Solid applications on the Solid Community Forum1.

In order to confirm or disprove the concerns that distributed social media feeds will not be able

to guarantee an acceptable user experience (UX), this thesis investigates the subjective usability

of fully distributed social media.

1https://forum.solidproject.org/

3

Chapter 2

Distributed Social Media

To assess the usability of distributed data sources for modern Web applications, current dis-

tributed social applications should be investigated first. In the past years multiple Distributed

Social Media (DSM) projects have been launched and gained significant popularity as part

of the fediverse (section 2.1). In sections 2.2 and 2.3 two of the largest projects, Diaspora and

Mastodon, will be discussed. Solutions to some of the problems encountered in previous projects

are offered in the Solid project introduced in section 2.4.

2.1 The Fediverse

The fediverse, a portmanteau of “federation” and “universe”, is a network of federated instances,

with each instance being a separate social network (GNU Social, Mastodon, Diaspora, etc.) [9].

The core idea of the fediverse is that content created through one instance can be shared with

users on any other instance. This interoperability of platforms is created through a set of

communication and authentication protocols which follow open standards. Originally the term

fediverse only encapsulated microblogging networks which follow the OStatus1 protocol. Since

other federated networks became reasonably popular and shared the same values, the set of

protocols was expanded to include ActivityPub2 and others [9].

1https://github.com/OStatus2https://activitypub.rocks/

4

2.2 Diaspora

The Diaspora network [10] is the pioneer of distributed social media, built in 2011 by a group of

students at New York University. It was developed as a proof of concept for distributed social

network protocols [11], representing the core values of decentralization, freedom and privacy [10].

The social network is not owned by the creators or any other entity, protecting it from corporate

take-overs or advertising. In September 2011 the developers stated, ”...our distributed design

means no big corporation will ever control Diaspora. Diaspora will never sell your social life

to advertisers, and you wont have to conform to someones arbitrary rules or look over your

shoulder before you speak.” [12]

New users can host their pods on open servers, or on closed ones if they receive an invitation.

Alternatively, they can create their own server and host their pod there. All Diaspora servers

are maintained by individual users, called podmins. Before hosting their pod on a server, the

user should verify that they trust the podmin, as this person will have full control over their

data.

On their pod a user maintains a set of aspects, each containing a list of user handles. These

aspects are used to group your contacts. When a user creates a post and shares it with their

contacts, a push system is used. Every post shared with an aspect will be pushed to all home

servers in which a user of that aspect resides. Additionally, a copy of your user profile will be

stored on every home server from which a user accesses your profile. As a result, your data

is copied to multiple servers, which requires you to trust both your own server admin, and all

servers where your recipients reside.

This form of data storage results in a smooth UX, as your application displays posts directly

from your own home server. However, the push system also leads to an architecture where

having larger servers is more efficient. When most communication happens within your server,

less foreign user profiles need to be stored on the home server. In 2011, an analysis of the

servers in the Diaspora network showed that 96% of users host their pods on one of the four

largest servers. Moreover, 70% of users host their pod on the server maintained by the Diaspora

developers3 [13]. The developers had foreseen that users would choose the convenient option,

and had listed the shrinkage of the largest server as one of their measures of success [11].

Apart from the fact that the Diaspora network did not end up as distributed as the creators

had anticipated, the network suffered another setback in 2013. Insufficient authorization caused

3https://joindiaspora.com/

5

Figure 2.1: The Diaspora user interface

security leaks, which let unauthorized users delete user profiles [14].

In conclusion, the Diaspora network provides a good UX, however it is not fully distributed

and is lacking in privacy and security.

2.3 Mastodon

Where Diaspora was crowned the anti-Facebook [11] of the fediverse, Mastodon4 is the decentral-

ized microblogging network which can be seen as the distributed version of Twitter. Figure 2.2

shows the Mastodon UI, which shares its look and feel with Twitter tool Tweetdeck5. Mastodon

is currently the largest and fastest growing social network of the fediverse. In early 2019 the

network surpassed 2 million users [15], with the main instance6 still gaining approximately 1.800

new users every week [16] in May 2019. Mastodon’s network topography is similar to Diaspora’s

with one federated server instance for 1000+ users, and most of the users grouped together on

a small amount of large servers.

4https://joinmastodon.org/5https://tweetdeck.twitter.com/6https://mastodon.social/

6

Figure 2.2: The Mastodon user interface

2.4 Solid

The Solid project7 is a set of conventions and tools for the decentralized Web, developed at MIT.

Solid, derived from “Social Linked Data”, focuses on true data ownership, modular design and

reusing existing data. Its goal is to provide a platform for a new type of Web, based on Linked

Data principles [17]. In contrast to Mastodon, Solid aims at a one-pod-per-person network.

In the most extreme case, each user would host their own pod(s) on a private, self-maintained

server. However, it is still in its development phase, and no Solid social media apps8 have

reached a large audience yet.

As mentioned in the introduction, developers have been voicing their concerns on the Solid

Community Forum9, doubting the usability of distributed data sources for social media apps.

“Listing shared posts (or displaying a feed): If we want to display all the

posts that have been shared with a particular user, we would start by listing the

share triples I mentioned just before, but then would we need to peek at all the

destination PODs to build the results? [...] If some users’ PODs are down or

even slow to respond, it would considerably affect the overall performance

of the app.”[18]

7https://solid.mit.edu/8https://github.com/solid/solid-apps9https://forum.solidproject.org/

7

“Now this isnt directly comparable with the way Solid works, and its much easier

to host home services these days, but still - people of today expect a certain uptime

when they surf around for content, and every dead link, or slow response time,

will be disappointing.”[19]

These concerns would also be valid for applications from the fediverse, in case a one-pod-

per-person approach would be used.

2.5 Summary

No fully distributed social media platforms with a significant user base exist in practice. We are

thus unable to derive the usability of distributed data sources for social media applications from

the usability proven by existing applications. Moreover, developers are expressing doubts that

this fully distributed architecture will provide sufficient guarantees regarding the user experience.

This doubt confirms our belief that the subjective usability of distributed data sources is not

self-evident, and that the research provided in this thesis is useful.

8

Chapter 3

UX Design

The usability of distributed data sources for social media applications is not self-evident, as was

argued in the previous chapter. In the next sections, why and how UX design for distributed data

sources is different from its centralized counterpart is discussed. Next, a conceptual overview of

the UX strategies used during this research is given.

3.1 Centralized vs. Distributed

The main difference between UX design for centralized and distributed data sources is having to

deal with the variation in load times. For a centralized Web application, we can safely assume

that most of the data is hosted on one server or data center. One can thus be fairly sure that,

while assembling a news feed, the post that was requested first will also be available first.

For distributed data sources this in-order arrival of posts cannot be guaranteed due to varying

load times which depend on the server where the data resides. During the user tests, the focus

will be on providing acceptable UX while building the social media feed with these varying load

times.

3.2 Strategies

Perceived performance is a measure of how fast something feels to the user. The idea is that

users are more patient and will think of a system as faster if they know what is going on and can

anticipate content before it is actually there. It is all about managing expectations and keeping

the user informed [2].

The strategies presented hereafter all aim at keeping this perceived performance high. How a

9

Figure 3.1: A schematic representation of the three different strategies discussed in section 3.2.

user perceives the waiting time until they are able to interact with a page depends on the strategy

used when loading and rendering the elements on the web page. The strategies presented here

differ in two aspects:

1. What is shown on the page while it loads?

2. When is an element displayed?

An overview of the three strategies discussed here is presented in Figure 3.1

3.2.1 Content Placeholders

Content placeholders, also called Skeleton screens, aim to create the lay-out of a web page

before the actual content is ready. Images and blocks of text are temporarily represented by

gray boxes with similar dimensions, which are then gradually replaced by the actual content

when it becomes available [2]. Skeleton screens were proposed in 2013 as an alternative to

spinners, to focus on progress instead of waiting time [20].

Through content placeholders users can anticipate the content, which should lead to them

being more patient and thus the app having a higher perceived performance. However, this effect

has never been thoroughly researched1. A small-scale user test has shown a slight increase in

1Or at least no research has been released to the public. Seeing as Facebook and Google use placeholders

extensively, it is safe to assume they did researched it.

10

perceived performance when compared to a blank screen or spinner [21]. Regardless of the lack

of concrete evidence, most currently popular websites and mobile applications (e.g. Facebook,

Instagram, YouTube, Google Drive, . . . ) have adopted the content placeholder. Examples of

skeleton screens in popular applications are shown in Figure 3.2.

A possible advantage of using placeholders for an application with distributed data sources,

is that it could significantly speed up the perceived performance. If, for example, the first post

on the feed is hosted on a slower pod, the user can already read the second (faster) post. On the

other hand, we predict the app to feel less natural and controlled due to posts and comments

not loading in perfect chronological order.

Note that skeleton screens are sometimes used as splash screens, where all placeholders are

replaced by the content at once [21]. When used in this thesis, content placeholders are always

used as an actual skeleton screen, where the skeleton objects are gradually replaced by content.

(a) Slack

(b) Facebook post (contrast manually in-

creased for visibility)

Figure 3.2: Skeleton screen examples from currently popular applications [2]

3.2.2 Spinners with Progress Indication

A different approach to optimizing the perceived loading time is through progress indicators and

feedback messages [22]. A splash screen is shown with a spinner or progress bar, indicating the

percentage of posts already loaded. Only once all posts (in this batch) have loaded will the app

show the feed.

This is, together with content placeholders, one of the most commonly used strategies in

modern Web and mobile applications. It has however been criticized for drawing the user’s

attention to the act of waiting [20]. The biggest advantage to this strategy is that the user

should not notice at all that the app uses distributed data sources. This will come at the cost

11

of a higher initial waiting time, equal to the delay of the slowest piece of data on the page.

3.2.3 In-order Rendering

As discussed in section 3.1, the in-order displaying of posts is self-evident for centralized social

media feeds. For a distributed social media feed, this poses a bigger challenge. The previous

strategies consisted of either showing each post as soon as it loaded, or letting the user wait until

all posts have arrived. The last strategy proposes a compromise between the two, by displaying

the posts for which all previous posts have been loaded and displayed as well.

An advantage that can be anticipated is the increased UX due its similarities with currently

popular applications, where a user is also unable to scroll past loading content on a news feed.

A disadvantage can be the possible inconsistency in loading times, depending on the delay of

the pods on which the first posts on the feed are hosted.

12

Chapter 4

Research Question & Hypotheses

After defining the context in chapter 1, the research question will now be stated formally. Based

on the information presented in chapter 2 and 3, hypotheses are then formulated to guide the

experiment in reaching answers to the research question.

4.1 Research Question

The research question is formulated as follows:

How can a good user experience be ensured when using distributed data sources in

the design of modern Web applications?

In this research question, we define the quality of the user experience as the subjective usability,

i.e. whether the user perceived the application to be usable or not.

4.2 Hypotheses

To reach an answer to the research question, the following three statements are hypothesized.

Hypothesis 1 Variable load times have negative effects on the subjective usability.

It was deduced from section 3.1 that varying load times cause the main difference between

centralized and distributed UX design. Hence, if these variable load times would not have

negative effects on the subjective usability, the answer to the research question could be based

on standard UX design principles.

13

Hypothesis 2 By using the spinner strategy1 to mask varying load times, the subjective usability

of a modern Web application which uses distributed data sources can be improved.

Section 3.2.2 states that the use of a spinner masks the varying load times associated with a

distributed architecture. If hypothesis 1 is correct, masking varying load times would lead to an

improved subjective usability.

Hypothesis 3 If the amount of delayed pods is small compared to the amount of fast pods

(≤ 20%), the use of placeholders can ensure a good user experience.

The assumption is made that the disadvantages of using placeholders, i.e. objects not loading in

an intuitive order, will have minimal negative effects on the subjective usability if only a small

amount of data pods exhibit a noticeable delay. In this case, it should be possible to still use

the conventional placeholder strategy to provide a good UX, even for distributed data sources.

1As described in section 3.2

14

Chapter 5

Experiment

The hypotheses from section 4.2 are tested by means of qualitative user testing of multiple

distributed social media scenarios, on a testing platform designed for this purpose. In the

following sections the aim, setup and results of the experiment are elaborated upon.

5.1 Aim

The aim of this experiment is to qualitatively test the perceived usability of distributed social

media. The test results are gathered in such a manner that concrete guidelines for UX design

of distributed social media can be extracted afterwards. The testing environment should be

representative for most modern-day social media platforms, mimicking their main features. The

focus of the test is on performing read-only evaluations, so features such as adding posts and

comments are omitted.

5.2 Setup

To fulfill the previously mentioned aims, a testing platform has been built which simulates a

data pod-driven social media feed by adding artificial delays to the data. It was observed in a

qualitative manner how the users perceive the usability of the app. The testing platform will

also be referred to as Instapod, as it mimics a data pod-based version of Instagram.

As most currently popular social media platforms (e.g. Facebook, Instagram, Reddit, Twit-

ter) use some form of feed as their main feature, the feed was deemed representative for a

generic social media app, and results can thus be generalized. The feeds shown during the tests

have been populated with data from Reddit, and are a combination of pictures with captions,

15

comments and replies to those comments. The user can interact with Instapod to change the

topic of the feed, load more posts and comments, and like posts or comments. In the testing

environment users cannot create their own posts nor add comments to existing posts. Figure 5.1

shows a comparison of the feed used in Instapod with existing social media feeds. The technical

implementation of the testing platform is described in subsection 5.2.1, while 5.2.2 goes in depth

about the scenarios considered during the user tests. Finally, the organization of the user tests

is detailed in subsection 5.2.3.

(a) Instapod

(b) Reddit (c) Facebook

(d) Instagram (e) Twitter

Figure 5.1: A comparison of the Instapod feed with currently popular social media feeds.

16

5.2.1 Testing Platform

The testing platform consists primarily of a ReactJS1 front-end, responsible for the user interface

and user interaction. The test controller, responsible for selecting and executing the correct

scenarios, is also a part of the front-end. All data resides in a single LowDB2 database and is

served through a NodeJS3 server.

Although the testing application uses only a single server, the use of data pods can be

simulated. First of all, the structure of the data is adapted to resemble the data as if it were

stored on data pods. To achieve this, all data created by one person is stored in the same place

(i.e. this person’s data pod). All other information related to this data created by other users,

such as comments on this user’s post, should only be available as links to other user’s pods. A

schematic representation is shown in Figure 5.2

Figure 5.2: Schematic representation of the data pod structure assumed in the testing applica-

tion.

As a second mechanism to simulate data pod-like behaviour, all responses with data from

the server are artificially delayed to mimic varying load times. For each configuration used in

the tests, a corresponding JSON file was made that links the users and their pods to a delay

value, matching the desired configuration. To ensure reproducibility, these delays are generated

1https://reactjs.org/2https://github.com/typicode/lowdb3https://nodejs.org/

17

once and reused during subsequent user tests. When a certain piece of data (e.g. a specific

post) is requested by the front-end, the server sends back both the requested data and the delay

value corresponding to the data pod of the author of this data. This delay is then executed in

the front-end, by setting a timeout on the state update. The choice to execute the delay in the

front-end is made to avoid throttling the server, which can only process a limited amount of

requests at the same time.

Data Pod Assumptions

During the implementation of the testing platform, certain assumptions were made with regard

to the storage of the data and the latency of the data pods. First of all, it was assumed that

the application provides a certain amount of topic pods, which contain a list of URLs to posts

related to this certain topic, as pictured in Figure 5.2. This allows us to easily set up a feed,

without needing to go into the details of querying sets of data pods.

Secondly, all links in the entire comment tree are assumed to be stored on the data pod of

the author of the post. This implies that the link to the post will always need to be fetched

first before any links to comments become known. Accordingly, it is impossible for a comment

to be displayed before the post to which it replies. Replies however can be loaded and displayed

before their parent comments, as their locations become known at the same time (i.e. when the

post is retrieved). Lastly, we assume that a pod’s delay stays constant over time.

Implementation of UX strategies

The UX strategies used during the user tests were explained theoretically in section 3.2. As

the exact implementation of the user interface possibly influences the outcomes of the tests, all

relevant implementation decisions made regarding these aforementioned strategies are presented

in the following paragraphs.

Placeholders With the placeholder strategy, the skeleton of the page is built immediately.

Every non-loaded post is replaced by the placeholder shown in Figure 5.3a until it loads. This

placeholder is the same for each post, regardless of the actual dimensions of the image or the

amount of comments on the post, as this information is not known before the post is fetched.

It is thus probable that the actual post will take up more or less space in the feed than reserved

by its placeholder, which causes the feed to shift when a post loads. However, the position of

18

elements currently displayed on the screen are only affected by elements which are also (partly)

in view, not by posts higher or lower in the feed.

As soon as a post is loaded the placeholder is replaced by the actual content (i.e. username,

image and caption). At this point in time the comment structure is also known, and each com-

ment or subcomment can be represented by its own placeholder. As with the post placeholders,

the comment placeholders have a fixed height and width, regardless of the actual content.

To mimick the placeholders currently used by applications such as Facebook and YouTube,

a shimmer animation4 is added to the placeholder.

(a) Post

(b) Comment

Figure 5.3: Placeholder implementation

Spinners The major implementation choice for the spinner strategy is the choice of loading

indicators and the type of feedback messages accompanying them. The loading screen for the

posts consists of a spinner animation with chasing dots from React Spinkit5, under which the

percentage of posts loaded is displayed. While loading comments, a pulsating loading indicator

from the Reactstrap library6 is shown at the bottom of the comment section, alongside a feedback

message indicating how many comments have already loaded. Figure 5.4 shows an example of

both loading indicators.

4https://codepen.io/cusx/pen/jBjWyV5http://kyleamathews.github.io/react-spinkit/6https://reactstrap.github.io/components/spinners/

19

(a) Feed loading screen (b) Loading indicator for comments

Figure 5.4: Spinner implementation

In-Order As far as implementation decisions go, the main difference between the in-order

strategy and the previously discussed spinner strategy, is the fact that posts appear in the

feed one-by-one or in small groups while the user is watching instead of appearing all at once.

To accommodate this feature, loaded posts fade into the feed instead of simply popping up.

Otherwise, the two strategies are implemented in a very similar way and use the same loading

indicators, adapted only by omitting the feedback messages.

5.2.2 Scenarios

Apart from the implementation of the testing environment, the set-up of the experiment also

includes defining a set of testable scenarios. These scenarios are defined as a combination of a

delay configuration and a UX strategy.

To represent different categories of pods, we introduce the terms fast pods, delayed pods and

heavily delayed pods. A fast pod is assumed to have negligible delay, and has thus a delay value

of 0. We define delayed pods as pods having a delay up to 5 seconds, normally distributed around

3 seconds. To achieve this, we sample a delay d as min(ds, 5) with ds ∼ N (3, 1). Similarly, a

collection of heavily delayed pods is sampled from N (5, 2), with a cut-off at 8 seconds. Figure 5.5

shows the distribution of the delays, generated for a data set with 3217 distinct data pods. The

average values for delayed and heavily delayed pods are a rough estimate, as the aim is to

uncover the possible negative influences of varying delays, not to simulate a realistic data pod

network.

20

Figure 5.5: Histogram showing distributions for delayed (∼ N (3, 1)) and heavily delayed data

pods (∼ N (5, 2)), with N = 3217 data pods.

Based on these definitions of fast, delayed and heavily delayed pods, we define following

delay configurations to be used in the test scenarios:

• Firstly, we consider a delay configuration with only fast pods. This represents our non-

distributed version of the application, and will be used to establish a ground truth to which

the other scenarios are compared.

• Secondly, we add the scenarios with only delayed pods, and those with only heavily

delayed pods. These delay configurations will be used once for each UX strategy.

• It is plausible and likely that a realistic distribution of data pod delays will be a com-

bination of the previous configurations. To account for this possibility, the fourth

delay configuration has 50% fast pods and 50% delayed pods, and the fifth is made up by

20% fast pods, 50% delayed pods and 30% heavily delayed pods. These configurations are

also combined with each UX strategy.

• Hypothesis 3 requires a last scenario to be added to the set. For the placeholder scenario,

an additional scenario with 80% fast pods, 10% delayed pods and 10% heavily delayed

pods is constructed.

An overview of all scenarios is presented in Table 5.1.

21

# UX Strategy delay configuration

0 placeholders 0% fast

1 placeholders 80% fast

10% delayed

10% heavily delayed

2 placeholders 50% fast

50% delayed

3 placeholders 20% fast

50% delayed

30% heavily delayed

4 placeholders 100% delayed

5 placeholders 100% heavily delayed

6 spinners 50% fast

50% delayed

7 spinners 20% fast

50% delayed

30% heavily delayed

8 spinners 100% delayed

9 spinners 100% heavily delayed

10 in-order 50% fast

50% delayed

11 in-order 20% fast

50% delayed

30% heavily delayed

12 in-order 100% delayed

13 in-order 100% heavily delayed

Table 5.1: Overview of all scenarios used during user testing

22

5.2.3 User Tests

Before the test starts the user has to fill out a questionnaire about their background, which can

be used to provide context for the results. Questions are asked about gender, age, social media

use, online privacy, patience and technological background. The full questionnaire is shown in

Figure 5.6.

The test itself consists of the test person judging a set of scenarios. The non-delayed scenario

is always shown first to give the users the opportunity to become familiar with the application.

The order of the other scenarios from Table 5.1 is randomized. Two randomly picked scenarios

from this set are added to the end of the list, to verify the consistency of the user’s answers.

Each user tester is thus judging 16 scenarios, which takes between 15 and 45 minutes depending

on the test person.

During every scenario the user is asked to select a topic and find and like at least one post

they like and one comment they agree with in the feed. Afterwards the user can choose to end

this scenario and is then asked to assess how quickly the page loaded, whether or not this was

acceptable for them, and to what degree they enjoyed using the app, as shown in Figure 5.7.

Comments given during the test are recorded.

5.3 Results

The results of the qualitative user tests are presented in this section. Firstly, the performance

of each UX strategy is discussed individually. Secondly, the performance of the UX strategies

is compared for each delay configuration. Afterwards the results are discussed and an improved

strategy is derived.

5.3.1 Performance of UX Strategies

While the main aim of the user testing is to gather in-depth feedback on the app’s usability, the

users were also asked to judge the acceptability of the initial delay and their satisfaction while

using the app on a 5-step scale. The average outcomes for each scenario are listed in Table 5.2

and represented visually in Figure 5.8. A more complete overview of this data, showing the

distribution of answers, can be found in Appendix A.

This section summarizes the feedback given during the tests, linking it to the acceptability

and satisfaction results. The index of scenarios used refer to the indices used in Table 5.1.

23

Figure 5.6: Questionnaire with background questions to be filled out by the test person before

starting the test.

24

Figure 5.7: Questions to be answered by the test person after interacting with a scenario.

placeholders spinners in-order

Data pod delay distribution acc sat acc sat acc sat

100% fast 5 4.75

80% fast, 10% delayed, 10% heavily delayed 4.42 4.32

50% fast, 50% delayed 4.37 4.11 3.78 3.89 4.11 3.67

20% fast, 50% delayed, 30% heavily delayed 3.63 3.47 3.21 3.63 3.40 3.65

100% delayed 3.74 3.63 3.74 4.00 3.32 3.63

100% heavily delayed 3.37 3.53 3.05 3.63 2.89 3.58

Table 5.2: Average acceptability [of initial delay] (acc) and satisfaction [during use] (sat) for

all scenarios. The numeric values correspond to textual answers in the following manner: 1 -

Not at all, 2 - No, 3 - Unsure, 4 - Yes, 5 - Very much. Only scenarios with an average score

of 4 or higher on both criteria are on average seen as usable by all user testers. The maximal

acceptability and satisfaction for each scenario is shown in bold.

25

(a) Average acceptability of initial delay

(b) Average satisfaction during use

Figure 5.8: Chart showing the average acceptability of initial delay and satisfaction during use

for all scenarios. The numeric values on the y-axis correspond to textual answers in the following

manner: 1 - Not at all, 2 - No, 3 - Unsure, 4 - Yes, 5 - Very much. Only scenarios with an

average score of 4 or higher on both criteria are on average seen as usable by all user testers.

26

Placeholders

The reactions of users to the placeholder strategy depends heavily on the distribution of the pod

delays. In case of scenario 1, where only 20% of the data pods are moderately or heavily delayed,

85% of users reported the speed of the application to be fast or instant, while all users stated

they (very much) enjoyed using the app. On average both the acceptability and satisfaction are

over 4 out of 5, which indicates that the application is perceived as sufficiently usable. These

results prove hypothesis 3. Users almost always scrolled past the small number of posts or

comments that did not load immediately. Only when a user had judged the post and comment

section as sufficiently interesting they would wait for the remaining comments to load.

For a higher percentage of delayed pods, such as in scenario 2 and 3, the users were more

divided. For scenario 2, where half of the data pods have a negligible delay, the speed and

satisfaction were on average still between acceptable and very acceptable. However, users began

to comment on their annoyance with seeing the posts and comments loaded in seemingly random

order. This annoyance was strengthened considerably in the third scenario, where 35% of users

reported not enjoying using the application, or not being sure about it.

Because all pods are moderately or heavily delayed in scenario 4 and 5, no information is

available during the first few seconds. Giving the users the possibility to scroll through the

empty feed is detrimental for the perceived usability, as most users will scroll back and forth

looking for a post that is not there yet. Building the comment sections is also highly confusing

and irritating in these scenarios. Users vocalized that filling up the placeholders one by one in

seemingly random order makes it difficult to keep track of the interdependence of comments.

For all delay configurations, users also noticed that the placeholders for images and comments

did not have the same dimensions as the actual image or comment. They reported scrolling

through the app as feeling jumpy and stuttering, especially for a large amount of heavily delayed

pods.

Spinners

Users seem to be divided into two groups, based on how they react to the presence of explicit

feedback messages. The first group consists of the people who appreciate the explicit progress

indication present in this strategy and feel calmed knowing approximately how long it will take

to load the feed or comment section. The second group has the opposite reaction. They feel

that the progress indicator only attracts their attention to the act of waiting, and makes them

27

nervous and less patient. It was further found that reacting positively to the feedback messages

and the user reporting themselves as being patient with technology is positively correlated with

r equal to 0.23.

Because the total waiting time in these scenarios is equal to the delay of the slowest pod in

the batch, the results between scenarios 6 and 8 and scenarios 7 and 9 would not be expected

to differ much. This assumption is confirmed by our test results. In 6 and 7 however, almost

all users remarked that the behaviour of the loading percentage was unexpected as it started

immediately at 30% or 50% due to that amount of fast pods. This is a side effect of the

implementation of the testing platform.

It is important to note that the spinner strategy as it was implemented here did not reach an

adequate performance for any scenario, and hypothesis 2 was thus disproved. The initial delay

was on average rated between unsure and acceptable, which would not be sufficient for a social

media app used on a daily basis. Multiple users commented that they would be more patient if

they were actively looking for something on the app, but this is usually not the case with social

media [23]. However, all users reported a high satisfaction while using the app after the initial

load, and even preferred the longer waiting time at the start to multiple shorter waiting times

during use.

As a last observation, batching the comments seems unnecessary to most users, and is also

mentioned as an annoyance. Some users reasoned that it seemed like bad UX design to display

a message stating that x out of 10 comments have loaded, but not display any of them.

In-order

The results for the scenarios using the in-order strategy were very inconsistent. This was ex-

pected, as the perceived delay depends entirely on the delay of the first post in the feed. A

method for significant improvement would be to order the feed according to delay of the pod

instead of chronologically. This would guarantee a faster and smoother user experience, at the

cost of loss of chronology. When questioned about this proposition, the general consensus was

that chronology is not that important in social media feeds, as long as the unseen posts are

shown before the others. Relaxing the chronological order in comment sections was a more

polarizing topic, but most users reported that it would be acceptable as long as they can still

easily determine which comments reply to each other.

28

Users who liked the progress indicators in the spinner scenarios usually disliked the in-order

scenarios, due to the lack of indicator and unpredictable waiting times. Additionally, users

disliked that they would sometimes need to pause mid-scroll to wait for the next post.

5.3.2 UX strategy comparison per delay configuration

For all delay configurations the placeholder strategy receives the highest score for acceptability

of the initial waiting time, as shown in bold in Table 5.2. These results are as expected. Either

the user starts scrolling through the feed immediately until the first loaded post is encountered.

In this case the waiting time will be equal to the delay of the fastest post in the batch. If the

user instead waits at the top of the feed until the first post appears, the waiting time will be

equal to the delay of the pod containing the first post on the feed. For the spinner and in-order

strategy this waiting time is equal to respectively the delay of the slowest pod in the batch,

and the delay of the pod containing the first post. Hence the initial delay for placeholders will

always be the shortest, and the results confirm that it also feels the fastest.

However, the satisfaction scores show that placeholders lack in other aspects. As long as

the percentage of fast pods in the network is higher than 50%, the test results show that

users are satisfied to very satisfied with the app. Users can quickly start reading posts and

comments, while the annoyance of having a part of the posts and comments still loading and

popping up is kept to a minimum. When the amount of fast pods drops to 20% or lower, the

satisfaction decreases significantly for the placeholder strategy, while the scores for spinners and

in-order remain almost constant. As mentioned in section 5.3.1, the lack of chronology and

stuttering completion of the feed and comment sections are the main causes for this decrease in

satisfaction. Neither of these issues are present in the other two strategies. This also explains

why the satisfaction scores for the spinner and in-order strategy vary significantly less than for

placeholders.

An overview of the results showing the distribution of the answers grouped by delay config-

uration can be found in Appendix B.

29

Chapter 6

Discussion

The experiment focused mainly on identifying the causes of a decrease in perceived usability.

Although users displayed highly varying preferences, three main negative influences can be

extracted from the feedback.

1. Inconsistency in waiting times

2. Inconsistency in lay-out

3. Multiple periods of waiting for the app to load, interrupted scrolling

If these negative influences are rephrased to focus on what an average user expects from a UX

strategy, the following statements are obtained.

1. The appearance of consistency in waiting times

2. Consistency in lay-out

3. Preference for waiting once at the start, scrolling should go smoothly

Based on these requirements, three possible improvements are proposed in the following para-

graphs.

Derived hybrid strategy From the results of the user tests an improved UX strategy can be

derived, based on the needs which users reported or implied. One aspect all users agreed upon is

the need for consistency in waiting times. Because of the intrinsic properties of distributed data

sources this consistency cannot be guaranteed in itself. However, the app can behave in certain

ways to give the appearance of consistency. The proposed strategy would have a short fixed

30

waiting time at the start of every load, while showing a progress bar or other loading indicator.

It would be advised to not use the progress indicator used in this thesis, as it would only be

suitable for half of your target audience. Network analysis should be done to determine the fixed

waiting time to ensure that at least 50% of pods can respond within this time period. Afterward

the feed is displayed with placeholders for the remaining posts and comments, effectively making

every possible scenario resemble scenario 1 or 2, which were the only scenarios that guaranteed

an acceptable user experience for all users. This guarantees the shortest possible waiting time

while providing a proper UX, without needing to change the order of the feed. The proposed

strategy was neither implemented nor tested within this thesis.

Relaxing the order of the feed In the usual social media feed, posts and comments are

either ordered chronologically, or ordered based on a certain measurement of popularity (likes,

amount of comments, . . . ). For certain content, e.g. a timeline of news events, this ordering is

essential and cannot be relaxed without undermining the usability. However, for a feed filled

with pictures of your friends’ daily life, this order is not tremendously important. As long as

unseen posts are shown before the others and the comment tree structure is preserved, posts

and comments can be reordered without being really noticeable to the users. For these cases it

would be an option to have a greedy UX strategy, in which the posts and comments residing

on the fastest pods are shown highest on the feed or comment section. While there is no doubt

that this would result in a smoother UX, developers should be mindful of the possible social

implications this kind of strategy would have. It would create a social imbalance based on the

quality of your data pod and network connectivity, where the fortunate are getting favoured by

the app itself.

Additional feedback messages If a pod has a delay which is noticeably larger than the

delays of surrounding pods, users might consistently scroll past the corresponding post or com-

ment that loads slowly. During the experiment, users often made an informed decision to wait or

scroll past loading comments based on whether the already loaded part of the comment section

was interesting or not. When questioned, users also noted that they would feel incentivised to

wait longer if they knew the identity of the author of the slow post or comment, especially if that

author turns out to be a close friend or someone famous. While the identity of the author might

not be known immediately, the URL of their data pod is and might already give an indication.

31

Chapter 7

Conclusions

Variable load times have negative effects on the subjective usability of a social media feed. When

using distributed data sources in the design of modern Web applications, the quality of the user

experience can be improved by firstly giving the appearance of consistency in waiting times,

and secondly by providing consistency in lay-out of the user interface. For up to 50% noticeably

delayed pods, a placeholder strategy can guarantee a sufficiently high perceived usability. For

a higher percentage of delayed pods, a hybrid strategy combining spinners with placeholders

could provide a solution. In defining the UX strategy, a trade-off has to be made between the

app feeling fast (content showing up on arrival) and the UX feeling intuitive (content shown at

once or progressively from top to bottom).

If the type of content shown in the feed is suitable for it, developers can decide to exchange

the sorted order of the content in the feed for increased speed and usability by reordering posts

and comments on speed of the pod they reside on instead of creation time or popularity.

32

Chapter 8

Future Work

The research presented in this thesis was a first exploratory study of the UX of distributed

social media applications, focusing on the effects of varying load times. Based on the results of

qualitative user tests, a strategy was hypothesized to minimize the negative effect of distributed

data sources on the user experience. Implementation and validation of this strategy, described

in chapter 6, is left to future researchers.

Secondly, the testing environment was limited to read-only interactions. The UX implications

of adding new posts and comments to the platform have not been investigated yet.

A third aspect which needs to be researched is the effect of having unreachable pods or

deleted data. This was also mentioned by developers as a possible negative influence on the user

experience. It can already be hypothesized that not handling these issues would turn out to be

detrimental to the UX. However, deleted data can presumably be handled in the same way as

in centralized Web applications. For example, Reddit replaces deleted comments by “[deleted]”,

and leaves the remaining comment tree intact. Facebook on the other hand removes the entire

comment tree from the users’ view.

33

Appendix A

User test results grouped by UX

strategy

In order to get further insight in the test results of the experiment presented in chapter 5, a

condensed visualization of the data can be found in figures A.1, A.2, A.3 and A.4. In each chart,

the rows aggregate the answers to the questions “Is the initial delay acceptable for you?” and

“Did you enjoy using the app once something loaded?”

Figure A.1: Bubble chart of the test results for the base case scenario. X marks the average

within each row.

34

Figure A.2: Bubble charts for placeholder scenarios. X marks the average.

35

Figure A.3: Bubble charts for spinner scenarios. X marks the average.

36

Figure A.4: Bubble charts for in-order scenarios. X marks the average.

37

Appendix B

User test results grouped by delay

configuration

Similar to the charts in Appendix A, the distribution of the results from chapter 5 is visualized

in figures B.1, B.2, B.3 and B.4. Each figure groups the chart by delay configuration. In each

chart, the rows aggregate the answers to the questions “Is the initial delay acceptable for you?”

and “Did you enjoy using the app once something loaded?”

38

Figure B.1: Bubble charts for the scenarios with 50% fast pods and 50% delayed pods. X marks

the average.

39

Figure B.2: Bubble charts for the scenarios with 20% fast pods, 50% delayed pods and 30%

heavily delayed pods. X marks the average.

40

Figure B.3: Bubble charts for the scenarios with 100% delayed pods. X marks the average.

41

Figure B.4: Bubble charts for the scenarios with 100% heavily delayed pods. X marks the

average.

42

Figure B.5: Bubble charts for 100% and 80% fast pods with placeholder strategy. X marks the

average.

43

Bibliography

[1] Statista, “Number of social media users worldwide from 2010 to 2021 (in billions),” 2019.

[Online]. Available: https://www.statista.com/statistics/278414/number-of-worldwide-

social-network-users/

[2] W. Danielson, “Building skeleton screens with css custom properties,” 2017. [Online].

Available: https://mcanousdesign.com/web-development/building-skeleton-screens-with-

css-custom-properties/

[3] W. Staff, “How cambridge analytica sparked the great privacy awakening,” WIRED, Mar

2019. [Online]. Available: https://www.wired.com/story/cambridge-analytica-facebook-

privacy-awakening

[4] H. Kozlowska, “The cambridge analytica scandal affected 87 million people, facebook

says,” Quartz, Apr 2018. [Online]. Available: https://qz.com/1245049/the-cambridge-

analytica-scandal-affected-87-million-people-facebook-says

[5] H. Davies, “Ted cruz campaign using firm that harvested data on mil-

lions of unwitting facebook users,” the Guardian, Dec 2015. [Online]. Avail-

able: https://www.theguardian.com/us-news/2015/dec/11/senator-ted-cruz-president-

campaign-facebook-user-data

[6] Wikipedia, “List of mergers and acquisitions by Facebook - Wikipedia,” 2019. [Online].

Available: https://en.wikipedia.org/wiki/List-of-mergers-and-acquisitions-by-Facebook

[7] [Online]. Available: https://support.google.com/plus/answer/9195133?hl=en

[8] T. Berners-Lee, J. Hendler, and O. Lassila, “The Semantic Web A new form of Web

content that is meaningful to computers will unleash a revolution of new possibilities,”

44

IEEE Intelligent Systems, vol. 21, no. 3, pp. 96–101, may 2001. [Online]. Available:

http://www.nature.com/doifinder/10.1038/scientificamerican0501-34

[9] Fediverse, “Fediverse, diversity is strength,” 2019. [Online]. Available:

https://fediverse.party/en/fediverse/

[10] Diaspora*, “Welcome to diaspora*. the online social world where you are in control.”

2019. [Online]. Available: https://diasporafoundation.org

[11] A. Bleicher, “The anti-Facebook,” IEEE Spectrum, vol. 48, no. 6, pp. 54–82, jun 2011.

[Online]. Available: http://ieeexplore.ieee.org/document/5779793/

[12] DiasporaFoundation.org, “Diaspora* means a brighter fu-

ture for all of us,” 2011. [Online]. Available:

https://web.archive.org/web/20111002003516/http://blog.diasporafoundation.org/2011/09/21/diasp

means-a-brighter-future-for-all-of-us.html

[13] A. Bielenberg, L. Helm, A. Gentilucci, D. Stefanescu, and H. Zhang, “The

growth of Diaspora - A decentralized online social network in the wild,” in

Proceedings - IEEE INFOCOM. IEEE, mar 2012, pp. 13–18. [Online]. Available:

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

[14] S. Schulz and T. Strufe, “D2 Deleting Diaspora: Practical attacks for profile discovery and

deletion,” in IEEE International Conference on Communications. IEEE, jun 2013, pp.

2042–2046. [Online]. Available: http://ieeexplore.ieee.org/document/6654826/

[15] R. Ozawa, “Mastodon, the twitter alternative, surpasses 2 million users,” 2019. [Online].

Available: https://www.techspotting.com/2019/02/23/mastodon-the-twitter-alternative-

surpasses-2-million-users/

[16] J. Kenny, “Usercountbot,” 2019. [Online]. Available: https://mastodon.social/@usercount

[17] T. S. Project, “What is solid?” 2017. [Online]. Available: https://solid.mit.edu/

[18] “General questions and clarifications on app development - Develop-

ing on Solid / App Development - Solid Community Forum.” [Online].

Available: https://forum.solidproject.org/t/general-questions-and-clarifications-on-app-

development/201/7

45

[19] “General questions and clarifications on app development - Developing on

Solid / App Development - Solid Community Forum.” [Online]. Avail-

able: https://forum.solidproject.org/t/business-opportunities-using-solid-pod-servers-

without-using-advertising/1301/11

[20] L. Wroblewski, “Mobile design details: Avoid the spinner,” 2013. [Online]. Available:

https://www.lukew.com/ff/entry.asp?1797

[21] B. Chung, “Everything you need to know about skeleton screens,” 2018. [Online]. Available:

https://uxdesign.cc/what-you-should-know-about-skeleton-screens-a820c45a571a

[22] R. Morey, “What is perceived performance and why you need to optimize it,” 2018.

[Online]. Available: https://wp-rocket.me/blog/perceived-performance-need-optimize/

[23] J. Mander and F. McGrath, “Gwi social: Globalwebindexs quarterly report on the latest

trends in social networking - q1 2017.” GWI Social. London: Global Web Index., 2017.