D5.1orig-2 Presentation Subsystem

From EChase
Jump to: navigation, search
Warning: this is a copy of the D5.1 document as originally submitted to the EC.

To contribute please use: Presentation Subsystem.

Back to D5.1orig System Specification

This logical node represents the user access layer to the eChase platform services.

The Presentation subsystem interacts, in sequence, with the Access Control subsystem and with the Application subsystem.

To the former it demands the necessary authentication and authorization for the current user while, to the latter, it requires the services the user needs.

It consists of two modules through which eChase users may perform two distinct groups of tasks:

  1. Administration of eChase (access and services management)
  2. eChase Browsing and Services usage

The two modules are:

  • Visualization and Navigation
  • System Admin

General guidelines for the User Interface[edit]

Users of web documents don’t just look at information or content; they interact with them in ways that have no precedents in paper document design. The graphic user interface of a web site comprises the interaction metaphors, images, and concepts used to convey functions and meanings on the computer screen. It also includes the detailed visual characteristics of every component of the graphic interface and the functional sequence of interactions that produce the characteristic look and feel of web pages and hypertext linked relations. Our purpose is to develop the visualization and navigation tool of the eChase system in the most clear and comprehensive way, to allow visitors to navigate through the content with easiness

Description of the User Interface[edit]

The spatial organization of graphics and text on the web page can engage visitors with graphic impact direct their attention and make their interactions with our web site more enjoyable and efficient.

What we will seek in the page design of eChase site is clarity, order, and trustworthiness.

Graphic design creates visual logic and seeks an optimal balance among visual sensation, information and content. Without the visual impact of shape, color, and contrast, pages are graphically uninteresting and will not motivate the visitor in the discovering of our system. In seeking this balance, the primary design constraints are the restrictions of HTML and the bandwidth limitations on user access ranging from slow modems to high-speed connections.

Visual and functional continuity in our website organization, graphic design, and typography are essential to convince our audience that our website offers them accurate and useful information and content.

A careful, systematic approach to page design can simplify navigation, reduce user errors, and make it easier for visitors to take advantage of the features and content of the eChase system.

User centered design[edit]

Fundamental, in designing the eChase system, is to provide for the needs of all potential users, adapting web technology to their expectations and never requiring visitors to conform to an interface that places unnecessary obstacles in their paths.

In this purpose our research on the needs of the target audience is crucial. It’s impossible to design for an unknown person whose needs we don’t understand. We have to create sample scenarios with different types of users seeking content from our site. Testing our designs and getting feedback from a variety of users is the best way to see whether our design ideas are giving them what they want from our site.

Bandwidth and interaction[edit]

Users will not tolerate long delays. Research has shown that for most computing tasks the threshold of frustration is about ten seconds. Web page designs that are not well optimized to the network access speed of typical users will only frustrate them.

In general, designing the eChase interface we ought to be conservative with graphics that can result too heavy. Even users with high-speed connections appreciate a fast-loading page.

Simplicity and consistency[edit]

Users are not impressed with complexity that seems gratuitous, especially those users who may be depending on the site for timely and accurate searching.

The interface metaphors and navigation of the eChase system should be simple, logical and in the same time familiar.

For maximum functionality and legibility, our page and site design should be built on a consistent pattern of modular units that all share the same basic layout grids, graphic themes, editorial conventions, and hierarchies of organization.

Our goal is to be consistent and in the same time predictable: our users should feel comfortable exploring eChase site and confident that they can find what they need.


One of the key elements that determine the success of a web site is its navigation scheme. How our navigation system is set up helps to determine the user’s experience, and may determine whether they’ll be back again or not.

We can have all kinds of great content on our eChase site, but if visitors don’t know how to get to them, the objectives of our project become useless. Worse, if visitors find our site’s navigation confusing and too complicated, they’ll simply give up and go to explore the rest of the Web, shop elsewhere in seconds and never to return.

So, next to advanced navigation tools, like semantic web navigation systems, we ought to provide to our visitors traditional and easy to use systems, like Google-style pagination of results, to assure the success of our eChase system.


Fluidity means an easy and stable framework in which to add and update content. This one aspect of building a site will drive our project toward its intended goal, whether it is to sell a product or inform users.

There are two main ingredients that determine whether or not a site is fluid. The first is an appropriately complex design: the design must fit the mood of the site and users’ interests, and put the focus where we want it directed. The second item that we should include is the idea of ease of use. This leads us to our central topic: navigation.

Designing navigation systems[edit]

Our eChase system can be seen as a collector of several kinds of content: we have to avoid visitors getting lost in our site. It is associated with confusion, frustration, anger. In response to this danger, we have to develop navigation tools to prevent people from getting lost (i.e.: bread crumbs, site map …).

We use them to chart our course, to determine our position, and to find our way back. They provide a sense of context and comfort as we explore new places.

However, getting lost in a large web site can be confusing and frustrating.

Navigation systems can be designed also to support associative learning by featuring resources that are related to the content currently being displayed. For example, a page that describes a product may include links to related products and services (this type of navigation can also support a company’s marketing goals). As users move through a well-designed navigation system, they learn about products, services, or topics associated to the specific content they set out to find.

Any page on a web site may have numerous opportunities for interesting connections to other areas of the site. The constant challenge in navigation system design is to balance this flexibility of movement with the danger of overloading the user with too many options.

Building context[edit]

With all navigation systems, before we can plot our course, we must locate our position.

Being a complex web site, in our eChase system, it shall be important to provide context within this great whole.

We should follow a few rules to ensure that our site provide contextual clues. First, all pages should include the organization’s name. This might be done as part of the title or header of the page. As a user moves through the levels of a site, it should be clear that they are still within that site. Carrying the graphic identity throughout the site supports such context and consistency.

Second, the navigation system should present the structure of the information hierarchy in a clear and consistent manner and indicate the location within that hierarchy.

Item to include and those to avoid[edit]

There are a few things that every navigation system should include. The first is systematic menus. The menus that we use on our site should be clear and to the point. A hierarchy of links should be made visible, yet not interfere with the content on the page. Users should be able to see where they are on our web site and be able to retrace their steps easily if needed. Also, uniformity is important. Avoid changing the type of system you use from one page to the next. And always keep it in the same place. Don’t put the menu on the left in one section and the right in another. Building every page with the same navigation system will make our site look clean and well kept. Another particular that should definitely be avoided is undefined categories. Subject headings such as "Other" or "Miscellaneous" will only confuse people.

Cross platform issues[edit]

Browsers already number in the hundreds, if not thousands. As browser versions continue to multiply, it’s becoming increasingly difficult to work around all the various browser bugs. Thus, when designing a navigation system, it is important to consider the environment the system will exist in. On the Web, people use web browsers such as Netscape Navigator and Microsoft Internet Explorer to move around and view web sites. These browsers have many built-in navigation features.

According to the objectives of the eChase project, for us it shall be relevant not to produce a system that depends on just one browser technology or browser plug-in.

The following section describes the web application interface including a light box that will be developed as part of the core eCHASE architecture, and also discusses example 3rd Party Applications.

Web Application[edit]

The web application will provide a web interface to the data stored in the Metadata Repository and the Media repository by interfacing with the stateless search engine service (SRW) in a decoupled manner described in Section

The web application will be lightweight and contain only a minimal amount of logic which is focused on the applications display. Therefore the design separates the interface from the business logic and the data. This follows the Model-View-Controller design pattern as a best practice. The core search engine business logic in encapsulated in the SRW and therefore is loosely coupled to the web front-end.

Web forms and pages will be implemented using JSP and Servlet technology hosted inside the lightweight servlet container, Apache Tomcat. A Front Controller will intercept all incoming requests and handle site security and the delegation of requests to the appropriate Application Controllers. Application Controllers manage the workflow of the business logic to process the request and finally dispatch the result of the business logic to a view (JSP) for presentation to the user.

For extensibility the web application will transform XML returned by search requests to the SRW into HTML with XSLT. This allows the user interface to be customized and modified very easily without changing the business logic inside the application.

The functionality of the web application consists of:

  • Intuitive user interface
  • Search by metadata
    • Google-style free text searching
    • Browsing of thesauri for powerful searching of well structured data
    • Powerful date handling for searching date ranges
  • Search by content
    • Upload images and search based on content
    • Search based on content of existing media
  • Display media and metadata clearly in a user friendly format
  • Display Unified data
  • Provide display of the pre-mapped legacy record
  • Ability to annotate records
  • Allow searches to be saved
  • Provide a light box to organize searches and objects found
  • Ability to annotate content packages created with the light box
  • Provide export of media and metadata

Searching and Navigating[edit]

Google-style searching[edit]

The web interface will provide Google-style input boxes to search the records stored in the Metadata Repository. This mechanism for searching is simple to use and allows a user to search across all fields simultaneously and retrieve results quickly. Free text searches will search the records through the indexes created by the Indexer component in . The index contains a correlation of terms and phrases to their associated records in both the Unified Database and the Legacy Database. This offers functionality to the web application to retrieve Unified and Legacy data as desired for display.

Thesauri navigation[edit]

The thesauri navigation component will provide functionality to view thesauri structure, such as concept hierarchies and viewing related terms. Users will use the thesaurus navigation and visualisation to choose terms that are then used to perform searches on the metadata in the repository.

mSpace Interface[edit]

mSpace is an interaction model designed to allow a user to navigate in a meaningful manner the multi-dimensional space that an ontology can provide. mSpace interfaces are based on slices through an ontological space, with each slice represented as a list of values. Typically, mSpace interfaces use a multi-panel display, where slices are presented as columns arranged from left to right. Selection in a slice will update the display so that the values displayed in the next slice (i.e. to the right of the current slice) are related to that value. For example, if there is a slice of artists and the next slice is painting titles, selecting an artist will display only that artist’s paintings in the titles slice. Values in each slice are filtered, so that there are always results to view in the next column when a selection is made. When an item is chosen in a slice, details about that item are displayed in a detail panel; if no details are available for that item, examples of related objects are shown. Slices can be freely interchanged, removed and new slices can be added to the mSpace. Users are able to record column arrangements that they find interesting, including selected items, for quick access.

An HCI technique called "preview cues" is useful when dealing with multimedia information in mSpace interfaces. Hovering over a title in a column pulls up a selection of multimedia content relating to that term. For instance, users without a clear idea of a music style are able to hear clips of that style, and if they are interested they can explore that concept further.

An implementation of mSpace was created specifically for the Sculpteur project in Java and deployed as a Java applet for the Sculpteur public demonstrator system. In the meantime, an official mSpace development project was started within IAM. This project is working on a DHTML/JavaScript implementation under a LGPL license. This lightweight approach is more appealing than the heavyweight Java applet developed for Sculpteur, and it fits in better with the web-based eCHASE architecture. There are also obvious benefits from collaborating with the official development project rather than developing an system independently. Considering these issues, we have decided to integrate the official implementation into eCHASE architecture.

Although much research on mSpace has been targeted at the semantic web, the interface can be applied to different data sources such as databases. For integration with the eCHASE architecture, some effort will be spent to port the relevant components of the mSpace system to use the SRW back end instead of an RDQL /3Store query mechanism. The mSpace interface could also be applied on the semantic web repository created from the unified database to take advantage of the more powerful semantic querying techniques, such as inference and reasoning.

Displaying results[edit]

There is a necessity to display a range of media formats and metadata schemas within the web application. Media formats that need to be supported are: Images, Video, and Audio. There is also a requirement to support viewing of records in their original legacy format before being mapped and translated into the unified schema. This allows users to see how a record matched their search criteria and how metadata has been mapped to the unified schema’s values. Therefore the design of the results view must be extremely flexible and customisable.

Results returned by the SRW are formatted as XML; as a result the web application will use XSLT to transform the XML data into HTML for display. This separates the display formatting from the application code and allows web designers to work on the user interface look-and-feel while the Software Engineers can concentrate on application logic.

Each content provider’s data will almost certainly conform to their own legacy schema, or extend a standard schema with their own metadata requirements. This results in a requirement to support the display of many schemas within the web application. The web application will be configured to use specific XSLT documents for each content provider’s legacy data in order to display each schema in a clean and appropriate format.

The display of media must provide the ability to display Images in multiple resolutions, video either by key-frames or as web-streamed content, and audio as web-streamed audio. There may be a requirement to present specific portions of video using time codes, for example where a metadata record refers specifically to a section within news broadcast.

Light Box[edit]

The light box provides the authors and experts a mechanism to collect and organize and annotate information for later use. Items found through the search engine with the web interface can be added to one of the users light box collections to either be used for future searches or to be exported as an item in the content package the user is building.

For example, the user finds a fine art painting and would like to find and create a content package containing other paintings by the same artist. The user can save the item in their light box and the use the saved item to search for the other paintings by the artist. The paintings found through subsequent searches can be placed in the users light box and the collection can be annotated. Once a collection has been completed it can be exported as a complete package for further use in the content creation process. These bundles will contain the media and associated metadata in XML format.

User annotation[edit]

One of the requirements of the eCHASE architecture is to allow users to author and manage annotations of content they find in the repository. This requires a complex annotation system designed specifically to satisfy the needs of eCHASE users. The development of such a system will be time consuming so the integration of existing collaborative annotation tools should be investigated, especially considering the development time restrictions and data integration priorities for the first prototype. The use of an existing system would allow end users of the eCHASE architecture to understand the properties and benefits of annotation systems, and could lead to a more detailed specification of the requirements for the annotation system in the eCHASE architecture.

An example of such a system is a wiki: a web application that allows users to add content, as on an Internet forum, but also allows anyone to edit the content. The term wiki also refers to the collaborative software used to create such a website. A defining characteristic of wiki technology is the ease with which pages can be created and updated. An example of a wiki system is Wikipedia, a Web-based, free-content encyclopaedia written collaboratively by volunteers and sponsored by the non-profit Wikimedia Foundation . It has editions in roughly 200 different languages (about 100 of which are active) and contains entries both on traditional encyclopaedic topics and on almanac, gazetteer, and current events topics. Its purpose is to create and distribute a free international encyclopaedia in as many languages as possible. Wikipedia is one of the most popular reference sites on the internet, receiving around 60 million hits per day.

Wiki software could be set up as part of the eCHASE installation and used for adding and managing annotations about objects. For example, a user viewing a record on a photograph in the web application could click on a link to add an annotation, which would take them to the editing of a new page on the wiki. The wiki system could also be used to manage annotations for the light box component. Pages created on a wiki are all strongly interconnected through hyperlinks, so users could link to annotations on similar content. Depending on the level of integration of the wiki and the eCHASE systems, there could be mechanisms to link the annotations with records displayed in the eCHASE web application. Links to external reference sites such as Wikipedia could also be investigated.

Some Wiki systems allow user profiling, so users could create their own private annotations as well as open annotations that other users contribute to. There are also various approaches that could be investigated to improve the integration of the wiki and the eCHASE architecture. For example, templates or formatting could be enforced for structuring annotations, allowing these to be easily indexed and possibly fed into the metadata repository. There may also be a need to annotate multiple objects with the same information, for example that a set of photos depicted a certain person.

3rd Party Applications[edit]

The eCHASE web application is used to retrieve media and metadata used to build a content package. Third party applications are used to author a content package from an export of data created through the eCHASE web application. The issues in creating and managing the content packages are described in Section .

In addition to third party applications using the exported content bundle it may be possible for third party applications to be extended to access the search engine directly. For example eLearning applications such as Giunti’s product Learn eXact can access the SRW to search and retrieve media and metadata for use in an education environment. Likewise applications could connect directly to the Media Engine web service.

Example applications that may be used to create content products are Macromedia Dreamweaver, Macromedia Flash , and Adobe Publisher .

Visualization and Navigation Tool[edit]

Search, Navigate and Visualize[edit]

The box labeled "Search, Navigate, Visualize" in contains all software components that allow a user to search, navigate, visualize and export the data stored in the databases. This component provides powerful search and navigation capabilities for the user who will create content packages. The key components are:

  • Search and Retrieve Web Service
  • Semantic Web Search Engine
  • Web application providing users with a graphical user interface to the search engines
  • Light box for saving, organizing and exporting content from the unified database and media repository

More detail on the search engines and web application can be found in Search Engine and Web Application respectively.

The purpose is to give a brief description of the main aspects that have to be considered while designing and developing the visualization and navigation tools of the eChase system.

Most of the eChase navigation and visualization functionalities will be built using and integrating existing technologies. Once the eChase final users will be correctly identified, the best visualization and navigation tools will be chosen and integrated together for the satisfaction of the user needs.

At this point of the project documentation, the user requirements for the visualization and navigation tool will be described in terms of:

  • general consideration to be considered in order to design the best tools for the eChase users
  • general use cases that describe the tools

Use Cases[edit]

The use cases will be described using the following template:

  • Name: the name respects the goal of the user while using the system
  • Actors: (in this case) the main actor that starts the use case itself
  • Summary description: description of the functionality, given by the system, that is perceived by the user like an added value
  • Pre-conditions: conditions that have to be satisfied at the beginning of the use case
  • Main success scenario: description of the main sequence of interactions between the actor and the system
  • Extensions: variations respect the main success scenario
  • Errors: variations that lead to an error situation
  • Post-conditions: conditions satisfied at the end of the use case
  • Related use cases: references to related use cases
  • Open points: points to be discussed

The actors involved in the described use cases are:

  • User: the eChase User

UC 1: Navigation tool

Name Content Navigation
Actors User
Summary description Let the user browse the result of a content search.
Pre-conditions * The user has been correctly recognized by the system
* The user has performed a search action
Main success scenario The user can:
* Choose the type of navigation he wants to use for browsing the search result (alphabetical lists, dictionaries navigation, graphical tree navigation, …)
* Browse the search result using the selected navigation tool
* Visualize the selected content (see Content visualization use case)
* Select the content using the content aggregation tools (see Content aggregation use case, not included in the present contribution)
Extensions * The browser used by the user doesn’t have all the technical features (Java Plug-in, flash player …) needed by the navigation tool.
In this case, all the instructions needed for the correct configuration of the user browser must be given.
Post-conditions The user has reached the content
Related use cases * Specific navigation tool use cases, not included in the present contribution
Open points The use case has to be extended with the use cases related to the selected navigation tool

Once the navigation tools to integrate will be chosen, "specialized" use cases will be described. For example, simple browsing functionality based on alphabetical lists will have functions for ordering the results according to any field shown in the page itself. More "smart" navigation tool, like graphical trees for semantic web features, will have different level of customization (the number of links to show …).

The general use case diagram for this area is:

Use case 1: diagram

Navigation – Use Case 1

UC 2: Visualization tool

Name Content Visualization
Actors User
Summary description Let the user open the selected content using the right "player"
Pre-conditions The user has reached a content (from a previous browse or search action)
Main success scenario * The user open the content
* According to the type of content, to the content itself and to the user preferences (see User profile use case, not included in the present contribution):
? the right viewer is loaded
? the content is displayed
? watermarks (except video and keyframes) are applied
? metadata are displayed
? rights information are displayed
* The user can select the content for using it during his "content aggregation" activities (see Content aggregation use case, not included in the present contribution)
* The user can perform a search action based on the current content or metadata (see Content search use cases, not included in the present contribution)
Errors The browser used by the user doesn’t have all the technical features (Java Plug-in, flash player, …) needed by the visualization tool.
In this case all the instructions needed for the correct configuration of the user browser must be given
Related use cases * Specific navigation tool use cases, not included in the present contribution
Open points Display of video:
* how will we proceed?
* Will video-content be streamed or be (progressive) downloaded? If streaming-technologies through TCP or UDP protocols will take place firewall issues might be a problem.

Use case 2: diagram

Visualization – Use case 2

Back to D5.1orig System Specification