Chapter 10

The Technical Development of the “Web Portal” Publishing Model ¹

10.1. The notion of “publishing module”

In Chapter 7, we presented the interfaces for accessing audiovisual resources which have been analyzed and indexed beforehand with the ASW Description Workshop. In this chapter, we will introduce the components and computerized tools that helped us to create these interfaces.

In order to determine these different components and tools, we shall see how we can characterize what a publishing module is. Before starting, we shall clarify a semantic point. Throughout this chapter, we will use the following generic terminology: “server” and “client”.

By the term “server” we mean the hardware and/or applications responsible for the remote processing and distribution of the pages of our portal. Note that our server applications are Semiosphere and Semioscape (see Chapters 8 and 9).

By the term “client” we mean the hardware and/or applications responsible for receiving the information sent by the server. In our case, the client hardware will be the user’s computer and the application will be the Web browser (Internet Explorer, Google Chrome, Mozilla Firefox, etc.).

We can define a component or publishing module as being the set of functions enabling us to manage a specific aspect of publishing, from access to the data to their display. One part of the module acts on the server, and another acts on the client. A module may call upon other modules. The functions for accessing the database are not specific to each component: they are contained in SemioscapeDataAccess (see Chapter 8). However, the requests for these functions are implemented in the requesting module. A module may very well contain another; this is the case for our video contextualization module, which contains the video player module (see Chapter 7). The modules may interact with one another. As we can see, the module for viewing the sequences of a video may send instructions to our contextualization module.

The server side of the module is responsible for the following operations:

– data collection;

– verification of the validity of the data;

– data formatting.

The client side is responsible for the following role:

– dynamic management of the display of the data.

Referring to the explanations given in section 8.1, this is essentially a question of the following “modules” or “building blocks”:

– specialized access to the audiovisual collection of a site – a collection which has been described and indexed beforehand (see the ArkWork corpus, the CCA corpus, etc.): access by topic, by thesaurus, by film collection, etc.;

– enriched distribution of the digital videos;

– contextualization of a video (display of the information in the metadescription);

– navigation within the sequences of a video;

– temporal (chronological, genuinely historical by era, etc.) location of the audiovisual collection of a video library (for example, the books and authors in the history of French literature – an example from the LHE video library);

– geographical location (i.e. on interactive geographical maps) of the audiovisual collection of a video library (for example, of archeological sites in the case of the ArkWork video library, of languages around the world in the case of the CCA video library, of authors and literary works in the case of the LHE video library, of Andean religious rituals in the case of the AICH video library which is devoted to Andean intangible cultural heritage, etc.).

In the following sections, we shall present our methodology of development. Then we shall demonstrate how our application, by way of its modules, resembles an RIA (Rich Internet Application)¹ [DEI 08], and finally, we shall present each of these technical “building blocks” by proceeding as follows:

– general overview of the technological module and the technology which is used;

– explanation of the graphical makeup of the module and the main processes which are carried out;

– discussion of an example of a practical case of development.

Some of the described functions will not be available on some sites, as in the final analysis, the owner will choose the functionality of his site.

In order to better analyze the different parts of the project, we have isolated – in the form of modules or “bricks” (geo-location, timeline, video player, menus, etc.) – the different parts of the project which are necessary for the correct implementation of the publication, and the valorization of the data.

The development phase of the ASW portal sites first consisted of the technical feasibility study i.e. the assessment of whether or not it would be possible to implement the features described in the prototype and how much time would be needed.

As development progressed, the modules were tested and evaluated to improve their presentation and their ergonomics.

These modules were designed and developed to be independent from one another. The resulting flexibility makes technical maintenance easier, but also aims at facilitating a possible addition of modules or the evolution of some modules.

One of our objectives during the development of these different components was to favor the use of existing Web tools, with a preference for open-sources, for two main reasons:

The first was to exploit feedback on tools which had been developed previously and had been being used for several years. The second was to take advantage of the future evolutions which will be provided by developer communities, and to benefit from highly customizable tools which best fit the specific objectives of our application.

Wherever possible, we favored the development of our modules via “server controls” integrated in the .Net platform² [LEB 09]. These server controls enable us to manipulate client script items (HTML, JavaScript) by way of a .Net language as well as C#³ [LEB 09] (server side language). Hence, we can benefit from all the advantages of the C# language – including object-oriented programming – and from our IDE Visual Studio (Integrated Development Environment)⁴ such as the autocomplete⁵ and debugging⁶ functions. One of the specificities of our application being the dynamic generation of our interfaces, from the server, these server controls were very useful to dynamically manipulate client items from our server. This would also enable us to facilitate maintenance.

When we could not use these “server controls”, we opted for “conventional” components and managed to adapt them so as to be able to dynamically manipulate them from Semiosphere (see Chapter 9).

10.2. RIAs

The reasons which led us to use “Rich Internet Applications” are: a) the large amount of information which offered by a portal, b) the overarching need to provide a data format which reflects their structure and, c) the necessity of offering the user as intuitive a means of navigation as possible.

In the absence of an official definition for these sorts of controls, we shall simply state that they are the result of the enrichment of one or more HTML elements, by client scripts such as JavaScript⁷ [TEM 07]. For example, the autocomplete control (Figure 10.1), which is available for searches on the google.com⁸ page, brings together three HTML elements: a text input field, a button and a table in which the suggestions appear. These are enriched by JavaScript functions which enable us, among other things, to collect the suggestions and display them.

The aggregation of these components forms RIAs (Rich Internet Applications). RIAs are Web applications which look more and more like programs installed directly on a computer’s operating system. Nowadays, they may very well be a substitute for “traditional” applications. In order to illustrate this, we shall take the example of Google Docs, a suite of online office software (word processor, spreadsheet…) which are used via a browser.

In order to better understand RIAs, we shall briefly look back – with no pretense of providing an exhaustive study – at their emergence in the evolution of Web programming through the mutation of roles in the client/server relation.

In order to illustrate these changes, we will take the hypothetical example of a Website for learning the times tables (from 1 to 10).

When the World Wide Web first appeared in the early 1990s [KEN 02], Internet sites were static (Figure 10.2): our server had no option other than to provide pages which had been written beforehand. In order to get the result of 2 multiplied by 10, the user had to request the page containing the 10-times-table (or the 2-times-table), which was stored by the server in advance. One might ask why the server did not simply return the result of the operation. The fact of calling preconceived pages implied too much work for the specific production of a page for each operation. In our case, this would have necessitated the implementation of 100 pages merely just for the 10 multiplications of these 10 tables. In receiving the page, the “light” client only had to take care of the display once the data had been loaded, according to the instructions which were sent to it. For each request, the page was fully loaded, i.e. the server sent a whole new version to the client and deleted all the information on the previous page. One of the consequences of this complete loading was a cutoff in the navigation between the moment that a request was sent and the moment the client received the response.

Later on, Websites became dynamic [NIX 09] (Figure 10.3). The server side was endowed with programming languages (PHP, JSP, ASP, etc.) to host applications. The latter enable processing to be carried out before the page is sent back to the client. From then on, our server was able to generate its pages dynamically. Instead of having a pre-written page for each table, it was endowed with a model, representing a page containing a table of multiplications. The server filled in this model according to the requested multiplier. As a result, the multiplicands, multipliers and products of each table (the data of our page), were able to be independently stored, in a database. The latter was requested to send the data to the application which was able to generate pages according to the accurate model.

However, the server side programming languages also enabled us to directly work out the results of the operations. This enabled the user to request that the server carry out the calculation and then return the result. Furthermore, thanks to the new possibilities for adding multimedia objects (music, video), our site was endowed with a musical collection so that navigation would be more enjoyable. However, each request of the client once again entailed total loading. Consequently, with each new request from the user, the music was interrupted and then played from the beginning again.

Soon after the turn of the millenium, following the emergence of server-side languages, we witnessed the rise of client-side languages such as JavaScript [TEM 07].⁹ The “light” client then became a “rich” client, i.e. it was now able to take responsibility for managing processing applications.

Initially, the integration of client-side programming languages gave the browser the possibility of calculating the result of 2 multiplied by 10 directly (i.e. without going through a process on the server side, thereby saving the cost of a connection).

However, the need for the client to communicate with the server during navigation was not eliminated. It still applied, e.g. in order to access data stored on a remote base.

The JavaScript language, in addition to enabling clients to perform calculations, provided them with Ajax Rich Internet Applications and Web development for developers without interrupting the navigation. Hence this language enabled us to make partial – but not total – changes. It was then that Ajax programming [DEI 08] (Asynchronous JavaScript And XML) emerged (Figure 10.4), which is a way of programming rather than a programming language in itself.

JavaScript, through its XmlHttpRequest function, enables us to make asynchronous requests to the server, i.e. to communicate with it, while continuing to navigate, and afterwards, to receive the answer in the form of XML data, so as to simply update the data to be changed, and hence preserve the integrity of the rest of the data.

If we return to the example of our site, we notice that it enables the user to ask the server for the ten times table and any other multiplication tables he wishes to consult, without disrupting the background music. Thus, the function of our video player and the display of our multiplication tables became autonomous from one another, i.e. the operation of one component no longer had any impact on the operation of the other components.

We can see how the advances in Web programming, especially the continuity of navigation provided by Ajax programming, were essential in the implementation of RIAs, since they are executed from a browser and constitute an aggregation of components which form a whole, while remaining independent of one another.

Note that apart from the initial loading of the page, it is possible to program all navigation around a Website by way of partial loads, although this may entail drawbacks.

An article [NEI 11] published on the blog of Theresa Neil, author of Designing Web Interfaces [NEI 09], listed 43 fundamental controls which stem from RIAs. Of these, 4 constitute the basic input for our modules, namely:

– scrolling menus for our direct and thematic access, galleries and thesauruses;

– tabbed windows, most of the contextualization of the videos;

– mapping tools for the geo-location;

– carousels, for viewing the sequences.

To these, we add two other controls that we have used and which may be considered to be RIAs:

– the video player for viewing;

– the timeline for the geographical localization.

10.3. The “Menu” publishing module

The first publishing module manages elements such as the “Direct and thematic access” menus, the thesaurus, the “Galleries” pages. They are presented in the form of scrolling menus or accordion menus and are Ajax Control Toolkit¹⁰ server controls known as Accordions.¹¹

The Ajax Control Toolkit is the outcome of a collaborative open-source project between Microsoft and the Asp.net Ajax community. Its goal is to provide asp.net users such as ourselves with a series of Web controls which can directly be manipulated by the computer languages that are supported by the .Net platform. Their objective is to enrich the navigational experience and the ergonomics of Websites. Furthermore, they offer very easy integration of Ajax functions.

These menus are very important for the organization of the portal, because it is through them that we benefit from the work on the ontologies – and later access the videos. Their aim is to store a significant quantity of information in a limited space, while offering the most intuitive access as possible. The objective is to link the collection (the OntoEditor¹² data) and the form (graphical user interface) so that the visual organization of the elements fits with the logical organization, in particular by reflecting the hierarchical relationships between the elements.

An Accordion (Figure 10.5) is made up of the following elements:

– Panes (the parts where we click to expand or collapse the contents);

– Contents (each pane has a content; this content may be any element written in HTML code).

The scrolling menus are managed via a function which constructs them dynamically when the page is loaded. The algorithm in question manages the construction according to two parameters. The first is the structure of the ontology and the second is the representation the site’s owner wishes it to have. Indeed, the owner may decide not to display one or more subsidiary levels of a category. For example, on the topic of “interdisciplinary archeology”, one need not necessarily display any of the sub-categories. In that case the link will refer to a menu containing all the “interdisciplinary archeology” videos, but the decision can also be taken to display only the first three sub-sections, or the sub-sections which have at least n number of videos. Each level is represented by a scrolling menu. Hence, the main menu reflects an imbrication of accordion menus, except the last level which is presented in the form of links.

Regarding the development, despite the differences between these menus both in terms of the container (size and color differences etc.), and the content (single link, lists of links, links in the form of a glossary) we have compiled their common features. Hence, our design work led to the creation of an “abstract scrolling menu” (which does not exist by itself), a basis for the creation of other menus, which would add their own specificities to it. This would make maintenance and modifications easier in the future. Any change to the general behavior of the scrolling menus will be implemented only through our abstract menu, and a change or addition of a type of menu will have no impact on the function of the other menus.

10.4. The “Video player” publishing module

The second publishing module concerns the digital distribution of videos. We opted to use a free and open-source video player: JW Player.¹³ This is a product of the LongTail Video¹⁴ company which provides a whole range of Plugins or complementary modules, with an API (Application Programming Interface),¹⁵ enabling developers to use a library of JavaScript functions in order to better be able to manipulate the player, and thus to adapt its behavior according to the needs.

The player (Figure 10.6) is made up of the following elements:

– the ControlBar (the control bar of the player);

– the Plugins (our additional modules).

Using this player, we were able to initiate different strategies of distribution, according to the speed of the user’s Internet connection, so that the user can watch our content in the best possible conditions. The way we currently choose to do this is to broadcast videos encoded in Flash format and distributed in streaming¹⁶ mode using a Red5¹⁷ server using the RTMP¹⁸ and HTTP¹⁹ protocols. One of the main advantages of streaming our publications is to enable the user to quickly access any passage of a video even if that video is long (the average duration of our videos is one hour).

During the development phase, we integrated some of the additional modules made available to us by the JW Player. We mainly used the following additional modules:

– sharing²⁰ (embeds access to social networks in the player);

– embed²¹ (embeds an access to the hosting code of a video into the player);

– d-related²² (embeds a list of related videos in the player at the end of a video);

– google analytics pro²³ (analyzes the interactions between the user and the player).

Thanks to the JavaScript functions of the API, the player can communicate with our other modules. For example, when a video is being played, one of these functions enables us to know when the other segment will be read. As a result, we can synchronize the information displayed with the segment which is being played. These functions also enable us to stop the video when any tab other than “Video” is clicked.

10.5. The “contextualization of a video” publishing module

The third publishing module concerns a part of the contextualization of a video from the “selected video” page. This presentation is done in the form of a tabbed window containing both the video player and all the information relating to it. This module was developed based on an Ajax Control Toolkit component called TabContainer or Tabs.²⁴

Here again, the issues of managing the space needed to display this information, linkage between the different categories of information, and ease of access to them were our main aims when in choosing to put this module in place.

A TabContainer (Figure 10.7) is constituted of the following elements:

– the TabPanels (the tabs);

– the Contents (Contents of the tabs).

A piece of Content may embed any HTML element.

When the data are loaded on the server side, they are systematically verified. If for a given category, not all of the data are available, then this category will not be displayed in the tab’s contents. For example, if the category “Role in the contribution” contains no elements, the corresponding part in the graphical interface will not be displayed in the browser. Once the information has been integrated into the content of the tab, the general state of the tab is tested. Hence, the tabs which do not contain information will not be sent to the client. This is often the case of the “Translation” tab.

Another operation which is carried out by Semiosphere when data are received is textual formatting. This manipulation may occur by changing the first letter of a word into uppercase or the concatenation of different data to produce a text. To illustrate this case, let us take the example of a documentary for which Muriel Chemouny and Valérie Legrand (both from the research team of ESCoM and coauthors of this book) played the role of director. The server application receiving the names and respective roles of the people uses an algorithm to concatenate our information with square brackets and commas, which yields the following result: Chemouny[Director], Legrand[Director].

Apart from the task of formatting our tabbed window, the development phase consisted of parceling the different tabs and then the different elements of the metadescriptions forming part of these tabs, whilst mutualizing the shared features. The content of each tab is managed as a “sub-module”. Even though they are independent, these “sub-modules” do call upon shared functions for the textual formatting or the construction of their container. Hence, it would be very easy for us, if need be, to add categories to our tabbed windows.

10.6. The “temporal location” publishing module

The fourth module is a carousel which enables us to view sequences of a video and navigate between the sequences. This module was designed based on the open-source component called JCarousel.²⁵ JCarousel was developed based on the library of JavaScript functions named JQuery.²⁶

This control is not necessary for our data to be readable. However, it offers an enriching user experience, since it gives the possibility to direct a user’s navigation within a video using miniatures (icons) which, if clicked, directly play a specific segment of the video.

The JCarousel (Figure 10.8) is composed of the following elements:

– the Items (our miniatures in the form of links);

– an ItemList (list of Items by which the visibility (or otherwise) of the miniatures will be managed).

When the browser loads the “Selected video” page, a total download is performed from the server. If this video contains sequences, they are displayed in chronological order, in the carousel, in the form of a miniature. By default and once the page has loaded, the description of the first sequence is found in the panel of the “Description” tab. The passage to another sequence may take place in two ways: either by the “natural” advancement through the video, or by the user clicking on a miniature which is different from that of the sequence being played. When the change occurs, an Ajax request is sent to the server to initiate a partial loading of the page. Hence, the information concerning the segment, in the content of the “Description” tab, is modified independently from the rest of the page. In particular this means that the progress of the video need not be interrupted.

The first step in developing of this module was to adapt to the dynamic generation on the client side. From then on, we set up the carousel by adapting the component to our color code, to the required dimensions and to our miniatures. Finally, we integrated Ajax functions using the Ajax Control Toolkit and its element called UpdatePanel, which enables one to target the precise element to be refreshed on a page (this is a partial refresh), so as to be able to update the information concerning the current segment, without interrupting the play of the video.

10.7. The “geographical location” publishing module

The fifth module is the timeline, which enables us to temporally locate the relevant periods within a video. This is especially useful in the case of videos which relate to archeology. Our timeline also enables us to simply target the dates (instead of the periods), for example for sociological documents. In order to implement this module, we decided to use a Web component called TimeLine²⁷ which is a result of the SIMILE (Semantic Interoperability of Metadata and Information in unLike Environments)²⁸ project. This project, jointly led by MIT Libraries (Massachusetts Institute of Technology Libraries)²⁹ and MIT CSAIL (Massachusetts Institute of Technology Computer Science and Artificial Intelligence Laboratory),³⁰ consists of developing open-source Web tools to improve the interoperability and the formatting of the data on the Internet network. The TimeLine object is used in many domains, ranging from timelines for digital collections, to the description of earthquakes.

TimeLine (Figure 10.9) is made up of:

– Bands (container in which the temporal graduation and the information are displayed);

– Ethers (representation of a unit of time within a Band);

– Tapes (colored bands which symbolize the duration of an event);

– Tracks (text linked to a tape).

When processing the client request, the server side of the timeline module extracts the temporal data of the information which relates to the video. Then, it defines one or more event(s) in the form of XML items. An event contains the data which enable us to locate a period or a date and edit it on a Band. The module fills in the following attributes: a start date and an end date, in the default format supported by TimeLine. These dates facilitate the visual delimitation (Tape) of the period. Moreover, we provide the text which is used as an accompaniment (Track). The whole system is loaded into the timeline from the server, and is displayed when it is loaded onto the client station.

The main step in the development of the timeline was the formatting. Indeed, the original TimeLine bears little resemblance to what we initially set out to provide. However, thanks to the functionalities which were made available to us, we first edited three specific Bands. The first and third (though the graduation is deliberately not displayed) are graduated according to centuries, and the second according to millennia. Then, we attributed each of them the color and format that we wanted. Subsequently, by using JavaScript to manipulate TimeLine, directional arrows were added.

10.7.1. The geographical location

Our sixth publishing module is responsible for geographically locating the videos. It enables us to locate the place which either concerns a video being played, or a collection of videos on the “Galleries” page dedicated to this purpose. In order to implement this solution, we chose Google Maps³¹ which is a free map Web service. It enables the Internet user to move around a geographical map, to place the cursor wherever he wishes, and zoom within that map. Furthermore Google Maps API Javascript³² enables developers to add and manipulate data in HTML format.

Like the timeline, this is an important advantage for enriching the users’ experience.

Google Maps (Figure 10.10) is composed of these different items:

– the Markers (items signaling the place of a video);

– the InfoWindows (items for displaying related information).

During the loading of a page containing our geographical location module, the Google Maps Web service is called. Then, we send it information in order to build the elements enumerated above, along with events relating to it. The events are the actions which must be performed when the system interacts with the user. For example, it may consist of displaying an InfoWindows module when a user clicks on a Marker.

To develop this module, first we had to set up dynamic generation of our client script Google Maps from the server. It should be noted that we could have selected an alternative: dynamic loading of the data from the client side, since this function is available in the API of Google Maps. However in order to maintain the same principle of generation as for the other modules, we opted for server-side dynamic generation.

Then, we imposed our model of InfoWindows. The latter was built based on the labels of our menus on the “selected video” page. Hence, any changes effected on the latter will automatically be reflected in the content of our InfoWindows.

10.8. Conclusion

We have just touched on the design and development of our Publishing Workshop. Now, although some of the features of the prototype are still being developed, we can take a look at a few possibilities as to the evolution of that workshop.

First of all, we could embed a function for sorting the videos of the menu on the “selected video” page. Indeed, at the moment, the user cannot influence the content of this menu, since the videos which are offered by type and genre are automatically chosen when the page is loaded. The possibility of enabling the user to sort the videos according to the different elements of an ontology seems to be of interest. The user would then be free to choose other categories by which to sort the videos, such as the type of discourse. On the one hand, this would add more interactivity to our portal, and on the other hand it would enable the user to better comprehend the advantages of our ontologies.

Secondly, we might consider putting an interface in place that would enable the publishing manager of a site to perform a certain number of modifications himself without the need for a computer developer’s services. The main elements which could be subjected to modifications by a site manager could be:

– the colors;

– the images;

– the text;

– the placement of the different menus on the homepage;

– the choice of the types of access to the videos and the modules of their portal.

Finally, throughout the lifetime of our portal, we will monitor information, so that the portal evolves in accordance with the progress of programming languages or the emergence of new mobile terminals.

---

¹ Chapter written by Richard GUÉRINET.

1 Rich Internet application. See also section 8.2.2.

2 An environment for the development and execution of computer programs, made available by Microsoft.

3 A programming language which is available on the .Net platform.

4 Software for helping to develop computer programs.

5 An input-aiding tool.

6 Tools which help to spot bugs in a computer program.

7 A computer language which enables us, among other tasks, to manipulate html elements, and hence, to create the interactivity in a Web page. All browsers which are targeted at the “general public” integrate JavaScript interpreters.

8 http://www.google.com/.

9 Javascript is a client side programming language which enables to manipulate html elements.

10 http://www.asp.net/ajax/ajaxcontroltoolkit/samples/.

11 http://www.asp.net/AJAX/AjaxControlToolkit/Samples/Accordion/Accordion.aspx.

12 See Chapters 8 and 9.

13 http://www.longtailvideo.com/players/.

14 http://www.longtailvideo.com/.

15 An API is a set of tools that a program makes available so that a third person can control it. It is materialized in the form of an instruction manual.

16 Streaming is a protocol of video diffusion where the video is not downloaded on the client computer. Instead, it is sent “piece by piece”. In particular, this method enables users to access any moment of a long video, without additional waiting time: http://fr.wikipedia.org/wiki/Streaming.

17 http://www.red5.org/.

18 http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol.

19 The diffusion of our videos in streaming, initially diffused in RTMP, using the HTTP protocol, is realized through the RTMPT protocol: http://wiki.gnashdev.org/RTMPT. The swing to RTMPT when the RTMP protocol is unavailable to the client is initially managed by the JW Player, and this constitutes one of its other advantages.

20 http://www.longtailvideo.com/addons/plugins/110/Sharing.

21 http://www.longtailvideo.com/addons/plugins/49/Embed.

22 http://www.longtailvideo.com/addons/plugins/54/D-Related.

23 http://www.longtailvideo.com/addons/plugins/107/Google-Analytics-Pro.

24 http://www.asp.net/Ajax/Ajaxcontroltoolkit/samples/Tabs/Tabs.aspx.

25 http://jquery.com/.

26 http://sorgalla.com/jcarousel/.

27 http://code.google.com/p/simile-widgets/wiki/Timeline.

28 http://simile.mit.edu/.

29 http://libraries.mit.edu/.

30 http://www.csail.mit.edu/.

31 http://maps.google.com/.

32 http://code.google.com/apis/maps/documentation/javascript/.