A Web-Based Application for the Display of Geolocated Tweets on a Map

Home , EllisLab

UNIVERSITY OF FRIBOURG Pervasive & Artiﬁcial Intelligence Research Group

LTMap A web-based application for the display of geolocated Tweets on a map

MASTER THESIS

Aron Martinez

Student number: 06-208-771 Address: Via Ravecchia 11b, CH-6512 Giubiasco Email: [email protected]

Head: Prof. Beat Hirsbrunner Supervisor: Apostolos Malatras

Giubiasco, March 24, 2013

Swiss Joint Master of Science in Computer Science

Acknowledgements

First of all, I would like to thank Apostolos Malatras for his support, guidance and good advice, and also for all the valuable feedback he provided me. I would also like to thank Prof. Beat Hirsbrunner for giving me the chance to be part of the PAI group for the duration of my master thesis. It has been a great pleasure to collaborate with the PAI research group and to meet all its very kind members during the project meetings and presentations. Finally I want to thank my family and friends for their moral support, and last but not least, I want to thank my wife Lucile for having always believed in me, and for her invaluable support and her continuous encouragement during the writing of the thesis.

iii Abstract

Abstract

Today, diﬀerent services oﬀer geolocated information based on social networks, but in most cases this information is available only for some major cities around the world, for only one social network at a time and without focusing on the actual personal interests of the user. The purpose of this master thesis is to create a web-based application that uses open- source APIs to access localization services and social network information and displays the retrieved information on a map, based on the user’s location. One of the main focuses of the application is usability, therefore the display of information needs to be user-friendly by using a clear and simple design on one hand, and functions simplifying the display (like, for example automatic localization of the user’s actual position) on the other hand. To simplify the portability and future enhancements of the application, it will be integrated into a Drupal 7 module, respecting the standards for Drupal module development.

Keywords

Usability, Geolocation, Google Maps, Social networks, Twitter, Facebook, Drupal

iv Contents

Contents

1 Introduction 1 1.1 Outline ...... 1

2 State of the Art 3 2.1 Introduction ...... 3 2.2 Social Networks ...... 4 2.2.1 Twitter ...... 4 2.2.1.1 Overview ...... 4 2.2.1.2 APIs ...... 5 2.2.2 Facebook ...... 6 2.2.2.1 Overview ...... 6 2.2.2.2 APIs ...... 6 2.2.3 Summary ...... 6 2.3 Geolocation ...... 7 2.3.1 HTML5 ...... 7 2.3.2 IP Geolocation ...... 8 2.3.3 Summary ...... 8 2.4 Maps ...... 9 2.4.1 Google Maps ...... 9 2.4.2 Yahoo Maps ...... 9 2.4.3 Nokia Maps ...... 9 2.4.4 Other map providers ...... 10 2.4.5 Summary ...... 10 2.5 CMS ...... 10 2.5.1 Drupal ...... 11 2.5.2 ExpressionEngine ...... 13 2.5.3 Comparison ...... 15 2.5.3.1 Price ...... 15 2.5.3.2 Usability ...... 15 2.5.3.3 Add-ons ...... 15 2.5.3.4 Final Choice ...... 16 2.6 Related Work ...... 16 2.6.1 Trendsmap ...... 16 2.6.2 Tweography ...... 18 2.6.3 GeoChirp ...... 18 2.6.4 A World of Tweets ...... 19

v Contents

2.7 Summary and Analysis ...... 20

3 Concept 22 3.1 Introduction ...... 22 3.2 Requirements Analysis ...... 22 3.2.1 Geolocation ...... 22 3.2.2 Map ...... 23 3.2.3 Tweets ...... 23 3.2.4 Layout ...... 23 3.3 SWOT Analysis ...... 23 3.4 Components ...... 24 3.4.1 CMS ...... 24 3.4.2 LTMap Module ...... 24 3.4.3 Twitter Plug-In ...... 26 3.5 Technologies ...... 26 3.5.1 PHP ...... 26 3.5.2 CSS ...... 26 3.5.3 JavaScript ...... 27 3.5.4 SQL ...... 27 3.6 Used software ...... 27

4 Implementation of LTMap 29 4.1 Introduction ...... 29 4.2 Architecture of LTMap ...... 29 4.3 LTMap Module ...... 30 4.3.1 Conﬁguration Page ...... 31 4.3.2 Fetching new Tweets ...... 32 4.3.3 Storing new Tweets ...... 32 4.3.4 Displaying all Tweets ...... 32 4.4 JavaScript Functions ...... 32 4.4.1 Map Display ...... 33 4.4.2 Geolocation ...... 33 4.4.3 Tweet Radius ...... 33 4.4.4 Tweet Display ...... 34 4.4.5 Map Update ...... 34 4.4.6 Other functions ...... 34

5 Operation instructions 35 5.1 Introduction ...... 35 5.2 Installation ...... 35 5.3 LTMap User Interface ...... 36 5.3.1 The Map ...... 36 5.3.2 Infos ...... 38 5.3.3 Actions ...... 39

vi Contents

5.3.4 Items ...... 40

6 Evaluation 41 6.1 Introduction ...... 41 6.2 Functional Evaluation ...... 41 6.2.1 Eﬃciency ...... 41 6.2.2 Functionality ...... 42 6.2.3 Maintainability ...... 43 6.2.4 Portability ...... 43 6.2.5 Reliability ...... 44 6.2.6 Usability ...... 44 6.3 Functional Comparison ...... 44 6.3.1 Trendsmap ...... 45 6.3.2 GeoChirp ...... 47 6.3.3 A World of Tweets ...... 49 6.3.4 Summary ...... 50 6.4 User Study ...... 50 6.4.1 Metrics ...... 51 6.4.1.1 Typology ...... 51 6.4.1.2 Participants ...... 51 6.4.1.3 Variables ...... 51 6.4.2 Scenario ...... 52 6.4.2.1 Use of LTMap ...... 52 6.4.2.2 Installation of LTMap ...... 54

7 Conclusion 56 7.1 Summary ...... 56 7.2 Limitations ...... 56 7.3 Future Work ...... 57 7.4 Final Thoughts ...... 57

vii List of Figures

List of Figures

2.1 Basic Structure ...... 4 2.2 Nokia Maps satellite view ...... 10 2.3 Drupal Architecture [Buy12e] ...... 12 2.4 ExpressionEngine Architecture [Ell12c] ...... 14 2.5 Trendsmap - Topics on the map ...... 16 2.6 Trendsmap - Additional features ...... 17 2.7 Tweography ...... 18 2.8 Geochirp ...... 19 2.9 A World of Tweets ...... 20

3.1 Allowing geolocation in Google Chrome ...... 22

4.1 Architecture of LTMap ...... 29

5.1 Activation of the LTMap module ...... 36 5.2 Conﬁguration of the LTMap module ...... 37 5.3 UI of LTMap ...... 38 5.4 Example of Tweet infowindow ...... 39 5.5 Example of address autocomplete suggestion ...... 39 5.6 Example of search query ...... 40

viii List of Tables

List of Tables

3.1 SWOT analysis of LTMap ...... 24 3.2 Metadata contained in the .info ﬁle ...... 25 3.3 Database ﬁelds and corresponding data types created by ltmap.install . . 25

6.1 Load times of LTMap ...... 42 6.2 Load times of Trendsmap ...... 45 6.3 Load times of GeoChirp ...... 47 6.4 Load times of A World of Tweets ...... 49

ix List of Tables

List of Acronyms

AJAX ...... Asynchronous JavaScript And XML API ...... Application Programming Interface ASQ ...... After Scenario Questionnaire CMS ...... Content Management System CSS ...... Cascading Style Sheets cURL ...... client URL FQL ...... Facebook Query Language FTP ...... File Transfer Protocol GPS ...... Global Positioning System GUI ...... Graphical User Interface HTML ...... HyperText Markup Language HTTP ...... HyperText Transfer Protocol IP ...... Internet Protocol ISP ...... Internet Service Provider JSON ...... JavaScript Object Notation LTMap ...... Local Twitter Map PHP ...... PHP Hypertext Preprocessor SQL ...... Structured Query Language SWOT ...... Strengths, Weaknesses, Opportunities and Threaths VPN ...... Virtual Private Network W3C ...... World Wide Web Consortium XML ...... eXtensible Markup Language

x 1 Introduction

1 Introduction

Geolocation is gaining increasing importance for many features related to web development. Some of the areas where geolocation is used are: advertising (displaying ad- vertisements that are related to the actual position of the visitor), language detection (displaying a website automatically in the visitor’s language), currency detection (displaying prices of an e-commerce site automatically in the visitor’s currency) and automatic redirection (redirecting the visitor to the website in his country). By behaving like this, websites are not attempting to violate the privacy of visitors, but simply trying to display content that is relevant to the visitors [TDC12]. Social networks are also getting increasing popularity today, and most of them offer geolocation features which allow the users to geo-tag their posts, status updates or Tweets. Even though social networks offer geolocation features to their users, it is not always very easy and intuitive to read such information, because not every item in the list of a user will be geo-tagged, and also because a single item tagged in a given location will probably not have much meaning for a user. Having the possibility to display many geo-tagged items would be more efficient: for example by letting a user display all geo-tagged items near his actual position in order to dicover what is happening around him. To allow for an immediate understanding and analysis, this information is ideally displayed on a map, in order to make the location of the single social network items (posts, staus updates, Tweets, etc.) more clear and intuitive. Currently, different services offer localized information based on social networks (see for example [Sta12a], [Cue13a] and [OP12]), but in most cases this information is still limited to a single social network and some applications are not very intuitive to use in their current form. In this Master thesis, the concept of a map displaying geolocated Tweets, with an according prototype, Local Twitter Map (LTMap), has been created and will be presented. LTMap uses Google Maps and the Twitter search API to display golocated Tweets around the user’s actual position on a map. It focuses on innovative features, easy extendability, usability and simplicity and attempts to optimize the caracteristics of some existing systems which will be analysed throughout the thesis.

1.1 Outline

This thesis is structured as follows: in chapter 2, the state of the art will be analysed. An overview of the existing social networks, geolocation technologies, map services and

1 1.1 Outline

Content Management Systems (CMS) will be given and some examples of similar existing applications will be analyzed. In chapter 3, the concept behind LTMap will be explained. After a look at the Strengths, Weaknesses, Opportunities and Threaths (SWOT) analysis carried out for the project, the components of LTMap will be explained, togeteher with its architecture and the involved technologies and used software. In chapter 4, the way LTMap was implemented will be explained in detail. After an overview of the architecture of LTMap, the LTMap module, with its diﬀerent functions, and the JavaScript functions needed for LTMap will be presented. Chapter 5 represents an operation manual for LTMap. First of all, the installation of the LTMap module will be explained, and then the diﬀerent features of the user interface will be explained. In chapter 6, an evaluation of LTMap will be carried out. First of all a functional evaluation of the main characteristics of LTMap will be done, then, a functional comparison with other systems will be carried out, and in the end, a user study plan will be presented. Finally, in chapter 7, a conclusion will be given, with an overview of the obtained results and a proposal of future enhancements.

2 2 State of the Art

2 State of the Art

2.1 Introduction

This chapter gives an overview of the aspects that build the foundations of displaying localized social media information with today’s technologies. There exist different ways to display data from social networks. A very popular form are lists (as it is the display chosen by most social networks, like for example [Twi12b], [Fac12a] and [Goo12a]), but also other displays are used, like maps (see for example [Sta12a] and [ZM12]). These alternative display methods are getting more and more popular. Each display method has its interesting features and also its limits, but this depends mainly on one’s personal needs, requirements and desires. In most cases (see for example [Sta12a], [Cue13a] and [OP12]) the display of social media is done one social network at a time, due to the different protocols and data of each network, which make an interaction between multiple networks quite difficult. Displaying social media on a map, like it will be done in the prototype related to this thesis, is a relatively new kind of application, and few systems offering such type of display exist today (like [Sta12a], [Cue13a] and [OP12]). The reason for this is that displaying social media on a map is complex and implies many different questions and choices: which area needs to be displayed, how many items to display, how to localize the visitor correctly, where to display the data on the map, what data to display, how to refresh the displayed data while the user is moving along the map, etc. Each choice from the above list implies a cascade of other choices: if, for example, you choose to display hundreds, or even thousands of tweets, you will not be able to display them on a small area of the map; or if you want to display lots of details about each single post (picture, location, date, title, text, etc.), you will not be able to display lots of items at once, due to the limited space available. Additionally, an application fetching data from social networks needs to adapt to the rules and limitations of the respective Application Programming Interfaces (APIs), like for example the maximum number of possible requests of Twitter APIs [Twi12d]. There are three main components needed for the localized display of social media (as depicted in figure 2.1): one or more social networks, a geolocation algorithm and a map on which to display the fetched data. There would be a fourth main component in this list, namely the users posting and viewing the data, but it is beyond the scope of this thesis to do a psychological analysis of the users’ behavior, so we will skip them and focus only on the technical aspects implied. In the following sections, we will look at these main components necessary for the localized display of social media, namely the main social networks (with their protocols,

3 2.2 Social Networks

Figure 2.1: Basic Structure

available fields, limitations, etc.), the existing geolocation techniques (with the difficulties related to them), the available map interfaces and, last but not least, the CMS into which the application will be integrated. After this, we will look at some examples of applications displaying social media on a map, and try to analyze their pros and cons in order to take inspiration from existing systems. For each example of application, an analysis will be made about which features could come in handy, which aspects could be improved and which ones should be ignored in the prototype of LTMap. Finally we will sum up the findings in a brief conclusion.

2.2 Social Networks

The main social networks from which data is fetched are Twitter and Facebook, this because on one hand, they have well working APIs for reading the data (see [Twi12c] and [Fac12b]), and on the other hand, because they already provide their users with a geo-tagging feature that allows them to add a location to their posts. This feature greatly facilitates the localized display of data.

2.2.1 Twitter 2.2.1.1 Overview Twitter is an online social network (or better, it is “one of the largest microblog services” available today [IET12]) that allows its users to post short messages limited to a length

4 2.2.1 Twitter of 140 characters, which can be read by all other Twitter users [HRW08]. These short messages are commonly called Tweets [IET12]. Tweets can have diﬀerent structures: actual messages by the user writing, messages forwarded from other users (called Retweets and indicated by “RT” in the concerned message), messages containing user identiﬁers (“@” followed by the user name) that are directed to these users, messages containing hashtags (“#” followed by a word) and also a mix of the above [KLPM10]. Tweets usually contain metadata, which represents additional information like the author, the time and date at which a message was posted and, if available, also the location at which the message was posted [LSdV+11]. People can follow other Twitter users in order to receive all Tweets that are posted by these users [KLPM10]. Each time a user you are following posts a new Tweet, this will be added to your timeline, together with the Tweets of all other people you are following. Each time another user follows you, it will be added to your list of Followers. On the other hand, each time you follow another user, it will be added to your list of Followings.

2.2.1.2 APIs Twitter offers different APIs that reflect different ways to access its data. These APIs are [Twi12c]:

• Search API: this API allows to run anonymous searches inside an index of recent Tweets, which includes between six and nine days of Tweets; the search focuses on relevance and not on completeness, which means that only the most relevant Tweets are fetched and therefore “some Tweets and users may be missing from search results”; the results can be limited to a given location by using the geocode parameter, and limited to a given area around the location by using the radius parameter [Twi12g]. • REST API: the REST API is the most complete API provided by Twitter, as it contains many different methods divided in the categories “Timelines”, “Tweets”, “Search”, “Streaming”, “Direct Messages”, “Friends & Followers”, “Users”, “Sug- gested Users”, “Favorites”, “Lists”, “Accounts”, “Notification”, “Saved Searches”, “Places & Geo”, “Trends”, “Blocks”, “Spam Reporting”, “OAuth”, “Help”, “Le- gal” and “Deprecated” (the methods inside this category are, as the name suggests, deprecated); inside these categories, there are GET and/or POST methods to retrieve and publish data [Twi12e]. • Streaming APIs: this set of APIs provides access to public streams (the “public data flowing through Twitter”), user streams (the “data corresponding with a single user’s view of Twitter”) and site streams (a “multi-user version of user streams”) [Twi12f].

The choice of the corresponding API depends strongly on the type of application that needs to be created, each API (or set of APIs) having its strengths and weak points for

5 2.2.2 Facebook given aspects (limit of queries, need of user authentication, etc.).

2.2.2 Facebook 2.2.2.1 Overview Facebook originated in 2004 as an online social network exclusively available to college students [GWH07]. Only in 2006 it became publicly available and started its huge spread [HP10], to become the most important social network available today, with over 950 million active users [SEC12]. Facebook allows its users to publish different types of data: status updates in text form (mostly short messages in the style of “I’m going to the mall” or “Working hard on that big project”) or containing a photo/video (in addition to an optional text message), life events (salient moments of one’s life, like a new job, a marriage, etc.) and places (the place where one is in that moment, togheter with a text message) [Fac12a]. Unlike Twitter, there are no one-way relationships in Facebook, in order to add some- one as a friend and see his data, one needs to wait for a confirmation of the friend request. If the other person has a public Facebook profile, his data will be publicly available and therefore one can freely visit his profile, but to create a real link with another person (and therefore add it to your list of friends) the friend request must be mutual [Fac12a].

2.2.2.2 APIs Facebook provides three distinct ways to access its data [Fac12b]: • Graph API: this API allows to access the social graph, which is Facebook’s core and contains information about people, photos, events, pages and everything connected to them [Fac12d]. • Facebook Query Language (FQL): this is not really an API itself, but can be used through the Graph API (see above) to run queries in the style of Structured Query Language (SQL); it allows to access some advanced features that the Graph API does not provide (e.g. “batching multiple queries into a single call”) [Fac12c]. • REST API: this API will be deprecated and is listed here only for completeness, it allows the user to interact programmatically with Facebook through HyperText Transfer Protocol (HTTP) requests [Fac12e]. As with Twitter, the choice of the corresponding API depends on the needs of the application to be developed: FQL can be used if more advanced features are needed (or if the developer prefers the SQL-like request style), while the Graph API can be used for all other situations.

2.2.3 Summary Although we have seen “only” the two major social networks existing today (many more could have been taken into consideration), only one was used for LTMap, namely Twitter.

6 2.3 Geolocation

The reason for this limitation is that for the ﬁrst prototype of LTMap, the purpose was to focus on only one social network in order to lay down a very solid foundation for future improvements and additions. The choice of Twitter is mainly due to the fact that Tweets are more easily interpretable, as they have a limited length and focus mainly on text content.

2.3 Geolocation

In order to display data coming from the user’s position (or at least from the user’s surroundings), the application must be able to localize the user’s position. This is done through geolocation algorithms that can determine the user’s position in diﬀerent ways [Kaa03]:

• Reading the data from a Global Positioning System (GPS) module: this is the most precise way, but requires that the user’s PC or mobile phone is equipped with a GPS module. • Analyzing the cellphone towers (triangulation) or wireless access points in the surroundings: this may not always be very precise, due to the possible distance between the user and the cellphone towers or access points. • Reading the user’s Internet Protocol (IP) address: this may not always be very precise (especially if the user is connected to a Visrtual Private Network (VPN) or accesses the internet through a proxy server). • Through a form in which the user physically enters its position: this position is then transformed into its actual coordinates through a separate service.

Most of the APIs available today provide automatic fallback mechanisms in order to try to get the most accurate position by GPS ﬁrst, then by falling back to cellphone tower triangulation or WiFi network and IP address reading and ﬁnally, in some cases, by providing the user with a form for inserting his address. No API available will give a warranty that the exact position of the user is returned. The attempt is always to get the position of the user within a radius of N meters (which will depend on the API and on the available technology, i.e. GPS, WLAN, IP address, etc.). In the following sections we will look at some of the main providers of geolocation APIs.

2.3.1 HTML5 One of the most diﬀused geolocation APIs available today is the Geolocation API provided by the World Wide Web Consortium (W3C) and making use of HTML5 [W3C12]. The API provides access to many diﬀerent sources providing location information: “GPS and location inferred from network signals such as IP address, RFID, WiFi and Bluetooth MAC addresses, and GSM/CDMA cell IDs, as well as user input”.

7 2.3.2 IP Geolocation

It allows to make single (or “one-shot”) position requests and also to track position through repeated updates [W3C12]. Being part of the W3C Recommendation ensures high compatibility and stability of the API.

2.3.2 IP Geolocation There are many IP geolocation services available today, but most of them are paid services (see for example [Max12c]). There are also free alternatives available, but often they are outdated, limited or distributed only as binary ﬁles. Some examples of free IP geolocation services are:

• MaxMind GeoLite [Max12d] (which provides also paid IP databases [Max12a], paid web services [Max12c] and a paid JavaScript API [Max12b]), giving access to downloadable IP databases updated once per month and distributed under a Creative Commons Attribution-ShareAlike 3.0 Unported License [Cre]. • freegeoip.net, which provides both a free web service [Fio11b] and a JavaScript API [Fio11a], but has a quite old database (last updated in April, 2011). • hostip.info, which provides an API returning geocoded IP addresses in the three formats HyperText Markup Language (HTML), eXtensible Markup Language (XML) and JavaScript Object Notation (JSON) [hos12b] and also downloadable IP databases [hos12a]. • ipinfodb.com, which provides IP location APIs in XML format [ipi12b] and JSON format [ipi12a].

All of the above provide diﬀerent results and accuracy, due to the age of the updates and the available granularity level (city, state or country), but none of them is satisfactory, because at most they will be able to provide the location of your actual Internet Service Provider (ISP), which is not always located near the user. IP geolocation services can be a good solution for general purposes (like, for example, automatically detecting the user’s language, or showing a country speciﬁc version of a website) but they can only be used as a fallback mechanism, and not as a standalone service, for geolocated display of information on a map.

2.3.3 Summary For the geolocation features of LTMap, it has been chosen to use HTML5 geolocation, as it allows for a more accurate positioning of the user than IP geolocation techniques. This was necessary in order to provide accurate data to the visitors and avoid to display data coming from the region of the user’s ISP (which would be completely useless to the user).

8 2.4 Maps

2.4 Maps

The display of interactive maps is very popular today, and there exist many different providers that offer APIs for displaying maps and objects (markers, lines, polygons, etc.) on them. In this section we will cite some of the major map API providers and describe their main features. The comparison of the different map services will be based on [SW12]. This section will give only an overview of the existing services, for a more in-depth analysis and comparison, please refer to the original paper [SW12].

2.4.1 Google Maps Google Maps was published in 2005 and was the ﬁrst free Web mapping service [SW12]. Today Google Maps is still the most important and complete free mapping service provider available (based on a comparison of the features described in [SW12]). The main features of Google Maps are [Goo12b]:

• Interaction: it offers various different, and well working, interaction possibilities (keyboard shortcuts, mouse pointer, mouse wheel, etc.). • Technologies: it offers different popular technologies to display, and interact with, the map interface (JavaScript, Ajax, iFrame, JSON, XML, etc.). • Extra features: it offers a large number of interesting extra features, like directions, public transport integration, walking directions, live traffic information, etc.

Google Maps offers a very complete and comprehensive JavaScript API, offering many methods to create maps and interact with them (by creating overlays, changing map types, using services like geocoding, etc.) [Goo12e]. Google offers also other APIs, like for example a simpler image API, a more complete business version of the Google Maps API, and specific APIs for Google Earth and Google Places [Goo12c].

2.4.2 Yahoo Maps Yahoo Maps is another big mapping service and map API provider. It has quite the same features as Google Maps, but it is slightly more limited: it oﬀers less zoom levels, less extra features and is also less intuitive to use [Yah12a]. The main problem with Yahoo Maps is that its APIs where discontinued in September 13, 2011. By visiting the corresponding website you ﬁnd a note recommending to use Nokia’s Ovi Maps API [Yah12b].

2.4.3 Nokia Maps Nokia Maps [Nok12] is more recent than the two previous mapping services. As we have seen above (see chapter 2.4.2), it replaced Yahoo Maps in September, 2011 [Yah12b].

9 2.4.4 Other map providers

Even if Nokia Maps is one of today’s well-known mapping services and map API providers, it does still give the impression of a development version for the moment, as it provides unsatisfying map data/images (especially for what concerns satellite images, see for example ﬁgure 2.2) and more limited features than Google Maps [Nok12].

Figure 2.2: Nokia Maps satellite view

2.4.4 Other map providers There are other mapping service and map API providers, like Bing Maps [Mic11] or MapQuest [Map12], but they have still some drawbacks (mainly the lack of satellite data), similarly to Nokia Maps. Another well known example is OpenStreetMap [Ope12b], but it is even more limited than the others (the streets displayed on the map are not always correct and up to date, there are no satellite images, etc.). The diﬀerence between OpenStreetMap and the providers cited above is that its maps are created and improved directly by the users and freely distributed under an open license [Ope12b].

2.4.5 Summary In order to provide an optimal user experience and the best features and map material available (at least for free), it has been chosen to use Google Maps as mapping service for LTMap. This results from the feature-richness and accuracy of Google Maps with respect to its main concurrents.

2.5 CMS

In order to facilitate and improve some aspects of the prototype, it has been chosen to integrate the ﬁnal application into a CMS. The main reasons for this are that a CMS already provides the main basic security features, a modular (and therefore easily

10 2.5.1 Drupal extendable) plugin/module system and also an easy content management mechanism [AH08]. Today, the most well-known free CMSs are Drupal [Buy09c], WordPress [Wor12] and Joomla [Ope12a]. These three CMSs offer different features and fit for different types of applications: WordPress is often used as a blogging platform, Drupal as a platform for informative sites and Joomla fits best for intranet sites [PRP11]. Of these three alternatives, only Drupal has been retained as a possible candidate for the development of LTMap, this because it is the fastest one [PRP11], and also the one that best fits the needs of LTMap. Additionally, the author has previous experience with the installation, setup and development of Drupal, which is of a great help with the development of LTMap. In addition to these free CMSs, there is also a commercial (but still open source) alternative, namely ExpressionEngine [Ell12a]. ExpressionEngine costs up to 299$ and also most of its add-ons have a price, but it is very stable, easy to use and extend and offers a very good support (one of the main advantages of commercial products). Still another option would have been to create a CMS from scratch, as it was done in a previous work by the author [Mar10]. But instead, it resulted preferrable to use an existing CMS solution. This choice has been made in order to use the modular structure (plugins/modules) of an existing CMS solution and to increase the security and stability of the final prototype. Additionally, in the previous work by the author it turned out to be too time consuming to create a CMS from scratch, even a very simple one like the one created for eGlossar [Mar10]. Instead of a CMS, a single page displaying the map and integrating all the logic for geolocation and display of the social network data could have been used. A CMS solution was preferred in order to rely on the existing security features, an existing content management mechanism and mainly a well established and working plug-in structure to use for easy future extensions of LTMap. In the next sections, Drupal and ExpressionEngine (the two CMS solutions retained as main candidates for the prototype of this thesis) will be presented and analyzed. After this, a comparison and summary will be proposed.

2.5.1 Drupal Drupal is a very popular open-source CMS offering a wide range of possibilities for adapting the design and the features through the use of many themes and plug-ins [Buy09c]. Drupal is written in the PHP Hypertext Preprocessor (PHP) language and uses SQL as a database language, Cascading Style Sheets (CSS) for theming and JavaScript for interactive and asynchronous features. Drupal works on different levels (or tiers), as you can see in figure 2.3: first of all there is the data level, where the data of the page is stored; then comes the module level, where Drupal’s modules can access the site’s data and carry out special functions; after that comes the blocks level, where blocks are displayed (these can contain data from the modules, from a menu or directly from the user); on top of the block level is

11 2.5.1 Drupal the level concerned with user permissions, which controls which data can be displayed for which user; last but not least comes the most important level, namely the templates level, where the whole layout of the site is generated by Drupal’s templates.

Figure 2.3: Drupal Architecture [Buy12e]

In this section we will look at the main characteristics and features of Drupal, by trying to analyze their pros and cons. Please note that the parts where no citations are provided are based on previous personal experience of the author. First of all, Drupal is open-source, and the same applies to most of its themes and modules. This means that you can get the CMS and its components for free and make changes to the source code as it pleases you. This ﬁrst point is a big advantage, because it means that you do not need to spend any money for the CMS, and you can adapt its source code to your needs. On the other hand, since Drupal is developed and maintained by a huge community (more than 630,000 users and developers), and since the support is provided by a volunteer community, it can be quite diﬃcult to get reliable support, because every support request is done on public forums and therefore is not always answered in an acceptable time lapse [Buy09c]1. Another important feature of Drupal is its very large number of modules (more than 17,000 available modules in total [Buy09a]) and themes (more than 1400 themes available

1Please note that only the basic information is taken from [Buy09c], the more critical part is based on previous personal experience.

12 2.5.2 ExpressionEngine in total [Buy09b]). This very large repository can be useful, because usually it is quite easy to find a module or theme that fits your needs, but the big number does also mean that for each search you do, you will find 5, 10, or even more results, which need to be installed and tested to see if they effectively correspond to your needs. This can be time consuming and stressing, since most of the results you find will not correspond to your needs or will need some fine tuning (either to adapt even better to your needs, or simply because the module/theme contains some bugs that need to be fixed). For what concerns usability, Drupal is quite easy to use. Once you installed it successfully, it will appear with some very basic content and a quite simple administrative menu on top. This could already be sufficient for most users, but as a developer with some experience and given needs, you will first want to improve Drupal’s features with some additional modules. For the design part, you can use existing themes and adapt them to your needs, but if you need to accomplish given special layouts or outputs (e.g. a different layout for each page in your CMS), it can get quite tricky to get the desired result.

2.5.2 ExpressionEngine As we did with Drupal, we will describe the main features of ExpressionEngine and analyze their pros and cons. As before, the parts where no citations are provided are based on previous personal experience of the author. The main architecture of ExpressionEngine is very similar to the one of Drupal: it uses PHP, SQL, CSS and JavaScript as its main components. The difference comes in the way it works (see also figure 2.4): the data (or information) layer is inside so-called channels (basically a grouping of fields for a given content, like for example “Title”, “Text”, “Images”, etc.); these channels are then read inside ExpressionEngine’s templates through the use of tags (which are very similar to XML tags and can output channel data or data from modules/plugins); these templates (which contain the HTML layout of the respective pages) can be grouped into template groups (a sort of folder) according to one’s needs and are displayed on the site. In contrast to Drupal, ExpressionEngine is a commercial CMS and therefore has a cost (of 99-299 $, depending on the license you choose [Ell12b]) associated with it, but it is “built on an Open Source foundation” and therefore still allows full access to its codebase [Ell12a]. With this combination, ExpressionEngine offers the “best of both worlds”, by providing commercial advantages (e.g. quick answers to customers, worldclass technical support and a reliable development and support team) on one hand, and the advantages of an open source foundation (through the use, as its core, of CodeIgniter, a very popular, fast, lightweight and open source PHP framework) on the other hand [Ell12a]. This combination makes ExpressionEngine a very powerful CMS solution for bigger projects, as one gets a very good commercial support and also the ability of adapting the core to one’s needs. ExpressionEngine is very complete: as soon as one has finished installing it, you get access to lots of interesting modules and plug-ins that you would need to install

13 2.5.2 ExpressionEngine

Figure 2.4: ExpressionEngine Architecture [Ell12c]

additionally in other CMS solutions. These include security features, user management, blog features, e-mailing/communication features, and many more [Ell12b]. This allows you to have a very complete system from the beginning, which covers most needs. For those core features that are not needed, there is the possibility to deactivate or uninstall the corresponding modules or plug-ins, so that they do not unnecessarily slow down the system. Another interesting feature of ExpressionEngine is that everything can be managed online, from the admin interface, without having to connect to a File Transfer Protocol (FTP) server. It is still possible to access configuration files or templates directly on the FTP server, but it is not strictly necessary as with other CMS solutions. This allows for a great flexibility as you are free to access everything from a web browser, without needing any other software or access rights. One of the disadvantages of ExpressionEngine is that after having finished installing it, you are provided with no content (if you choose the default layout, and not the example theme provided with the basic installation). This means that when you access the site after having installed ExpressionEngine, you will be provided with a blank page. On the other hand, it is very easy to add new pages: basically, you can simply copy and paste the HTML code from an existing, static site (or from HTML templates) and simply make the desired parts dynamic by adding the contents, menus, etc. For more special features, you need to install add-ons (modules, plug-ins or extensions), like with other CMSs. There is only a limited number of available add-ons (approximatively 1700), which means that you are not granted that you will find an add-on that fits your needs exactly, but on the other hand, if you find one, you can be quite sure that it will be of good quality (although it will eventally be commercial).

14 2.5.3 Comparison

2.5.3 Comparison In this section we will compare the two CMSs described above, in order to ﬁnd an ideal candidate.

2.5.3.1 Price As we have seen, Drupal has no costs related with it, as it is free (and so are all its modules), while ExpressionEngine has a quite important cost connected with it, as you need to purchase a license for the CMS and eventual additional licenses for the add-ons you may need. Even if the cost for a working install of ExpressionEngine may seem important, it has been proved, by previous personal experience of the author, to be quickly amortized by a quicker overall development of the working website.

2.5.3.2 Usability On the administrative side, both CMSs descibed above are quite usable, but in order to make Drupal really usable, you need to perform some changes and add some modules, while with ExpressionEngine you have already everything you need from the beginning, right after the install. The main features of ExpressionEngine that increase the usability for administrators are: • Admin menu: the menu allows already to access all respective sub-items (and not only the main items, as with the basic Drupal install). • Completely separed admin interface: the admin interface of ExpressionEngine is clearly separed from the public site, this means that you have no admin menu or editing icons breaking up your layout when you visit the public site while connected as an administrator. • Easy template integration: you can simply copy and paste your HTML code into a new template, without having to take care of special CMS elements as in Drupal. • Completeness: ExpressionEngine comes with many pre-installed features that you would need to manually add in Drupal, these include, for example, functions for easily communicating with other site members, access rights and automatic noti- ﬁcations based on given events.

2.5.3.3 Add-ons Drupal has much more modules than ExpressionEngine has add-ons, but as we have seen, this does not necessarily need to be an advantage, as for each module you search, you will ﬁnd lots of diﬀerent possibilities, which do not always work as desired. ExpressionEngine, on the other hand, has only few available add-ons, but most of them are of good quality. The disadvantage is that the add-ons of very good quality are commercial and therefore a license needs to be purchased.

15 2.6 Related Work

2.5.3.4 Final Choice Although from the previous sections it should clearly appear that the author prefers the use of ExpressionEngine over the use of Drupal, the CMS used to develop LTMap is Drupal. The reason for this is that LTMap aims to be compatible with the existing website of the University of Fribourg. Since Drupal has been used for the existing website, LTMap will be developed using Drupal, too, in order to be able to integrate it easily and make it work properly on the website of the university. Please note that the use of Drupal is in no way a negative point (even if this may appear from the above sections). Drupal is a very good platform for the development of LTMap: it is free and open source, it oﬀers lots of existing modules from which one can take a very good inspiration, and it allows for an easy integration into the university infrastructure.

2.6 Related Work

In this section we will look at some examples of existing applications displaying data fetched from social networks on a map.

2.6.1 Trendsmap Trendsmap is “a real-time mapping of Twitter trends across the world” [Sta12a]. It tracks the most important words and topics on Twitter and displays them on a map (see ﬁgure 2.5), by regularly updating the display as words become more or less popular [Sta12b].

Figure 2.5: Trendsmap - Topics on the map

Trendsmap was programmed in Ruby [Rub12] and uses the JQuery JavaScript framework [The12]. The topics are fetched from the Twitter API [Twi12c] and are displayed on a map using Google Maps [Goo12e]. It is one of the most promising applications displaying data from Twitter on a map, and it oﬀers many interesting features, which we will describe now.

16 2.6.1 Trendsmap

First of all, Trendsmap is lightweight and hence loads very fast. When you visit the homepage [Sta12a] you are already presented with the map (and if the localization feature is enabled in your browser, it will already be centered on your location, city or region). Depending on your location and on the corresponding number of topics to display, after some seconds you are provided with the topics displayed according to their importance (larger and darker topics indicate stronger trends [Sta12b]). Trendsmap offers automatic localization features, allowing you to localize your exact location, your city or your region. Additionally, it offers some overviews on the homepage (below the map, see figure 2.6), displaying actual trends (globally, by country and by region) and also the globally trending users [Sta12a].

Figure 2.6: Trendsmap - Additional features

By clicking on a topic in the “Breaking Globally list”, you will be presented with a map showing all locations where the given topic appears. The same happens when clicking on a user in the “Globally Trending Users” list, with the difference that you are provided with the locations where that user has published Tweets. You have even the possibility to display all locations where Tweets are available [Sta12c]. Trendsmap does also have some drawbacks. The first main problem with the map is that the topics are not always displayed in their exact position, because there may be many topics from a given location (and therefore there is a cloud around a given location) [Sta12b]. This is not a fault of the application itself, but more a physical limit of the map space available. To overcome this problem, a different display of the topics would be needed, which would probably not be as intuitive as the display chosen by the developers of Trendsmap. Additionally, the topics may not be visible at first, because they are shown based on their importance (and topics of a minor importance appear only starting from a given zoom level), which means that if you look at Switzerland, for example, you will see no topics on the map, but if you zoom in to its major cities, like Zurich, you start to see some topics that appear. This, too, is not a problem of the application itself, but depends on the limited space available on the map display: if everything would be shown from the beginning, the map would become overloaded and the topics would be very hard to distinguish. Nevertheless, Trendsmap stays one of the fastest and most complete applications around today. It runs very well and has many interesting features, with only some minor drawbacks concerning usability and not really depending on the application itself.

17 2.6.2 Tweography

2.6.2 Tweography Another interesting application for displaying Tweets on a map is Tweography [OP12]. The particularity of Tweography is that it does not display all geotagged Tweets around you, but only your personal geotagged Tweets [She09]. This allows a single user to keep track of his geotagged Tweets, even if “only” 200 at a time. In order to access your Tweets, Tweography uses Twitter OAuth to authenticate you. The OAuth authentication protocol “allows users to approve application to act on their behalf without sharing their password” [Twi11a]. The problem with Tweography is that it is facing some difficulties and the message “Twitter API is suffering from epic failulitis. Refresh and hope for the best?” does always appear above an empty map (see figure 2.7).

Figure 2.7: Tweography

Another sad aspect of Tweography is that it is far from being well documented. All you get is a footer with two links to Twitter proﬁles, but there is no documentation at all. Because of this, the information above is either taken from external sources, or directly deduced from the behaviour of the application.

2.6.3 GeoChirp Geochirp [Cue13a] is another very promising application, although it is slightly diﬀerent from the other applications, considering that it does not display Tweets on a map. In Geochirp you are provided with a map, but it is not used to display Tweets on it, but to choose a given location around which you want to display Tweets. Once you have chosen a location, you can set a search radius in miles and the number of Tweets to display per page, and you are provided with an according list of Tweets in the speciﬁed search area. The bigger the search radius, and the more varied the found

18 2.6.4 A World of Tweets

Tweets will be. By increasing the number of Tweets to display, you can have a better overview of the Tweets posted inside your search radius. On the right side, you are provided with the most influent people (or “Tweple”, as Geochirp calls them) in the area you specified (see figure 2.8).

Figure 2.8: Geochirp

In addition to these features, Geochirp provides the user with the possibility to trans- late the Tweets that are displayed and to interact directly with each single Tweet, by replying to it, retweeting it or adding its author to one’s list of following. Additionally, the user can get more informations about a given author by clicking on his nickname, this will open a popup window displaying a description, the location, the number of updates, the number of followers/following, and some other data about the author. All the basic functions (which are already very promising) are accessible without logging in, but if a user does login to Geochirp (with OAuth, the same protocol already described for Tweography, see chapter 2.6.2), he is provided with even more features, like the possibility to save his searches, create and manage people groups and add people to these groups.

2.6.4 A World of Tweets A World of Tweets [ZM12] displays where people are tweeting around the world. The display happens anonymously (no Tweet data, whether the text nor the author of the Tweet, is displayed), the focus is only on the actual position of the Tweet. From the location data, A World of Tweets generates a heatmap (or, if desired, a “Smoky Clouds” map) updated in real time as new Tweets are posted in a given location. As the number of Tweets in a given location grows, the location gets “hotter” or, in other words, more red (see image 2.9).

19 2.7 Summary and Analysis

Figure 2.9: A World of Tweets

There are diﬀerent options to choose from for the display of the data: you can switch between a heatmap and a “Smoky Clouds” view, between a map and satellite view, you can hide the map or the heatmap, you can display labels which show you the country of the posted Tweets, you can clear the heatmap and you can even get a 3D stereo view (by wearing 3D red cyan glasses). In addition to the map view, A World of Tweets displays also diﬀerent statistics, like real time tweeting stats, tweeting stats of the current day, tweeting stats from the launch of the application on 1st November 2010, the number of countries where Tweets have been posted, the total number of Tweets processed, the top 20 countries, etc. A World of Tweets uses Twitter’s Streaming API (with occasional aid of Yahoo Place- maker [Yah12c]) to fetch geolocated Tweets and display them on a static map using HTML5 (or Flash if the browser should not support HTML5). Although not displaying actual Tweet data (texts, authors, details, etc.), A World of Tweets is very interesting because it allows to get a very intuitive overview of where the most Tweets are posted, focusing only on the location and ignoring other details about the Tweets.

2.7 Summary and Analysis

In this section we will sum up the findings from the descriptions of the single components described above, and define which component fits best for the use in our prototype and why this is so. We will also take into consideration the strengths and weaknesses of the examples that we have seen. For what concerns the social networks, in this thesis (and for the related prototype), we will focus first of all on Twitter. Additional social networks can be added at the end (subject to time limitations) or in future improvements, thanks to the modular structure of the application which allows easy improvements. The reason for this limit is that with this thesis we want to build the solid foundations

20 2.7 Summary and Analysis for an application displaying data coming from social networks on a map, therefore the main focus will be on the underlying technology for displaying data on a map, and Twit- ter will be used as a ﬁrst “example” social network due to the fact that Tweets already contain information about their location, which helps with the geolocation feature of the application. For the geolocation features of the application, the application will make use of the HTML5 Geolocation API, as it provides more accurate results. The IP geolocation techniques would ensure a higher cross-browser compatibility, but it is preferrable to use them as a fallback mechanism on browsers that do not support HTML5, and provide accurate positions on browsers that support HTML5. The display of the map will be achieved through the Google Maps API, because it is the most complete and accurate maps API availbale today. It provides both a complete set of API methods on the developer side, and a very good and accurate display of the map on the user side. With other map APIs it would be hard to achieve the same results, as we have seen before (see chapter 2.4). The CMS on which the application will run would have been ExpressionEngine as a ﬁrst choice, because of the advantages seen in chapter 2.5, but in order to maintain an optimal compatibility with the rest of the IT infrastructure of the University, Drupal has been chosen as the best solution.

21 3 Concept

3 Concept

3.1 Introduction

In this chapter, we will provide an insight into the diﬀerent aspects that have been taken into consideration for supporting the development of LTMap. After a short introduction outlining the requirements analysis and considering the SWOT analysis, we will look at the general structure of LTMap and the components and technologies used to develop it.

3.2 Requirements Analysis

In this section an overview of the main features of LTMap will be given.

3.2.1 Geolocation Although being a hidden feature running in the background, geolocation is the first feature a visitor encounters on LTMap. Geolocation needed to be as easy and intuitive as possible, but still very accurate. This was made possible through the use of HTML5: it is very simple, as (for privacy reasons) it just needs a confirmation by the user the first time he visits the website (see image 3.1), after that the geolocation of the user is entirely automatic, and it is also very accurate, as it can access different data about the user (GPS position in case a GPS module is available, or else network position and/or IP address of the user).

Figure 3.1: Allowing geolocation in Google Chrome

In case the automatic geolocation described above does not work, an error message is displayed and a text-ﬁeld for manual input of the user’s address is activated. The address entered is then converted to a location using the Google Maps API, and the map is refreshed, showing the corresponding location.

22 3.2.2 Map

3.2.2 Map The map is the foundation of LTMap, as it is needed to display the Tweets on it. The map used for LTMap needed to be very intuitive, but still feature-rich and detailed enough to display also precise addresses with a good resolution. The best available choice for this was Google Maps, because it is very popular (and therefore well known by most users), intuitive and also very feature rich if compared to other mapping services (see chapter 2.4).

3.2.3 Tweets The Tweets to display on the map needed ﬁrst of all to have location information in order to be displayed in an accurate manner. A possible fallback mechanism for non- geolocated Tweets could have been to use the location provided by the Tweet’s author in his proﬁle, but this choice would not have been ideal, due to the fact that large amounts of Tweets would have been located in one single point (due to the fact that many Tweets are not geolocated). Additionally, the Tweets needed to be as many as possible, in order to be able to display Tweets for every region that may be displayed on the map. Since Twitter limits the number of requests that can be done on its APIs, the only way to display many Tweets was to store them in a database and load them on the map. Each time a visitor reaches the website, a request is done to the Twitter API in order to fetch the latest Tweets and then these are stored in the database and displayed together with the previous Tweets already stored before.

3.2.4 Layout The layout of LTMap was the last, but not least, point to take into consideration during development: on one hand the focus was on the features of LTMap, therefore the design was only considered in a later moment, but on the other hand LTMap needed to be both appealing and usable, therefore the design needed to be studied with care.

3.3 SWOT Analysis

Before the start of the development of LTMap, a SWOT analysis was carried out to determine and preview the strengths, weaknesses, opportunities and threaths of an application displaying localized Tweets on a map. This analysis is shown in table 3.1 and should not need any further explanations.

23 3.4 Components

Low costs Intuitive to use Automatic position detection Strengths Easy to improve and expand Automatic recovery of content Multiple possible data sources Easy future addition of other data sources Not many available examples Learning of involved technologies Weaknesses Need to respect given plugin structure for future additions Dependance on external services Big spread through Open Source license Opportunities Adaptation for use in other applications Users not understanding purpose of the system Threats Browser incompatibility Privacy of users

Table 3.1: SWOT analysis of LTMap 3.4 Components

3.4.1 CMS Although the CMS is only a minor part of this project, it is the cornerstone on which the LTMap module relies and it is also used to display informative pages describing the project and documentation pages trying to help the user if he should need support. The choice to add informative pages has been made because some of the existing examples (see chapter 2.6) consist only of a single page containing the application itself, but lack of any additional information or documentation. The purpose of LTMap, in contrast, is to be well documented and easily understandable for everyone.

3.4.2 LTMap Module The core of the LTMap application is the LTMap module, a Drupal module responsible for displaying the map (using Google Maps), fetching the user’s location (using HTML5 geolocation) and displaying data from a given set of social networks (determined by the corresponding installed plugins). Although the module supports only Twitter for the moment, it is able to integrate with additional social networks in the future. The LTMap module was built from scratch following the instructions on the Drupal website [Hun12]. It consists of the following files: • ltmap.info - contains all metadata about the project (see also table 3.2). • ltmap.install - creates the base structure needed when installing the module (this includes database tables and the corresponding fields and data types, see also table 3.3). • ltmap.module - the actual code executed by the module; • plugins/twitter.php - the custom functions needed to store and display Tweets. All the above files are located inside the module folder ltmap, inside the folder /sites/all/modules/, recommended by Drupal for custom modules [BDF+10].

24 3.4.2 LTMap Module

In table 3.2 you can find all possible metadata fields that may appear inside a .info file (optional fields are in italics).

name The name of the module, displayed on the Modules page description A one-line description telling administrators what the module does, displayed on the Modules page core The version of Drupal the module is for stylesheets CSS files to be loaded by the module scripts JavaScript files to be loaded by the module files External files the module uses (for class or interface decla- rations) dependencies Other modules that the module requires package The name of the package the module is part of php Minimum PHP version required by the module configure The path to the main configuration page for the module required Allows to make the module enabled by default hidden Allows to hide modules from the Modules page

Table 3.2: Metadata contained in the .info ﬁle

In table 3.3 you can find all database fields of the database table ltmap and the corresponding data types that are created by the ltmap.install file.

tid Primary identifier of the Tweet created_at Creation date of the Tweet from_user Author of the Tweet (nickname) from_user_id User ID of the Tweet’s author from_user_name Username of the Tweet’s author text Content of the Tweet source Source of the Tweet geo Geo data for the Tweet lat Latitude of the Tweet’s location lon Longitude of the Tweet’s location iso_language_code Language code of the Tweet profile_image_url Profile image URL of the Tweet’s author to_user_id User ID of the Tweet’s recipient

Table 3.3: Database ﬁelds and corresponding data types created by ltmap.install

Even if not all of the fields cited above are used by LTMap, the attempt was to store as much data as possible, in order to be prepared for eventual future adaptations of the application. The LTMap module first of all tries to fetch the actual position of the user by using HTML5 geolocation (see chapter 2.3.1), then it generates the map, centered on the user’s actual position, using the Google Maps JavaScript API (see chapter 2.4.1), to which the coordinates fetched by the geolocation are passed, and finally it displays the social network data read from the corresponding plug-in(s). The map displayed lets the user freely decide which type of map (satellite or map) and which zoom level he wants to display. The application does in no way limit the user from this point of view, it simply displays the Tweets inside the geographical area chosen by the user. The geolocation is intended to be as easy as possible and should happen nearly automatically (in the ideal case), the user only needs to confirm that the application can

25 3.4.3 Twitter Plug-In access its position information. If the automatic geolocation should fail, the user is provided with a field in which he can provide his address. For the display of the data from the social networks, the module gives the user the possibility to filter the displayed data according to a search filter, which will be described in more detail in chapter 5. We will not describe the source code of the LTMap module in detail, because the code is well documented and therefore no additional description should be needed.

3.4.3 Twitter Plug-In The Twitter plug-in is the first, and for the moment the main and only, plug-in for the LTMap module. Its purpose is to read the public stream provided by Twitter and format it correctly for the LTMap module to be able to display the data on the map. Please note that the use of “plug-in” is not related to the module structure of Drupal, it has been chosen as a name for the social network extensions which can be added (or “plugged in”) to the LTMap module to read the data from the corresponding social network. The plugin consists of a single file, twitter.php, located in the plugins folder inside of the module folder. The plugin does not display data directly, and the user has no direct interaction with it, it does “only” get the Tweet data from Twitter and sends it to the LTMap module. As with the module file, we will not describe the code of the Twitter plug-in, because the code is already well documented.

3.5 Technologies

In this chapter we will describe the main technologies used for the development of LTMap.

3.5.1 PHP The LTMap module, as well as Drupal itself, are programmed in PHP. PHP is a very rich scripting language allowing a very good and fluid interaction with SQL, therefore it fitted the needs of this project optimally. In addition, the author had already used PHP for different personal, university and work projects, which allowed to acquire a good background experience, being a great advantage for the development of this project.

3.5.2 CSS The layout of the application, and also of the CMS in general has been personalized through the use of CSS.

26 3.5.3 JavaScript

The common practice of using external CSS files was adopted, in order to have a cleaner overall structure and, more over all, to be able to use the same rules in all involved files, without needing to repeat them in each file. As with PHP, CSS was already used in many previous projects by the author, therefore a very good background knowledge was already available, which facilitated the design and development process.

3.5.3 JavaScript JavaScript was used mainly for the Google Maps part of the application, but it was used also for the filtering process and some additional features, like for example the display of the address field and the corresponding search button when the automatic geolocation does not work properly (due to missing permission in the user’s browser or communication problems). Additionally, JavaScript was used to do Asynchronous JavaScript And XML (AJAX) calls to external, Drupal related files. Where JavaScript was used for custom purposes, the framework jQuery [The12] was used to enhance and simplify the use of JavaScript through its built in functions for loops, recovery of HTML elements, calculations, etc. Like with CSS, the used functions are stored in external files, in order to reuse them in the whole project, without having to rewrite them in each single file. As with PHP and CSS, JavaScript and jQuery were already used for various projects by the author, so there was already a good background knowledge.

3.5.4 SQL The database used by the CMS and by the LTMap module is based on the database language SQL. SQL is a good choice for applications of this type, as it is quite fast (for smaller datasets like the ones used in this project) and still simple to use. As with the other techonologies used, the author had already good background knowl- egde of SQL, which simpliﬁed the development process. To enhance the working experience with the databases, Adminer [Vrá12] was preferred upon phpMyAdmin [php12] due to its optimal structure (a single, lightweight PHP ﬁle without the need of any installation) and its very intuitive and complete Graphical User Interface (GUI).

3.6 Used software

For the development of LTMap, and for the writing of this thesis, the following software was used:

• For editing the PHP, CSS and JavaScript ﬁles, Sublime Text 2 [Sub12] and Note- pad++ [Ho11] were used.

27 3.6 Used software

• To test the prototype of LTMap locally on the PC, XAMPP [Sei12] was used to install an Apache webserver and a MySQL server (additionally, the prototype was also tested directly on the hosting of the author). • This thesis was written in LATEX 2ε, with the support of [OPHS11]; for the writing of the thesis, LEd [DS09] was used; the bibliography was generated automatically using BibTeX [Fed06] and the list of acronyms was generated using the nomencl package [VS05]. • For the management of the used litarature, JabRef [Jab12] was used.

28 4 Implementation of LTMap

4 Implementation of LTMap

4.1 Introduction

This chapter allows the reader to look behind the curtains of LTMap, by explaining its implementation and how its single functions work exactly. Although this chapter is only an addition to the comments present in the sourcecode, which are already quite exhaustive, the implementation of LTMap will be described with as much details as possible, in order to allow the reader to better understand its features. Before explaining the implementation of the diﬀerent features of LTMap, its underlying architecture will be outlined in the next section.

4.2 Architecture of LTMap

In this section, we will describe the architecture of LTMap in some more details. You can see an overview of the architecture in ﬁgure 4.1.

Figure 4.1: Architecture of LTMap

The LTMap application is built with the components described in the previous chapter (see chapter 3.4), which are interconnected in the following way: the Drupal CMS is the

29 4.3 LTMap Module foundation of the application, into which the LTMap module and its social network plug-ins are integrated, the social network plug-ins receive data from the APIs of the corresponding social networks and store it in the database (DB), this data is then fetched by the LTMap module and diplayed on the corresponding map (using Google Maps for the map display and HTML5 geolocation to fetch the position of the user). Dashed arrows in ﬁgure 4.1 represent interactions with external services, while plain arrows represent internal interactions. Gray elements (additional social networks and their corresponding plug-ins) are not integrated into LTMap yet and will be implemented in future improvements. The Twitter plugin uses the following data extracted from the fetched Tweets:

• Author: the author of the Tweet. • Text: the actual text of the Tweet. • Date: the date at which the Tweet was posted. • Coordinates: the geographical coordinates of the Tweet.

The author, text and date are displayed on the map inside an infowindow for each Tweet, toghether with the date of the Tweet. The coordinates are used to display the Tweets in their corresponding position on the map. Tweets without geolocation data are ﬁltered out, as they would not allow to be placed on the map.

4.3 LTMap Module

The LTMap module uses the standard structure of a Drupal 7 module and accesses different hook functions of the Drupal core to execute the needed functionalities [Buy12d]. The diﬀerent functions have the following purposes:

• ltmap_help: displays a short help text on the module’s help page; • ltmap_enable: used when the module is enabled, to detect if the database schema, available in the ltmap.install file (see chapter 3.4.2), must be installed or not; • ltmap_menu: used to create the administrative menu item to configure the module; • ltmap_form: used to generate the configuration form for the module’s configuration page; • ltmap_cron: this function is called periodically, when a Drupal cron run happens [Buy12c]; it is used to retrieve new Tweets each time a user visits the homepage; • ltmap_block_info: used to declare the blocks used by the LTMap module and optional block configurations (see [Buy12a] for a complete list of available configurations);

30 4.3.1 Conﬁguration Page

• ltmap_block_view: returns the actual content of the block [Buy12b].

The following functions are located in the twitter.php plug-in and are needed to load and store Tweets:

• ltmap_save_tweets: custom function which goes through each new found Tweet and checks if it is already stored in the database, if not, it is added by calling ltmap_save_tweet; • ltmap_get_tweets: custom function used to fetch new Tweets in the JSON format via the PHP Client URL (cURL) library and convert them into PHP objects; • ltmap_save_tweet: custom function used to store a new Tweet in the database; • ltmap_load_tweets: custom function used to load all Tweets stored in the database.

In the next subsections, we will look in more detail at the module’s conﬁguration page and the process of fetching, storing and displaying the Tweets, and also at the functions executed to carry out these tasks.

4.3.1 Configuration Page The configuration page is generated through the two functions ltmap_menu (allowing to access the corresponding menu item under admin/config/content/ltmap) and ltmap_form (generating the configuration form). The function ltmap_menu places the configuration page of LTMap under “Configura- tion” » “Content authoring” » “LTMap” by defining the path admin/config/content/ ltmap. It also defines the title of the configuration page (“LTMap”) and gives a short description for the overview pages (admin/config and admin/config/content). For the page callback of the configuration page, the standard callback drupal_get_form is used. To access the configuration page, the privilege “access administration pages” is needed. The arguments are defined in the function ltmap_form, which contains three form fields:

• ltmap_cron_key: a textfield for storing the cron key of Drupal; • ltmap_gmap_key: a textfield for storing the Google Maps API key; • ltmap_max: a textfield for storing the maximum number of Tweets to display in the LTMap block (defaults to 100); • ltmap_twitter_app: a field of type “item”, which contains a link to the page for creating a new Twitter application.

31 4.3.2 Fetching new Tweets

4.3.2 Fetching new Tweets New Tweets are fetched each time a visitor interacts with the map (see chapter 4.4.5 for more details), by calling the cron function ltmap_cron. This function ﬁrst of all does a SQL query to determine the ID of the last stored Tweet, then it generates a Twitter search URL containing the location of the user, a search radius around his position, the desired number of results and the ID of the last Tweet (in order to assign it to the since_id parameter of the search string, used to avoid searching for Tweets already stored in the database). The URL generated above is then passed to the function ltmap_save_tweets (see chapter 4.3.3).

4.3.3 Storing new Tweets The function ltmap_save_tweets, which stores new Tweets in the database, uses the search string generated through ltmap_cron and passes it to the function ltmap_get_ tweets to recover the latest Tweets. The function ltmap_get_tweets then uses cURL to read the page with the results from the search string and converts the results into a PHP object, which is then returned to ltmap_save_tweets. For each Tweet found, ltmap_save_tweets checks if it is not a duplicate already existing in the database (as a double check to avoid duplicate content), and if it is a new one it is passed to the function ltmap_save_tweet. The function ltmap_save_tweet takes the data from each single Tweet and stores it in the database, provided that it contains geolocation data. If this should not be the case (and therefore the Tweet could not be displayed with a precise position on the map) the Tweet is discarded.

4.3.4 Displaying all Tweets The Tweets stored in the database are displayed using the function ltmap_load_tweets, which simply executes a SQL query to load the stored Tweets and return an array containing all of them.

4.4 JavaScript Functions

In order to make everything work properly, some helper functions in JavaScript have been added to the LTMap module, inside the ﬁle main.js. These functions initialize the map with the needed options, manage the geolocation and the alternative manual address ﬁeld, calculate the radius for the Tweets to display based on the visible portion of the map and manage the markers and overlays connected to the single Tweets. We will look in more detail at each of these functions in the next subsections.

32 4.4.1 Map Display

4.4.1 Map Display The map display is handled by Google Maps, by executing the line map = new google.maps.Map(document.getElementById("map_canvas"), myOptions); in the initialize function. This command generates a new map, using the options concerning the map’s zoom and type, deﬁned in the array myOptions. The array myOptions deﬁnes the default zoom level and map type and deactivates scrollwheel zooming and the StreetView control.

4.4.2 Geolocation The geolocation is handled by the HTML5 geolocation function and interacts with the map in the conditional if(navigator.geolocation) {...}. First of all, a check is performed if geolocation is supported by the browser. If it is supported, the user’s position is stored in two hidden fields on the website (one for the longitude and one for the latitude) and the map is centered on this position. If it is not supported, the function handleNoGeolocation is executed, which displays an error message and a field allowing the user to manually enter his address (with an autocomplete function to support him). There are two possible error messages displayed to the user, depending on whether the geolocation is simply not working at the moment, or if it is not supported by the browser. After the user has compiled the text field for a manual search of his address, the function codeAddress is executed, which checks if the address is valid and uses the Google Maps geocoder to transform the textual address entered by the user into coordinates that can be displayed on the map.

4.4.3 Tweet Radius To optimize the loading of Tweets, the search string generated by the LTMap module (see chapter 4.3.2) uses the radius parameter to limit the fetched Tweets inside a given search radius. This radius is calculated by the function getRadius (calculations adapted from [Mer07]). The function getRadius determines the position of the center and one of the corners (the South-West one), converts their coordinates into radians and calculates the distance between them by using the great circle distance formula (see equation (4.1)) [Mer07].

d = earthR · arccos[sin(centerLat) · sin(cornerLat)+ (4.1) cos(centerLat) · cos(cornerLat) · cos(cornerLon − centerLon)]

This formula returns the radius of a hypothetic circle that encloses the visible map portion. This is done to limit loading times and optimize Tweet visualization when fetching new Tweets: if each time we would load all new Tweets since the last update,

33 4.4.4 Tweet Display this would eventually make the system very slow (depending on the time lapse between two updates); on the other hand, if we load only n Tweets (let’s say 100, for example) but they are not necessarily located around the visible portion of the map, there will be only few possibilities that a visitor will see new Tweets for his geographic region.

4.4.4 Tweet Display The display of Tweets is handled by the function display_tweets, executed after each update of the map, just after the cron run of the Module (see chapter 4.3.2). The function display_tweets receives the existing Tweets (stored in the database) from the cron run and loops through each of them (until the maximum number of Tweets to display is reached) to check if it is inside the map boundaries actually displayed. If this is the case the Tweet is added to the map (the corresponding marker and infowindow are generated) and to the Tweet list (using the same HTML content as in the infowindow for maintaining a coherent user interface). The function is also responsible for displaying the information in the “Map info” section and the filters in the “Actions” section. In order to allow the dynamic loading of the author’s Twitter profile and of the “Re- ply”, “Retweet” and “Favorite” pages, Twitter’s intents [Twi12h] are used. For this the file widgets.js is included by the module and special links are generated by the display_tweets function. The rest is managed dynamically by Twitter.

4.4.5 Map Update Among the JavaScript functions described, there is also a listener which checks for the “idle” event and is executed each time a visitor interacts with the map (moving, zooming, etc.). The listener is deactivated when an infowindow is opened, allowing the user to move the map and read eventual hidden parts of the infowindow. When an interaction with the map is detected, the listener calculates the new radius of the visible portion, stores the new position and executes an AJAX call to the ﬁle cron.php, responsible for executing all cron calls of Drupal, including our function ltmap_cron (see chapter 4.3.2). After successful execution of the AJAX call, the Tweets are displayed on the map.

4.4.6 Other functions There are other, minor JavaScript functions responsible for listening to specific events, like for example the submission of the address field if the geolocation does not work, the submission of the “Go to address” field in the “Actions” section, the submission of the “Filter results” field and the click on the “Clear” buttons (all the above take into consideration both the click on the “Submit” or “Clear” button and the pressing of the “Enter” key on the keyboard while inside the corresponding textfield).

34 5 Operation instructions

5 Operation instructions

5.1 Introduction

One of the main goals of this thesis was to create an easy to use and intuitive application. The purpose of this chapter is to explain the operation of LTMap with as many details as possible, although its operation is very intuitive and well explained inside the application itself. First of all, the installation of the module will be explained, then the interaction with the single user interface elements (such as the map, the Tweets and the available ﬁlters) will be explained.

5.2 Installation

In order to install the LTMap module you need to have a working Drupal 7 system, with admininstrative access to it and access to the FTP server where it is installed. In order to make the LTMap module work properly, you also need a valid Google Maps API key associated to your Google account (you can get one by following the instructions on [Goo12d], please take care that you activate an API key for the “Google Maps API v3 service”). Additionally, you need to create a Twitter application (see [Twi12a]) with your Twitter account. To install the LTMap module you need to take the following steps:

• Download the module from http://ltm.aronmartinez.com/ltmap-7.x-1.x-dev. zip (.zip archive) or http://ltm.aronmartinez.com/ltmap-7.x-1.x-dev.tar. gz (.tar.gz archive); • Extract the downloaded archive and copy the resulting folder ltmap to the modules folder of your Drupal 7 installation (which is located under sites/all/modules); • Go to the Modules administration page of your Drupal installation (under www. yoursite.com/admin/modules), open the module group “AM”, enable the LTMap module and save your configuration (see figure 5.1); • Still on the Modules administration page, next to the LTMap module, click on the “Configure” link and on the module configuration page (see figure 5.2) insert your Drupal cron key (which can be found in the Status report page, under “Cron maintenance tasks”), your Google Maps API key and the maximum number of Tweets you want to display in the LTMap block; additionally, if you have not

35 5.3 LTMap User Interface

done it already, you can click on the “Create Twitter application” link to access Twitter’s page for creating a new application; • Go to the Blocks administration page (under www.yoursite.com/admin/structure/ block) and search the block named LTMap under the “Disabled” group; • Click on the “conﬁgure” link next to the LTMap block and conﬁgure it according to your needs (you can, for example, choose to display it on you front page by assigning it to the “Content” region of your theme and assign the value to the “Only the listed pages” option in the “Pages” tab; • Go to the corresponding page and check if the block is showing correctly.

Figure 5.1: Activation of the LTMap module

5.3 LTMap User Interface

The LTMap user interface is composed of the following elements (see ﬁgure 5.3):

• Map area: the interactive map of LTMap, with the Tweets found in the corresponding area displayed as markers; • Infos: some information about the displayed map and Tweets; • Actions: the available actions for the map and the display of items; • Items: the items (for the moment only Tweets) found in the selected area of the map.

5.3.1 The Map When the page containing the LTMap block is loaded the ﬁrst time, the visitor’s browser will ask him if he wants to allow the computer to share the actual location (see ﬁgure 3.1, in chapter 3.2.1, for an example). If the visitor accepts to share his location, the map will automatically be centered on the visitor’s position (this will also automatically be done for future visits, depending on the browser settings).

36 5.3.1 The Map

Figure 5.2: Conﬁguration of the LTMap module

If the visitor denies the request to share his location, an error message is displayed and a text field, allowing him to enter his address manually, is displayed below the map. While the map and Tweets are loading, an animated loader image is displayed on top of the map, in order to make it clear to the visitor that the system is running in the background. The Tweets are represented as standard Google Maps markers on the map. When a visitor passes over one of the markers with the mouse, the Twitter username of its author appears. By clicking on the marker, instead, an infowindow opens, which displays all information related to the Tweet (see figure 5.4). Inside the Infowindow you find the following information:

• Profile picture: the author’s profile picture, linked to the corresponding Twitter profile; • Author name: the full name of the author (e.g. Aron Martinez), linked to the corresponding Twitter profile; • User name: the “@username” of the author; • Text: the text of the Tweet, with its mentions, hashtags and links; • Date: the publish date of the Tweet; • Reply: a link to directly reply to the Tweet;

37 5.3.2 Infos

Figure 5.3: UI of LTMap

• Retweet: a link to directly retweet the Tweet; • Favorite: a link to directly set the Tweet as favorite; • Twitter icon: a Twitter icon to immediately distinguish an item as a Tweet when additional social networks will be added in the future; • Close button (x): a button to close the infowindow.

5.3.2 Infos The “Map info” box below the map, on the left side, displays some information to the visitor. These include the radius displayed on the map (which is also used in the request to the Twitter Search API in order to limit the search results) and the total number of Tweets displayed.

38 5.3.3 Actions

Figure 5.4: Example of Tweet infowindow

Please note that the maximum number of Tweets is limited, in order to avoid too long loading times when a large radius is displayed on the map (or, in other words, when lower zoom levels are used). The maximum number of Tweets to display can be set in the LTMap module conﬁguration page (see chapter 5.2).

5.3.3 Actions The “Actions” box below the “Map info” box allows the visitor to interact with the map and the list of Tweets. The “Go to address” ﬁeld allows the visitor to change the area displayed on the map directly, without having to zoom or drag the map. In order to simplify the writing of addresses, an autocomplete functionality displays a list of suggestions as soon as the user starts typing (see ﬁgure 5.5).

Figure 5.5: Example of address autocomplete suggestion

The “Filter results” field, instead, allows the visitor to filter the displayed items by one or more search terms. In figure 5.6, for example, a search query with the term “test” has been done, and the corresponding Tweet (containing the word “testing”) has been

39 5.3.4 Items displayed. In addition, the searched word is highlighted in yellow in the corresponding Tweet (both in the infowindow on the map and in the Tweet under “Item list”).

Figure 5.6: Example of search query

5.3.4 Items The right section below the map, named “Item list”, displays all items retrieved on the selected map area in a list form. This approach has been chosen to simplify the use of the LTMap module and allow the visitors a more direct overview of all retrieved Tweets. In order to maintain the focus on the main element of LTMap (namely the map) and to avoid presenting the user a huge list of items on page load, the items are organized in an accordion, where they are grouped into diﬀerent sections (corresponding to the diﬀerent social networks). This accordion is closed by default and can be opened by the user if needed. For the moment only Tweets are retrieved by the module, and the section named “Facebook posts” serves only testing purposes. In the future, additional sections can be added for the additional social networks added to LTMap. Inside the “Tweets” section, all the retrieved Tweets are displayed. Their layout is identical to the structure described above for the infowindow (see chapter 5.3.1), with exception of the close button of the infowindow, so it will not be described again. Inside the “Facebook posts” section, for the moment there is only a message stating that no Facebook posts are available.

40 6 Evaluation

6 Evaluation

6.1 Introduction

The work carried out on LTMap has shown that it meets the aspects fixed in the concept phase, but also that there are still some possible improvements and changes to be done in order to optimize the application. These aspects will be outlined through a functional evaluation of the application. This chapter is structured in three main parts: a first part, in which the functional evaluation carried out will be exposed, by analysing the actual state of the application according to specific characteristics; a second part, in which a functional comparison is presented, in which the features of LTMap are compared to other existing systems; and, finally, a third part, in which a user study plan is proposed, which should be the base for a future user study of the system. Due to time and resource limitations, it was not possible to carry out a user study directly, during the writing of this thesis. For this reason only the theroetic part of the user study is presented in this thesis, but it can be used as a base for future studies on the system.

6.2 Functional Evaluation

The functional evaluation of LTMap will be based on the main ISO9126 characteristics, as outlined in [RBeA10], namely: • Efficiency: the load times of the application; • Functionality: the functional items (navigation, forms, etc.) of the application; • Maintainability: the files of the application that need maintenance; • Portability: the effort required to install the application on another system; • Reliability: the performance of the features of the application; • Usability: accessibility and effort needed to learn how to use the application. The six points listed above will be analyzed in detail in the next subsections.

6.2.1 Eﬃciency The load times of LTMap, which were tested with the “Net” tab of Firebug [Moz10], are displayed in table 6.1 (please note that only the “onload” time has been considered).

41 6.2.2 Functionality

# Time (s) # Time (s) # Time (s) # Time (s) 1 2.30 11 3.92 21 2.81 31 2.80 2 3.65 12 3.86 22 5.85 32 4.19 3 3.89 13 3.53 23 3.62 33 4.08 4 5.00 14 4.05 24 2.81 34 4.11 5 3.81 15 3.86 25 3.35 35 4.14 6 3.86 16 4.72 26 4.26 36 2.43 7 3.84 17 2.32 27 3.86 37 2.34 8 2.58 18 3.80 28 3.98 38 2.23 9 3.51 19 4.85 29 4.29 39 5.73 10 4.04 20 4.02 30 3.67 40 3.98

Table 6.1: Load times of LTMap

These values correspond to an average of 3.78 seconds and a median of 3.86 seconds. The minimum load time measured was 2.23 seconds, while the maximum was 5.85 seconds. The overall load time may not seem optimal, but if we consider that LTMap loads map data from Google Maps and needs to load 150 Tweets (or more, depending on the module settings), with the proﬁle picture of their authors, this load time is a good result and ﬁts the expectations for the application.

6.2.2 Functionality The functional items of LTMap include the following items:

• Map: the map where Tweets are displayed; • Forms: the textﬁelds and corresponding buttons oﬀered by LTMap; • Accordion: the accordion in which Tweets and other items are displayed.

All these items are optimized in order to be as intuitive as possible to the visitor. The map of LTMap has been kept simple and intuitive. The original markers, infowin- dows and interaction methods of Google Maps have been used in order to be as familiar as possible to the users and give them as much continuity as possible with the existing Google Maps interface (see [Goo13] for an example). It allows to switch between map and satellite view, in order to adapt to the preferences of the visitors. It also allows to zoom in/out and move around both with the mouse and the buttons provided by Google Maps. The only exceptions to this are the StreetView feature (which is not needed for LTMap), and the zoom interaction when scrolling, which was disabled (because, due to the big map covering a large amount of the page, it could have caused unvolontary zooming while scrolling the page). The textfields for address input have an autocomplete function, which starts displaying addresses as soon as the visitor types something, in this way the user can choose the address from one of the suggestions, instead of having to type long addresses or having to try out different combinations of street, city and nation (depending on the visitor’s desired address, there could be multiple similar places which correspond, so the user would be forced to enter the desired street, city and country in order to be sure to reach the desired address). The textfields also have clear labels and placeholder texts (which

42 6.2.3 Maintainability unfortunately do not work on Internet Explorer, but the label texts still allow for a clear understanding of the purpose of the textfields). The accordion under the “Item list” section was inserted to allow for an easy filtering of the different social networks which may be added in the future (even if for the moment only Twitter is supported by LTMap). Additionally, the choice of showing it closed by default was done in order to avoid displaying a long list of Tweets to the visitor, even if it may not be needed. In this way the visitor remains concentrated on the map (which is the main focus of LTMap), but has still the possibility to display an overview of all Tweets displayed on the map in an intuitive list view, where the Tweets are ordered by date, in descending order.

6.2.3 Maintainability The maintainability of LTMap is one of the weak points of the module, because for the moment the integration of Twitter does not reflect the desired plugin structure depicted in the concept phase. After technical problems in the attempt of integrating all the Twitter features in a separate PHP file, some of the needed Twitter functionalities were put in the JavaScript file main.js, in order to grant the proper functioning of the prototype for testing and presentation purposes. As a consequence, the code inside main.js is a mix between general purpose code belonging to the module and code specific for the Twitter social network, and the code contained in plugins/twitter.php handles only a part of the interaction with Twitter. In case of the addition of a new social network, the corresponding PHP functions need to be added to a new PHP file inside the plugins folder and the file main.js needs to be enhanced with the needed JavaScript code. The other files belonging to the module are easily maintainable: there is one CSS file, all.css, inside the css folder; all needed images are included in the images folder; all needed plugin functions are included in the plugins folder, inside a file named YOUR_SOCIAL_NETWORK.php (e.g. twitter.php); and the module files ltmap.info, ltmap.install and ltmap.module reflect Drupal’s module structure and are well com- mented, so they are easy to maintain.

6.2.4 Portability The portability of LTMap is granted for Drupal 7 systems, since the module structure reﬂects the standards of Drupal 7 modules. Portability for other versions of Drupal, or even for other systems is not granted for the moment, but can be provided in the future, by adapting the existing code to the needs of a new system. The portability of LTMap is still not ideal, because the user needs to provide some conﬁguration data after installing the module and also to create a Twitter application to make the Twitter search API work properly. Unfortunately these portability issues cannot be avoided, because LTMap needs a valid Google Maps API key and a Twitter application in order to work properly. In the

43 6.2.5 Reliability future these issues could be ﬁxed by providing authorization mechanisms, like Twitter OAuth [Twi11b].

6.2.5 Reliability LTMap has been tested in depth for its proper functionality, both in its main features (such as search fields and the interaction with the map and with the Tweets) and the more “behind the scene” features (such as module and block configuration). In all the performed tests it has shown a good level of robustness and has always worked properly, as expected. The tests on the front-end user interface were carried out more in depth due to the great number of possible variables: used device, used browser, available screen resolution, etc. These tests did also show some important aspects that needed to be optimized, like for example the address search field, which did not always give a precise result if a partial address was provided. In order to overcome this problem, an autocomplete functionality was added to the field, which offers the user the possibility to choose from a list of addresses as soon as he starts to write something in the field. This also improved the usability of the system (see chapter 6.2.6). Another example is the accordion in the “Item list” area, which was added only afterwards, in order to avoid loading a long list of Tweets on each page load. The back-end features, on the other hand, showed no problems, because they were based on Drupal’s very robust and well performing architecture, which handled most of the work.

6.2.6 Usability Usability was one of the main aspects that were taken into consideration in the concept of LTMap. The system needed to be as simple and usable as possible. The usability of LTMap has been granted by the simple structure of the block that is displayed in the front-end by the module and by some features that granted the user an easy interaction with the structure, such as the autocomplete functionality already mentioned before (see chapter 6.2.5) and the accordion feature that allows to obtain an overview of all recent Tweets available in the region, without the possibility of hiding it if the user does not need it. In order to facilitate the use of LTMap, all elements are easy to use and well explained (in the online prototype, there is also a help page which explains the single elements in more detail).

6.3 Functional Comparison

In this section, the main characteristics (eﬃciency, functionality and usability) of LTMap will be compared to the characteristics of the following systems (which have already been

44 6.3.1 Trendsmap introduced and described in chapter 2.6):

• Trendsmap: an application mapping Twitter trends in real-time [Sta12a]; • GeoChirp: an application which allows you to “search for people Twittering for speciﬁc things in a speciﬁc area” [Cue13b]; • A World of Tweets: a heatmap of locations where people are Tweeting [ZM12].

Tweography [She09] has not been taken into consideration, because it could not be tested properly during the writing of this thesis (see also chapter 2.6.2).

6.3.1 Trendsmap Trendsmap has shown slower load times than LTMap in the tests carried out, which are displayed in table 6.2.

# Time (s) # Time (s) # Time (s) # Time (s) 1 3.59 11 4.81 21 4.94 31 5.10 2 4.39 12 4.93 22 3.77 32 5.69 3 6.27 13 3.59 23 5.04 33 5.27 4 3.70 14 5.13 24 5.07 34 5.40 5 4.68 15 3.86 25 4.11 35 4.03 6 3.52 16 4.88 26 3.85 36 5.11 7 4.45 17 5.39 27 6.52 37 3.46 8 4.18 18 3.52 28 5.25 38 4.22 9 4.42 19 5.09 29 5.37 39 3.59 10 8.02 20 4.85 30 3.98 40 3.88

Table 6.2: Load times of Trendsmap

The average load time of Trendsmap is 4.68 seconds, while the median is 4.75 seconds. The minimum load time measured was 3.46 seconds, while the maximum was 8.02 seconds. Although the load times are longer, it must be considered that Trendsmap has also a more complex interface than LTMap, with many additional elements, such as trending countries, cities, users and videos. Therefore the average load time of Trendsmap is still very good. For what concerns functionality, Trendsmap has some additional elements to take into consideration, if compared to LTMap:

• Map: the map where topics are displayed; • Forms: the search ﬁeld and other textﬁelds and buttons; • Accordions: the accordion on the right side of the map (where information about Trendsmap and the list of Tweets are displayed), and other accordions in the subpages of Trendsmap; • Lightboxes: the lightboxes for videos in the “Trending Videos” section; • Social buttons: the social buttons in the header; • Carousel: the carousel for the videos in the “Trending Videos” section.

45 6.3.1 Trendsmap

All the items have been tested and seem to work well. The map of Trendsmap, like the map of LTMap, uses the standard Google Maps layout and is intuitive to use. What deviates from the standard layout of Google Maps are the topics, which are not displayed as markers, but as labels in a tag-cloud style (more important topics are displayed bigger and bolder than less important topics). In the case of Trendsmap, this layout is much better than a layout using markers, because it allows to have an immediate overview of the topics, whithout having to click through each marker singularly. On LTMap, on the other hand, such a layout would not have been possible, since we need to have the exact position of a Tweet, and because the only compact information available would have been the user name of the author, which would not have been very useful in a tag-cloud-like layout. There are some additional elements which enhance the user experience and usability, such as the four custom buttons in the top left corner, which allow to automatically locate the visitor’s position, its city, its region or to display the whole world. Also the accordion box on the right side of the map is very useful and intuitive: it allows to have the Tweets related to a given topic at hand, over the map, in order to have an immediate overview of the Tweets when the visitor clicks on a topic; additionally, it can be hidden in order to display a larger portion of the map. On the map of Trendsmap, as with LTMap, the zoom interaction when scrolling has been disabled. This is very helpful, because the map takes up the whole page width and scrolling would become very difficult if the map would zoom in/out on each scrollwheel movement. The form elements are very intuitive to use. The search field in the top right corner, for example, has an autocomplete feature which displays both locations and topics as the user types (in this way one single search field can be used, instead of two, like on LTMap). The problem with the autocomplete feature is that it does not behave exactly as the user may expect: first of all, the locations are only found in English (therefore if you search “Milano” or “Zürich”, no location will be displayed) and seem to be displayed only if topics are available (for example, “Lucerne” or “Lugano” give no results); additionally, the topics are not always found (if the user searches “Zurich”, no topics are found, but if he zooms in on the map over the region of Zurich, there are different topics available). On LTMap, instead, the autocomplete feature of the address field accesses the available addresses of Google Maps, which are found properly in any language. But, on the other hand, LTMap is missing an autocomplete function for the search field. The accordions provided by Trendsmap are very useful, due to the fact that lots of information are displayed, and therefore a unique long list of topics and/or Tweets would be cumbersome to read. On the other hand, the interaction with the accordions is not optimized: if you click on the title bar nothing happens, only if you click on the small arrow on the right side the accordion opens or closes. To optimize the interaction with the accordions, the title bar should open the corresponding accordion tab, as it has been made on LTMap. The lightboxes enhance user experience and behave as expected: if you click on a video, it displays larger in a lightbox and starts playing; if you click outside the lightbox, press the “escape” button or click on the close (“x”) button in the bottom right corner, the

46 6.3.2 GeoChirp lightbox closes and the video stops playing. The social buttons provided by Trendsmap have the original layout provided by Twit- ter and Facebook, but the interaction with the buttons is confusing: a part from the Face- book “Like” button, which behaves as expected, all other social buttons on Trendsmap (“Tweet” button in the header, “Follow on twitter” button near to the “Globally Trend- ing Users”, and the links “Favorite”, “Retweet”, “Reply” and “Follow” for the single Tweets) open a popup window asking to authorize Trendsmap.com to use your Twitter account. This is confusing because a user would expect a direct interaction with Twit- ter, and not an interaction with the “Trendsmap.com” Twitter application. The use of Twitter intents, as on LTMap would be more intuitive and immediate. The carousel for the videos behaves as expected and has been conﬁgured in order to scroll multiple items at once if a user clicks on one of the arrows (this way a user must not click through each single video, but can scroll multiple items at once, which is more intuitive and faster).

6.3.2 GeoChirp GeoChirp has shown slightly faster load times than LTMap in the tests carried out, which are displayed in table 6.3.

# Time (s) # Time (s) # Time (s) # Time (s) 1 3.51 11 4.56 21 3.51 31 3.58 2 3.58 12 3.31 22 3.50 32 3.63 3 3.54 13 3.48 23 3.50 33 3.18 4 3.74 14 3.43 24 3.56 34 3.67 5 3.41 15 4.34 25 3.32 35 3.27 6 4.90 16 3.33 26 3.88 36 3.62 7 3.83 17 3.17 27 2.97 37 3.82 8 3.83 18 3.28 28 3.39 38 3.19 9 3.27 19 3.79 29 3.74 39 3.49 10 3.39 20 4.08 30 3.76 40 3.77

Table 6.3: Load times of GeoChirp

The average load time of GeoChirp is 3.60 seconds, while the median is 3.51 seconds. The minimum load time measured was 2.97 seconds, while the maximum was 4.90 seconds. From these measures GeoChirp results slightly faster than LTMap, but due to the minimal diﬀerence, the load times of the two systems can be considered equal. Like Trendsmap, GeoChirp has some additional functional elements to take into consideration, if compared to LTMap:

• Map: the map where the location is chosen; • Form: the search ﬁeld and the corresponding button; • Accordions: the accordion on the right side, under the “Refresh” button; • Notiﬁcation box: the Growl-like popup boxes (see [Gro13]) in the top right corner that inform the user about new Tweets; • Lightboxes: the lightboxes for messages and retweets/replies;

47 6.3.2 GeoChirp

• Social buttons: the social buttons in the header; • Sliders: the sliders below the map allowing to choose the number of Tweets and the search radius. The map of GeoChirp, like the map of LTMap uses the standard Google Maps layout and is intuitive to use (although it uses an older version of the Google Maps API, which displays some UI elements slightly differently). GeoChirp uses a standard marker and infowindow to display the actually chosen position. The circle displaying the chosen search area is added as an overlay on the map. The functioning of the map is quite intuitive and easy, as soon as the user clicks on a point of the map, the marker and the corresponding search area are moved to that position. The only drawback that was noticed is that it is not possible to move the marker to another position inside the search area, because the click inside the blue circle overlay is not interpreted. The user must therefore first click on a point outside of the search area (which is far enough from the desired point in order to not cover it again with another search area) and only then he can click on the desired point. In contrast to LTMap, on GeoChirp the zoom interaction when scrolling is active, this is not very intuitive, because undesired zooming is carried out when scrolling the page. The search form is quite simple, but not very intuitive to use. First of all, it is not clear what kind of search is carried out, if the search is made inside the actual search area, in the actual map portion, or globally. The search button is placed after the sliders, so one would think that the sliders are part of the search form (and therefore do not react until the search button is clicked), but this is not the case, since the sliders react as soon as their value is changed. For this reason it would be better to place the search button right after the search field, and place the sliders to the right of the search button. The accordion under the “Refresh” button allows to hide the “Top Tweple in your area” box, if it should not be needed. It is managed in a way that optimizes usability, since the whole title area causes the accordion to open/close, like in LTMap. The notification box appearing in the top right corner when new Tweets are posted is very useful and appears always in the correct position, also when the user scrolls down the page, it follows and keeps appearing in the top right corner of the window (instead of displaying in the top right corner of the page and being hidden when scrolling down). It has also a close button, allowing the user to close it if he does not need it. Another feature connected to new Tweets is the “Refresh” button, which is deactivated until new Tweets are posted. This is very intuitive, because the user can avoid to refresh the page unnecessarily and can be sure that if he refreshes the page, there will be new items. The lightboxes that open for error messages (e.g. request to login) and retweets/replies are quite usable, as they can be closed by clicking the close button in the top right corner and also by clicking outside the lightbox (but not by pressing the “escape” button, as for Trendsmap). The social buttons in the header of GeoChirp behave as expected: they open the Facebook and Twitter profile of GeoChirp. The “Reply” and “Retweet” links connected to the single Tweets, instead, are not very intuitive: like on Trendsmap, they do not

48 6.3.3 A World of Tweets carry out a direct action of replying/retweeting, but instead require to login in GeoChirp ﬁrst. The sliders allowing to customize the number of Tweets displayed and the search radius behave quite well, but have some drawbacks: the actions related to them are rapid and perform as expected, but they do not align with the “steps” below them and they could be interpreted as being part of the search form, which is not the case (see above).

6.3.3 A World of Tweets In the tests carried out, which are displayed in table 6.4, A World of Tweets has shown the fastest load times measured between the systems that are compared here.

# Time (s) # Time (s) # Time (s) # Time (s) 1 2.47 11 1.76 21 2.24 31 3.08 2 2.32 12 1.78 22 1.83 32 2.24 3 2.28 13 1.82 23 1.78 33 1.84 4 1.99 14 2.29 24 1.82 34 1.97 5 1.97 15 2.14 25 2.04 35 1.94 6 1.77 16 2.01 26 2.42 36 1.83 7 3.99 17 1.80 27 1.82 37 2.01 8 2.19 18 2.02 28 2.00 38 1.78 9 1.91 19 1.93 29 1.94 39 1.92 10 1.68 20 3.21 30 1.99 40 1.73

Table 6.4: Load times of A World of Tweets

The average load time of A World of Tweets is 2.1 seconds, while the median is 1.97 seconds. The minimum load time measured was 1.68 seconds, while the maximum was 3.99 seconds. These very fast load times can be explained with the fact that A World of Tweets does not actually load Tweets, like the other systems analyzed, but “only” counts the Tweets posted around the World. This largely decreases the necessary data to load and therefore decreases load times. Additionally there is no interactive data, so the Google Maps API does not need to be loaded, which also allows to reduce the load times. A World of Tweets has very few functional elements to take into consideration:

• Map: the map where the Tweet locations are highlighted; • Social buttons: the social buttons in the header.

Unlike the other systems that have been analyzed, A World of Tweets does not provide an interactive map, but a static map, over which the heatmap is drawn dynamically and updated each time that a new Tweet is posted. This map does not allow any interaction (like zooming in or moving around), with exception of the map customization controls on the left side. These map controls allow to switch between a heatmap and a smoky clouds view, between a map and a satellite view, to show/hide the heatmap, the labels and the map, to clear the heatmap and even to activate/deactivate a 3D stereo view of the map. These customization functions work very well and act as expected, with

49 6.3.4 Summary exception of the “Clear heatmap” link, which clears the heatmap for a fraction of a second, but displays it again right afterwards. The social buttons in the header act as excpected, by allowing to share the page on the corresponding social networks. There are no other interactions with social networks on the page. The rest of the page displays many different statistics which are very useful to analyze the share of Tweets posted in different countries and different timelapses (like, for example, in real time, concerning the actual day or since the start of the application in November 2010). One drawback of the application is that it seems to have some difficulties getting data about Switzerland, since the light-blue box above the “Continents Overview” section displayed “UNDEFINED IS 230TH WITH NULL% OF TWEETS” during the tests carried out.

6.3.4 Summary As we have seen, every application has diﬀerent characteristics, with the corresponding strencths and weaknesses, and approaches the display of Tweet data in a diﬀerent way:

• LTMap focuses mainly on usability and on the precise display of Tweet locations; • Trendsmap focuses more on trends and on their approximate location; • GeoChirp focuses more on the display of Tweets than on their location; • A World of Tweets focuses only on statistics about the location of Tweets and their number per country and continent.

The applications have also different load times, which are strongly related to the complexity of their user interfaces and the data they need to load. Finally, the applications have also different user interface elements needed to interact with them: some, like Trendsmap and GeoChirp, are more complex and offer more interaction possibilities, while others, like LTMap and A World of Tweets, offer less interaction possibilities. In all cases studied above the interaction worked very well and was a pleasure. The minor problems noticed do in no way limit these positive experiences and are intended as a positive critics to improve the respective features.

6.4 User Study

Due to time and resource limitations, unfortunately it was not possible to carry out a user study for LTMap, but in order to facilitate a more in-depth evaluation of LTMap in the future, in this section the prepared user study plan will be presented. Given that LTMap is an online application, and that one of the main focuses of LTMap is usability, it was planned to carry out a usability study, in order to point out the strengths and weaknesses of its user interface.

50 6.4.1 Metrics

In the next sections, the metrics of the planned usability study and the planned scenario will be presented.

6.4.1 Metrics In order to carry out the usability study of LTMap, some basic metrics need to be deﬁned. These metrics are based on [TA08] and include: type of study, number of participants, background knowledge of participants and involved variables.

6.4.1.1 Typology The usability study to be carried out should be a formative study, based on the obser- vation of two distinct user groups using LTMap in a lab test. The formative study should consist of a first lab test analyzing the use of LTMap, of one correction loop of the module based on the findings of both user groups, and finally of a second lab test with the improved module.

6.4.1.2 Participants The participants involved in the usability study of LTMap should be split in two groups of approximatively ﬁve people:

• the ﬁrst group would consist of basic users, simulating visitors on a site displaying the LTMap block in Drupal and simply interacting with it; • the second group would consist of more experienced users, simulating the administrators of websites using the LTMap module and needing to install it ﬁrst.

The participants of the ﬁrst group would need to be familiar with the use of internet, and if possible also with Google Maps and Twitter. The participants of the second group, instead, would need to be familiar with the use of Drupal and its modules, in addition to the familiarity with Google Maps and Twitter.

6.4.1.3 Variables The variables involved in the usability study, which need to be analyzed are as follows:

• Success: the number of tasks successfully carried out by the participants; • Time: the time needed to carry out the different tasks; • Effort: the effort (like for example the number of mouse clicks) needed to carry out a task; • Errors: the number of errors committed; • Satisfaction: the satisfaction felt by the participants during the use of the system.

51 6.4.2 Scenario

All variables, except satisfaction, should be measured by Drupal and/or by the investigators (in addition to the questions asked to the participants), while satisfaction is a self-reported metric that needs to be provided directly by the participants.

6.4.2 Scenario In this section, the two planned scenarios (use of LTMap and installation of the LTMap module) will be presented and explained. Although the second scenario focuses mainly on the installation of the LTMap module, it will also include a part about the use of the LTMap block, in order to have also some interaction, and the corresponding feedback, by expert users.

6.4.2.1 Use of LTMap In this section, the scenario for the evaluation of the use of LTMap will be presented. The scenario is divided into the different main areas (or sub-scenarios) to test, which are each divided into the different tasks to carry out. Each area has a set of questions related to it, in form of a small After-Scenario Ques- tionnaire (ASQ) related to that sub-scenario [TA08]. The last three questions are always general statements which evaluate effectiveness, efficiency and satisfaction and should be accompanied by a 7-point rating scale going from “Strongly disagree” to “Strongly agree” (as proposed by [Lew91] and suggested by [TA08]), while the other questions are closed questions that can simply be answered through “Yes” or “No” checkboxes. All the above questions/statements could be enhanced through extra open questions (like “If no, what went wrong?” after each closed question, or even a general “Observa- tions” field for each sub-scenario), but the goal is to keep the tasks as simple as possible for the user and collect such information through the observations of the investigators, or where possible directly through Drupal. The scenario planned for analyzing the use of LTMap is as follows:

1. Access to LTMap • Tasks: – Open http://ltm.aronmartinez.com; – Wait for the site to load. • Questionnaire: – Did the page load correctly? – Did automatic geolocation work as expected? – Was there a satisfactory number of Tweets displayed? – I am satisﬁed with the ease of completing the task. – I am satisﬁed with the amount of time it took to complete the task.

52 6.4.2 Scenario

– I am satisﬁed with the support information (online help, messages, documentation) when completing the task.

2. Map interaction • Tasks: – Move the map around; – Zoom in and out; – Click on a marker; – Use the provided functions inside an infowindow; – Close the opened infowindow. • Questionnaire: – Did the map react as expected? – Were new Tweets loaded correctly? – Was the infowindow intuitive to use? – Did the links inside the infowindow behave as expected? – I am satisfied with the ease of completing the task. – I am satisfied with the amount of time it took to complete the task. – I am satisfied with the support information (online help, messages, documentation) when completing the task.

3. Address search • Tasks: – Type a full address in the “Go to address” field and click on “Go”; – Type a partial address, choose an address from the ones proposed by the autocomplete feature and click on “Go”; – Click on “Clear”. • Questionnaire: – Did the full address search give the expected result? – Did the autocomplete feature provide useful hints? – Did the “Clear” button work as expected? – I am satisfied with the ease of completing the task. – I am satisfied with the amount of time it took to complete the task. – I am satisfied with the support information (online help, messages, documentation) when completing the task.

4. Filter search

53 6.4.2 Scenario

• Tasks: – Type a search term in the “Filter results” field and click on “Search”; – Click on one of the displayed markers on the map (if any); – Open the “Tweets” tab in the “Item list” area; – Click on “Clear”. • Questionnaire: – Did the filter search work as expected? – Was the searched term easily retrievable in the search results? – Did the “Clear” button work as expected? – I am satisfied with the ease of completing the task. – I am satisfied with the amount of time it took to complete the task. – I am satisfied with the support information (online help, messages, documentation) when completing the task.

6.4.2.2 Installation of LTMap In this section, the scenario for the evaluation of the installation of the LTMap module will be presented. As in the previous scenario, it is divided into the diﬀerent main areas (or sub-scenarios) to test, which are each divided into the diﬀerent tasks to carry out. The scenario planned for analyzing the installation of the LTMap module is as follows:

1. Download and install the LTMap module • Tasks: – Visit http://ltm.aronmartinez.com/installation; – Follow the instructions. • Questionnaire: – Was the download and installation procedure well explained? – Did the installation work properly? – I am satisfied with the ease of completing the task. – I am satisfied with the amount of time it took to complete the task. – I am satisfied with the support information (online help, messages, documentation) when completing the task. 2. Configuration of the LTMap module • Tasks: – Visit http://ltm.aronmartinez.com/configuration; – Follow the instructions.

54 6.4.2 Scenario

• Questionnaire: – Was the configuration procedure well explained? – Did you find the cron key easily? – Did you manage to get a Google Maps API key? – Did you manage to create a Twitter application? – Did you encounter any errors? – I am satisfied with the ease of completing the task. – I am satisfied with the amount of time it took to complete the task. – I am satisfied with the support information (online help, messages, documentation) when completing the task.

3. Configuration of the LTMap block • Tasks: – Go to your block administration panel; – Search the block named LTMap under the “Disabled” group; – Click on the “configure” link next to the LTMap block; – Configure it in order to display it on you front page (by assigning it to the “Content” region of your theme and assign the value to the “Only the listed pages” option in the “Pages” tab). • Questionnaire: – Did you find the LTMap block easily? – Did you manage to display the block properly on the front page? – Does everything display correctly? – I am satisfied with the ease of completing the task. – I am satisfied with the amount of time it took to complete the task. – I am satisfied with the support information (online help, messages, documentation) when completing the task.

4. Use of LTMap • See chapter 6.4.2.1

Although the main focus of the group of administrators is the installation of the LTMap module, the last point of the scenario is about the eﬀective use of LTMap, in order to have an additional feedback to the user group (and in order to allow these users to satisfy their curiosity and “play” with the module they installed).

55 7 Conclusion

7 Conclusion

7.1 Summary

This thesis presented the concept of LTMap, a map displaying geolocated Tweets with automatic geolocation of the visitor, which aims to enhance interaction with geolocated Tweets, and is the base for the fututre addition of other social networks. Additionally, a prototype was created with the purpose of illustrating the potential and the exact features of LTMap. The main differences between LTMap and the other existing systems by [Sta12a], [Cue13a] and [ZM12], are the usability of the user interface and the precision of the displayed Tweets. Usability was granted through the use of a simple and intuitive user interface, while pricision was granted through the exclusive use of geolocated Tweets and the display of Tweets in the exact location where they have been published. Through the integration in a Drupal 7 module, the installation of LTMap in an existing system is very easy, provided that the existing system uses Drupal 7. For what concerns the configuration of the module, it uses the standard Drupal 7 module configuration elements, which makes it easy to configure and intuitive to use. LTMap is therefore an application that is not only usable and intuitive for the users, but also for the site administrators which decide to integrate LTMap into their existing Drupal website.

7.2 Limitations

Although the final result of the prototype does not correspond fully to the expectations made initially in the concept phase (due to some issues, which were not foreseeable in the initial concept phase), this thesis has presented a concept and a corresponding prototype of a precise and easy to use application, which displays geolocated Tweets around the user’s actual position on an interactive map. The main issue encountered was the plugin structure of the social networks inside the module: due to the fact that it was not possible to integrate all functions needed for the retrieval, storage and display of Tweets into one single PHP file, some features were integrated correctly into a PHP plugin file (twitter.php, as seen in chapter 4.3), while others needed to be carried out in JavaScript and were integrated into the main JavaScript file (main.js, as seen in chapter 4.4). In order to add further social networks in the future, the proposed structure needs to be respected, or alternatively the module structure needs to be reviewed and the Twitter plugin optimized with eventual future enhancements of the Twitter API. This

56 7.3 Future Work unfortunately does not reﬂect the easy plugin structure that was desired for LTMap in the concept phase. Another issue encountered concerns the initial conﬁguration of the module, which is not as intuitive as desired. This applies mainly to the integration of the Twitter API, because the user needs to create a new Twitter application in order for the module to work properly. This must be made manually by the user because no easier method was found for the moment. The last limitation is the number of integrated social networks: it would have been nice to integrate at least one additional social network, in order to allow a more in-depth use of the LTMap module, but this was not possible due to time limitations. Although the purpose of this thesis was to create a very usable application which can be easily expanded in the future, some aspects could not been taken into consideration, as we have seen above. It was preferred to create a fully working system, which can be presented and tested properly and enhanced in the future. Nevertheless an important focus was made on usability, as it was attempted to create an application that is as usable and intuitive as possible.

7.3 Future Work

Even if LTMap provides a very intuitive user interface and a complete set of features, it could be enhanced with some useful additional features. The first useful addition would be a more intuitive plugin structure for integrating additional social networks. This would require a more in depth study of all possible social networks, because each one has its own API and item structure. Also the configuration part of the module could be optimized, by adding for example an OAuth mechanism for the supported social networks, in order to avoid the manual adaptations needed actually (like the creation of a Twitter application). Another useful addition could be the possibility to filter the displayed items by date, or better by a given date range. Additionally, LTMap could give the user the possibility to display all social networks at once, by providing a “Stream” view (in alternative to the provided accordion which allows to display only one social network at a time). This new visualization would display all items of all social networks in a single stream, ordered by date.

7.4 Final Thoughts

This thesis was very interesting to carry out and also very useful to put into practice and enhance the knowledge about web development acquired in the last years, in both university and work experiences. Since web development and social networks are two of my passions, I was very moti- vated to carry out this work. I am very grateful to have been allowed to write this thesis in the PAI group.

57 7.4 Final Thoughts

This thesis also allowed me to realize that some aspects connected to social networks and web development are broader than it may seem. One very complex exercise, which was also one of the most interesting ones, was to enter in a user’s mind and try to optimize the user interface as much as possible in order to provide him a usable application that ﬁts his needs. The exercise became even more complex when functionality and usability entered in conﬂict, because it turned out that a feature-rich application has some needs that are not always compatible with the requirements of a usable application (and the same applies the other way around). This thesis allowed me to learn a lot about Drupal module development, social networks (with their respective APIs), PHP and JavaScript.

58 Bibliography

Bibliography

[AH08] Andy Austin and Christopher Harris. Welcome to a new paradigm. Library Technology Reports, 44:5–7, 2008.

[BDF+10] Matt Butcher, Greg Dunlap, Matt Farina, Larry Garﬁeld, Ken Rickard, and John Albin Wilkins. Drupal 7 Module Development: create your own Drupal 7 modules from scratch. Packt Publ., Birmingham, 2010.

[Buy09a] Dries Buytaert. Download & Extend - Modules, 2009. URL: http://drupal. org/project/modules (last accessed 29.07.2012).

[Buy09b] Dries Buytaert. Download & Extend - Themes, 2009. URL: http://drupal. org/project/themes (last accessed 29.07.2012).

[Buy09c] Dries Buytaert. Drupal CMS Beneﬁts, 2009. URL: http://drupal.org/ features/ (last accessed 29.07.2012).

[Buy12a] Dries Buytaert. hook_block_info, 2012. URL: http://api.drupal.org/ api/drupal/modules!block!block.api.php/function/hook_block_info/ 7 (last accessed 28.12.2012).

[Buy12b] Dries Buytaert. hook_block_view, 2012. URL: http://api.drupal.org/ api/drupal/modules!block!block.api.php/function/hook_block_view/ 7 (last accessed 28.12.2012).

[Buy12c] Dries Buytaert. hook_cron, 2012. URL: http://api.drupal.org/api/ drupal/modules!system!system.api.php/function/hook_cron/7 (last accessed 28.12.2012).

[Buy12d] Dries Buytaert. Hooks, 2012. URL: http://api.drupal.org/api/drupal/ includes!module.inc/group/hooks/7 (last accessed 28.12.2012).

[Buy12e] Dries Buytaert. The Drupal overview, 2012. URL: http://drupal.org/ getting-started/before/overview (last accessed 02.12.2012).

[Cre] Creative Commons. Attribution-ShareAlike 3.0 Unported. URL: http:// creativecommons.org/licenses/by-sa/3.0/ (last accessed 07.08.2012).

[Cue13a] CueBlocks Technologies. Geochirp, 2013. URL: http://www.geochirp.com/ (last accessed 07.03.2013).

59 Bibliography

[Cue13b] CueBlocks Technologies. What is GeoChirp, 2013. URL: http://www. geochirp.com/whatisgeochirp.html (last accessed 07.03.2013).

[DS09] Sebastian Deorowicz and Adam Skórczynski. LaTeX Editor, 2009. URL: http://www.latexeditor.org/ (last accessed 07.08.2012).

[Ell12a] EllisLab, Inc. ExpressionEngine - Overview, 2012. URL: http:// expressionengine.com/overview (last accessed 29.07.2012).

[Ell12b] EllisLab, Inc. ExpressionEngine - Overview - Pricing, 2012. URL: http: //expressionengine.com/overview/pricing (last accessed 29.07.2012).

[Ell12c] EllisLab, Inc. ExpressionEngine - The Big Picture, 2012. URL: http://ellislab.com/expressionengine/user-guide/intro/the_big_ picture.html (last accessed 15.03.2013).

[Fac12a] Facebook. Facebook, 2012. URL: http://www.facebook.com/ (last accessed 11.09.2012).

[Fac12b] Facebook. Facebook Developers - APIs, 2012. URL: http://developers. facebook.com/docs/reference/apis/ (last accessed 15.09.2012).

[Fac12c] Facebook. Facebook Developers - FQL, 2012. URL: http://developers. facebook.com/docs/reference/fql/ (last accessed 15.09.2012).

[Fac12d] Facebook. Facebook Developers - Graph API, 2012. URL: http://developers.facebook.com/docs/reference/api/ (last accessed 15.09.2012).

[Fac12e] Facebook. Facebook Developers - Old REST API, 2012. URL: http://developers.facebook.com/docs/reference/rest/ (last accessed 15.09.2012).

[Fed06] Alexander Feder. Bibtex, 2006. URL: http://www.bibtex.org/ (last accessed 07.08.2012).

[Fio11a] Alexandre Fiori. freegeoip.net for hackers, April 2011. URL: http:// freegeoip.net/static/dev.html (last accessed 07.08.2012).

[Fio11b] Alexandre Fiori. freegeoip.net Web Service, April 2011. URL: http:// freegeoip.net/static/index.html (last accessed 07.08.2012).

[Goo12a] Google. Google+, 2012. URL: https://plus.google.com (last accessed 11.09.2012).

[Goo12b] Google. Google Maps, 2012. URL: https://maps.google.com/ (last accessed 11.09.2012).

60 Bibliography

[Goo12c] Google. Google Maps APIs, June 2012. URL: https://developers.google. com/maps/documentation/ (last accessed 07.08.2012).

[Goo12d] Google. Google Maps JavaScript API v3 - Obtaining an API Key, 2012. URL: https://developers.google.com/maps/documentation/ javascript/tutorial#api_key (last accessed 16.02.2013).

[Goo12e] Google. Google Maps Javascript API V3 Reference, August 2012. URL: https://developers.google.com/maps/documentation/javascript/ reference (last accessed 07.08.2012).

[Goo13] Google. Google Maps Example - Bd de Pérolles 90, Fribourg, Switzerland, 2013. URL: http://goo.gl/maps/PLIZN (last accessed 07.03.2013).

[Gro13] Growl. Growl, 2013. URL: http://growl.info/ (last accessed 15.03.2013).

[GWH07] Scott A. Golder, Dennis M. Wilkinson, and Bernardo A. Huberman. Rhythms of Social Interaction: Messaging Within a Massive Online Network. In Charles Steinﬁeld, Brian T. Pentland, Mark Ackerman, and Noshir Contractor, editors, Communities and Technologies 2007, pages 41–66. Springer London, 2007.

[Ho11] Don Ho. Notepad++, 2011. URL: http://notepad-plus-plus.org/ (last accessed 07.08.2012).

[hos12a] hostip.info. Download the IP Addresses Database, 2012. URL: http://www. hostip.info/dl/index.html (last accessed 07.08.2012).

[hos12b] hostip.info. Using the IP Addresses database - IP Address Lookup, 2012. URL: http://www.hostip.info/use.html (last accessed 07.08.2012).

[HP10] Hui-Yi Ho and Hung-Yuan Pan. Use behaviors and website experiences of facebook community. In International Conference On Electronics and Infor- mation Engineering (ICEIE), 2010, pages V1–379 –V1–383, 2010.

[HRW08] Bernardo A. Huberman, Daniel M. Romero, and Fang Wu. Social Networks that Matter: Twitter Under the Microscope. CoRR, December 2008.

[Hun12] Lee Hunter. Creating Drupal 7.x modules, July 2012. URL: http://drupal. org/node/361112 (last accessed 07.08.2012).

[IET12] Yohei Ikawa, Miki Enoki, and Michiaki Tatsubori. Location inference using microblog messages. In Proceedings of the 21st international conference companion on World Wide Web, WWW ’12 Companion, pages 687–690, New York, NY, USA, 2012. ACM.

[ipi12a] ipinfodb.com. IP Address Geolocation JSON API, 2012. URL: http: //ipinfodb.com/ip_location_api_json.php (last accessed 07.08.2012).

61 Bibliography

[ipi12b] ipinfodb.com. IP Address Geolocation XML API, 2012. URL: http:// ipinfodb.com/ip_location_api.php (last accessed 07.08.2012). [Jab12] JabRef. JabRef reference manager, 2012. URL: http://jabref. sourceforge.net/ (last accessed 07.08.2012). [Kaa03] Eija Kaasinen. User needs for location-aware mobile services. Personal Ubiq- uitous Comput., 7(1):70–79, May 2003. [KLPM10] Haewoon Kwak, Changhyun Lee, Hosung Park, and Sue Moon. What is Twitter, a Social Network or a News Media? In Proceedings of the 19th international conference on World wide web, WWW ’10, pages 591–600, New York, NY, USA, 2010. ACM. [Lew91] James R. Lewis. Psychometric evaluation of an after-scenario questionnaire for computer usability studies: the ASQ. SIGCHI Bull., 23(1):78–81, 1991. [LSdV+11] Wen Li, Pavel Serdyukov, Arjen P. de Vries, Carsten Eickhoﬀ, and Martha Larson. The Where in the Tweet. In Proceedings of the 20th ACM international conference on Information and knowledge management, CIKM ’11, pages 2473–2476, New York, NY, USA, 2011. ACM.

[Map12] MapQuest. MapQuest, 2012. URL: http://developer.mapquest.com/ (last accessed 07.08.2012). [Mar10] Aron Martinez. eGlossar - Ein webbasiertes Glossar unter Nutzung von Web 2.0 und Web 3.0. Bachelor thesis, University of Fribourg, 2010.

[Max12a] MaxMind. GeoIP Downloadable Databases, 2012. URL: http://dev. maxmind.com/geoip/downloadable (last accessed 07.08.2012). [Max12b] MaxMind. GeoIP JavaScript, 2012. URL: http://dev.maxmind.com/geoip/ javascript (last accessed 07.08.2012). [Max12c] MaxMind. GeoIP Web Services, 2012. URL: http://dev.maxmind.com/ geoip/web-services (last accessed 07.08.2012). [Max12d] MaxMind. GeoLite Free Downloadable Databases, 2012. URL: http://dev. maxmind.com/geoip/geolite (last accessed 07.08.2012). [Mer07] Meridian World Data, Inc. Distance Calculation, 2007. URL: http: //www.meridianworlddata.com/Distance-Calculation.asp (last accessed 22.12.2012).

[Mic11] Microsoft. Bing Maps, 2011. URL: https://www.microsoft.com/maps/ developers/web.aspx (last accessed 07.08.2012). [Moz10] Mozilla. Firebug, 2010. URL: http://getfirebug.com/ (last accessed 07.03.2013).

62 Bibliography

[Nok12] Nokia. Nokia Maps, 2012. URL: http://maps.nokia.com (last accessed 07.08.2012).

[OP12] Tracy Osborn and Andrey Petrov. Tweography, 2012. URL: http://www. tweography.com/ (last accessed 21.08.2012).

[Ope12a] Open Source Matters. What is joomla?, 2012. URL: http://www.joomla. org/about-joomla.html (last accessed 15.09.2012).

[Ope12b] OpenStreetMap. OpenStreetMap API, May 2012. URL: http://wiki. openstreetmap.org/wiki/API (last accessed 07.08.2012).

[OPHS11] Tobias Oetiker, Hubert Partl, Irene Hyna, and Elisabeth Schlegl. The Not So Short Introduction to LATEX 2ε– Or LATEX 2εin 157 minutes, version 5.01 edition, 2011. URL: http://www.ctan.org/tex-archive/info/ lshort/english/ (last accessed 30.07.2012).

[php12] phpMyAdmin devel team. phpmyadmin, 2012. URL: http://www. phpmyadmin.net/home_page/ (last accessed 07.08.2012).

[PRP11] Savan K. Patel, V.R. Rathod, and Satyen Parikh. Joomla, Drupal and Word- Press - a statistical comparison of open source CMS. In 3rd International Conference on Trendz in Information Sciences and Computing (TISC), 2011, pages 182 –187, 2011.

[RBeA10] A. Rio and F. Brito e Abreu. Websites Quality: Does It Depend on the Appli- cation Domain? In Quality of Information and Communications Technology (QUATIC), 2010 Seventh International Conference on the, pages 493–498, 2010.

[Rub12] Ruby. Ruby Programming Language, 2012. URL: http://www.ruby-lang. org (last accessed 10.09.2012).

[SEC12] SECDatabase.com. Facebook Current Report, Form 8-K, (July 26, 2012), July 2012. URL: http://edgar.secdatabase.com/700/119312512316895/ filing-main.htm (last accessed 11.09.2012).

[Sei12] Kai ’Oswald’ Seidler. XAMPP, 2012. URL: http://www.apachefriends. org/en/xampp.html (last accessed 07.08.2012).

[She09] Nischal Shetty. Tweography – your tweets on a map, December 2009. URL: http://www.twi5.com/tweography-your-tweets-on-a-map/ 7902/ (last accessed 11.08.2012).

[Sta12a] Stateless Systems. Trendsmap, 2012. URL: http://trendsmap.com (last accessed 30.07.2012).

63 Bibliography

[Sta12b] Stateless Systems. Trendsmap - About/FAQ, 2012. URL: http://trendsmap. com/about-faq (last accessed 30.07.2012).

[Sta12c] Stateless Systems. Trendsmap - Locations, 2012. URL: http://trendsmap. com/local (last accessed 30.07.2012).

[Sub12] Sublime Text. Sublime Text 2, 2012. URL: http://www.sublimetext.com/2 (last accessed 07.08.2012).

[SW12] Manuela Schmidt and Paul Weiser. Web Mapping Services: Development and Trends. In Michael P. Peterson, editor, Online Maps with APIs and WebServices, Lecture Notes in Geoinformation and Cartography, pages 13–21. Springer Berlin Heidelberg, 2012.

[TA08] Thomas Tullis and William Albert. Measuring the User Experience: Collect- ing, Analyzing, and Presenting Usability Metrics. Morgan Kaufmann Publish- ers Inc., San Francisco, CA, USA, 2008.

[TDC12] Jamie Taylor, Joseph Devlin, and Kevin Curran. Bringing location to ip addresses withip geolocation. Journal of Emerging Technologies in Web Intel- ligence, 4(3), 2012.

[The12] The jQuery Foundation. jQuery: The Write Less, Do More, JavaScript Li- brary, 2012. URL: http://jquery.com/ (last accessed 07.08.2012).

[Twi11a] Twitter. OAuth FAQ, July 2011. URL: https://dev.twitter.com/docs/ auth/oauth/faq (last accessed 11.08.2012).

[Twi11b] Twitter. Twitter Developers - OAuth FAQ, 07 2011. URL: https://dev. twitter.com/docs/auth/oauth/faq (last accessed 28.02.2013).

[Twi12a] Twitter. Create an application, 2012. URL: https://dev.twitter.com/ apps/new (last accessed 16.02.2013).

[Twi12b] Twitter. Twitter, 2012. URL: https://twitter.com/ (last accessed 11.09.2012).

[Twi12c] Twitter. Twitter Developers - Getting Started, 05 2012. URL: https://dev. twitter.com/start (last accessed 28.07.2012).

[Twi12d] Twitter. Twitter Developers - Rate Limiting, 07 2012. URL: https://dev. twitter.com/docs/rate-limiting/1 (last accessed 28.02.2013).

[Twi12e] Twitter. Twitter Developers - REST API Resources, 07 2012. URL: https: //dev.twitter.com/docs/api (last accessed 28.07.2012).

[Twi12f] Twitter. Twitter Developers - The Streaming APIs, 05 2012. URL: https: //dev.twitter.com/docs/streaming-apis (last accessed 28.07.2012).

64 Bibliography

[Twi12g] Twitter. Twitter Developers - Using the Twitter Search API, 07 2012. URL: https://dev.twitter.com/docs/using-search (last accessed 28.07.2012).

[Twi12h] Twitter. Twitter Developers - Web Intents, 08 2012. URL: https://dev. twitter.com/docs/intents (last accessed 31.01.2013).

[Vrá12] Jakub Vrána. Adminer - Database management in single PHP ﬁle, 2012. URL: http://www.adminer.org/ (last accessed 07.08.2012).

[VS05] Boris Veytsman and Bernd Schandl. nomencl - A Package to Create a Nomenclature, 2005. URL: http://www-h.eng.cam.ac.uk/help/tpl/ textprocessing/nomencl.pdf (last accessed 28.12.2012).

[W3C12] W3C. Geolocation API Speciﬁcation, May 2012. URL: http://www.w3.org/ TR/geolocation-API/ (last accessed 07.08.2012).

[Wor12] Wordpress. Wordpress - Features, 2012. URL: http://wordpress.org/ about/features/ (last accessed 15.09.2012).

[Yah12a] Yahoo. Yahoo! Maps, 2012. URL: http://maps.yahoo.com/ (last accessed 07.08.2012).

[Yah12b] Yahoo. Yahoo! Maps Web Services, 2012. URL: http://developer.yahoo. com/maps/ (last accessed 07.08.2012).

[Yah12c] Yahoo. Yahoo! Placemaker Beta, 2012. URL: http://developer.yahoo. com/geo/placemaker/ (last accessed 11.08.2012).

[ZM12] Carlo Zapponi and Andreas Markdalen. A World of Tweets, 2012. URL: http://aworldoftweets.frogdesign.com/ (last accessed 11.08.2012).