1 Introduction

The last two decades have seen a fast migration of communications, end-user terminals, storage devices and so on, from analog to digital. Perhaps, the unique technological sector that has marginally felt such a change has been terrestrial TV broadcasting. Though digital satellite television has gained a conspicuous part of the market, especially in suburban or mountain regions, it has not substituted analog TV but has often integrated it by providing thematic channels and pay-per-view services. A similar consideration can be done for IPTV, Web-based TV (e.g YouTube, Vimeo) and P2P TV (e.g. Joost, Babelgum, Current TV) that although they offer different capabilities from user’s point of view (i.e. video on demand for Web TV and P2P TV), are limited by the unavailability of broad-band connections and, above all, are not still used by most of persons usually watching analog TV. Generally speaking, it can be said that analog TV, even if new digital ways to deliver television signals exist, has not lost its importance but only complemented and integrated. The switch-off of terrestrial analog TV signals, made basically by imposition (for instance the ultimate date for the completion of the transition to digital in Europe has been set to the end of 2012), has practically determined the advent of digital terrestrial television. This will complete the process of digital convergence, bringing along its real treasure: its enormous community of users. In this scenario, it will be possible to also convey interactive services to a number of persons onto a well-known device such as television. In this case, tools designed to enrich the user experience [7, 26] suddenly become a factor enabling a first step in the reduction of the digital divide, or at least in helping to bridge the gap separating entire communities and users groups (due, for example to economical, cultural or age reasons) from the access to information and communication technologies. Furthermore, the pervasive broadcasting infrastructure will result in a proper networking infrastructure, enabled to provide access to telematic services and interactive applications [28]. In particular, digital terrestrial TV seems to be a favorable solution to actually lead people, affected by digital divide, to experience basic Internet access in a familiar environment by adopting usual instruments such as a remote control.

In this paper we demonstrate the feasibility of Internet and Digital Terrestrial Television integration by proposing a web browser prototype which is able to access web contents through TV. The web browser, named WebClimb has conventional web browser features and enables an user to display a web page on the World Wide Web and interact with texts and images, without reformatting and compressing web content on the server side. One of the main feature is that Web Climb is an MHP (Multimedia Home Platform) application to be broadcast through a TV channel and not embedded in a specific device, though it could be too. This allows TV broadcasters to provide an Internet access service independently from the final user’s device. The whole system has to be seen in the context of a multichannel access and has not to be considered in comparison with other devices like laptops or i-phones.

This paper is organized as follows. After presenting some fundamentals of digital terrestrial television and MHP in Section 2 and reviewing some related works in Section 3, we introduce in Section 4 the system requirements and the proposed model architecture, describing the three major layers that compose it in Sections 4.1, 4.2 and 4.3 respectively. Finally the design patterns and the GUI are discussed in Section 5, experiments and results are presented in Sections 6 and 7 concludes the paper.

2 Some issues on DVB and MHP

There are many standards to manage interactive and digital television technology. In Europe, Asia, Australia, part of Latin America and some countries of Africa the Digital Video Broadcasting (DVB) [31] has been adopted, whereas the OpenCable Application Platform (OCAP) and the ATSC’s Advanced Common Application Platform (ACAP) represent the standards that are leading the TV innovation in the United States. The Integrated Services Digital Broadcasting (ISDB) is active in Japan and DMB (Digital Multimedia Broadcasting) is used in China. Another interesting standard is the ISDTV (International Standard for Digital Television) [12] being adopted as Brazilian system for digital terrestrial TV based on ISDB standard.

In our work, we focus on the European DVB standardFootnote 1 and then in the following we will briefly discuss some of the main parts of the standard, with particular reference to Multimedia Home Platform (MHP) that is an open and interoperable middleware specification for interactive TV [34]. MHP defines a generic interface between interactive digital applications and the terminals where these applications run. This interface decouples different provider’s applications from the specific hardware and software of the different MHP terminal implementations [35].

In addition to this, DVB specifies Java technology as the application environment language and PersonalJava as the virtual machine that provides a subset of the Java 2 platform (it is almost equivalent to Java Development Kit 1.1.8). DVB also defines a suite of APIs that includes most of the Java TV API, HAVi User Interface, DAVIC (Digital Audio Video Council) APIs and DVB APIs. The applications, controlled by the MHP middleware, are called DVB-J applications or Xlets and they can be either resident in the STB or downloaded from an object carousel of a TV channel.

Recently MHP introduced a framework named GEM (Globally Executable Multimedia Home Platform) [11] intended to harmonize all the different standards, described at the beginning of this section, in an unique and common system. GEM is based on MHP 1.0.2 without the DVB specific parts, introducing a worldwide and shared core middleware definition. Moreover most of the different middleware adopted by each standard are compatible with GEM (e.g GINGA [33] by the Brazilian Standard). The GEM grants that digital television applications will be independent from the broadcasting framework [2], maximizing the compatibility and portability among different middleware. So a content provider can build an OCAP or GINGA application and be relatively confident that it will take only a few changes to get it working in MHP, ACAP, and any other GEM-based standard.

Two MHP standards exist: MHP 1.0.x [9] and MHP 1.1.x [10]. The main differences between each other are described in [32] and in [25]. The basic aspect that is important hereafter is that a new profile, the Internet Access [17, 18], has been added in MHP 1.1 to the already existing profiles, such as Enhanced Broadcast and Interactive Broadcast (see Fig. 1).

Fig. 1
figure 1

MHP profiles [4]

The Interactive Broadcast and Internet Access profiles include support for the return channel in the MHP receiver, so it enables a range of interactive services connecting the receiver with the external world. The return channel can be a PSTN line, ADSL or else. The MHP specifications defined that this connection has to support TCP/IP protocol, instead support for HTTP protocol is not mandatory. It is important to point out that MHP 1.1 platform can also deal with applications written in DVB-HTML, that is a combination of a subset of WWW standards (XHTML 1.1 modules, CSS2 etc.).

Currently, the MHP test suite used to evaluate the compliance of commercial set-top boxes is based only on MHP 1.0, so no MHP 1.1 test suite exists. So far set-top-boxes on the market only support MHP 1.0, consequently, there are no boxes that support the Internet Access Profile. Therefore an alternative manner to provide the support for Internet applications (e.g web browsing) could be to allow the end-user to download from the TV object carousel a web browser as a DVB-J application.

In this paper such a solution is presented. We develop a DVB-J application, MHP 1.0.x compliant that, for this reason, can be utilized by all the STBs today on the market or previously acquired. This application, named WebClimb, allows to access the Internet through the use of the return channel that the Interactive Broadcast Profile makes available. WebClimb could be embedded on the set-top-box itself or downloaded from the broadcast TV carousel similarly to an usual MHP application. In this case an MHP application could be broadcast by different TV channels and the services such application offer to the users can drive the interests of TV watchers. Doing so for a TV channel, providing an Internet access on television would be an important add-on which could grow the number of its users.

3 Related works

Concerning web browser for digital terrestrial television, proprietary solutions are made available by companies such as Oregan Networks,Footnote 2 Microsoft (MSN TV)Footnote 3 and others in order to achieve Internet access on TV. However, all these solutions are not open standard and propose, instead, a proprietary solution based on a specific hardware equipment (STB) already endowed with a custom-made software. Anyway, some commercial applications compliant to DVB-MHP standard exist. Such platforms, named Interactive TV platforms, were born mainly for the development of MHP services by acting as an engine to render applications written by using standard well-known languages such as HTML or XHTML and avoiding to deal with Java programming language. Due to this, Interactive TV platforms can therefore manage web pages and act as a browser.

In Table 1 some Interactive TV platforms features are summarized.

Table 1 The DVB-MHP Interactive TV platforms

These systems appeared in early 2000s and currently little has changed. These solutions remain the only effort in the direction of a digital terrestrial television web browser based on the DVB-MHP standard. Since each of these systems has some limitations, the solution proposed in this paper is placed to overcome these problems in order to provide a comprehensive system. For instance, Pontegra BrowserFootnote 4 and Ortikon Ace Browser platformsFootnote 5 are able to display only a specific subset of DVB-HTML documents, consequently just a negligible fraction of common web pages is effectively displayable on a TV screen through these systems.

On the contrary, Yambo,Footnote 6 released by CINECA, is only able to deal with a non-standard XML document, specified by CINECA itself. A few plug-inFootnote 7 have been developed to adapt existing content management systems such as Joomla or Moodle to produce content in the format supported by Yambo. At the current state of implementation, the only publication format is a fixed template for a limited quantity of text and images in a preset layout. Moreover most of these applications, including Sofia Backstage Browser PlatformFootnote 8 and Goonie Browser,Footnote 9 were not born for browser purposes and most of them do not show a real user interface. Evo BrowserFootnote 10 is an example of an embedded web browser used within IPTV set-top-boxes. The browser applications used in IPTV terminals make use of specialized web content, in general created and managed by a proprietary CMS, tightly coupled to the end user platform. The basis technologies used are HTML, CSS and Javascript, but the content is formatted and presented depending on the specific features available on the user appliance.

Another example of embedded browser is the Elsag browserFootnote 11 which is a proprietary application and it is resident on Elsag STBs, so it is usable exclusively on this kind of device. There are also research works in this direction such as the solution proposed in [8] where the authors designed an integrated web browser for digital home networking and digital data broadcasting based on ACAP standard instead of DVB standard. Anyway the use of native browser is a solution widely adopted in mobile phones [37] and sometimes is used in set-top-boxes. In general, this kind of applications are ad-hoc applications depending upon the hardware. On the contrary, the use of an application downloadable from a TV broadcast signal grants the independence from the end-user terminal. Moreover STBs for DTT were thought like low price devices and the integration of a native browser could cause a price increase, instead in the other case the application fruition is free of charge for the user. Another idea to achieve Internet-TV convergence is to convert Web content and simplify information format before displaying on TV screen as it commonly happens in mobile browser like Net Front.Footnote 12 In such a case a client/server architecture optimizes web pages before sending them to the client device. In [13] and [14] such solution is explored. This sort of approach requires the usage of a server-side application gateway acting as a web-spider to collect a predefined set of web contents and reformatting them to fit the constraints of the TV environment. The converted contents are then transmitted via the TV carousel. In general, this approach is useful in the production and management of the so called “walled garden services”, where the broadcaster or service operator is able to control and validate the contents to be accessed by the user but can become extremely cumbersome in the access to the open Internet. An interesting work regarding the design and the implementation of a Java browser is [36], where a Java-based XML browser, named XSmiles is proposed. The efforts in [36] and then carried on in [20] are devoted to create a common device independent platform for multimedia applications designing a graphical user interface framework for digital terrestrial television [5, 6]. This framework is dedicated to the next generation set-top-boxes. The XSmilesFootnote 13 browser works completely in JDK 1.2-1.4 and partially in JDK 1.1.8 and there was an attempt for porting a limited version of X-Smiles on a MHP compliant digital television set-top-boxes but the current state of this attempt is unknown.

Furthermore, it is worth pointing out that in the Internet world few web browsers, completely written in Java, exist and most of them require runtime version like J2SE 5 (JDK 1.5), one example of this is Lobo.Footnote 14 It is immediate to understand that this runtime version is not compatible with STB runtime which is lower (JDK 1.1.8).

All these works raise important issues, such as:

  • some applications are only embedded in STB (resident application) such as Evo Browser. This kind of application is custom-made and hardware dependent since the web browser is not an add-on application on the TV channel.

  • the Interactive TV Platforms do not present a GUI interface (i.e. Sofia and Goonie browser) and some of these applications display a subset of DVB-HTML (i.e Pontegra and Ace Browser) or non-standard XML pages (i.e Yambo).

  • some applications use proxy server for information transcoding, such as NetFront, and this solution does not allow an adequate and authentic visualization of the web pages.

  • in [14] the “transcoded” web contents are pushed onto TV carousel and then broadcast to TV watchers; this solution does not allow an Internet access independently, from the TV carousel and the broadcaster.

  • some existent Java browsers are not compliant with STB runtime environment (i.e. Lobo, XSmiles).

All these issues influenced our thinking in designing WebClimb which wraps all these features described above getting a comprehensive system. WebClimb, as said in Section 1, is a DVB-J application on DVB-J platform (JDK 1.1.8), MHP 1.0.x compliant, and can be downloaded by the broadcast TV signal or, alternatively, could be embedded in a STB, and locally executed. It permits to properly manage web contents, without a server-side conversion, and visualize them on a TV screen, by means of a Graphic User Interface (GUI). The Internet connection is performed through STB’s return channel. Basically, WebClimb is an XHTML browser and assures a fine visualization for any XHTML web page but it can also manage HTML pages composed by XHTML tag [30]; tags not recognized by the application are ignored. Since the web provides data that do not necessarily have to be displayed as web pages on the television screen, WebClimb performs (on the client side) a web content filtering. In the future it will be explored an adaptation technique rather than a simple web content filtering. In particular during WebClimb design, specific care has been dedicated to consider the limitations imposed by the TV set: low screen resolution and reduced interactivity due to the device the user has at his disposal (usually only the remote control). In fact contrarily to what happens when using a PC, the television web browser has to be based on a resolution of 720×576 pixels and at most 256 colors, and for the interaction a mouse and a keyboard are not generally available.

4 The system model

In Fig. 2 the system infrastructure is presented: a TV broadcaster transmits the WebClimb application multiplexed on its TV signal to all the receiving STBs (otherwise it could already be on STBs as a resident application).

Fig. 2
figure 2

The system infrastructure

For better comprehend the system functionalities let’s first introduce an usage case. A user, by selecting that specific TV channel supporting such an Internet service, can access to the list of applications provided by the channel and choose WebClimb to navigate the web via the return channel (e.g. telephone line) and the remote control of the STB. Thus content coming from the Internet is now available on the television screen and the user can enjoy web content by interacting with the remote control, sitting on his armchair while watching TV. For instance, if the user, while watching at a football match, wants to know information about a certain football player, he can switch on WebClimb application and access to the net for searching.

So the functional requirements to be satisfied by WebClimb are, intuitively, the Internet access and the web page browsing. The browser will use HTML, XHTML, CSS data and it shall be able to import any valid URL or URI and to save each URL as bookmark. WebClimb shall run on various brand and model of STBs and should be able to comply with DVB-T and MHP 1.0 standards. The standard compliance imposes some constraints, such as application dimension (less than 2 MBytes). Furthermore, additional constraints are imposed by the TV environment such as TV screen resolution. This application will have to be also working in ACAP, OCAP or GEM-based standard with only few changes (as already explained in Section 2), being portable on other platforms. The Java Runtime Environment (JRE 1.1) is the technology to use in order to be compatible with the DVB-MHP platform. WebClimb shall be an Xlet, transmitted by the broadcaster, and so it shall be hardware independent. It will have to be as much as possible easy to be used and easy to be learnt by users, such as elderly persons. In general the users are far from screen and interact via remote control, so in the application a scaling of text and a help section have to be provided.

Now in the remaining part of the section, the overall architecture of WebClimb browser is explained. In Fig. 3 the WebClimb conceptual architecture onto the reference architecture of a web browser proposed in [19] is pictured, where the fundamental subsystems composing the whole system and the relationships between each other are captured. In particular we choose a modular architecture identifying different and independent modules, instead of a compaction-oriented architecture, although the latter solution is the better way to achieve the application minimum footprint. However the modular architecture can aid both during maintenance and at design time of the application. Moreover a modular architecture, as proposed, permits to make the application independent from the use of third party modules. In fact, for example, as soon as smaller module (in size) will be available for the XML parsing, then will be easy to replace the existing module with a new one (see Section 4.2.1). Also a clear separation between the content presentation from the application engine gives the ability to add new operations to existing object structures without modifying those structures. For example it is possible to insert new functionalities regarding the GUI or to allow the rendering of new HTML element in the Layout Engine (see Section 4.2.3) without affecting the rest of the system. The system architecture has influenced also the design pattern used to implement WebClimb as it will be described in detail in Section 5. So our application has a full modular implementation though tries to satisfy the requirement of a small foot-print anyway.

Fig. 3
figure 3

The WebClimb System Architecture. The dark boxes are third party modules

The system architecture, for the sake of simplicity, is composed by three main layers (from bottom to top):

  • Networking

  • Rendering/Layout

  • GUI (Graphical User Interface)

The lower layer (Networking) handles network communication and it manages HTTP/HTTPS connection over return channel. The second layer (Rendering/Layout) performs XHTML data-parsing, creates the data model and then makes rendering on TV screen; finally the GUI level is the application front-end.

4.1 Networking layer

The Networking module (Fig. 4) parses URLs (Uniform Resource Locator) and URIs (Uniform Resource Identifier), coming from GUI layer transparently with respect to Rendering/Layout layer. The WebClimb Networking Manager resolves these URLs and URIs and returns a stream that allows the client to send and receive data.

Fig. 4
figure 4

Networking layer

This module hides to the application higher level that return channel connection takes place by data link protocol Ethernet or PPP, and handles the session management connection through DVB API.

The application level protocol HTTP is implemented by HTTPClient (Apache Jakarta Commons)Footnote 15 which allows to use lower level protocols such as TCP and UDP available through MHP standard. HTTPClient is a library outside the suite of MHP 1.0.x library, since in that platform, as specified in Section 2, support for HTTP is not mandatory.

4.2 Rendering/layout layer

The data obtained by Networking layer are the input for Rendering/Layout layer (in Fig. 5 such an input is represented by the XHTML document) where some processing steps are performed.

Fig. 5
figure 5

Basic data flow in Rendering/Layout layer

4.2.1 Document parsing

A key component of the Rendering Engine is the parsing operation that converts a data stream in a data structure, specifically in a tree structure. The parser, together with the layout engine (later discussed in Section 4.2.3), it is the core of the web browser architecture. Many parsers written in Java language exist; those capable of creating well-formed documents with a small code dimension in terms of memory occupation are to be adopted because of the operational DVB-MHP platform conditions. An XHTML parser, such as JTidyFootnote 16 has been chosen in WebClimb implementation; this external library can handle also non-standard XML like HTML. After parsing, a DOM (Document Object Model) is obtained representing the XHTML page. A parallel step (see Fig. 5) consists in processing the stylesheet linked to the web page, through a third part CSS parser library like SACParserFootnote 17 (Simple API for CSS).

The CSS Parser takes as input the Cascading Style Sheet and outputs a Document Object Model style tree (see Fig. 7) called CSSModel.

4.2.2 Data model and assignment algorithm

In Fig. 6 (left) an XHTML source example is presented and in Fig. 6 (right) our application’s data model, called XHTMLModel, created through one-to-one association with DOM model, obtained as described in Section 4.2.1 is pictured.

Fig. 6
figure 6

XHTML web page example (on the left) and on the right the XHTMLModel

After that, the data model is decorated with style information (see Fig. 7) through the assignment algorithm. In Fig. 8, finally, a decorated model, the XHTML+ CSS Model, is presented.

Fig. 7
figure 7

CSS style sheet linked to XHTML and the CSSModel on the bottom of the figure

Fig. 8
figure 8

The XHTML+CSS Model and its visualization on the viewport

For each element in XHTMLModel the assignment algorithm searches the CSS selectors that match the elements in the document model. Selectors may range from simple element names to rich contextual patterns. If all conditions in the pattern are true for a certain element, the selector matches the element. Then the algorithm assigns to matched element CSS style rule composed by property’s value according to cascading (weight-origin of a style sheet and specificity of a selector) and inheritance rules defined in the Cascading Style Sheet level 2 Specification [29].

4.2.3 Layout engine

The layout engine is the module that takes web content (such as XHTML, image files, etc.) and format information (such as CSS), that is XHTML+CSS Model in Fig. 8, and displays the formatted content on the screen [24]. Our layout engine follows the visual formatting model specification describes in CSS Style Sheet Specification [29].

In the visual formatting model each element belonging to the XHTML+CSS Model generates zero or more boxes according to the box model. The box model describes the rectangular boxes that are generated for each element in the model and laid out according to three positioning schemes: normal flow, floats and absolute positioning. Actually WebClimb supports only normal flow scheme, the others will be implemented in the next future.

In the normal flow scheme, boxes belong to an inline formatting context or to a block formatting context. For example (see Fig. 8): the tag a is an inline element, and so the rectangular box associated is laid horizontally, after the sibling element box; the tag div instead is a block element so the box is laid out the previous box vertically. All the boxes are attached to the containing block inside the viewport (main window of the screen). WebClimb’s viewport resolution is 640×480 pixels so when the viewport is smaller than the initial containing block, the browser offers a scrolling mechanism. All elements in the XHTML+CSS Model know which are the right positions (coordinate points) to fill in the viewport due to the fact that are inline or block elements. Furthermore each element also knows its own dimensions obtained from dimensions of the inner block that composes a containing block (see Fig. 8). Additionally all elements in the XHTML+CSS Model are responsible for rendering themselves drawing appropriate widgets, using the Viewport GUI Toolkit (see Section 5.1) based on AWT and HAVi graphics API.

4.3 Graphical user interface layer

The Graphical User Interface (GUI) has the remote control as input device and television screen as output device. Some policies, described in [3, 27], have been followed during the development of WebClimb graphic interface to answer to the criteria of effectiveness, efficiency and satisfaction in the service navigation, such as separation of the content from presentation and the functional coherence by assigning consistent and unambiguous function to each button of the remote control. According to the DTT accessibility recommendation [1, 22] it is necessary to provide an interface for the text editing. In [21] a study was performed on comparing different text editing interfaces for DTT like virtual keyboard and multi-press interface. On the basis of the consideration emerged from that paper, the virtual keyboard had a smaller number of errors but an higher average time to complete a task compared with the multi-press method. The higher number of errors in multi-press are probably due to the STB latency time at the moment of pressing a button (e.g. password typing) and also to the number of presses required to select a special character.

In another study [16] emerged that there is not a remote-control-based text entry method that is significantly better than the others even if there is a certain preference for the virtual keyboard. So we decided to implement a virtual keyboard to minimize the error rate, privileging the accuracy to the quickness. In addition it is simple to provide WebClimb with both text editing interfaces allowing the user to make a choice. To accomplish the DTT recommendation the color button have been set at the bottom of the screen in horizontal position in the same color sequence as in the remote control, the Back functionality, which allows to switch back to the TV channel, and the Exit functionality to close the application, have been implemented too. Finally the minimum font sizing (18pt), which is required also to avoid graphical flickering effect on the screen, has been respected and an user help has been provided. Focusing on usability, we have kept in mind that the TV remote control is the only device that has to be adopted to control the system at the client side. Consequently the implementation of all functions that are usually provided by a mouse (pointing, clicking, dragging) have to be replaced by actions on the remote control buttons. For example, as already said, a virtual keyboard interface (Fig. 9) has been devised. The user navigates the virtual keyboard on the TV screen using the arrows keys of the interactive keypad and selects the desired alpha-numeric character by pressing the OK button. Once he has selected the character, this appears on the text box area.

Fig. 9
figure 9

WebClimb’s virtual keyboards. a Virtual keyboard for URL editing. b Virtual keyboard for FORM editing

The WebClimb GUI has two navigation levels: the first concerning application user interface and the second concerning the navigation inside the viewport through which the user can move across a web document. The users can switch from one to the other with the pressure of the yellow key button of the remote control (see Fig. 10). The focus of the first level of the GUI components is controlled with the arrow buttons of the remote control and selection is made with OK button. As shown in Fig. 10, the top of the GUI contains the navigation toolbar which shows the current URL and home-page, back and forward buttons as it usually happens in a common browser interface. In the center of the GUI there is the content area (viewport). At the bottom of the GUI there are, as said before, the color buttons: red button exits the application, green button activates the menu, yellow button enables switching of the two navigation levels (as previously explained) and blue button allows to go back to the TV stream. Dragging function through viewport’s scrollbar is performed through the arrow up/down key on the remote control.

Fig. 10
figure 10

Digital television GUI: 1. Main Menu; 2. Content area (Viewport); 3. Navigation Toolbar; 4. Color Button Toolbar (the yellow button enables link navigation within the viewport); 5. Highlight; 6. Scrollbar

Inside the viewport (second navigation level) some GUI components are focusable elements (link, text input, radio button, check box etc.); the user can pass through each focusable element by means of the up-down arrow of the remote control. With the OK button one element is chosen; for example if an XHTML form text input is chosen a virtual keyboard for text editing appear (Fig. 9b). If the OK button is pressed again the inserted text is sent according to the POST or GET method of the tag form. The control remains in the viewport until yellow button is pressed again. The GUI provides other useful features such as the opportunity of adding a web page to bookmarks and the zoom-in/zoom-out font size as a fit-to-width property that automatically reformats and re-sizes content to the viewport. In Table 2, WebClimb innovative features for display optimization have been summarized. In particular the HTTPS and XHTML full support are some of the main innovative features behind the implementation of WebClimb in comparison to others STB browser described in Section 3 and then used in the experimental results provided in Section 6.

Table 2 WebClimb features

5 Design patterns and the GUI

In this section we present the implementation of the architecture described in the previous section. Given the complexity that is behind a browser development it has been necessary to use object oriented design patterns in order to guide the realization of a modular software [15, 23]. The system architecture follows the Model View Controller (MVC) architectural pattern. Using MVC the application is split into separate layers: Model layer represents the data, View is the data presentation and Controller defines the domain logic of the application. The MVC pattern decouples Model and View establishing a publish/subscribe protocol between the Model and the View. Such a protocol is implemented by using the Observer pattern that specifically defines a one-to-many dependency among objects in such a way that when an object changes its state, all its dependents are notified and updated automatically. In our application, the Model is represented by FacadeModel class and the main View is the MBScrollContainer class that represents the Viewport on the television screen (as described in the previous section and shown in Fig. 10). The Controller is an object that, through the controllerLogic() method (see Fig. 11), sets a new URL to the FacadeModel.

Fig. 11
figure 11

The Facade Model and the Controller Logic unit

The FacadeModel object represents the main entry point to the system and it is implemented as a Facade pattern and as a Singleton pattern too. Facade and Singleton patterns provide a single point of access to an instance of FacadeModel object and a single point of maintenance of the system (see Fig. 11). Summarizing the previous concepts: the FacadeModel receives as input the document’s URL (through the controllerLogic() method), a stream is opened, the parser starts to read the stream and generate the DOM, one node at a time; then a data model (XHTMLModel) is created. This one is implemented through a tree structure (Fig. 6 described in Section 4.2.2).

Once the model is created the class XHTMLModel is visited through the Visitor design pattern involving the class VisitorDecorator. VisitorDecorator implements a visit algorithm that cares about decorating each XHTML element in XHTMLModel with CSS information, in order to create the XHTML+CSS Model. Then the VisitorRenderer class (Fig. 12) is implemented by the Visitor design pattern as well; each element in XHTML+CSS Model is visited (e.g. paragraph or body element in Fig. 12) and a draw() method is performed and, if necessary, proper widgets contained in the Viewport GUI Toolkit are painted (see Section 5.1).

Fig. 12
figure 12

The class VisitorRenderer implemented by the Visitor design pattern

5.1 Viewport GUI toolkit

Graphical User Interface (GUI) has been built around a toolkit of widgets (e.g. button, label or list). GUI widget has two main features: the first one is visual presentation and the second one is the reaction of the widget to the user interaction (these are referred as “look” and “feel” respectively).

In digital television environment for graphical purpose, HAVi Level 2 User Interface specification was included in DVB-MHP that uses java.awt package as its core. Not all the classes from AWT package and from HAVi framework satisfy graphical browser’s needs [5]. Therefore a Viewport GUI Toolkit was implemented based on HAVi and AWT package. These widgets are graphical elements that paint themselves on the browser viewport.

In Viewport GUI Toolkit, the event mechanism from AWT was improved to meet digital television needs, for example, to transfer the focus from one widget to another. All the widgets extend org.havi.ui.HContainer and are in charge of rendering themselves and they can be one of the following types:

  • Focusable: widgets that can be navigated using the remote control (e.g. links). Such widgets can also launch action (for example GET/POST method in a form).

  • Selectionable: widgets that allow the selection of an item (e.g. radio button or a list etc.).

  • Text user input: widgets that allow the user to input some text.

6 Experiments and results

Digital television STBs have a restricted run-time environment: they have limited memory and CPU speed so it is important that applications, designed for STBs, have a small footprint. WebClimb’s memory occupation is 1.28 MBytes and using Proguard (Java code optimizer and obfuscator)Footnote 18 its dimension decreases till to 966 KBytes. This size is compliant with DVB-J application’s size, anyway a complete optimization has not been performed yet.

WebClimb prototype was tested with IRT MHP Reference Implementation (M4iTV) an IRT’s Middleware for interactive TVFootnote 19 based on the Version 1.0.3 of the MHP Standard published by ETSI in [9]. M4iTV is a software emulator that permits to verify the correctness of the application’s code and the right visualization on the screen. For this reason it constituted the first phase of the testing environment for this application. In the second testing phase, the application behaviour has been checked on different STBs of diverse brand and model.

6.1 First phase tests on IRT emulator

The first kind of experiments was performed with the use of IRT emulator as explained before: given a test web page, we make a qualitative comparison of the rendering among WebClimb and other browsers, both designed for PC and for STB.

Different types of test pages were used for the experiments. Web pages presenting several features, according to the requirements defined for WebClimb, have been analyzed to investigate malfunctions. In the sequel some of the most significant experiments over quite well-known pages are proposed for comparison. The first case concerns with a structured web page with complex CSS associated with this (e.g. BBC homepage) and the second is a low graphics version of another structured web page (e.g. BBC news web page). The third category are actually XHTML pages: some examples of such a class are Google XHTML web page and San Severo country house web page for their W3C compliance. Finally the fourth typology are mobile web pages (e.g. the Italian newspaper La Repubblica and The New York Times mobile versions).Footnote 20 Figures 13, 14 and 15 show the comparison among WebClimb and PC browsers. In particular WebClimb output (bottom row of each figure) and the results obtained with Microsoft Internet Explorer and Mozilla Firefox browser are proposed. It can be appreciated how the different contents (images, text, etc.) are correctly rendered and located; no alterations of the page intelligibility are registered. After that we have compared WebClimb with some of the browsers presented in Section 3, in particular with Goonie Browser (evaluate version 27-1-2006), XSmiles 1.2, Sofia Digital 1.5.1, Espial Escape 5.1.8 (PDA) version of Evo Browser. It is worth pointing out that only Sofia and Goonie were tested on IRT emulator like WebClimb, so only these browsers work in a real digital terrestrial television environment; XSmiles and Espial Escape demo versions are stand-alone Java applications that work in a PC environment.

Fig. 13
figure 13

Comparison among Internet Explorer (top), Mozilla Firefox (middle) and WebClimb (bottom). Column on the left shows results obtained for BBC home page, on the right BBC News low graphics version is displayed. a Internet Explorer output. b Internet Explorer output. c Mozilla Firefox output. d Mozilla Firefox output. e WebClimb output. f WebClimb output

Fig. 14
figure 14

Comparison among Internet Explorer (top), Mozilla Firefox (middle) and WebClimb (bottom). Column on the left shows the results obtain for Google XHTML web page and on the right San Severo country house is displayed. a Internet Explorer output. b Internet Explorer output. c Mozilla Firefox output. d Mozilla Firefox output. e WebClimb output. f WebClimb output

Fig. 15
figure 15

Comparison among Internet Explorer, Mozilla Firefox and WebClimb for La Repubblica (Italian newspaper) mobile version web page. a Microsoft Explorer output. b Mozilla Firefox output. c WebClimb output

In Fig. 16 (left column) the comparison among WebClimb and these STB browsers is presented when BBC home page is requested. It can be appreciated that WebClimb shows properly web page’s contents, due to the correct implementation of the positioning algorithm following the visual formatting model specification, instead for Goonie and XSmiles an overlapping of the graphical elements on the screen happen (see Fig. 16c and e). On the contrary, Escape, better succeeds in managing images but objects location is often wrong. In Fig. 16 (right column) BBC News low graphics web page is displayed. It is interesting to verify that in this low-graphic case other browsers improve their behaviour approaching WebClimb rendering. Moreover we have to point out that in both web pages (BBC home page and BBC low graphics) an error occurs with Sofia browser during web page loading and for this reason Sofia browser is not reported in Fig. 16.

Fig. 16
figure 16

Comparison among (from top to bottom) WebClimb, Goonie, Sofia, XSmiles and Escape browsers for BBC home page (on the left column) and low graphic version of the BBC News (on the right column). Rendering fails with Sofia browser for both of the web pages then, for this reason, it is not figured. a WebClimb. b WebClimb. c Goonie. d Goonie. e Xsmiles. f XSmiles. g Escape. h Escape

In Fig. 17, WebClimb is compared with the other browsers results in the case of XHTML test pages like Google (left column) and San Severo country house (right column). XSmiles rendering fails when Google XHTML web page was required and Sofia rendering fails on San Severo country house (these failures are not reported in Fig. 17). In particular, it is important to highlight that all browser present a similar behaviour though some errors are registered. Character encoding is correct when using WebClimb and other browsers but this is not true with Escape (as evidenced in Fig. 17h). In fact specific attention has been paid, during WebClimb design, to support different character encoding (e.g UTF-8, ASCII, ISO-8859).

Fig. 17
figure 17

Comparison among WebClimb, Goonie, Sofia, XSmiles and Escape browsers for Google (column on the left) and San Severo country house (column on the right). The rendering fails in XSmiles browser for Google XHTML and in Sofia on San Severo country house web page. a WebClimb. b WebClimb. c Goonie. d Goonie. e Sofia. f XSmiles. g Escape. h Escape

In Fig. 18, La Repubblica web page is presented: all the browsers were able to display this web site, but Goonie browser makes a mistake in character encoding (as highlighted in the Fig. 18b) and Sofia browser presents a very disturbing overlapping of the graphical elements on the screen (Fig. 18c).

Fig. 18
figure 18

Comparison among Escape, Goonie, Sofia, XSmiles and WebClimb browsers for La Repubblica (Italian newspaper) mobile version. a Escape. b Goonie. c Sofia. d XSmiles. e WebClimb

Finally, Fig. 19 presents results for The NYTimes (mobile version) web page:Footnote 21 in this case a processing error occurs in all browsers but WebClimb and Escape. These tests confirmed the ability of the proposed solution in displaying and presenting different kinds of web contents properly due to a modular application design that permits to operate in a focused way in each browser components. With respect to other browsers, WebClimb offers a clear presentation of the information contents thanks to the right handling of character encoding and also to the management of the graphical elements on the screen. WebClimb behavior has been verified on pages of disparate categories giving positive results generally.

Fig. 19
figure 19

Comparison between WebClimb and Escape in the case of The NY Times mobile version web page. The other browsers (Goonie, Sofia, XSmiles) gets a failure. a WebClimb. b Escape

6.2 Second phase tests on STBs

A second experiment was performed downloading WebClimb prototype on real STBs by means of a TV broadcasting platform and evaluating it on a real DVB-T system.

In this circumstance we have carried out a quantitative evaluation of the performances in an actual operative environment. We tested WebClimb’s behavior on different STBs: DiPro DP-001 InteractI, ADB X75-T (terrestrial MHP development Set Top Box), i-Can 5100TX, Elsag Aries 1000H, Telesystem TS7.0DT and Humax DTT-3500.Footnote 22 The first, the second and the third are three ADB’s different models and since ADB is one of the main producer of STBs, with over 10 million digital set-top-boxes sold worldwide, this test was particularly fundamental to check WebClimb compatibility. Elsag Aries 1000H was chosen due to its memory features, that is the highest respect with to others STBs. The main differences among these STBs are shown in Table 3; in particular the flash memory, which ranges from 8 MBytes memory to 32 MBytes, the RAM (from 40 MBytes to 128 MBytes) and the Internet connection that can takes place with a modem or ethernet connection.

Table 3 STBs features

A test is performed on the STBs list in Table 3 evaluating the rendering time for a set of web pages (the same used in Section 6.1 for the qualitative evaluation). In Table 4 results for the i-Can 5100TX STB are shown. The 10/100 Ethernet interface of the i-Can 5100TX is used for the Internet access, so connection time is almost neglegible on the total rendering time. WebClimb is compared only with Sofia and Goonie browsers because are the only Xlet applications available among the evaluated web browsers. The WebClimb browser shows the better rendering time compared to the other browsers. This waiting time, although quite high, is anyway acceptable in the digital terrestrial television environment. Similar results are obtained for the other kind of STBs on the same set of pages.

Table 4 Web pages rendering time (sec.), i-Can 5100TX with ethernet connection

It is interesting to analyze the data presented in Table 5. The same test has been performed for the same three browsers running on IRT emulator on a PC with the following features: Intel Pentium M 740 / 1.73 GHz , 512 Mbytes RAM. WebClimb still shows the best behaviour and the rendering times are much smaller than those measured on a STB platform, this fact is due to the different hardware capabilities of the PC and of the i-Can 5100TX. The Sofia browser very often gives a notification error both on the STB and on the IRT emulator; this is because the application does not provide a correct URL management. It is worthy highlighting that Goonie browser crashes when the BBC home page is requested on the STB, instead the same application works fine on the same web page on the emulator. This happen because STB has limited capacity in terms of memory and CPU. WebClimb instead of Goonie is able to render this web page without failure.

Table 5 Web pages rendering time (sec.), IRT emulator with ethernet connection

In conclusion, WebClimb has generally shown the same results achieved on IRT emulator in terms of graphical elements visualization on TV screen; web page examples considered before were rendered exactly in the same manner and therefore are not illustrated again. On the other hand it is important to underline that tests on STBs with different memory capacity were useful because they demonstrated that for this kind of application, which manages a large amount of data, it is necessary to assure a minimum memory resource.

In fact WebClimb operates on STBs with reduced memory, sometimes it happens that, after a certain number of navigated pages, the application’s performances slows down drastically, in the sense that it is not possible to load new web pages. This phenomenon is due to a memory saturation effect, primarily because this does not happen on IRT emulator which runs on a PC environment and secondly because this happens less and less if STB’s memory increases. We perform some tests on this issue and the problem is due to the automatic garbage collection and memory management of the Java runtime environment. Generally, the Java VM performs garbage collection when an application needs more memory to continue execution. Even though we write a program paying attention to indicate the runtime to run garbage collection upon dereferred objects, this does not grant that the garbage collection will occur at that time. This can be a problem for systems with memory constraints like STBs. So we force the garbage collectionFootnote 23 to free memory, but the problem still remain an open issue to be investigated in the next future.

However from all these experiments it rises up that WebClimb browser, with its 900K byte footprint, needs low memory requirements for execution and works on all STBs tested, both for ethernet and modem connection. So the test performed on commercial STBs prove the effectiveness of our prototype demonstrating its efficiency on different model and brand of STBs.

6.3 Usability tests

To get a feedback on the actual usability of WebClimb prototype, a preliminary evaluation test has been carried out. In particular, a specific group of features has been individuated; for each of these features a set of measures has been taken into consideration and evaluated by the users participating to the test on the basis of a Mean Opinion Score (MOS) approach. The group of users, composed by 10 persons (7 males and 3 females), aged between 30 and 60 years, was asked for rating with a value, ranging from 1 (bad) to 5 (excellent), 4 different measures, listed hereafter, according to each of the to-be-evaluated features.

  • Effectiveness: it measures the way the user is able to achieve his aim correctly and completely;

  • Efficiency: it measures the effort done by the user relatively to effectiveness;

  • Satisfaction: it measures how much the user is satisfied in using the application;

  • Easiness to learn: it measures how it is easy for the user to learn when using the application;

The WebClimb features under evaluation were chosen with the purpose to investigate how much acceptable was the manner to provide some critical functionalities within the browser interface, due to the fact that the user has to interact by only using a remote control. The evaluated features were the following:

  1. 1.

    Use of color buttons

  2. 2.

    Switching between interface and navigation commands (yellow button)

  3. 3.

    Use of the virtual keyboard (i.e. URL address typing)

  4. 4.

    HTML controls navigation (i.e. links, radio buttons, check boxes, etc.)

  5. 5.

    Menu

The whole test has taken 4 days and has been done in ad-hoc room equipped with a common TV screen (32 inches). The user sat on a chair, in front of the television at a distance of 3.5 meters and acted on the remote control of the STB.

The usability test was divided into two phases: the training phase and the analysis phase. During the training phase the user was required to train for a short time (usually some minutes) on a generic MHP application with a medium-high level of interaction (e.g. use of numeric key-pad and color buttons, return channel, different graphic elements and so on). This was necessary to allow the user to experience DTT-MHP platform both in terms of devices and in terms of delays and ways of interaction with the application contents. This was done to avoid that the user’s judgement, during the successive WebClimb evaluation, was affected by the PC-like performances expectation and did not permit to get an actual answer of WebClimb’s possible inefficiencies. So, after the training phase, the user passed to the analysis phase on the WebClimb browser starting from a pre-selected homepage. He was asked to prove, in a defined sequence, all the different 5 features listed above, by performing an action such a feature was designed for. This was repeated three times to check how the user was able to learn and remind the diverse actions. At the end of this process, the user was required to express his vote, between 1 and 5 (1 bad, 2 poor, 3 fair, 4 good, 5 excellent), according to the 4 measures, for each of the 5 experienced functionalities. All the gathered scores have been averaged over the number of users (10 as previously said) taking part to the evaluation test. Such results are reported in Table 6.

Table 6 MOS for the usability test

By analyzing these results, it can be assessed that a medium-high degree of scores has been achieved for all the different measures with respect to the diverse features under investigation. This can be appreciated especially when looking at the MOS average values (MOS-AVG) both for features and for measures (respectively last column and last row). Furthermore, it is interesting to highlight how the values for the parameter Easiness to learn are particularly good; this indicates that the user capacity to deal with WebClimb improves after repeating some actions.

7 Conclusions

In this paper we presented the WebClimb browser, a Java-based DVB-MHP web browser for digital terrestrial television STBs. The system model architecture has been described and then qualitative and quantitative results on different kinds of experimental tests have been provided in order to verify the performances of the proposed browser.

WebClimb can be broadcast via a TV carousel or embedded on a STB and locally executed; it collects web contents and displays them without asking for reformatting of such a content from the server side. The WebClimb browser, as well, can function as Interactive TV platform enabling broadcasters and network operators to create content for enhanced and Interactive Television using standard web tools.

Experimental tests both on a MHP emulator and over commercial STBs have given positive results especially in comparison with other similar applicative tools. A preliminary analysis from the point of view of system usability has been performed too; a complete analysis with a large number of different kinds of end-users will be set up before releasing the MHP browser. Furthermore in the near future WebClimb will be optimized in term of dimension and also for what concerns memory management on STB and additional positioning scheme of visual formatting model will be implemented (e.g. floats and absolute positioning).