Curs 2010-2011

Enginyeria de Telecomunicació

Aplicacions Multimèdia (13340)
Mòdul Desenvolupament d'Aplicacions de Comunicacions

Credits:10,5               ECTS credits:   8

Total number of student hours:     200

Introduction to the project

This document is the teaching guide for the Application Development project, which is part of the first course of the second cycle of the Telecommunications Engineering studies of the Pompeu Fabra University. The Application Development project is done in the second trimester and it naturally continues the work carried out by the students in the Application Design project in the first trimester. The objective of the project is for the students to acquire hands-on experience with Information Technologies by developing a real distributed computer application.

The Application Development project follows the principles of Project Based Learning (PBL), where students learn by doing.  Central to this project is the notion of apprenticeship, which prevails over simple knowledge transfer. In this project, students will work together in groups of 4-5 to design and develop a prototype of a distributed multimedia application. Students will learn to apply and combine technology from several different areas: software engineering, image processing, video servers, user interfaces, databases, and testing. In addition, students will acquire more transversal competences, such as planning and managing activities, taking decisions, working in a team, or analysis and synthesis capabilities.

This guide describes both aspects directly related to the project to be developed (assignment, functionalities, etc) and aspects of the course functioning itself (activity planning, evaluation, etc).

Prerequisits for this project

In order to be able to participate in this project, students should have a working knowledge of mathematics, programming and telecommunications theory corresponding to the third year of Engineering studies.

More specifically, students should have the following competences:

•·         To be able to apply basic mathematics (analysis, statistics, algebra and logic)

•·         To have basic experience in object oriented programming (Java)

•·         To have good knowledge of the OSI and TCP/IP protocol stacks and their protocols

•·         To have basic experience in database modelling

•·         To have knowledge of XML

Moreover the student will be expected to have a positive attitude towards teamwork, and to be prepared to solve not only technical problems, but also to participate in project planning, management and reporting.

The results of each student will be evaluated in the following way:

•-          Individual evaluation (30%)

•§         Final exam (30%)

•-          Project (70%)

•§         Project deliverables (20%)

•§         Tutoring sessions (5%)

•§         Final project documentation (15%)

•§         Final project software (15%)

•§         Final project presentation (15%)

Note that, with respect to the Application Design project, the continuous evaluation component has been removed.  Moreover, given the practical nature of the project to develop, a new final project software component has been added.

In order to pass the project, students will need to satisfy all of the following:

•-          The overall grade must be 5.0 or higher

•-          The grade for the final exam must be 4.5 or higher

•-          The grade for collaborative work must be 5.0 or higher

In order to evaluate the final exam, each module will be evaluated separately and the grade for each module will be weighted according to the number of hours dedicated, as follows:

If all the members of a group get a grade of 6 (or greater) in the final exam, 1.5 points will be added to the final exam grade to all the members of the group.

The rules of the final presentation project are:

•-          The presentation file (for instance a powerpoint file) should be uploaded, at least one day before the presentation, to the folder in the corresponding folder of the Moodle space of the Application Development project.

•-          The order of presentation will be, as much as possible, the alphabetical order (group A, group B, ..., group G).

•-          The presentation will consist of three phases: project presentation, demonstration of the application, answering questions from the panel. The students responsible for each of these tasks will be randomly selected just before the presentation.

•-          Each final presentation will be 40 minutes (20 minutes for the presentation, 10 minutes for demonstrating the application and 10 minutes for answering questions from the panel). 

The final presentation will be evaluated by the following:

•-          Clarity of the presentation

•-          Credibility, convincingness

•-          Technical content

•-          Time control

•-          Answers to questions from the panel

These five criteria apply equally for the final grade of the presentation.

This section defines the global assignment for the project, as well as the contents of each individual module. 

Assignment

The global assignment, which is presented in this section (and its subsections), is pretty similar to the one used in the Application Design project of the first trimester, although there are several differences.

Although the general description presents and contextualises the project, the functionalities to be developed are concreted in section Functionalities. That section describes the basic functionalities that the project must necessarily implement. Moreover, other functionalities are suggested, although they are not required. Furthermore, the groups of students can add their own extra functionalities, which will be positively evaluated as long as they are justified.

By contrast with the Application Design project (where the study and comparison of different approaches and technologies for designing each component was promoted), the Application Development project clearly specifies the particular technologies to be employed to develop each component.

The main objective of the project is the development of a new distributed application which allows the user to share, edit and annotate digital pictures.

Each group of students will design and develop a distributed application which will allow the user to share pictures and videos. The application will work over an instant messaging platform. Thus, the application will run on each user's computer, in a peer to peer fashion.

The application will have a graphical editor providing basic image processing tools. In particular, the graphical editor will allow the loading, storing and visualization of images of different formats. For the JPEG images, it should be able to store the images in different levels of quality. The editor will also allow changing the images size (scaling), filtering (smoothing and edge enhancement) and modifying the contrast.

The application will allow community video sharing. Users will have access to the information related to the videos that other users have. When a user A decides to retrieve a video of other user B, the user A will ask the user B to stream the video through a point to point video transmission, instead of  directly downloading the video.

The system will also provide the capability to semantically annotate the pictures. Thus, each picture could be annotated with a series of tags or keywords. The system will allow two kinds of annotation: free annotation and annotation according to an ontology. By using free annotation, the user may assign any tag or keyword to a picture. By using the annotation according to an ontology, the user may annotate a picture only with tags from an ontology. The system will support several ontologies, in such a way that when annotating a picture not only the keywords must be provided but also the related ontology.

The kind of ontology the system will use is very simple. In particular, it is a kind of hierarchical taxonomy where there is only a type of relation: each child node is semantically "included" in its parent node. In order to illustrate it, next we show an oversimplified taxonomy of animals coded in XML:

<?xml version="1.0" encoding="UTF-8" ?>

<taxonomy>

<name>animals</name>

<subclass>

<name>animal</name>

<subclass>

<nombre>insect</nombre>

<subclass>

<name>mosquito</name>

</subclass>

<subclass>

<name>bee</name>

</subclass>

</subclass>

<subclass>

<name>mammal</name>

<subclass>

<name>lion</name>

</subclass>

<subclass>

<name>tiger</name>

</subclass>

</subclass>

</subclass>

</taxonomy>

The users must be able to search for pictures (both locally and on the network of applications) according to the tags the pictures have been annotated with. Two kinds of search must be provided by the application: free search and search based on ontologies. The free search will allow the user to search for pictures containing the tags or keywords that he specifies in the search engine user interface. The search based on ontologies will promote "smarter" searches. For instance, taking advantage of the above ontology of animals, a search where the user specifies the keyword mammal will find not only the pictures annotated with the keyword mammal, but also the pictures annotated with the keywords lion or tiger (that is, its children in the hierarchy).

A group of users of the application is composed of journalists who have a data bank of news including text and pictures. Each of these users maintains his own data bank of news that he receives from a provider. The news is received in a very simple XML format. Next we show an example of news:

<?xml version="1.0" encoding="UTF-8" ?>

<news>

<title>Colombian rebels 'free hostages'</title>

<contents>

<paragraph>Two women hostages have been freed by Colombian rebels, Venezuelan President Hugo Chavez has said.</paragraph>

<picture>chavez.jpg</picture>

<paragraph>Mr Chavez, who was involved in efforts to mediate their release, made the announcement after speaking to them, Reuters news agency reported.</paragraph>

<paragraph>Clara Rojas and Consuelo Gonzalez had been held for several years.</paragraph>

<paragraph>A similar attempt to rescue them was called off last month amid recriminations between the rebels and the Colombian government.</paragraph>

</contents>

</news>

The application will store this kind of news in the database, and the search engine will allow the user to access the pictures referenced in the news by typing a keyword in the user interface. The search engine will provide several search modalities:

•-          search for the pictures that appears in any news that contains the keyword in any paragraph

•-          search for the pictures where the following applies: the keyword appears in a paragraph which is adjacent to the picture (that is, the paragraph is located just before or just after the picture)

•-          search for the pictures that appears in any news that contains the keyword in its title

Two kinds of functionalities are distinguished: basic and others. The basic functionalities are mandatory (they must be implemented). The others are not mandatory, but they will be positively evaluated if implemented. Furthermore, the group of students can implement additional functionalities they consider convenient or useful. The latter will be positively evaluated as long as their convenience is justified, and their rate will depend on their degree of ingenious and difficulty.

• Basic functionalities

•- The application will support free annotation of the pictures

•- The application will support picture annotation according to concrete ontologies

•- The application will allow the user to search for pictures (both locally and on the network of applications) according to the tags the pictures have been annotated with. Two kinds of search must be provided by the application: free search and search based on ontologies (intelligent).

•-  The application will maintain, in the database, a data bank of news, and the search engine will allow the user to access the pictures referenced in the news by typing a keyword in the user interface. The search engine will provide several search modalities:

•o   search for the pictures that appears in any news that contains the keyword in any paragraph

•o   search for the pictures where the following applies: the keyword appears in a paragraph which is adjacent to the picture (that is, the paragraph is located just before or just after the picture)

•o   search for the pictures that appears in any news that contains the keyword in its title

•-   The graphical editor will allow the loading and writing of images including the JPEG format for which it should be able to choose the (storing) quality.

•-   The graphical editor will provide the following point to point functionalities:

•o        Change of contrast/luminance

•o        Edge detection

•o        Image enhancement (sharpening)

•o        Blurring

•-         Implementation of a point to point video transmission protocol between two clients.

•- The application will allow the user to (freely or according to an ontology) annotate a rectangular region of a picture with metadata. For instance, the region of a picture where a lion is shown could be annotated with the metadata lion.

•- The search engine will take into account the annotation of concrete regions both when searching and when visualising the results, showing the region of the picture particularly relevant to the search.

•-  The application will provide a module to access Picasa. The users will be able to maintain their contents in both the local repository (a folder in the hard drive) and a remote repository such as Picasa.

•-  The application will provide an authentication and authorization module. Users must have a Google account in order to use the application and share and store dynamic contents in Picasa (apart from storing them in local repositories).

•-  The graphical editor may include other point to point operations such as: histogram equalization, rotation, red eye removal, etc.

•-   Instead of using a point to point video transmission approach (as mentioned in the basic functionalities), a video over demand solution is proposed in order to give service to the users.

•-   Capability of performing real-time or off-line video transcoding in the video transmission, be it point to point or video over demand.

•-   Capability to rate the pictures (according to criteria such as photographic quality, interest, etc.).

The application that will be developed is composed of different modules (video, database, user interface and messaging system modules). All these modules have to be integrated for the proper implementation of a distributed interchange of multimedia contents.

The objective of this module is the integration of different modules contained within the application, using good software engineering practices. In order to achieve this objective, the students will use standard design patterns and frameworks recognised as appropriate tools for this type of implementation.

• Design of software architecture

The software architecture will be based on the design of the standard Model-View-Controller (MVC) pattern. This architecture must take into account the interactions among the different modules that comprise the application.

•  Functional requirements

•   Access module for messaging system

Google Talk is the messaging system that will be used to exchange contents. Google Talk will exchange:

•-          Search messages

•-          Result messages from the searches

•-          Point to Point content exchange.

•-          Interaction with the streaming server access module.

•  Database access module

 The application has to interact with the user's multimedia data content kept in the database. In order to achieve database-independence, contents in the DB will be mapped to application objects. Moreover, both the DB access and all the queries that are launched against the DB must be configurable.

•  User interface module

The Model-View-Controller (MVC) pattern has to be followed by the application by implementing the View within the user interface.

•  Picasa access module (optional)

Users will be able to have either local contents (e.g. hard disk folder) or a remote repository such as Picasa. Therefore, this module will be in charge of storing all of Picasa's contents.

• Image and video

• Objectives

The specific objectives of this block are:

•-          To apply basic image processing techniques: filtering, equalization, scaling, etc.

•-          To attain a general vision of the most used standards in image and video compression

•-          To understand streaming technology and related concepts

•-          To integrate the access to the video server into the project

•   Description

•  Image

The graphical editor of the application will allow:

•-          To load, store and visualize the images in different formats. Moreover, in the case of JPEG, it should be able to store the images with different levels of quality

•-          To change the size of the images (scaling)

•-          To perform lineal filtering: blurring and enhancement of the edges

•-          To modify the contrast

•  Video

The following objectives are envisaged for video streaming:

•-    To test and analyze different technologies such as VideoLan, DarwinStramingServer and JavaMediaFramework which provide video streaming capabilities.

•-    To test a point to point video streaming solution based on VideoLan and on JavaMediaFramework.

•-    To test a video on demand solution based on DarwinStreamingServer and on VideoLan.

•-    To test VideoLan capabilities for transcoding on the fly.

•-    To integrate the streaming solution within the application. For this issue a communication protocol between users is needed.

 •   Databases

•  Objectives

The main objective is learning to use XML databases by employing standard languages and libraries. In particular, learning to use:

•·         XPath and XQuery as languages to query XML documents and sets of documents

•·         XUpdate as a language to update collections of XML documents

•·         and the XML:DB api to access XML databases.

The database access will be integrated in the application development.  The integration of the database access with the communication and user interface modules is particularly important.

• Tools

The eXist database server will be employed. The graphical user interface provided by eXist can be used in order to learn and practice the use of XPath and XQuery. However, the XML:DB library must be employed for communicating the application with the database server when developing the project. Through this library, both XQuery and XUpdate messages will be sent to the database server. The library will be used from the Java programming language.

• Description

The collections needed to store the XML documents (containing the data required for the correct functioning of the system) will be created.

The queries, required for the proper working of the system (for instance, queries to obtain the results for the queries initiated by the user), will be programmed. Moreover, the required updates (for instance, operations to update picture metadata) will be also programmed.

The software, designed and developed for accessing the database, will be integrated with the rest of the project. The integration of the database access with the communication and user interface modules is particularly important. Actually, in the development cycle, these modules should be jointly designed, as they are interdependent.

• User Interface

• Learning objectives

Based on the user requirements gathered in the first trimester, and depicted in the work and sequence flow model, the main objective is the development of a UI prototype for a P2P application.

In order to achieve the goals of the UI subject, the student should master the following specific learning points:

•-          In depth comprehension of the user requirements for the target user and the methodologies best suited to obtain these requirements from real users.

•-          To know how to create the Information Architecture of the interface, based on the users' mental model (i.e. using the card sorting method) and avoiding mistakes from a system centric approach.

•-          Knowledge about how to plan, organise and run interview studies with paper prototypes.

•-          To analyse and interpret the results from the studies with paper prototypes and to filter these results into the UI design.

•-          To organise and run usability tests and to integrate the results of the test into a new version of the functional prototype.

The general goals of the UI subject are:

•-          The student will be able to gather user requirements and user feedback through studies with real users through all the phases of the design cycle; integrating the results with the technological requirements of the project.

•-          The students should master technological programming knowledge in order to be able to implement the UI of their application.

•-          The students should be able to search and read the previous literature relevant to their project and apply the information that they found according to what matters in each of the development phases.

The UI prototype should be done using the Java programming language and, at least, the SWING libraries.

• Subject structure

This subject structure has two parts:

•-          User centred design methodologies for the creation of the Information Architecture and the presentation of the information in the UI; the creation of the paper prototype, the running of the usability test and the analysis of the user data in order to inform the technological development.

•-          Programming of the UI using Java and Swing libraries.

Due to this twofold structure, there will be a separate evaluation of each of these two parts.

• Deliverables

Apart from the final project deliverable, there are 2 partial project deliverables. The next subsections describe each of these 3 deliverables as well as their related deadlines.

•First project deliverable (D1)

The first project deliverable will consist of a first prototype of the application, and the deadline to deliver it is 29 January at 12pm.

•  Integration and software engineering

•- Implementation of the module to access the messaging system so that the client can send queries to other clients and they return results.

•- The clients are able to download contents (optional)

Note: This implementation has to use Test Driven Development Technique (Mandatory)

•Image and video

•-          Results and conclusions of the JPEG coding practical session

•-          The source of a program which filters an image and stores it in JPEG format according to the quality level specified by the user

•  Databases

•-          Concrete model of the database (collections, xml's) defined for the project.

•  User interface

•-          Information architecture

•-          Paper prototype

•-          Plan for the test with paper prototype: specially the interview guide

•  Second project deliverable (D2)

The second project deliverable will consist of an extended prototype of the application, and the deadline to deliver it is 19 February at 12pm.

Note: the software corresponding to this deliverable must be demonstrated in an interview with the professors.

•   Integration and software engineering

•-          The clients are able to download contents (mandatory)

•-          Define a module to access the contents metadata. As a result of this module, the technology of data persistence should be transparent. Moreover, both connection to database and the actions sent to it must me completely configurable. The rest of modules which use this module will retrieve the metadata as objects. (Mandatory)

Note: This implementation has to use Test Driven Development Technique (Mandatory)

•  Image and video

•-          Source code of a simple example program that establishes a communication protocol using the messaging system between two clients A and B and that allows to show a video of A at client B.

•-          Analysis of the advantages and disadvantages of the possible available solutions for video streaming, both for point to point and video on demand transmission.

•-          Optional: results and conclusions of the MPEG coding practical session

•    Databases

•-          The first set of queries created for the application (in XQuery)

•  User interface

•-          Content of D1.

•-          The study with the paper prototype should have been conducted with at least 6 users

•-          Final results from the analysis of the study with the paper prototype.

•-          Plan for the usability test with the functional requirements: goals, metrics, guide of the test, sample of users, where the test would be conducted, etc.

•-          Source code of the user interface prototype

• Final project deliverable (D3)

The deadline to deliver the final project deliverable is 12 March at 12pm.

•  Integration and software engineering

•-          This part is optional. The groups that are interested should implement any of the two optional functional requirements previously described. Moreover, this deliverable can include the improvements done to deliverables 1 and 2 (D1 and D2).

•  Image and video

•-          Integration of the programs developed into the graphical editor of the application 

•   Databases

•-          Final model of the database, as well as the set of queries and updates programmed for the project.

•    User interface

•-          Content of D1 and D2.

•-          Documentation of the analysis of the results of the usability test with the functional prototype.

•-          Main problems found during the integration and tradeoffs that would have been needed in order to adjust the technical development to the user feedback and vice versa.

•-          General conclusions about the user interface: to link the user requirements in the first trimester with the lessons learnt during the second trimester.

•-          Functional prototype of the user interface, completely integrated with the application

• Quality control

•-          Report on the tests carried out (to other group).

• Deadlines

The next table shows the deadline to deliver each of the project deliverables

 • Methodology

The project's activities can be classified in five groups:

•·         Classes: these are sessions with all students together, aimed at knowledge transfer.  A class allows a professor to explain the basic theory necessary to solve the problems of his or her module.

•·         Seminars: Seminars are more interactive than classes, and are aimed at apprenticeship rather than knowledge transfer.  In a seminar, students present and discuss their work, or collaborate on solving a particular problem.

•·         Work outside the classroom: a large part of the time dedicated to the project will be spent outside the classroom.  As this is a project aimed specifically at apprenticeship and "learning by doing", students will be expected do much of the work of their project autonomously and outside class hours.  The work done outside the classroom typically includes reading articles or books, programming the application, writing the project's documentation, preparing presentations, etc.

•·         Supervision:  these are sessions where the students work on the project under the lecturers' supervision, so that the lecturers can solve the concrete students' doubts.

•·         Tutoring: each group has a tutor (one of the project's professors), which whom they will have a tutoring session of one hour every two weeks.  The purpose of tutoring is to review the group's progress and project planning, and to discuss any particular problems (especially non-technical problems) the project may have encountered.

All formal communication in the project will be done through the Moodle platform.  Only in exceptional cases will direct e-mail be used.

However, groups may use any means of internal communication they wish, including blogs, a website set up for the group, or online collaboration tools.  The UPF or the project's coordinator will not provide such additional tools, however.

Each group must maintain an archive where all the group's documents and results are stored. Such an archive can be a physical file or (recommended) an on-line document repository such as Google Groups/Docs, Blogspot, etc (the group is free to choose the platform). The group's tutor must have access to the group's archive. Sometimes the lecturers will ask the students to include new elements in the archive (for instance a summary of an installation process) and they can require the students to show the archive. Even though the contents of the archive won't be evaluated, its proper maintenance and update can be evaluated.  

Each group is required to produce a progress and planning report before each tutoring session, i.e. once every two weeks.  This report describes the results obtained in the two weeks, the hours worked by each group member on each task, the planning for the next two-week period, and any problems encountered during the period.  A template for the progress and planning report will be made available on the project's Moodle.

All group members must be present in all tutoring sessions.  If a group member is not available for the scheduled tutoring session, he or she should notify the group tutor at most one day before and try to find an alternative day and time for the tutoring session with the consent of both the group members and the tutor.  Students who fail to show up for tutoring sessions without valid reasons may be penalized (tutoring accounts for 5% of the final grade, see section 5).

After the first tutoring session, the group should send the first progress and planning report to the tutor. Since the second tutoring session, the group should send the report at least one day before the tutoring session.

During a lecture on any particular subject, the students can only work on this particular subject.

If a group decides to employ (for any of the areas) a technology which is different from the ones specified by any lecturer, they must ask permission to use it to the corresponding lecturer (and the lecturers of related areas). Anyway, even if the lecturers allow the students to use a different technology, the students will be the only responsible to guarantee the integration of the alternative technology with the rest of technologies.

The students are encouraged to use NetBeans as IDE for developing the application, as it is appropriate to visually edit Java user interfaces.

The way to deliver the application (as well as the previous prototypes) is uploading it to the space assigned to each group in the SVN server. The information regarding how to install and launch the application will be included in a README.txt.

The way to deliver any other kind of material (non-software), as for instance the project documentation, is uploading it to the corresponding folder on the Moodle sever.

Every time that a group of students uses literal pieces of material (whether it is text or source code) from external sources (Internet, articles, books, etc.) in its works (deliverables, presentations, application, etc.) the source of the used material must be explicitly cited.

It is absolutely forbidden to copy from other groups (whether the copied element is source code, documentation, presentation, etc). Also, remember that finding out a copy will mean failing the project for all the students involved in the copy, in addition to initiating the subsequent disciplinary proceedings.

Information sources 

•Integration and software engineering

Maven

Better Builds with maven:

http://gforge.nci.nih.gov/docman/view.php/27/7059/BetterBuildsWithMaven.pdf

http://maven.apache.org

http://pimpam.googlecode.com

Software metrics

Sonar: http://sonar.codehaus.org

Commons Logging

http://commons.apache.org/logging/guide.html

Smack

http://www.igniterealtime.org/downloads/download-landing.jsp?file=smack/smack_3_0_4.tar.gz

Authentication in Google applications

http://code.google.com/apis/accounts/AuthForInstalledApps.html

Picasa Web Albums Data API

http://code.google.com/apis/picasaweb/overview.html

API to access http resources

http://hc.apache.org/httpclient-3.x/

• Image and video

Java Advanced Imaging:

[1] http://java.sun.com/products/java-media/jai/downloads/download-1_1_2.html

[2] http://docs.sun.com/app/docs/doc/806-5413-10?l=es&a=load

Mpeg: http://www.chiariglione.org/mpeg/

Mplayer/Mencoder: http://www.mplayerhq.hu

VideoLan: http://www.videolan.org

JPEG: http://www.jpeg.org/

Digital compression of still images and video. R. J. Clarke, Academic Press 1995.

VideoLan 

http://www.videolan.org

DarwinStreamingServer

http://developer.apple.com/opensource/server/streaming/

JavaMediaFramework

http://java.sun.com/javase/technologies/desktop/media/jmf/

• Databases

eXist, http://exist.sourceforge.net/

XPath, http://www.w3.org/TR/xpath

XQuery, http://www.w3.org/XML/Query

XUpdate, http://xmldb-org.sourceforge.net/xupdate/xupdate-wd.html

XML:DB, http://xmldb-org.sourceforge.net/xapi/

•    User interface

•-          Barker, Iain. What is information architecture?. KMC Column. Step Two Designs Pty Ltd. May, 2005. [http://www.steptwo.com.au]

•-          Card sorting. http://www.nosolousabilidad.com/articulos/cardsorting.htm

•-          Card sorting. http://www.useit.com/papers/sun/cardsort.html

•-          Gaffney, Jerry. What is card sorting?. Usability Techniques series. Information & Design. 2000. [http://www.infodesign.com.au]

•-          Antoli, A., Cañas, A., Fajardo, I., Salmerón, L. Problemas asociados al uso inexperto de la técnica Card Sorting. [www.ugr.es//~ergocogn/articulos/card_sorting.pdf]

•-          Paper Prototyping: Getting User Data Before You Code. [http://www.useit.com/alertbox/20030414.html]

•-          Snyder, Carolyn. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. The Morgan Kaufmann Series in Interactive Technologies. Paperback.

•-          Preece, Rogers, Sharp. Interaction design: beyond human-computer interaction. Chapter  10. Introduction to evaluation. New Cork, 2002. John Wiley & Sons.

•-          Ebling and John. On the contributions of different empirical data in usability testing. Proceedings of the conference on Designing interactive systems: processes, practices, methods, and techniques New York City, New York, United States

•-          Rubin, Jeffrey. Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests.

•-          Mayhew, D.J. The Usability Engineering Lifecycle. Morgan-Kaufman, 1999. ISBN: 1-55860-561-4.

•-          Nielsen, Jakob. Usability Engineering (The Morgan Kaufmann Series in Interactive Technologies).

•-          Van Dijck. Peter. Information Architecture for Designers [http://iabook.com/]

•-          Wodtke, Christina. Information Architecture [http://www.eleganthack.com/blueprint/ ]

•-          Creating a GUI with JFC/Swing

http://java.sun.com/docs/books/tutorial/uiswing/index.html

•-          A Swing Architecture Overview

http://java.sun.com/products/jfc/tsc/articles/architecture/

•-          Programmer's Guide to the Java 2D API, http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d-bookTOC.html

http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf