Presentation Layer

At the top of the three-tier architecture is the presentation layer. It consists of a thin client, which is the Android mobile news app, named Habito News.

Habito News is a prototype mobile news app implemented in the Android plat- form with a twofold objective. First, it will be used as the research tool to explore news reading interaction by deploying it to collect users’ interaction data that sub- sequently will be analysed to construct a user model. Second, it will be used to demonstrate an adaptive news app in which the user interface and interaction auto- matically adapt according to users’ news reader type.

4.2. Three-tier Architecture 75

Figure 4.3: Habito News screens during the registration phase.

Habito News Baseline version : It mimics the BBC news app in terms of its layout organisation of headlines and news stories presentation. News stories are organised in rows of thumbnails and there are eleven news categories in which the user can select to read news. Primarily, the choice to mimic the BBC news app layout was because it is representative of news app interface designs and a widely used news app with more than five million downloads1 on Google’s marketplace. Figure 4.4 depicts how Habito News baseline version displays news headlines and the article’s story compared to the BBC news app. Figure 4.3 depict the screens during the registration phase and information collected through a built-in questionnaire that will be discussed in Chapter 5.

All the development of the app was done on Android Studio version 2.3, with Java language for application programming and XML markup for displaying the user interface. All the communication between the presentation and service layer is achieved through a RESTful API, which exposes methods to retrieve and store data in the database (i.e. Data access layer). It defines the client’s app five components

Figure 4.4: Left: News headlines organisation, Right: News article presentation. Both compare Habito News to BBC news app.

as follows:

1. UI Components: A set of Android views and widgets responsible for render- ing, manipulating and displaying the content (e.g. headlines, news content). Among the most popular views such WebViews and Adapters, a particular view, a ViewPager, was implemented, which allows more accurate scroll ges- ture directions to be obtained as opposed to a regular view component. This was important, as we are interested in capturing all possible interactions with the interface as accurately as possible.

The horizontal rows of thumbnails are simply multiple ViewPager adapters that define placeholders for the article’s thumbnails. Implementing it in that particular way allows us to locate which articles were browsed or seen (post interpretation and approximation based on the item reached in each horizontal ViewPager). It will be further discussed during the feature extraction process (Section 5.3.2.1 in Chapter 5).

2. Interaction Logger: A lightweight background service that collects data as- sociated with users’ interactions with the user interface and context related in terms of GPS coordinates and data from Google’s Activity Recognition API (Note: All data collected will be discussed in Chapter 5). It stores the data in the Data access layer through the RESTful API, which defines methods that

4.2. Three-tier Architecture 77 are exposed in the web services layer (i.e. Interaction logger methods). As explained for the previous components, we are interested in low-level interac- tions with the user interface, and thus the logger captures from swipe events to precise scroll positions to open/close windows and others. The service also considers battery-life limitations of smartphones, and thus it was designed in a way for the impact on a phone’s performance to remain negligible. It does not, therefore, send requests to a server frequently rather it stores data locally and transfer it in short bursts.

3. RSS Feeder: A component, which is responsible for retrieving the news feed from the public BBC API. It is an asynchronous background task that receives the news feed to and populates it in the UI components. The component is implemented asynchronously in order to be transparent to the user without interrupting user’s news reading experience and not to block the user interface from displaying the news articles. It utilises an external open source library2 that implements a SAX (Simple API for XML) parser, which is responsible for reading and interpreting the XML feed.

4. Adaptation Mechanism (AM): It is responsible for retrieving users’ news reader type and generating on the fly an adaptive user interface based on a set of adaptation rules.

The AM communicates with the API (Appendix D - Method #13) to retrieve a user’s type, as it was inferred from the User Modelling component in the server side in a form of percentages. Chapter 6 explores two different ap- proaches on how the set of adaptation rules were generated. A single rule is defined by a name, which is an identifier for the rule, the three news reader types percentages, represent how close/related it is with each news reader type and a list of features associated with that rule. The features represent a single user interface region/area, related within Navigation level features or Reading level features. The skeleton of a rule is an XML format is given below:

<?xml version="1.0" encoding="utf-8"?> <rule> <name></name> <trackerPercent></trackerPercent> <reviewerPercent></reviewerPercent> <dipperPercent</dipperPercent> <features> <feature></feature> <feature></feature> <feature></feature> <feature></feature> <feature></feature> </features> </rule>

The user type is divided into three percentages representing the three types (e.g. Trackers 60%, Reviewers 25%, Dippers 15%) (it will be further dis- cussed in Chapter 6). It defines methods for parsing those percentages and reading a rules.xml file in which the adaptation rules are stored. The adap- tation rules are discussed in Chapter 6. At this point, as Figure 4.5 de- picts, the AdaptInterfaceActivity class loads the list of features (Appendix D - rules.xml), setting flags and populated lists that will be used by the next Activity to be called. For example, depending on the main layout news head- lines organisation in the feature list, the appropriate Activity is called, i.e., MainActivityTrackers, MainActivityReviewers or MainActivityDippers. The setting flags enabled the user interface generation to be dynamic, as the Ac- tivity loads the relevant View from the layout xml files and attaches it to the Activity view to construct the user interface. For example, a flag was used for the top static area for each of the three news headlines’ organisation to indicate whether this user interface region should present tracked article, a search box feature, or no feature at all. Similar flags were used for other user

4.2. Three-tier Architecture 79

Figure 4.5: Adaptation mechanism Flow diagram of the automatic generation of the user interface (Initialisation stage in red, News Headlines Organisation in green and News Articles Presentation in blue).

interface regions. Chapter 6 discusses the design generation and the different user interface regions in detail.

Likewise, a handler was implemented in the ArticleActivity, which is respon- sible for matching user interface features in each reading level based on a user’s news reader type. Details about the different user interface features are provided in Chapter 6. A news article is divided into three levels with each level presenting different information of the article (similar to the Elas- tic News project (BBC RD, 2014)). When the user clicks to read an article, the ArticleActivity is launched, which is different for each news reader type and reflects their characteristics. The activity displays a TabView that con- sists of three tabs implemented as Fragments (LevelOneTab, LevelTwoTab, and LevelThreeTab). The choice of fragments preferred, as multiple screens (levels) could be implemented under the same activity, thus makes the article

activity more lightweight, as opposed to loading a new activity for each level. The HTML content of the news article (as loaded from the RSS feeder) is parsed into the correct format for the WebView present on all the three frag- ments while the tabs load. The three tabs correspond to the levels associated with the amount of the article’s content displayed to the user (again, Chapter 6 presents the reading level features). For example, as the user progresses from one level to another, more of the article’s story and different visualisation and features are applied to the content. The user also has the option to navigate back and forth tabs, not necessarily in a linear way, but any tab is enabled to be selected. Of course, the idea is to provide different visualisation and additional text as the user progresses through the tabs in order to facilitate a better reading experience.

It is also important to mention that different external APIs were used to imple- ment different reading level features such as a summarisation API, keyword extraction, wordcloud, and an according-style presentation of background in- formation related with the news article. All these features shared a common functionality, the HTTP request to the relevant API. An Android Volley tool was used to make the HTTP requests to external APIs as it allowed for mul- tiple concurrent connections. For example, in the case of the accordion back- ground information feature with the concurrent Wikipedia API requests. It adds a new request to the queue, populates the headers and additional API’s parameters before making the call, and then provides a method to handle the response. Further, another common functionality between reading level fea- tures was the extraction of the news article’s text. The JSoup library was used for that purpose, which provides an easy way to manipulate HTML content. 5. Session Management: It is responsible for managing user authentication and

maintaining the continuity of news reading sessions. It generates a Univer- sally Unique Identifier (UUID) that represents a 128-bit long value, which guarantees uniqueness across time and space. It therefore, provides a way to keep track of individual and unique news reading sessions. Further consider-

4.2. Three-tier Architecture 81 ations about a user’s session needed to be taken into account based on how Android lifecycle works and the differences between home button and back button. By default, pressing the back button means that the destroy method will be triggered, whereas the home button pauses the activity, and thus it stays alive in background. Given this behaviour we reset a user’s session only when the back button is pressed, whereas we treat home button as a pause and perhaps a continuation to the current reading session.